e Process：COCOMO II》书中勾勒出的估计误差，在项目先期误差甚至达到4倍，随着项目进展估计的误差才逐步缩小，所以对进度和工作量的估计应该是一个范围，在项目中不断根据实际情况去修订，上面例子中合理的答案应该是项目延期一倍。不过遗憾的是这种几十年前的过时理论常常会被人忽略和遗忘，而去追逐先进而耀眼的灵药。
估计就是估计，决不能被当成严肃的承诺。项目经理的“英雄本色”情结经常会鼓励其寻找“银弹”的冲动：利用现有资源按时完成已经超期的项目，当然有时是有领导和用户的重压。根据项目管理中进度、质量、资源和范围的约束关系，这显然是不可能的任务。如果期望在预计的时间内完成，一般会在需求上下功夫：考虑优先实现那些用户业务所必须的需求，力求削减并非必要的需求，或是在后续版本提供——实践证明通过充分沟通大约可以达到目的。当然调整资源也是一个办法，问题是增加人手的时机，搞不好反而会更加延缓进度——“人月神话”的brooks法则。如果想在“质量”上打主意，我个人认为不是好的选择，原因是软件系统对需求的实现程度是二元的——要么实现，要么没有实现，不存在部分实现的情况，换句话说就是系统的质量和所实现的需求是相关的，质量的降低也就意味着需求没有实现。
上面的解释中存在逻辑上问题：将软件系统开发的理论扩展到了系统产品的研发，不过应该还是有些借鉴价值的。
一个荒秃的山坡。
一具血淋淋的尸体仆倒在地上。
从尸体的伤口上判断头颅是被野兽撕掉并叼走的。
“为什么还不提取DNA样本？” 凯瑟琳问到。
“需要等法医来确认他真的已经死亡。” 格雷森无奈的耸耸肩。
——《CSI: Crime Scene Investigation》
点评：原来号称制度建立完善的美国也会闹出这样的笑话！其实无论多么完美的流程制度都不能确保在任何实际情况下是适用的，如何平衡规范和灵活始终是个难题，其原因是你要解决的是现实问题，而不是在纸面上或在头脑中。如何使流程适应当前项目的特点，确定流程中各项活动的先后顺序、执行的程度、乃至是否需要执行这项活动，关键是流程定义者和执行者对活动及其影响的理解程度。
回顾一下软件项目生命周期模型，包括瀑布（线性）模型、V模型、螺旋模型、增量模型、迭代模型、XP极限编程等等，其实包含的活动多是相似的，不同之处在于项目过程中各个活动的取舍、先后顺序、执行的程度——之所以出现如此多种的模型，关键在于无法用一种模型去适应特性各异的项目。如果说有什么模型可以通用，那就是RUP（Rational Unified Process） ，不过它是一个灵活的软件开发流程平台，换句话说，它即指导你如何去做，同时又没有明确告诉你如何去做——如何运用还得靠使用者的聪明才智。
对于研发项目而言、既然流程的定义和裁剪是无法回避的问题，那么就不要避重就轻的将它放在工作的角落里。一般的解决方法是根据项目特点（例如周期、工作量、投入资源、难易程度等等）将项目分类，并分别制定各类项目的开发流程；或者制定流程裁剪的原则，规定哪些活动可以裁剪、哪些活动可以合并。
另一种方法是针对各项活动，列出可裁剪属性、可选项、裁剪指南，明确实践中对单项活动的执行情况。例如对“确定信息采集的方法”可以进行如下定义：
活动 可裁剪属性 可选项 裁剪指南
确定信息采集的方法 技术 用户评审 对于新需求
观察 对于现有操作的充分理解
使用任何现有的应用 如果应用已经存在，并且至少覆盖用户的一些需求
上面两种方法分别从宏观和微观角度来指导流程的裁剪，都是非常必要的。有的QA、项目经理可能会对其工作量提出疑问，我个人认为这项工作是项目管理的关键之一：一个良好的过
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
