CMMI on line

计划不是用来看的，是用来执行的。PP讲述了如何做计划，PMC讲述的就是如何跟踪计划的执行并在实际情况偏离计划时采取纠正行动。

我们先看看SG1，SG1讲述的是如何根据计划来跟踪计划的执行问题。
SG1: Actual performance and progress of the project are monitored against the project plan.
中文大意是：根据计划，跟踪项目的实际性能和过程。

那么我们要跟踪计划什么内容呢？简单的说，计划里面写了什么东西，就要跟踪什么东西。我们回顾一下PP是怎样说项目计划有什么内容的？计划要有估算、进度、数据包的管理、技能准备、干系人的参与等内容，所以项目跟踪也需要踪以上内容。

SP 1.1 Monitor the actual values of the project planning  parameters against the project plan. 项目计划的参数就是指项目的范围、规模、性质、任务、工作量、费用等，每个企业都可以根据实际需要确定这些参数。在项目进行过程中，要密切关注这些参数的实际情况与计划估计的情况是否一致。

SP 1.2 Monitor commitments against those identified in the project plan. 简单地说就是要跟踪项目成员承诺的任务是否按时间按要求完成，跟踪其他干系人是否能完成承诺的事情，如：第三方是否能如期交付软件、硬件、接口等。

SP 1.3 Monitor risk against those identified in the project plan. 跟踪项目计划中已经识别出来的风险，要考虑风险是否发生了变化，同时也要考虑有没有新的风险产生。

SP 1.4 Monitor the management of project data against the project plan. 项目计划中计划了数据包的管理，实际项目进展中，要落实这些工作。什么是数据包，请参考“项目计划”这个帖的说明。

SP 1.5 Monitor stakeholder involvement against the project plan. 跟踪项目干系人的参与。如计划了什么时候要开始什么任务，什么时候客户要开始准备系统环境等，需要依据计划去跟踪。

SP 1.6 Periodicall review the project's progress,performance,and issues. 定期检查项目的进度、性能和问题。定期并不是指按照一定周期，只有有计划去检查，在某些时间点去做检查，就叫定期。另外什么是项目性能？简单的说就是项目按计划执行的实际能力，如任务完成能力、项目组成员的实际水平、文档的质量、代码的质量等。那什么是“issues(问题)”呢？凡是影响项目不能按计划进行的情况，都是问题。

SP 1.7 Review the accomplishments and results of the project at selected project milestones. 在项目选定的里程碑检查项目情况。项目里程碑一般会是：需求确定、架构设计完成、软件发布等关键路径上的关键节点。SP1.6强调的是定期去检查项目状况，SP1.7强调的是要在关键节点检查项目状况，两个SP是有某种程度的重叠的。

SG1讲述的是如何跟踪计划执行的，而SG2讲述的是当实际情况明显偏离计划的时候，要采取纠正行动。
SG2: Corrective actions are managed to closure when the project 's performance or results deviate significantly from the plan.
中文大意是：项目的性能或者结果明显偏离计划时，要采取纠正措施保证按计划进行。

SP 2.1 Collect and analyze the issues and determine the corrective actions necessary to address the issues. 收集和分析问题，并确定必要的纠正措施来解决这些问题。

SP 2.2 Take corrective action on identified issues. 针对识别出来的问题实施纠正行动。

SP 2.3 Manage corrective actions to closure. 管理纠正行动保证问题被解决。

实际情况与计划情况有偏差是正常的，原因可能是计划本身做得不太好，也可能是实际工作没有到位。SG2强调的是要分析原因，找出问题根源，采取适当的行动，解决问题，使项目按照计划进行。

通常情况下，偏离计划的情况大多数是进度推迟、预算变大等超出计划估计的情况，作为项目管理者不应该轻易改变计划，而使计划与实际一致，而是应该努力改善实际情况，否则计划的意义就丧失了。但凡事也有例外，确实有可能做计划的时候定了一个“不可能完成”的计划，这是就确实需要变更计划。但凡是涉及到预算变更、关键节点推迟等关键变化，公司应该制定严格的变更控制制度，公司高层应该参与这些关键变更的评审，以保证计划的严肃性。

在3级的IPM还有4级的QPM，做项目计划的时候合理性会越来越得到保障，另外用于管理项目的参数也会越来越多，并且会有量化的管理目标。详细的内容以后再论述。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

好帖！终于见到可以看得懂的没有什么大理论的好文了！

请问对于项目进度的修改怎样监控，当项目进度修改了以后，对于这次修改需要有哪些记录？什么方式记录？只看配置管理的版本控制吗？

---

CMMI是一个刚出炉的香喷喷的小蛋糕，我要细细的闻，慢慢的品尝，把它吃到肚子里。

记录什么内容，怎样记录，根据企业需要确定，CMMI没有规定一定要记录什么东西。我们做配置管理也不是为了做配置管理而做配置管理的，有用的东西才做。

一般来说，没有必要去记录进度的全部修改痕迹，如果觉得就当前版本就可以了，是不需要记录以前版本的。当然，也可以只记录有价值的版本。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

请问PMC和PPQA两者都有监督和采取纠正措施并跟踪关闭。那么这两者的区别在哪呢？
还有PPQA只是监督某项成果有没有而不去管成果的内容，是否能有效保证过程的执行呢？比如在酒瓶子里装进了醋而QA只检查有没有瓶子。

---

CMMI是一个刚出炉的香喷喷的小蛋糕，我要细细的闻，慢慢的品尝，把它吃到肚子里。

PMC是对照计划跟踪计划的执行情况，如任务是否按时、按质完成，有什么困难，要克服什么技术问题，计划跟踪要处理这些问题，保证按计划进行。

PPQA只跟踪过程的执行情况，只检查项目组有没有“遵纪守法”，至于任务是否按时完成，为什么不能按时完成，都不是QA的职责，QA相关的职责只是检查项目经理是否进行了PMC的活动。

有这样的一些误区，很多不喜欢做项目管理的项目经理，把计划跟踪的事情交给QA来做，以为这就是QA的职责，这是不对的，这些事情都应该由项目经理来做，QA来做其实是“狗拿耗子”，QA不是计划的制定者并且没有相关知识和技能，不可能做好计划跟踪的工作。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

请问对于项目成员提交的个人周报怎样度量其所填的内容，比如工作量分配，是否真实呢？

---

CMMI是一个刚出炉的香喷喷的小蛋糕，我要细细的闻，慢慢的品尝，把它吃到肚子里。

你提的这个问题背后可能隐含更严重的问题，先回答一下你的问题：
项目经理一定是知道这些内容是否真实的，QA就难以判断是否真实，其实也不应该去怀疑真是性，我们就认为每位员工都是诚实的。
另外，通过工作产品的产出、CM报告、测试报告等，都可以从侧面了解真实性的。

如果整个项目组一起来欺骗QA，提交假数据，这个问题就很严重的，解决的办法不是想办法去查证他们是否提交真实数据，这样只会恶性循环。

公司的文化氛围、风气可能有问题，一般来说，不要以过程执行情况作为项目考核依据，至少在过程改进刚开始的阶段，应该鼓励大家诚实、多发现问题，一起来改进，否则很容易出现“造假”的情况。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

感谢您无私的贡献！！！

PM说“我们这个项目跟别的项目不一样，有技术探险，没有现成的技术拿来用，要自己摸索，而且项目组成员还要参与别的项目，所以工作时间和工作量都很难估算。还有，所以不做估算了，”这样做是合理吗？qa有没有好的发放去控制，或者是引导项目组？

 

你提到的情况其实很常见，但这个时候更加需要做估算，估算本身也是一个由粗到细，逐步逼近的过程。
最开始的时候不确定因素很多，没有关系，将这些不确定因素都记录下来，持续跟踪，最开始的时候可以大概进行一个估算，当不确定因素发生变化时，再细化估算。
事实上每个公司都会对项目有基本的期望的，问问你们的大领导，对这个项目有什么方针性的要求，例如成本不能超过多少，什么时候要发一个怎么样的版本，什么时候要验收等等。要在公司要求的框架范围内，将项目的各种不确定因素控制好。
计划是用来控制变化的，而不是因为有变化而不做计划，计划不是一成不变的，是因应变化而变化的。

作为QA要做好引导工作不容易，需要你本身就是比较资深的项目管理才能有效地对PM进行教育，光是说估算的大道理，会很容易让PM觉得烦，认为你的工作对他没有帮助，所以就会说一堆你似懂非懂、好像有道理又好像没有道理的说法和理由来打发你。看看你的的领导，还有那个PM的直接领导，是否对这些问题认识比较深，让他们出手教育PM比较好，从中你也学习一下工作方法和提供工作水平。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我是一名初学者，找了很多关于CMMI方面的资料，但是，都让我很难理解和接收。而这里我觉得资料很齐全，分析问题透彻，非常适合我们初学者，而且对会员提出的回答很及时。谢谢

我来就是要问这个问题的，原来专家已经考虑到了。

我原来一直以为PMC也应该由一个独立于项目组的人来做呢。因为项目成员有可能为了使项目进展看起来正常而隐瞒事实，不如实记录项目的进展。现在的情况是，项目经理肯定是开发出身，多少都有些重技术、轻管理的思想，觉得记录项目性能什么的都是虚的。但专职的管理人员虽然一般也是开发出身，但是毕竟经过了一个较大的角色转变，能够理解收集项目性能数据的意义。

我们公司现在是有一个专职的项目跟踪员，来跟踪所有项目，但是一个人跟踪多个项目，也不可能去了解项目为何拖延，他的工作只是记录、上报。

作为QA，我也要评价项目的执行过程。但我这个QA也是一个人跟多个项目，不可能去评价每个项目的过程。因此其实我只是对每个项目的工作产品进行评价。我觉得这样太流于表面了，根本不能对项目质量有什么控制。

所以我想可不可以由一个人同时做PPQA和PMC的工作呢？

zhangcb:

PMC是对照计划跟踪计划的执行情况，如任务是否按时、按质完成，有什么困难，要克服什么技术问题，计划跟踪要处理这些问题，保证按计划进行。

PPQA只跟踪过程的执行情况，只检查项目组有没有“遵纪守法”，至于任务是否按时完成，为什么不能按时完成，都不是QA的职责，QA相关的职责只是检查项目经理是否进行了PMC的活动。

有这样的一些误区，很多不喜欢做项目管理的项目经理，把计划跟踪的事情交给QA来做，以为这就是QA的职责，这是不对的，这些事情都应该由项目经理来做，QA来做其实是“狗拿耗子”，QA不是计划的制定者并且没有相关知识和技能，不可能做好计划跟踪的工作。

如果把项目监督与控制（PMC）单纯看成进度的跟踪那也太简单了，正如楼主帖子里所说，PMC涉及的是整个项目组，包括开发人员、QA、高层、协同开发组、客户和其他支持人员等等，是大家互动的一个过程，跟踪项目进展只是PMC的一个SP而已。PMC是对计划的跟踪，这就要求PP的能力，包括QA的计划、SCM计划、组间协调计划等等等等，如果一开始除了开发就没有其他计划，也谈不上什么PMC，直接叫进度监督好了

进度跟踪也不是让组员报告一下今天大概完成几个这样，日报或周报一般来说要报告这些内容：进展（当日/累计/计划累计/全体），bug解析进展（总数 / 解析中 / 确认待），遗留课题，联络周知事项，项目经理除了跟踪开发计划，还要跟踪其他计划，比如，原来QA计划到目前为止要检查的项目检查了没有，QA指摘对应了没有，未对应指摘的理由，计划中某日我要提供给其他项目组的程序能不能按计划提供，如果不能按计划提供，要联络其他项目组的leader，协调解决方案，某日计划由其他项目组提供给我们的程序是不是能按时提供，如果不能按时提供，我要不要变更计划或者采取其他应对措施，SCM有没有按照计划执行，有没有新的风险产生，原来的风险在我的措施下有没有减轻或者关闭，原来计划中的输出物有没有输出，客户突然提出来访，对我的计划有没有影响等等等等，列举不完，这些只是写出来让人直观的了解一下，绝对不是一个人能搞定的。

项目经理的主要责任是制定计划和执行计划，要执行计划自然就要跟踪计划。如果说项目经理制定了计划，就让别人去跟踪，或者说项目经理自己跟踪自己制定的计划时会造假，这样的项目经理可以说是完全不及格的。有项目管理经验的人都会知道，项目跟踪与控制的工作，项目经理肯定是首要负责人。

当然，项目经理可以有一些助手协助他跟踪项目进展情况，一些大的项目团队，项目管理是一个team的人来做的，但发挥核心作用和决策作用的，仍然是项目经理。

至于为什么会出现项目经理不想跟踪计划，如果自己跟踪，他们很可能应付甚至造假，可能有这些原因：
1.项目经理水平不够，或者是根本没从技术人员的身份转变过来。
2.公司的过程可能比较僵化、不适用，项目经理不想执行。
3.项目经理的顶头上司监督不严，可能项目经理的顶头上司也是一个喜欢搞技术不喜欢搞管理的人。
针对不同的原因，就要采取不同的改进办法，你们可以仔细分析一下，出现这些问题的根本原因是什么，对症下药。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

谢谢，这么晚了还来回答问题。：）

如果让您给项目经理的工作做一个定义，技术和管理各占百分之多少？

因为目前我所在的团队就是专做项目管理的，我的领导认为项目经理95%的经历应该放在技术上。

“绝对不是一个人能搞定的”，再结合您上面所说的，您的意思是不是PMC的工作一部分由项目经理完成，另一部分还要有一个专职的项目跟踪员？

jessise:

进度跟踪也不是让组员报告一下今天大概完成几个这样，日报或周报一般来说要报告这些内容：进展（当日/累计/计划累计/全体），bug解析进展（总数 / 解析中 / 确认待），遗留课题，联络周知事项，项目经理除了跟踪开发计划，还要跟踪其他计划，比如，原来QA计划到目前为止要检查的项目检查了没有，QA指摘对应了没有，未对应指摘的理由，计划中某日我要提供给其他项目组的程序能不能按计划提供，如果不能按计划提供，要联络其他项目组的leader，协调解决方案，某日计划由其他项目组提供给我们的程序是不是能按时提供，如果不能按时提供，我要不要变更计划或者采取其他应对措施，SCM有没有按照计划执行，有没有新的风险产生，原来的风险在我的措施下有没有减轻或者关闭，原来计划中的输出物有没有输出，客户突然提出来访，对我的计划有没有影响等等等等，列举不完，这些只是写出来让人直观的了解一下，绝对不是一个人能搞定的。

我认为项目管理没有所谓“专门”做的，项目需求、设计等工作管理，需要管理者很熟悉需求和相关的技术，否则无法谈管理，任务划分、任务跟踪、检查任务的完成情况、解决一些技术问题等，都不是“纯”管理的事情。
微软有产品经理和程序经理两种管理类的角色，产品经理负责管理客户需求、控制产品质量、监控项目整体进度，而程序经理要指导程序员工作，分配好具体的技术类工作。而很多公司这两种角色会是同一个人。

至于技术和管理各占多少比例的问题，回答这个问题先要定义什么叫技术工作，什么叫管理工作。而我认为项目的管理工作，很多是业务管理工作、技术管理工作，这些工作是相当重要的。技术和管理，我认为都占100%，任何一方面不做好，项目都不可能成功。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

你提到的产品经理和程序经理的设置，很像IPD了，这是一种管理上的安排，属于企业高层才能决定的问题。而且产品经理的职位是高于程序经理的，产品经理可以管程序经理。

如果在一个公司里，行使产品经理职能的人对行使程序经理职能的人没有约束力呢？那这个产品经理该怎么开展工作？

看了你的答案，基本上我知道问题出在哪里了，因为当前我们公司的项目管理就是“专门”做的。真正的项目经理被解放出来跟程序员一起开发去了。