项目生命周期模型的使用与制定 推荐

[align=center]生命周期模型的使用与制定[/align]
[align=center] [/align]
在实施CMMI的改称改进之中，生命周期模型是一个比较陌生的概念。在CMMI二级的“项目策划”（PP）过程域里，sp1.3就要求项目定义生命周期。我们一般的做法，就是在项目计划里写上项目是使用什么“瀑布模型”，或是“迭代”、“增量”之类的名称，然后评估的时候，评估组就认为这样就满足了这个特定实践的要求。

有一部分人就一直在思考：“如此为什么项目策划可以有效？”

其实“生命周期模型”这个概念，是一个非常普遍的管理手法。生命周期不但可以在项目里使用，产品也明显有生命周期。其他项目的活动里，都可以用生命周期来考虑，比如一个变更请求单，就可以有一个“提交”、“已指派”、“在处理”、“等待验证”、以及“审批通过”等等的阶段。甚至在设计里，一个对象，很多时候也可以用生命周期来进行分析与设计的活动。有一次我把生命周期的概念，引进一个任务流程管理系统的时候，开始大家不很明白，后来证明这样让每一个在系统里的任务的状态都可以表达得非常清楚明确，以前客户要求的报告，我们都开发不了；有了这个概念，就经常可以高效地满足客户的报告需要了。

那么，项目的生命周期意义在哪里？我们要记住，所有这些概念，都应该对项目管理有帮助的。否则我们的理解是有问题的。

首先，让我们看看项目策划面临的问题。

立项的时候，项目只有一个比较模糊的需求（客户需求），项目需要按照这个需求，策划出一个相对合理、可靠的计划，并且这个计划的成功机会是比较高的。
这是策划的含义。策划也是管理的基础。我们员工的能力很强，不会比任何其他国家民族的员工差。但是我们的效率比较低。原因不是在能力，而是在管理。我在中国观察到的，就是我们的管理非常不科学：是领导说了算，然后经理们就把任务定下来，有小部分项目连计划都没有，每周每周的定任务，逐个逐个地盯着任务的进展。这就是管理。我们对很多很多项目过程中的因素都不明不白。生命周期模型总结了一大部分的策划因素：有些是策划项目时需要考虑的，有些是对策划有帮助的，都已经包含在生命周期模型的概念里。所以项目生命周期模型是非常重要的一个概念。

生命周期模型又如何提高策划能力？

生命周期模型的第一个概念就是“阶段”。“阶段”在很多方面对我们提供了很多帮助。

项目只有“客户需求”，就只能做一个粗略的策划。我们发现，项目的进度和工作量的主要决定因素，就是客户需求的内容：规模与复杂度。按照客户需求策划不简单。要提高策划的质量（做到计划可以预测项目的绩效），我们需要一些依据。个人经验肯定有帮助，但是记录好的个人经验更有帮助。这就是为什么成熟的团队一般都重视文档记录的原因。其中有一个发现：项目的阶段的时间和工作量的分配，是相对稳定的。这是一个非常有用的知识。一来，“阶段”提供了一个比较实在的依据，让策划的风险降低了。二来，如果开始的估算不准确，项目最多等到第一个阶段结束的时候，就可以有一个比较准确的计划了。

我要在这里谈一下“里程碑”。里程碑是一个管理点。没有大小的强制准则。只要项目觉得有管理意义的，就可以制定一个里程碑。但实际来讲，把里程碑和阶段连接起来，有一定的好处。比如，每一个阶段，都可以做一个反馈会议，检查检查有什么经验教训、有什么可以改进的地方，都是很好的。高层一定应该有一、两次比较严格的检查。这些都是里程碑的作用。

每一个阶段都有特殊的输出。

一般过程管理的人，都着重阶段里的“活动”。这样比较容易理解。因为员工进行了这些活动，就一定会有这些输出。就是因为这样，要管理的事情就多了。我发现如果我们把重点从“活动”转移到“工作产品”，就是输出，而不特别关注阶段里的活动，我们更能得到高质的输出，同时管理的工作量也降低了。经理们的活就没有这么累了。

如果大家对“生命周期”这个概念可以灵活使用的话，就很容易看到大部分的工作产品的开发过程，都可以用阶段来描述的。就是说，每一个主要的工作产品，都有自己的生命周期的。比如：需求文档的生命周期包括：抽取需求、分析、分配、描述等阶段。项目里面的另一个考虑，就是可以利用这些工作产品，来制定项目的WBS。这样的WBS，就可以反映项目的工作范围，满足了 CMMI 项目策划的 sp1.1的要求了。

关注工作产品比较关注活动有用的另一个原因，就是一个工作产品，可以有好几个开发方法。比如说，需求的抽取，可以用访谈、问卷、交流会议、专注小组、市场调查等等方法。按项目的需要，可以使用某一个或是任何得一组（好几个）方法来抽取需求。这样，员工就有机会发挥他们的能力，激动他们的热情。

每一个阶段有了它的必然输出之后，就需要制定这些输出的质量准则与要求。这个很重要。这是管理是否有效的一个重要环节：每一个阶段的关键输出，都是高质量的。需要留意的，是这些输出的质量指标，可能按不同的开发方法不同而有所不同。比如：如果项目是按瀑布模型管理的，那么需求阶段的输出，“产品需求”与“系统方案”就需要非常明确。反之，如果我们是使用迭代方法的，项目就不能要求非常明确细致的“系统方案”，但其中也需要有一定的平台内容，同时包括增加功能的机制，等等。

那么，在部分关键的阶段完结之后，高层就可以审核项目的进展情况，并评价项目未来的风险。

所以说，生命周期其实就是一个项目的整体管理模式。而项目生命周期的体现，就是项目计划。

在CMMI第二级的时候，项目经理可以按自己的经验，制定项目的生命周期模型，作为管理项目的依据。模型包括：

阶段定义

每个阶段的输出（工作产品）

每个工作产品的可能开发方法

每个工作产品的内容要求和质量指标

高层在哪些里程碑进行审核。

这样，项目就可以制定项目的WBS，有依据地做出项目的粗略估算。项目经理就自然地对整个项目的进展，有了一个全面的掌握。这就对策划项目有了依据，不用再好像以前一样，逐周逐周地指派任务。成熟的策划，就是有了整体（从现在到项目完结）的项目策划能力。项目的生命周期模型，对这个活动非常关键。

在CMMI的二级，每一个项目都制定自己的生命周期模型。因为我们只能够依赖项目的几位骨干人员的经验。但是到了第三级的时候，这些经验，都应该积累到组织的层面。EPG组应该收集了一定数量的，在项目实施过的生命周期模型，按产品类别、技术、员工经验、市场要求、研发目标等等因素分类，定义好一套（好几个）有效的生命周期模型，让以后的项目选择使用。比如：研发新产品，需求与设计阶段，可能需要大一点比例的时间与工作量。但是维护项目，重点就可能在实施与验证阶段上面。

所以，EPG制定组织的标准生命周期的时候，应该是根据项目个别积累的经验来制定的。如果EPG没有项目实施的经验，制定出来的标准规程，项目使用的时候就未必是有效的。同时，这些定义，也应该有相应的绩效数据。又因为这些生命周期，是按多个因素分类的，每一个项目可以根据自己的产品与目标选择一个适合的生命周期。在每一个阶段里，可能有不同的方法可以选择。选定了方法之后，还可以按项目的特征，调整方法的细节。项目这些选择，就是“裁剪”。这些选择的依据，跟这些标准生命周期的分类关系非常密切，就是“裁剪的准则”。

这里对“生命周期模型”的概念，做了一个简单的介绍。如果大家有什么实际的问题，欢迎提出来讨论交流。