进度管理：死亡之旅-最后期限-Leadge 电子邮件杂志第8期

　　老板BB:大家能够同意这个时间,我很高兴,好，4月1号前完成分析，7月1号前完成设计，那么你们有3个月的时间实现项目。这次会议是一个榜样，它表明了我们新的协商和授权程序工作的有多么好。现在，大家可以离开，开始工作了。我期望在下周前，可以在我的办公桌上看到 TQM(全面质量管理)计划以及 QIT(质量改进团队)任命情况。

　　老板BB:记住，SEI下周要过来做一次评估。这是评估指南。你要把它读一遍，记住它，然后把它撕碎。它告诉你如何回答 SEI 审计师问你的任何问题。它还告诉你在构建过程中可以使用哪些部分内容以及避免使用哪些部分内容。到 6 月份时，我们会被确定为 CMM3 级机构。

　　案例分析:

　　倒排进度有时在受资源约束的时候是有效的进度安排方法,当在用户需求无法明确的情况下却下明确了产品交付时间,这样倒排的进度没有任何意义,唯一的是给高层管理的心理安慰.倒排进度好比用结论本身在证明着结论的正确性,它给我们带来的最大迷惑就是已经假设了结论的正确性,然后我们乐此不疲的在用这种未知的假设做着让高层满意的推论.

　　过程很重要,好的过程有助于我们开发出好的产品.但在不切实际的进度面前过程更加显得苍白无力.对进度的恐慌迫使我们有强烈的意愿去达到各阶段的目标和里程碑,因为你和高层领导都清楚这样一个事实,如果里程碑无法达到,你去告诉你的领导你严格的遵守了各个过程是多么没有说服力的话语.而实际上你完全遵守过程执行,往往减少后期大量的返工时间,更容易达成项目目标.不是过程不好,而是我们不够成熟,我们需要的是尽可能早的暴露风险和未知,这样你才能安下心来长舒口气.

　　重要片断:

　　令你大为惊奇的是，现在要回答“当用户敲击回车键时，系统应该做什么？”这个问题，需要填写15页的表格和问答题。（华丽而无效的过程）

　　3.27号，距离分析完成还有一周时间，你们已经产生了大量的文档和图示，但是你们对问题的分析却和1 月3号时一样的浅薄。(交付物代表了什么？)

　　4.1日,奇迹发生了,你的上司给高层发邮件说明你们已经成功的完成了分析阶段.老板团队所表现出的不可思议的团结和团队协作(盲目的乐观)

　　有传言说，一旦被 SEI 授予 CMM3 级，和BB同层以及更高层的管理者就可以得到丰厚的奖金.(权力和政治)

　　"如果我们要将设计详细到代码级的程度,我们为何不直接去编写代码呢?"
　　"因为那样的话，你当然就不是在设计了。而设计阶段惟一允许做的事情就是设计."

　　评审会议很快就变成有关面向对象的意义、分析和设计的定义以及何时使用聚合和关联的争论。(偏离主题的评审)

　　你告诉你的上司，这些变更意味着你需要对系统的大部分内容进行重新分析和重新设计,但是他却说，“分析阶段已经结束。惟一允许做的事情是设计。现在回去设计吧。”（死板的规程）

　　7月1号，另一个奇迹发生了！你完成了设计！一份无法反映真实需求的设计文档.充斥着大量的类图,模型和序列图.(复杂而无用的模型)

　　你的上司雇佣了一个顾问来构建一个计算所编写的代码行数的工具。他把一张很大的坐标纸贴在墙上，在顶部标出了数字1000000。每天他都会延长红线来显示增加了多少行代码。（毫无意义的度量）

　　接着，他立刻闪现出了管理方面的洞察力，说，“我知道了！，任何一行代码都不能超过 20 个字符。任何超过 20 个字符的代码行必须得分成两行或者更多的行——越多越好。现有的所有代码都必须按这个标准改写。这会使我们的代码行增加！”

　　拼凑、拼凑、拼凑还是拼凑。你和你的团队疯狂地编码。到8月1号，你的上司皱着眉头看着墙上的坐标纸，制定出了强制性的每周要工作 50小时。（加班已不能解决问题）

　　最后，到3月份。经过了大量的 65 小时工作周后。一个非常不可靠的版本完成了。实地使用时，错误的出现率非常高，技术支持人员对于发怒的客户的抱怨和要求束手无策。所有人都不高兴。(为时已晚)

　　4月，高层决定通过购买的方式来解决问题，他购买了由 Rupert工业公司开发的产品的使用授权并重新销售。客户的怒火被平息了，市场人员沾沾自喜，而你被解雇了。（替罪羊产生）