翻译 项目管理艺术 2.4 这是个大块

2.4 计划为什么失败

任何事情都可能出错，而项目计划最容易成为替罪羊。如果一个人随意评估，漏掉需求，或者被车撞了，都是由计划（或者计划的负责人）来承担责任。如果国家的电力供给停止10天，或者团队里最好的程序员得了大病，有人就一定会说，“看吧，我告诉过你计划不可行。”然后就在计划制定者面前摇动手指。这虽然不公平，但总在发生。人们厌恶计划，把它置于一种不可达到的程度。即使是最好的计划者，拥有了最聪明的头脑和最有效的工具，所能做的仍然只是试图预测未来。

但是，如果在开始项目时能注意到那些可能使计划散架的原因，采取措施使风险最小化，那么计划则能在开发过程中成为实用精确的工具。

2.4.1 盲目行动

如果计划是在项目初始时创建的，那么对计划有影响的决定会有上百个。这就出现了问题，没有人可以预测出，也不能草率的决定。项目管理人只有很少的信息来作出符合实际的预测，除非需求都已经理解了，高层计划已经在进行之中了。然而更多时候，一个粗糙的计划充满捏造的数字和武断的想法，这个稻草人披着可靠计划的外衣被放置在项目中。

通常，人们很容易掉进精确度对正确性的陷阱：一个看起来印象深刻的计划，拥有详细的日期和时间（精确度）不一定就接近真实的情况（正确性）。精确很容易，但是正确却很难。

然而，项目和计划总是要启动的。黑夜中的一枪可以给与团队活力，在适当的位置给与限制。可以先开始一个研究过程来充实计划，提出并解答一些重要的问题。但是如果未经验证的糟糕设想被用作了计划的基础，而且还没有进一步的改正，那么离风险就不远了。用充分的证据显示，任何人都无法在项目早期估算出项目需要的时间总量。

Barry Boehm在他1989年的关于关键工程的论文中说道，计划评估在项目中越早，计划的出错规模越大（图 2-3 所示）。如果所有的计划评估都在项目早期进行，那么它最后可能会向任一方向偏离近400%（虽然没有数据证明，但我怀疑错误会向我们倾斜，我们花的时间要比预期的长）。在设计阶段，应为更多的决定都很明晰了，分歧缩小了，但仍然很大。只有项目到了实现阶段，项目评估的范围才能变的合理，但即使这样，还是离正确的计划决定有20%的误差。

图 2-3 项目中错误评估的范围（取自 Boehm的《软件工程经济学》）。

这就意味着项目经理需要明白计划评估的正确性是随着时间增长的。计划要不停的被关注，项目前行就要不停的进行调整。

2.4.2 计划是一种可能性

当我刚从大学毕业，开始我的第一个大型项目工作（Windows 和 IE）的时候, 高层任务书从比我更牛的人那里到了我的团队。我因为太年轻，而没有负责太多的工作。计划就做一天的，我的任务是把设计任务书分给和我共事的几个程序员和测试员。

当我们在一起讨论设计任务书和我们基于工作项目做出的计划表的差异时，高层任务书就显得无处不在。它都是从上至下，排版细致，日期和时间的排列错落有致，就像项目完成后制作的一样。

尽管我们都对其不屑一顾，但多数时候，我们还是如实地遵从这些计划。虽然我们不知道它们是怎么来的，但我们还是很信任我们的领导的，同时我们自己的工作就够忙的了，哪里有时间去操心这些。（实际上，他们通常都提供了这些计划书的基本解释，但是我们太忙或是太信任了，以至于不去关心这些计划书。）

稍后，当计划安排成为了我负责的工作时，我认识到了这个关于计划没有点明的事实。他们不是来自未来的礼物。也没有万能公式和理论能创建出完美的计划。尽管我经验不多，但我也能认识到，作计划并不是一个孤立的工作：它总是表现为或包括了许许多多项目当前或将来的不同方面。计划仅仅是一种预测。不管计划被起草的多么精确，多么令人信服，它们都是许多更小的估计的总和，每一个估计都不可避免的倾向于不同方面的，不可预见的疏漏和问题。只有那些在软件开发的各个方面都严格要求并且进行良好判断的领导和团队才能做出优质的计划。你不可能只精通一个很小的领域就期望能把计划做好。

所以，如果团队的每个人都同意计划是一组概率的集合，那么问题就不再是计划本身的了，就在于计划怎么被使用上了。假设曾有一份计划出现在小组会议上，或是用电子邮件群发，如下就是一个很好的问题：定好的期限有多大的可能性？如果没有提出任何可能性（例如，5个最有可能的风险是什么，以及它们能出现的概率），做计划的那个人也没有对他的假设做出解释，那么就应该假定计划是可能的，但不是不可行的。计划应该对项目组开放，得到大家的意见，使相应的事项或信息加入到计划中，使其更加可行。

诀窍就是计划不需要十分完美（这是安慰，其实也没有完美的计划）。计划只要足够好到让团队和领导信任就行了，它提供了跟踪和调整的项目的基础，使项目有了成功的几率，让客户，业务人员和所有的项目发起人都满意。

2.4.3 评估并不容易

在设计过程中（在第 5章和第6章讲到），设计人员，程序员和测试员都有一部分的工作是将设计分解为可构建的小块工作。这些小块的工作通常称为工作条目或者工作细目分类（7），成为了项目的设计说明书具体条目。这些工作条目（但愿）被合理的分布于项目组，通过总结，计划就做出来了。每个工作条目都要有由程序员分配的的时间，有了这些评估，计划就构建好了。
用最简单的定义，好的工作评估拥有很高的正确度可靠性，而差的工作评估则很低。我不期望这些定义能得什么奖，但是它们至少意味着一点：这是那些定义项目标准的团队领导人的判断依据。这就需要一个有效的过程能够评审估计结果，推动他人，领导他人以及引起他人注意，从而让这些评估能够达到所需要的一定程度。我觉得再评估过程中，如果能让测试和QA团队也参与进来，就更明智了。让他们参与到设计讨论中，问问题或提供解释。最少，这样也可以帮助他们评估自己 的工作，可能这些工作和编程工作的评估并不相关。通常。QA对于那些别人没有注意到的设计疏漏和潜在的失败用例有很强的洞察力。

2.4.3 .1 万物都基于评估
做计划很困难是因为很少有人喜欢估计他们负责的复杂的事情。平常都是对自己满怀信心， ("这本书/这部电影/这个网站 太烂了，要是我能做的更好"), 等到了要开始做，或者要在描述自己职责的合同上签名的时候，情况就变了。我们都知道，今天承诺要做的事情，很可能到时间的时候，根本做不出来，或者就不用作了。这可能比我们想象的还要难。程序员和普通人一样，也都对估计问题很头疼。谁要是说事情能够在确定的时间内完成，就是在冒出错的风险。
以我的经验，即使程序员理解相信评估的过程，也不大喜欢去做。部分原因是和想象中的不符（“这么少的信息，怎么做这个工作？”），精度不够（“告诉我这个 工作实际要做多久。“）。同情在这里要所有限制，从事工程，建筑工作的每个人都面临着相同的挑战，不管是盖摩天大楼，改造厨房或者是发射太空飞船。从这些人怎样进行评估，就可以看出来他们的挑战或者技术与网站程序员和软件工程师面对的没有本质的区别。最主要的区别就是他们有多少时间来进行评估，以及他们是 怎样合理利用这些时间的。
（第5章和第6章将会进行详细论述）。

2.4.4 好的评估来自于好的设计
通过和程序员的共事，我学到的关于评估的最重要的一点就是好的评估来自于可靠的设计和需求。如果具备了以下两点，优质的工程评估就不是没有可能：正确的信息和优秀的工程师。如果规格不明确，而且序员被要求从这些无法理解的混乱文档中变出数字信息 ,那么结果显而易见，最后得到的一定是不准确的胡乱评估。这意味着好的评估是每个人的责任，是整个团队的工作。项目经理和设计人员特别要协助工程师进行可靠的评估。如果评估进行的杂乱无章，或者项目负责人都没有参 与其中，就不要指望能得到可靠的评估结果了。
　　如果项目负责人承认计划的评估进行的不够，而且也乐意冒风险，那么这样的评估也无所谓了。在小型，快速的项目中，粗略的估计可能正是这样的项目需要的。需求随时会变，业务和组织的性质可能要求更少的结构性，更多的适应性。低质量的评估没什么错，如果没有人将它们同高质量评估弄混淆的话。
我发现了一个很有用的技巧，无论什么时候，只要程序员不想做评估，我就会问＂我要回答什么样的问题，才能让你对做评估更有信心？＂通过使他明确细节，我给了他直面其内心恐惧和挫折感的机会,这样我就可以帮助他解决问题。当然,我可能要帮忙找出问题的答案,讨论一些我认为本应该是其分内的工作，但是最后，我 们将会对怎样得到更好的评估进行探讨。
以下是另外一些保证有效评估的方法：
为评估建立基线可靠区间。如果只是猜测，那么对正确度只能有40%的信心；拥有好的评估,则有70%；再有详细全面的分析，则能达到90%。团队领导需 要对评估的正确性程度达成一致，同时还有做评估的总时间花费和遗漏估计的风险怎样管理。一个达到90%的评估应该正好差不多才行。如果你决定让你的团队提 高评估的质量，你就要给他们相应的时间。
骨干程序员要通过提出有价值的问题，提供完善的解决方案来设立评估质量的标准，这样可以作为团队仿效的榜样。采取一切必要措施消灭任何作假或倒退动机，（例如，“不要让我做这个，”“可能吧，”等等。）。找出一切他们交付合格评估所需要的正面因素，并提供合理的时间以保证达到指定的评估质量目标。
要信任程序员。如果你的脑外科医生告诉你手术要用5个小时，你会要他3个小时做完吗？不能吧。有些时候，压力是用来使人诚实，但也只是作为一种平衡措施（规范的做法应该是程序员对于自己不喜欢的事要做高一些的评估，喜欢的则可以低一些）。有些时候，可以做多重评估（来自两个开发人员），这样也是保证全面的控制的一种方法。
评估取决于程序员对项目目标的理解。评估不仅基于程序员对设计说明文档（如果它们有的话）的理解，还基于对项目标的理解。在Gerald Weinberg的《计算机编程心理学》这本书中(Dorset House, 1971), ，记录了高层目标对程序员做的低层设想的直接影响有多么缺乏透明度。可能出现技术难题是显而易见的，程序员解决它的方法可能会随着整个项目的高层意图发生戏剧性的改变。
评估要基于以前的效率。程序员在整个项目过程中跟踪评估是很不错的习惯。这应该是他们和项目经理讨论内容的一部分。项目经理应该明白团队里面每个人都擅长估计那些内容。极限编程使用术语“速率”基于以前的效率情况来表示一个程序员（或项目组）大概的工作效率。
规格和设计都要进行很好的评估以达到工程需要的程度。这是在项目管理和程序员之间的评判。评估期望的质量越高，规格说明的质量就应该越高。我们将在第7章谈论关于好的规格说明的事宜。
使用已知的方法做好评估。最有名的方法就是PERT(10),它试图通过平衡高，中，低三种评估来最小化风险。这有两点好处。第一，它使所有人都意识到评 估只是预测，可能的结果存在一定的范围。第二，它给项目经理扼杀那些太冒险或者太保守计划的机会（更多的砝码可以用在低层或高层评估上）。

2.4.5 常见的疏漏

当好的评估不断改进计划的同时，有很多影响计划的因素是抄近路到达个别工作项的。这就出现了一个陷阱，不管所有的评估多么完美，那些真正的计划风险是没有被写下来的。 在世界大部分地方，减少灾难的发生几率几乎不可能，但骨干工程师得病，或者去休假的可能性确是很大的。这里有一些项目经理应该熟悉的常见的计划疏漏。问题是通常你只有在被一个疏漏弄得火烧眉毛后，才会在以后留意它。这就是为什么项目管理特别是计划管理，需要经验才能精通。失败有很多种方式，不对其结果负 责，就没有办法进行发现失败的演练。
以下列表中的问题总是帮助我在早期就能发现计划中潜在的问题。大多数来自于项目结束后的问题回溯。发现那些别人在项目早期就提出的问题，避免此问题的发生。（什么被错过了？什么还没有解决？是什么造成的差别？是什么让我采取纠正措施的？）
病假和假期是否也采用某种形式包含在计划中。
是否每个人都要使用计划，是否要经常汇报工作进度（以某种不烦人的方式）。
是否要有人每周或每星期关注所有计划。此人是否有足够的权威来发问及做相应调整。
团队是否对计划有拥有权并对计划负责。如果不是，为什么？团队是否对计划的制定和工作的执行有贡献，或者只是从上面传达下来。
项目负责人是否增加了新的特性需求而不是帮忙缩减。项目负责人是否总是对新的工作说不，并对团队提供合理的解释，怎样来回应新的（晚到的）需求。
团队成员是否被鼓励对那些不符合目标和愿景的新工作说不。
使用什么样的概率来作评估。90%,70%还是50%。这一点在高层计划中提到了没有。客户知道这一点了吗？是否为了能得到更高的概率而花更多时间对其他提议进行讨论。
计划中是否有周期性的时刻用来进行调整和重新商议。
在假日季节，计划时候过少的预计了工作时间。（在美国，感恩节到圣诞节通常是工作效率不高的。）一些严重的自然灾害是否也要考虑（例如芝加哥的暴风雪，安萨斯的龙卷风，西雅图的酷暑）？
规格说明和设计计划对于工程师做好评估工作是否足够。

工程师是否进行过做工作评估的培训，或者是否有这方面的经验。

2.4.6雪球效应
关于上面的列表 ,让人郁闷的是,即使你全考虑到了,因为对于计划,每个贡献都是相互依赖的,所以计划很容易变动。团队从设计选择到评估所作的每个决定，都是以后所有决定的基础。一个在项目早期出现并后来被解决的疏漏将会对项目有很大的影响。这种计划的组合行为很容易被低估，因为缘由和结果不是同时出现的 （你可能会在原因发生之后看到影响）。最坏的情况，当许多主要的疏漏发生时，坚持计划的可能几乎为零（见图　2-4）。

图2-4　雪球效应

当然，这很难发生。概率的作用形式是一系列独立时间发生的几率是每个事件单独发生概率的乘积（也成为组合概率）。所以，如果你完成这一章的概率是十分之九，完成下一章的概率也是十分之九，那么你完成两章的全部概率不是 9/10,而是81/100。这就意味着如果你的团队一周中每天都达到90%的正确性， 随着时间流逝，计划变动的几率在不断的增加。概率是不讲感情的，它提醒我们平均信息量无处不在，并且可不是项目和管理者们的好伙伴。