经典项目过程导致失败的原因

经过 20 年的应用，人们发现经典项目过程存在很多问题，这迫使人们研究它存在的问
题，以期找到解决方案。经典项目管理最困难的问题是项目难以规划，做出来的计划往往会
出错。于是开发小组往往走向两个极端：要么是不做规划，这样的小组根本无法回答“你们
什么时候能完成？”这样的问题。要么是在计划中投入大量的精力，直到自己确信计划是正
确的，但这种“正确”往往是自欺其人的，这种计划可能更全面，但不意味着更准确或更有
用。因为软件的特点不确定性是始终存在的。
尽管经典项目管理把费用、质量（功能目标）、时间设定为最重要的三角约束，遗憾的
是很多人的研究都告诉我们，传统方法不一定会得出满意的答案，下面是很多人做的研究结
果：
大约 2/3 的项目会显著超出费用预算（Lederer and Prasad 1992）。
产品中 64%的功能很少或者从不会被使用（Johnson 2002）。
一般项目花费的时间会超出进度表 100%（Stndish 2002）。
这就迫使我们仔细研究项目失败的原因，归纳起来可以有 5 个原因。
1）初期的估计偏差可能很大
下图显示了 Boehm 所考虑的不确定性在顺序开发过程不同点的范围，这个图称之为不确
定性锥形。 图上表明，在项目定义阶段，对进度估计的偏差可能达到 60% ～160%，也就是
说一个预 期 20 周完成的项目，实际花费可能在 12～32 周之间。而在写下需求之后，估计
的偏差可能还在±15%，这时的 20 周预期可能实际上可能会花 17～23 周。这么大的预估偏
差根本就无法实施有效的项目管理。
2）活动不会提前完成
设想某一个资深程序员正在为一个产品编制一个有趣的新功能，同时他还承担了一个为
CMMI 审核准备文档的任务，他会怎么样分配时间？毫无疑问，他会把大部分时间用于编制
这个有趣的程序，而准备审核只留下了刚刚够用的时间，而且是到最后才不得不草草完成。
实际上这种行为非常普遍，以至于有了一个名称叫帕金森定律（Parkinson’s Law，1993）：“工
作总是要拖到最后一刻才完成。”
如果一项工作在甘特图上分配了 5 天，处理这个活动的员工一定会用满 5 天，即使能够
提前完成，他也会通过增加一些花哨的修饰（镀金需求），或者尝试着用一些新的热点技术。
在不少企业文化中，一项活动提前完成，往往被指责为当初他做的估计不准确，或者会另派
其它的任务给他，为什么要冒这个风险来提前完成呢？人的本性就是如此：用多余的时间去
做一些对自己有价值，但对别人不一定有用的事情。
3）延误沿着进度表向下传递
由于传统的计划是基于活动的，因此它们主要关注活动之间的依赖性。考察下面的甘特
图，它显示了 4 项活动及它们之间的依赖关系。
如果需要提前完成测试，就要求一些事件的幸运巧合：
对中间层的编码提前完成，而它受到向数据库添加数据表这一活动完成时间的影
响。
对用户界面的编码提前完成。
提前安排好测试人员。
关键之处在于，即使一个如此简单的案例中，在启动测试之前也有 3 件事情必须发生，
但是下面任何一件事情，都可能导致测试推迟：
用户界面编码结束时间延误。
对中间层编码花费时间超出计划。
中间层编码花费时间符合要求，但是向数据库添加数据表结束过晚，导致延误了测
试时间。
未安排好测试人员。
也就是说提前启动测试需要完成很多事情，其中一件事情延误，都可能导致总体上的延
误。事实上我们已经确认了活动很少会提前完成，所以发生的绝大多数事情是延误，而这种
延误会沿着进度表传递下去，最终导致后续项目很少会提前启动。
4）不按照优先级开发功能
传统项目管理方法不一定能够带来高价值产品的第三个原因是，制定的计划没有按照对
用户或者客户所具有的价值大小来排列工作的优先级。很多传统的计划实际上假定工作都可
以完成，工作的顺序主要是由依赖性来决定。但是随着项目结束时间的逼近，开发小组会匆
忙放弃一些功能以跟上进度，由于不是按照功能优先级顺序开发的，某些被放弃的功能反而
比交付的功能更重要。
5）忽视了不确定性
传统规划方法的第 4 个缺点，是不承认不确定性的存在。人们假定最初的需求分析就可
以产生对产品来说完整的、完善的定义。我们假定用户在计划覆盖的整个时间内都不会改变
想法，他们的观点也不会更细化，也不会提出新的需求。
与之类似，我们还忽视了如何构建产品这样的不确定性，某种技术在实现中才发现并不
一定合适，但我们已经给它分配了确定的时间（两个星期），事实上我们不可能指望一开始
就确定项目进程中所需要的所有活动，但我们又不愿意承认这一点。
在分析了传统项目管理方法所存在的问题以后，我们对那么多项目令人失望就不会感到
奇怪了。基于活动的规划方法分散了我们对功能的注意力，而功能才是衡量客户价值的单元。
本来项目的参与者满怀好意的把多任务处理当成解决延误的办法，结果却造成项目更加的延
误。当进度表剩余时间不够的时候，不可避免地要放弃一些功能，由于开发人员是按照最有
效的开发方式来安排进度的，因此放弃的功能对用户来说不一定是价值最低的。
忽视用户需求的不确定性，会导致虽然按时完成了任务，但很多后来发现的重要功能没
有办法加入，或者即使加入了但要不是项目延误，或者不恰当的降低质量。
这是在这些分析的基础上，我们就必须考虑解决这些问题的办法。