《软件过程与管理》案例讨论

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