控制好项目进程中的里程碑

案例


　　公司新成立，管理部负责按照CMM2级关键过程域制定了软件开发的规范，在推进规范执行的过程中，希望先选一个项目组作为试点。小王刚从系统分析员的 岗位上被任命为项目经理，负责一个物流货运系统的软件开发项目。经历过以前项目开发的混乱过程，小王希望自己的项目经理生涯能有一个良好的开端，于是，主 动申请把自己的这个项目作为试点。

　　按照规范要求，小王首先编制了项目的开发计划。管理部在制定规范的同时，也编写了相关文档的模板。所以参照开发计划模板，小王很快就完成了项目计划的编写。按照计划模板的说明，确定了需求分析、设计、编码实现、测试和投产五个里程碑。

　　由于开发人员对业务比较熟悉，需求分析阶段按时完成了。项目能够按照计划顺利进行使小王很高兴。这时，管理部通知小王安排第一个里程碑活动，需要对阶段成果，即需求分析说明书进行同行评审。这时小王才发现没有在开发计划中考虑里程碑活动的时间开销。

　　在管理部的指导下，小王重新调整了计划，并且组织了对需求文档的同行评审。评审通过后将需求文档归入项目受控配置库。这样，在以后的项目过程中如果要对需求文档进行修改，必须经过一定的变更流程。

　　在项目开发计划中，小王还明确了后面每个里程碑的活动内容和进度安排，不同的里程碑有不同的活动内容。

　　经过多方努力，小王的项目终于按期完成了。公司也开始全面推行新的开发规范。回顾项目的开发过程，小王感到里程碑活动虽然能够及时发现项目出现的偏差，但是也耗费了自己很多精力，增加了不少工作量。

　　项目里程碑，就是在项目执行过程中定义一系列的检查点。里程碑更多地是为了让公司管理层和客户及时了解项目的执行情况。而里程碑活动是需要增加项目开销的，所以对于项目经理来说，工作量只能是增加而不是减少。

　　也正是因为里程碑是需要工作量开销的，所以过度的监控管理会对项目的正常工作产生干扰。因此里程碑的设置要视项目的具体情况而定。

　　我们知道不同的开发模式有不同的阶段划分。象小王的项目采用了传统的瀑布模式，一般划分为需求、设计、开发、测试、验收等阶段。如果是RUP模式一般 划分为创建、构造、实现、测试等阶段。每个阶段结束的时间点，一般都会定义一个里程碑。如果项目复杂，还可以在一个开发阶段中定义多个里程碑。总之，里程 碑的定义是比较灵活的，要根据项目的复杂度和时间跨度等具体情况而定。如果都按照一种模式确定里程碑的话，实际操作起来会很困难。比如一个项目要求在一个 月内完成，这期间还按照要求设定四五个里程碑，在实际操作中就很难完成，因为里程碑活动本身也需要时间和资源的投入。再比如，一个项目的开发编程阶段需要 三个月，还按照固有模式在阶段结束后安排里程碑，就可能导致项目的失控。所以，项目经理在里程碑的设定上要根据项目实际情况，在组织标准流程的基础上，加 以适当剪裁。只有在项目计划阶段，制定出合理的里程碑，才能够保证项目执行过程中对里程碑的有效控制。

　　首先，在里程碑的设定上，项目经理要综合考虑以下几点因素：

　　1.可交付成果。在里程碑应该有阶段工作产品，以便检验工作的成效。

　　2.时间跨度。里程碑设定要考虑适当的时间间隔。过度的检查会影响项目正常工作，增加项目成本。

　　其次，里程碑设立的是否合理，应该有专人负责检查确认。现在很多IT企业成立项目管理办公室或项目管理部，专职负责项目计划的跟踪和监控。设置里程碑 的目的，就是为了及时跟踪并发现项目中的问题，根据实际情况调整项目计划，使项目始终处于组织受控的状态，从而减少项目失败的风险。要让里程碑发挥作用， 也必须有专人根据项目计划，负责协调组织管理里程碑活动，使里程碑定义的管理活动得以有效地完成。

　　各个里程碑的输出产品不尽相同，管理活动也会有所差别。一般来说，在里程碑活动中通常需要完成下列工作。

　　计划更新：在项目计划中确定的进度安排，尽管使用了各种科学的估算方法，但也仅仅是我们的一种估计。项目实际运作中碰到的情况千变万化，项目实际进度 不可能完全按照事先的估计完成，总会或多或少存在偏差。里程碑的一项重要工作就是按照项目实际完成情况，对剩余的工作量和计划进度进行重新估计，并修订以 形成新的项目计划。另一方面，项目本身具有逐步细化的特征，随着项目的进展，我们对项目的估计也趋于精确。所以，为了保证项目计划的有效性，项目经理项目 必须定期更新项目计划。里程碑就是项目计划变更的关键时间点。

　　需求跟踪：在IT项目中，用户需求的变更随时都可能发生。应该说，需求变更是IT项目执行过程中的正常现象，作为项目经理要关注的焦点不是减少变更， 而是如何有效地管理需求变更。作为需求变更的管理基础，必须对项目需求进行跟踪管理。通过需求跟踪，我们可以获得与一项需求有关的程序及其中的单元/函 数。当需求发生变更时，可以确认受影响的程序及其中的单元/函数。反之，当我们因对一项需求或设计进行变更，而修改某单元/函数的代码时，我们可以获得可 能影响的相关需求。

　　文档更新：在里程碑活动中，要及时对发生的变更进行记录，更新有关的项目计划和工程文档。现在有很多轻量级的开发模式，提倡尽量减少文档。尽管如此，保持文档的更新，及时收集汇总项目过程中产生的文档，也是里程碑中一项重要的工作。

　　阶段配置管理：项目工作产品到达里程碑，需要从开发状态转入受控状态，需要针对不同的工作产品类型进行配置审计和基线化工作。不同组织都会有自己的执 行规范。一般来说，对于文档配置项，可能需要组织评审活动；对于代码配置项，可能需要组织测试活动。经过这些评审或审核的流程后，相应的工作产品要及时进 行基线化。这样才能保证项目的有序进行，作为软件组织才能真正控制住开发的成果。不会因为项目组人员变动或其他突发事件的发生，造成项目工作的损失或项目 进度的延误。

　　阶段质量保证：里程碑也是质量保证人员介入的时间点。对项目的考察，除了检查项目阶段产品的质量和项目执行的进度之外，项目组的过程质量也是重要的评 价因素。适当安排质量过程审计，对提高项目组成员的质量意识，提高项目组执行组织质量过程规范的力度，有很大的好处。当然，不是每个里程碑都需要安排过程 审计。

　　软件度量：里程碑也是评价项目组阶段成果的时候，要准确地评价成果，必须有一定的度量数据基础。作为组织的知识积累，也有必要及时收集项目的工作量、 工作效率、计划执行质量、工作产品质量等度量数据。不同水平的组织对度量的要求不同，但是这并不意味着不要度量。虽然在CMM中度量是4级的关键过程域， 但业界经验告诉我们，越早进行度量，越有利于企业产品质量的提高。

　　阶段总结：现在的软件项目越来越依赖开发团队的协作，不同的阶段会有不同的人员参与。及时组织项目成员进行阶段总结，是团队建设的重要环节。一方面， 项目成员通过总结，可以加快提高自身的能力；另一方面，软件组织通过对阶段总结内容的收集和分析，能够构建组织的知识库，提高这个组织的能力。

　　管理评审：通过对里程碑各种活动结果的汇总和综合，组织能够多角度、多层次地了解项目执行的情况。这样才能对项目的状态进行正确地评价，并根据实际需要调整对项目的投入力度。

　　在实际工作中，并不是每个里程碑都要进行这么多工作。在制定项目计划时，应根据每个阶段的特点，对里程碑活动内容加以剪裁。里程碑实际上是为组织级提 供了解项目状态的视角，过多的工作需要相应的资源和时间投入，同时也会影响项目的正常进度。所以在实际工作中，要掌握好两者之间的均衡。同时参与里程碑活 动的质量保证人员和项目管理人员，应该根据项目计划，提前做好相应的准备工作，尽可能减少里程碑活动的时间开销，提高里程碑活动的有效性。项目经理也应该 充分考虑里程碑活动的重要性，组织项目成员积极配合。只有多方积极配合，才能真正做好里程碑工作。