项目进度的黑洞[1]

项目进度控制是项目 管理 工作中的重要一环，但现在的软件开发项目进度失控的例子却屡见不鲜，甚至进度的延迟总是在快到计划结束的时刻暴露出来，然后谁也不知道到底什么时候才能够结束项目。因此，业内流传着这样一句令人心酸的话：“规划规划全是鬼话，计划计划全是空话”。前不久，我就遇到了这样的一个实际项目。

　　“当进度报告上显示已完成90％时，项目就像遇到了一个黑洞，不断地吞噬着项目组队的时间。你说这是怎么了？”在A 公司工作的一个好友和我谈起时，话语中露出了深深的不解和抱怨。是呀，问题出在哪呢？根据我的经验，这是经典的“上梁不正下梁歪”问题，我认为要想对项目进度有效的监控与管理，必须抓好以下两个方面：

　　◆ 项目计划：计划的可行性和可操作性是进度监控的基础；

　　◆ 项目进度度量：对项目进度进行科学的度量，才能够获得项目的真实进展情况，并对项目计划做出相应调整。

　　首先，我们从90％，这个项目完成百分比的来源说起，项目经理在进度报告中写下这个值的时候，他的依据是什么？在这个项目后来的实际情况来看，当时90％的数字是有误的，其实只有50％左右，说明获取这个进度数字时出现了问题。为了更好地理解这个问题，我们来看一个生活中的实际例子：

　　假设我们驱车从厦门开往福州，在途中我们如何获得进度信息呢？对于熟悉这一路段的司机来说这个问题很简单，可以从窗外的景象来得知已经开到哪里，从而做出正确的估计。但是对于软件开发项目而言，项目团队就像进入了一个全新的征途，就像一个第一次驶过这一路段的司机一样，很难从“窗外的景象”来判断自己的进度。那对于这样的情况，该采用什么方法呢？对于司机而言，他能够通过路边的里程碑这一个简单工具。

　　来获知自己的进度信息，那么为什么项目团队不为自己设立一些这样的“里程碑”呢？

　　从这个简单的故事中，我们似乎已经可以得到一些启示，那么现在问题的关键在于如何合理地设立标识项目进度的“里程碑”，接下来我们来看看具体如何操作。

　　在一个软件开发项目中，需要完成的事务很多也很复杂，其复杂度足以让任何人无法对其工作量进行有效的估计，因此对工作任务进行分解是十分重要，这也是设定里程碑的基础。但如何进行工作任务分解呢？这也许也是困扰许多人的一个问题。其实工作任务分解可以从两个方面获得帮助：

　　◆ 软件开发生命周期：不管你打算采用什么样的软件开发生命周期模型，它都可以帮助你将整个软件开发项目进行阶段性的划分，而这些阶段就可以做你计划中很重要的里程碑。

　　◆ 软件开发需求：软件开发生命周期只给你的项目计划提供了一个框架，而软件开发需求才是其中的血肉，因此软件开发需求的整理与规格化，是细化项目计划的基础。也就是说，在制定项目计划时，应该在你选择的软件开发生命周期模型的框架下，结合软件开发需求来细分任务和设定里程碑。

　　回顾在这个项目中，他们考虑到项目的复杂性，采用了其熟悉的瀑布型（软件开发生命周期），并且在制定计划时，项目经理认真参考了许多经验值，将2个月的时间按照经验值中的百分比给需求分析、系统设计、编码实现、系统测试、部署交付五个阶段分别安排了时间。并且根据软件需求说明书的内容，列出了软件模块，

　　并根据每个模块细化了系统设计和编码实现的进度安排。一切看起来都很正常，但是为什么还是没有效果呢？我从他们对细节的回顾中发现了一些问题：

　　◆ 所有的项目计划均是由项目经理的估计值制定的，也就是说项目经理包办了整个项目计划的制定工作；

　　◆ 在项目计划中只是简单地在每个阶段的结束时间上标上了一个里程碑符号；

　　◆ 进度报告中的项目完成百分比，是直接通过“已经历的时间（2 个月）”计算得到的；

　　◆ 项目过程中，需求在变化，但项目计划却没有跟进；

　　◆ 项目延迟的主要原因在于两个方面：项目需求增加，以及系统设计和编码实现的时间都超过了原先的计划。