**第1章

项目管理失当**

**2001年6月1日：“开发时间表、飞猪和其他幻想”

2001年10月1日：“竭尽所能，再论开发时间表”**

我的第一个栏目是在2001年6月微软内部网络杂志《Interface》上发表的。为了进入IMWright的人物角色，我需要找到一个真正让我苦恼的主题。而工作时间表和进度跟踪再好不过了。

项目管理的伟大神话至今都让我疯狂，它的威力远胜过其他任何主题。这些神话是：

1．人们可以按期完成任务（事实上，项目可以按期交付，但项目员工能按期完成各自任务的概率不会高于击中曲棍球的概率）。

2．有经验的人估算日期比较准（事实上，他们能够较好地估算工作，但不是日期）。

3．人们必须准时完成各自的任务从而使整个项目按时交付（事实上，员工们不能按时完成自己的任务，所以你若想你的项目能够按期交付的话，你必须进行风险管理、范围管理并通过沟通来减轻人性的弱点可能给项目带来的负面影响）。

在这一章中，IMWright将讨论如何通过管理风险、范围和沟通，来保障项目能够按时完成。前两个栏目专门讨论开发工作时间表，接着讨论善后事宜的管理（我们称之为“Bug分诊”）、死亡行军、撒谎以掩饰问题、快速而精准的估算、服务管理、风险管理，以及在一个大型项目中整合各种方法以便协同运作。

不得不提的是，通过我在微软这些年工作期间的观察，在不同的规模、不同的抽象层次中，项目管理有不同的表现形式。这些层次包括：一个团队或功能层次（大概10人左右）、项目层次（50～5 000人为一个特定版本工作）以及产品层次（由高级主管领导的多个版本开发）。敏捷开发在团队层次很适用，传统方法在项目层次中很适用，而长期的战略性规划方法在产品层次很适用。然而，人们很少同时在不同层次工作，实际上，每个人总是会分年段地在这些层次间工作。所以人们常常认为某一层次的高效方法应该应用到其他层次上，悲剧就这样产生了。准则就是：小型、紧凑的团队跟大型松散的组织动作方式不同，应相应地选择适合你的方法。

——Eric

2001年6月1日：“开发时间表、飞猪和其他幻想”

一匹马走进酒吧，说道：“我能在两天内完成那个功能。”开发成本计算和时间表是个笑话。相信它的人，要么是傻瓜，要么是初出茅庐的项目经理。这不是模糊科学，这是瞎编。不错，的确有人相信编码工作可以被精炼成一个可预见进度和质量的可重复的过程，那我儿子至今还相信牙仙子呢！事实上，除非你只需编写10行那么长的代码，或者代码可以直接从以前的工作中复制过来，否则你不可能知道编码会花费多长时间。

作者注：项目经理（Program Manager，PM）有很多职责，其中职责之一是说明最终用户体验和跟踪所有项目的整体进度。这种角色是必要的，但他们常常不讨开发者的喜欢，因而也很少得到开发者的尊重。真遗憾，项目经理是一份很难做好的工作。但是，对于Wright先生来说，项目经理仍然是一个有趣并且容易达到的目标。

译者注：①关于牙仙子（Tooth Fairy）。美国人有个信仰：小孩子换牙时，父母会告诉他把牙齿用信封装好，放在枕头下，早上起来的时候牙仙子会用钱跟他换牙齿。这钱当然是父母给的，用来鼓励小孩子拔牙。牙仙子在美国是人尽皆知的，虽然只是一个“善意的谎言”!②关于飞猪（Flying Pigs）。猪会飞吗？美国人常用此来比喻离奇荒诞之事。

里氏震级估计

译者注：里氏震级（Richterscale）是地震等级的一种数值标度，分1～10级，每上升一级，强度增加约60倍。

当然，你可以估算，但估算出来的时间是成对数关系的。有些事情需要花费几个月，有些事情需要几周，有些需要几天，有些需要几个小时，有些则只需几分钟。而我跟我的项目组项目经理（Group Program Manager，GPM）一起给一个项目做时间安排时，我们对每个功能使用“困难/中等/容易”3个等级来评估。“困难”意味着一个全职开发人员需要花费整个里程碑时间；“中等”意味着一个全职开发人员需要花费2～3周时间；“容易”意味着一个全职开发人员需要花费2～3天时间。没有其他等级了，也不做精确的时间表。为什么呢？因为我们俩知道，我们无法预测更精确的时间了。

在我的记忆里，除了一系列里程碑、测试版、正式版发布等“项目日期”外，我没有在开发时间表上为各个功能规定交付日期。一个好的开发时间表应该是这样的——它只是简单地列出在每个里程碑期间需要实现的功能。那些“必须有”的功能放在第一个里程碑期间内并且都是要完成的，如何完成则是根据开发人员的数量和“困难/中等/容易”等级；“最好有”的功能放在第二个里程碑期间内；“希望有”的功能放在第三个里程碑期间内；除此之外的所有功能统统不做。通常情况下，如果到了第三个里程碑期间的第二周，仍然有较多“最好有”、“希望有”的功能没有实现，这时候大家都很惶恐，你就要把所有“希望有”的功能扔掉，并且“最好有”的功能也只保留一半。

作者注：里程碑的设定因团队而异，也因产品而异。典型情况下，一个里程碑跨越6～12周不等，是“项目日期”，是组织（50～5 000人）用于同步工作和复审项目计划的时间点。在里程碑期间，各个团队（3～10人）可能使用他们自己的方法来跟踪具体的工作，比如简单的工作条目（workitem）清单、产品备忘录及实施进程图。

译者注：产品备忘录（product backlog）是在项目开始的时候，需要准备一个根据商业价值优先级排好序的客户需求列表，是一个最终会交付给客户的产品特性列表，涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。实施进程（burndown）图是敏捷软件开发方法Scrum中常用的一种图表，用来展示剩余待完成工作与时间之间的关系。时间标识在横坐标轴上，未完成工作标识在纵坐标轴上。

风险管理

这才是我要引出的主题。在开发成本计算和时间安排上不能只盯着日期或时间不放，应该关注风险管理。我们通过软件的功能和特性来取悦客户，不管这是个软件套包还是网络服务。这里的风险指的是，我们未能在合适的时间，将符合质量要求的功能集合交付到客户手中。

一个好的开发时间表通过优先处理关键功能来管理风险。这些关键功能是能让客户满意的最小功能集合。通过“困难/中等/容易”这种评级方法，可以判断出在这个最小集合中包含哪些功能是切实可行的。其他的功能按照优先顺序和一致性原则依次加入。

然后你开始编写代码，并且看着功能实现从困难转向容易，又从容易转向困难。通过集中所有必要的资源，以降低不能按时交付高质量的“必须有”的功能的风险，其他的都是次要的。你还可以将不紧要、但又不失挑战性的项目交给实习生去做。

作者注：具有讽刺意味的是，几乎所有的工程师和经理都赞同优先处理“必须有”的功能，但事实上很少有人真的这么做，因为“必须有”的功能通常是乏味的，比如安装、软件工程创建、向后兼容性、性能优化和测试套件等。然而没有这些功能，你的产品根本就无法发布。因此，产品发布往往是因为这些问题而一拖再拖。

一定要破除“功能交付日期”的神话，因为开发人员专注于这种日期的时候会破坏风险管理。真正要关心的日期只能是“项目日期”，比如各个里程碑、测试版，等等，而绝不应该是“功能交付日期”。项目日期之间一般都有较长时间的间隔，而且这种日期不会很多。管理这几个日期要容易得多。如果要求开发人员在某个日期之前一定要实现某个功能，当他们不能按时完成时他们往往不会告诉你，而是对你说“我正在加紧做……我会加班……”之类的话。

在软件开发过程中进行风险管理，我们还要特别注意以下几个因素：一个是过度劳累的员工，一个是匆匆忙忙实现的、质量很差的功能，再一个就是你花费几周的时间且动用2～3位甚至更多的高级开发人员去解决一个棘手的问题。如果你的开发人员是在围绕“功能交付日期”付出大量的努力，而不是帮助你在产品的关键功能上降低风险，那么真有可能浪费时间了。

客户赢了

一个产品的成功与否，取决于你对关键功能的风险管理能力。当你给你的开发团队解释清楚这一点之后，情况就完全不一样了。当然，额外的功能可以锦上添花，但最关键的还是要专注于存在风险的地方，充分沟通，并一起努力把它们解决掉。

当所有人都理解了目标，所有人都能比以前工作得更好。每个艰巨任务的完成都能鼓舞士气，即使初级员工也会因为成熟的决议而得到回报。最终，我们的客户是大赢家，因为他们得到了真正想要的功能，并且产品质量也是他们当初所期望的，而不是一些勉强实现的、质量不能保证的垃圾。

顺便提一句，我对开发时间表的所有论述，对于测试时间表同样适用。

2001年10月1日：“竭尽所能，再论开发时间表”

该对我6月份的那个栏目（“开发时间表、飞猪和其他幻想”）的评论做出一些回应了。其实，大部分评论都是恭维之词，这里就不再赘述了，因为没有必要再次证明我有多么正确。我这里要做的是，回应一下那些对那个栏目还在无知中徘徊但又非常热情的读者朋友们。

作者注：这是我仅有的一个“邮包”栏目，收集了我对一些读者来信的回复。我还在持续不断地收到读者对我的栏目的大量“反馈”，但一旦一个栏目很受欢迎，很多新的话题便会涌现出来；讨论那些新话题的价值要远远超过对一个老话题邮件的回复。不管怎么样，当我回顾这个早期的栏目时，我意识到，可能Wright先生应该再次清空他的邮包了。

软件工程绝对是含糊的

我对关于不能也不应该对一个功能的开发做时间安排的论断表示怀疑。文中精确地论述了“编码”活动。遗憾的是，这是初中生干的事情——拼凑一个VB程序来解密信息、相互通信。我们可是软件工程师啊，不是电脑苦工。

——一个充满怀疑的无知者

我经常听到这种说法，但请就此打住。银行经理并不管理银行，软件工程师也不在软件上做工程。他们开发软件，定制软件，通常事无巨细、从头至尾参与其中，并不需要了解操作范围、公差、故障率、压力条件等度量标准。的确，我们的系统有这些标准，但这些标准不是为软件编码准备的。

我曾到一个工程学校进修过。我的朋友当中也有很多是电力、基建、航空、机械等方面的工程师。这些工程师做的项目，其构造模块和结构流程都经过了很好的定义和提炼，而且都是可预测的。虽然有时候为了达到客户的要求需要一个合适的设计，但只要用一种新颖的方法把各个模块组合在一起就很有创造性了，就算是最标新立异的建筑也会符合一定的公差要求，并且具有严格的可控质量和功能。

但对软件开发来说，情况就不一样了，尽管很多人竭力想让这两者达成一致。软件的各个构造模块太底层了，变数太多。它们之间的交互影响太难预料了。像Windows、Office、Visual Studio及MSN等大型软件系统的复杂度，已经远远超过了工程的正常范围，以致哪怕只在这些系统中做微小的功能改动，也无法粗略估计出这些改动所引起的“平均失效时间”。

因此无论好坏，还是抛开痴心妄想和崇高理想，回到现实中来吧！我们必须承认，我们是开发者，而不是工程师。我们不能奢望轻易得到传统的工程领域积累了成百上千年的经验才做到的“可预测性”。这无异于我们奢望：不用跟电脑说什么，电脑就能按照我们心里的想法去做事。我们还办不到！

作者注：在我写下这个栏目6年后的今天，微软已经对很多软件进行了“平均失效时间”的评估。除此之外，把编程当做工程看待的各种方法也逐渐出现了。这个我会在第5章的“软件发展之路——从雕虫小技到系统工程”栏目中再次介绍。纵然如此，我仍然认为本栏目很好地见证了软件开发作为一个专业领域，它已经走过了幼年，但跟它早已长大成人的传统工程兄弟相比，他还只是个十几岁的小朋友。

相信一半你看到的，别信你听到的

如果我在某个功能或者一段代码上依赖于另外一个团队或产品组，我肯定不想听到像“你要的东西应该可以在这个里程碑期间内完成”这样的说法。我需要一个很具体的交付日期。我要有具体细节。

——一个需要日期的人

我想写几个关于依赖关系和组件团队的栏目，也许将来会吧，但眼下我只想讨论依赖方的开发时间表。首先，假设你的依赖方确实有一份开发时间表，你会相信它吗？你也许会说：“当然要信，我有其他选择吗？”建议在你的胃病恶化之前赶紧吃一点PepcidTM（一种胃酸抑制剂）。不光只是开发时间表，不要相信依赖方所说的任何事情。如果他们坐在隔壁房间，他们告诉你外面正在下雨，你首先要做的是到自己的窗口去看一下。

但我并不是说你不能跟依赖方合作。相反，你应当与他们很好地合作，因为依赖方可能为你的团队、产品和客户带来大量的经验和意外的收获。我只是告诫你要高度警惕当前正在发生的事情。要向他们提出定期多次交付的要求，并对交付的东西进行自动化测试。获取他们对RAID进行读和写的RDQ，观察它们的数量以及存在问题的地方。派你的项目经理去参加他们的分诊会议。加入他们的邮件列表。

作者注：查一下本书最后的“术语表”，以便理解这些用于Bug跟踪的词汇。

基本上，你需要像鹰一样盯着依赖方。他们是你的团队和产品的一个扩充。你跟他们接触、沟通得越多，你在规避其短处以及促进其改变方面的能力就越强。至于他们承诺的功能什么时候能够完成，你必须依赖你在如下3个方面上的影响力：提高优先级，沟通渠道，独立测试（为了知道他们的功能是否真正可用了）。

激励：不能光靠比萨和啤酒

总的来说，你的观点用在项目早期的计划上还行，但对于产品发布前的最后一个里程碑就不那么合适了。时间表怎样提供最后期限和时间约束，让团队遵照执行，使得它能作为一种日常管理工具去激励团队的执行力？你必须要解决诸如此类的问题。

——一个找不到（汽车）油门的人

首先我要重申：如果你坚持让开发人员遵从“功能交付日期”，那他们为了准时交付可能会撒谎。他们会隐瞒自己的工作状态，会在质量和完成度上给你虚假信息。如果你不想你的开发团队这么对你的话，你必须建立起一个更好的激励机制。我用过3种不同的方法，这些方法能使大家互相协调工作并产生良好效果。

第一种，也是最基本的方法，就是应用里氏震级估计。我的开发人员知道，我期望的是每个功能在大致那么多的时间内完成。如果一个原先估计需要2周的任务实际上花了2周半，可能关系不大。但如果花的时间比原先估计的要长得多，那么通常是有实实在在的原因的，那个开发人员必然会让我知道这个原因。如果缺乏充分的理由去延期交付，则足以对开发人员形成一种鞭策。然而，因为没有卡得很死的日期，大家几乎不会去想到隐瞒和欺骗。

第二种激励工具是瞄准里程碑日期。这有招致大家走捷径的危险，但总体的效果是鼓励开发人员从一开始就努力工作，并且让他们对自己是否落后于进度做到心里有数。“功能交付日期”和里程碑日期关键的不同在于，后者是给整个团队设置的日期，需要整个团队一起努力去达到它。因此，个人抄近路的压力就会小很多。然而，这种危险性仍然无法杜绝，逼得我使出最后也是最有效的一招。

作者注：一个自我导向的团队向着一个清晰的共同目标一起努力，这是很多敏捷方法的核心概念，尽管在2001年我还不知道有敏捷方法。

最后一种激励工具是迄今为止我使用起来最有效的。我向团队解释清楚哪些功能是必须要有的，必须优先完成。我告诉他们，必要时任何其他的功能都可能被放弃不做。遗憾的是，这些必须要有的功能常常做起来比较乏味，没有意思，甚至不值得一提。因此我告诉我的团队，如果他们想要做那些很酷的功能，必须首先保质保量地完成之前的这些关键功能。之后，再去做那些不那么关键却要炫得多的东西。这种激励是积极的，有建设性的，并且非常有效。屡试不爽！

在日期上沉沦

继续前面的讨论：时间表在不同的功能单位之间（不只是开发，还有项目管理、测试、用户体验、市场推广、外部合作）同步工作时，绝对是必要的；你还必须要解决这个问题。

——一个出格的人

如果你确实需要具体的“功能交付日期”来同步各个方面和依赖方的工作，那么你的软件永远也没法发布。当然，我们的软件一直在发布——我们甚至准时发布了庞大的Office XP。要知道，它的发布日期是在两年之前计划的。因此，肯定存在其他的一些关键因素。

其实真正起决定作用的，是要在顺序、成本和方法上达成一致，并且提供及时的状态报告。各个方面之间要协商达成协议，定义好状态汇报的流程，并且避免工作的相互牵制。

 顺序：讨论协商各个功能实现的先后顺序已经不是什么新鲜事了，尽管有些部门从来都不能对优先顺序达成一致。

 成本：成本的协商通常发生在开发人员和项目经理之间（例如一个开发人员说：“如果我们使用标准控件，可以帮你节省2周的时间。”）但有时候就只是开发人员做决定。其实，成本的协商也应该让测试和实施人员参与进来。

 方法：讨论协商使用哪种方法通常在项目管理规范书中做，但很少在开发和测试的规范书中做——这对他们不利。

 状态汇报：至于状态的及时汇报，你务必要把邮件和测试发布文档（Test Release Document，TRD）登记起来，或者两者任选其一，以便让项目经理、测试和实施人员了解项目的进展情况。测试部门需要对阻碍工作继续进行的Bug使用警报。项目经理采用类似于“规范书变更请求”（Spec Change Request，SCR）的方式来汇报规范书的更改。（了解更多关于SCR的内容，可阅读第3章的“迟到的规范书：现实生活还是先天不足”栏目。）

如果各个不同的部门能够对他们的工作顺序进行合理的安排，知道各自的工作需要花费多少时间，对他们使用的方法也很有信心，并且保持着最新的状态报告，那么项目就上轨道了！问题找到了，风险降低了，意外也很少发生。更重要的是，没人顶着因为人为的交付日期而犯错的压力。相反，每个人都朝着同一个目标在努力——为我们的客户交付一个令人愉快的体验。