凭直觉的项目估算 VS 仔细的项目估算

凭直觉的项目估算

　　公司正在开发库存管理系统ICS1.0，张辉是项目经理，在参加项目监督委员会第一次会议的时候，他对期望的功能已经有了总体设想。
　　王路明是委员会的领导，他问："张辉，ICS1.0需要多长时间？"
　　张辉回答："大概要9个月，不过这只是粗略的估算。"
　　"不行,"王路明说，"我真希望你说3个或4个月，我们一定要在6个月内拿出系统，能完成吗？"
　　"我不能肯定，"张辉说，"我还得仔细研究一下，不过我相信可以找到办法在6个月内完成。"
　　"那么把6个月当成项目完成的目标，" 王路明说，"无论如何我们都必须这样做。"委员会的其他人一致同意了这个决定。
　　到第5周的时候，又增加了一些产品概要设计工作，这使张辉更确信项目花费的时间更接近原先9个月的估计而非6个月，然而他还是认为运气好的话可能在6个月内完成项目。他不想被看作惹麻烦的人，所以决定等等再说。
　　张辉的团队努力地工作着，进展稳定，但需求分析的时间比期望的要长。预定6个月内完成的项目已经过去4个月了。"2个月无论如何也做不完剩下的工作。"他只好告诉王路明，项目需要延长2个月，总共需要8个月的时间。
　　几个星期后张辉意识到设计进度也不像期望的那么快。"先做容易的部分，"他告诉项目组人员，"其余的部分遇到时再考虑。"
张辉再次向监督委员会汇报："8个月的项目已经过去了7个月，详细设计基本完成，工作卓有成效，但是8个月还是无法完成。"张辉通报了第2次进度的拖延，并将完成目标定为10个月。王路明对拖延产生了抱怨并要求张辉想办法把进度计划仍安排为8个月左右。
　　第9个月，项目组完成了详细设计，但部分模块的编码还没有开始。很显然项目仍无法在10个月内完成，张辉只好又要求第3次进度延期----12个月。在宣布项目延期的时候，王路明的脸涨红了，张辉明显感到了非常强烈的压力，他认识到他的工作已经处于紧要关头了。
　　编码非常顺利，但一些地方需要重新设计和重新实现，而这些地方项目组没有把详细设计调整好，一些实现过程相互冲突。在第11个月的监督委员会会议上，张辉宣布了第4次进度拖延----13个月。王路明脸色铁青，"你知道自己在做什么吗？"他大声说，"你根本不知道！你根本不知道项目什么时候做完！让我来告诉你什么时候做完！13个月必须完成，否则就是失职！我简直受够了被你们这帮家伙用绳子拽来拽去！你和你的项目组每周要工作60小时，直到拿出成果！"张辉感到血压又升高了，自从王路明把他引到一个不现实的项目进度中之后，他的血压就一直没正常过。但他知道4次进度拖延已经使自己没有什么可让人相信的了，他觉得必须服从强制加班，否则会丢掉饭碗。
　　张辉向项目组通报了会议的有关情况，并要求他们努力工作，设法在13个月结束的时候交付软件。额外的实现过程掩盖不了额外的设计缺陷，但每人每周工作60小时，辛勤的汗水和顽强的意志最终保证了他们完成了项目并交付了产品。

 

 

 

仔细的项目估算

　　公司正在开发Cube-It2.0，关于项目计划，项目经理张莉、部门经理陈健、市场代表王路明、还有CEO一起开会讨论。
　　"Cube-It 1.0已经相当成功，我们需要在完工之前尽快拿出升级版本，"王路明说，"我们要在6个月内完成较大的升级。"
　　"根据我看到的初步产品计划定义，这不大可能，"张莉说，"现在我估计进度在6个月到15个月之间，最可能9个月。"
　　"9个月，不是开玩笑吧，我要比这更详细的估算。"王路明说。
　　"产品概念还没修正，不足以提高更精确的估算。"张莉说"由于产品定义的所有不确定性，甚至理论上都不可能在6个月完成。如果在定义功能集的时候可以去掉一些功能，我们当然可以花更少时间开发出来。不过据我所知，我们需要的一个具有完全功能的版本。"
　　CEO大声说："对，我们的1.0版本产品品质较好但比较简单，这虽然给了我们一个非常好的开端，但是我们还是发现了它有一些重要的功能缺陷，需要在版本2.0中加入。" 　　"我必须坚持6个月到15个月的估算。"张莉说。
　　"这不够，你要给我一个更精确的估算，"陈健说，"你说有可能6个月完成，把目标定成6个月吧。"
　　"对不起，我不赞成。"张莉说。"我们只是自己骗自己，6个月是实施最小功能的最低限度时间。我'最可能'的估算是9个月，不是6个月。"
　　"相信我，我希望告诉你想听的。"张莉继续说，"和一群比我级别更高的人坐在一起不容易，告诉你我不能给你想要的也不容易。然而如果我给了你更精确的估算也毫无价值，这样的话下次你根本不会相信我，我宁愿现在告诉你真实的情况。"
　　张莉走到白板前画出了估算收敛图。"我能承诺的是随着工作的进行，估算在稳步地修正。一旦需求完成，我将提供精确到+15%以内的估算，完成详细用户界面设计精确到+10%以内，一旦做完详细设计，我提供的估算精确到+5%以内。"
　　"我同意。"CEO说，"我们依据这些需求进行吧，这样能算出多快交付一个产品。"
　　到第5周，张莉完成了产品概念，他把估算修正为9个月到15个月，"最可能"15个月。他又向王路明，陈健和CEO汇报。王路明和CEO迫切要求一个详细的交付日期，但张莉婉言谢绝。"产品概念中有很多不确定性。"他解释到，"从上次会议至今，虽然我们已经确定了很多，但仍有数百条细节要敲定，累计要花很多时间。"
　　"范围从9个月到15个月，不是6个月到15个月，"陈健指出，"是否意味着没有可能6个月内交付下一个版本？"
　　"这正是我要说的。"张莉说，"根据市场部认定的XX功能的功能数量，没办法在9个月内完成。"
　　"为什么'最可能'进度估算从9个月增加到15个月？"CEO问。
　　"市场部要求的产品功能比我原先设想的多，"张莉说，"但是仍有很多时间重新定义功能集，保证最多12个月交付产品，也不一定要太完美了。"
　　17周时张莉和他的团队完成了需求说明书。他们定义了更小的产品功能集，张莉修正了估算，项目要花9到12个月，最可能10个月。
　　"10个月！太多了！"CEO说。"我认为整个项目你都会坚持用'3个月'这个词。什么时候提供更详细的估算？"
　　"产品设计结束的时候能拿出来，误差+10%以内，大约两个月做完。"张莉说。
　　第24周，Cube-It小组完成了产品设计。张莉又修正了估算，项目花费43到52周，最可能48周完成。"按最长进度52周做计划比较保险，不会比这个时间更长了，"他告诉陈健，王路明和CEO。毫无疑问他们接受了52周的估算。
　　第7个月，Cube-It小组完成了详细设计，张莉又修正了进度，他汇报说项目看起来要花47到51周，最可能49周完成。
　　Cube-It小组在第50周结束时交付了产品，CEO祝贺张莉工作完成出色。
　　张莉休息了几周，在Cube-It2.0开始后的第55周，他开始了下一个新项目。他估算新项目要花6到12个月，"这对进行的工作还很不够，必须更精确些。"一位新上任的高层经理抱怨。
　　"不，他不会那样做。"陈健一边在白板上画估算收敛图一边解释。"进度中有不确定性，因为软件本身有不确定性。张莉要花很多时间修正估算以便使她的计划协调一致。"

　　尾声
　　两个案例的项目规模一样，第一个案例研究中的项目花了56周而不是50周，因为最初估算很糟糕。糟糕的估算导致了糟糕的计划决策和草率容易出错的设计。
　　两个案例研究中的项目进度调整次数相同。在前一案例中，张辉第一次调整进度，管理层就认为项目失控，他们把进度调整看作项目延期。进度调整越多，项目看起来越失控。在本案例中，管理层认为项目从始至终受控，每次张莉调整进度，项目看起来更加受控。
　　项目结束时，张辉的项目被认为失败，而且个人信誉全无；张莉的项目被认为成功，而且他打下了基础，下次项目计划上会少一些对立。