《代码之殇》（原书第2版）——第1章 项目管理失当 2002年5月1日

2002年5月1日：“我们还开心吗？分诊的乐趣”

如果你没有把这个概念搞清楚，请告诉我……

项目经理希望瞬间得到无穷多个功能，测试人员和服务营运人员希望永远也不要增加新的功能，而开发人员只想在不受外界干扰的环境下编码实现很酷的东西。现在，邀请这几个方面的主管，让他们带着相互冲突的理想去同一间房间，关上门，再给他们点可以用来打架的东西。会发生什么呢？分诊！

作者注：当产品开发问题涌现（比如未完成的工作条目、Bug或设计变更）出来时，它们都被记录在一个工作条目数据库中。分诊会议就是为了安排这些问题的优先级，并且决定每个问题如何解决而召开的。很多“冲突”（保守的说法）就是源自于这个会议。

译者注：关于分诊（Triage）。这是一种根据紧迫性和救活的可能性，在战场上决定哪些人优先治疗的方法。战地医学的基本原则之一是，如何将伤者划分为3类：①无论是否接受医疗都会死亡；②无论是否接受治疗都没有生命危险；③只有及时地接受医治才能保全性命。抛开它的病理本质，分类本身极其重要，只要你希望最大限度地保存有生力量。如果你不进行分类，结果将会比你做分类时要糟糕得多。

很庆幸，鲜血没有从分诊室的门缝中流出来。当然，这正是调解员要做的事情。大部分分诊会议都搞得像大屠杀一样。但必须要这样吗？我在微软见过的几次最激烈的争吵就发生在分诊会议室里。这样很糟糕吗？抑或就该这样子？

战争是地狱

参加过残酷的分诊会议的人，他们都会告诉你这样不好。即使你赢得了大部分的争论，你也会被这粗暴的分诊搞得精疲力竭。
基本上，病态的分诊和病态的团队常常同病相怜。它们在团队成员身上制造坏的“血液”，让他们常常产生报复性的、毫无建设性的行为。
为什么要这样呢？我们这里鼓励激情。我们想要人们为他们的信念而战，站在我们客户的立场上做出正确的决定。带一点点健康的竞争有问题吗？然而，当这竞争不是一点点也不健康时，那就不好了。

这不是个人的事情

不应该认为Bug是个人的事情，但事实却是这样的：
 对于发现Bug的那个测试人员来说，Bug代表着他工作的质量：“什么叫这个Bug不够好，无需修复？”
 对于定义这个功能的项目经理来说，Bug考验着他当初的设计：“那个Bug完全摧毁了这个功能的特色！”
 对于服务营运人员来说，Bug意味着实实在在的、可能永无穷尽的工作：“什么，你不关心这个Bug？反正不要你每天早上3点钟进办公室来重启服务器！”

作者注：关于早上3点钟重启的趣事。像大部分提供软件服务的公司一样，微软现在正在改变营运模式，不再提供每周7天、每天24小时的不间断电话服务了。取而代之的是，我们把服务设计成具有自愈能力（重试、重新开始、重启、重新镜像、重置机器）的系统。现在的服务营运人员只需在正常的上班时间，根据自动产生的替换清单对组件进行更换就行了。

 对于开发人员来说，Bug代表着一种个人的价值判断：“事情没那么糟糕吧！”
分诊所做的决定应该基于我们客户的利益和微软的利益，而不能光凭个人的感觉。然而，因为各个方面对于Bug有着各自不同的立场，分诊讨论转眼之间就会脱离轨道。

分诊的5条黄金法则

你怎样才能保证分诊正常地进行并且具有建设性呢？采纳我下面的5条黄金法则吧：
1.关上门。分诊是一个协商的过程，而协商最好在私底下进行。当做决定的过程保密时，大家更容易坦诚相见、相互妥协乃至达成一致。这也便于分诊的与会者把他们的决定作为团队的决定向其他人解释
。
2.所有的决定都是团队决定。当达成一致意见之后，所做的决定就不再是个人决定，而已经上升到了组织的高度。作为分诊团队中的一员，每个人都要无条件地支持这些决定。分诊的与会者应该具备为每个分诊决定做出辩解的能力，就好像这些决定完全出自于他自己一样
。
3.每个专职领域只派一名代表。分诊必须快刀斩乱麻。遗憾的是，参与的人越多，过程就越漫长；个人情绪掺杂得越多，一致的结论也越难达成。一个人做个决定可以很迅速，但你需要整合各个方面的观点来做出一个集思广益的选择。因此，折中的办法是，每个专职方面各派出一名代表参与讨论，从而兼顾效率的同时，使各方观点得以充分体现。

4.指定一个可以做最终决定的人。如果与会者不能达成一致，我们就需要有一个人做出最终决定——理想的话，这种情况不会发生。就我个人而言，我更倾向于让项目经理来做这个最终决定，因为项目经理本来就是做协调工作的，之后也是他的职责要去解释这些决定并让其付诸执行。他应该不会滥用这个特权。然而，真正的威胁还在于，可能会有某个工程方面的代表（绕开项目经理！）把他的决定强加给所有的与会者，这样也能让大家达成一致。

5.所有的决定都应遵从“贵格会”信条。这是最重要的一条法则。通常所说的“一致意见”意味着所有人都同意，但对于像分诊这样艰难、牵涉个人观点的事情，这个要求显然太高了。遵从“贵格会”信条只是意味着没有人反对——所有与会者必须为大家都能接受的解决方案而协同工作，只要不起冲突即可。这样就会产生一种很容易就能实现的、通常也是最理想的结果。（注意：这里说的“贵格会”只是指遵从相同信条的一类人，而不是有宗教信仰的那种。）

遵照上述5个法则，你的分诊就会充满热情、具有建设性并且富有效率。不过，下面我还要讲一些细节问题，以使得本栏目更加充实。

魔鬼藏在细节里面

这里有一些细节上面的处理技巧，可以让你的分诊会议开得更加顺利：
 如果你们的争论针对的是人，而不是Bug，你就需要把焦点转移到“做什么最有利于客户和长期股票价格”的话题上去。这种方法避开了讨论个人问题，同时把会议的焦点集中到了它本该集中的地方。

作者注：在所有的栏目中，我都在谈论要把注意力放在客户和业务上，而不是个人问题上。你可能想知道，为什么你不能只考虑客户，而不去管长期的股票价格。我对这个观点表示理解，但我也知道，如果我们的业务做得不好的话，我们也就没有客户了。因此，拥有一个商业计划来指引我们的工作，这对于为我们的客户提供可持续性的利益是很必要的。
 如果你对某个Bug或某个修复需要得到额外的信息，有时候你需要通过电话或亲自从分诊团队之外邀请一个人进来。请记住，当你完成提问之后，继续争论你们的决定之前，一定要送走这个访客。否则，分诊的机密性就会被破坏，所做的决定也就不再是分诊决定了。
 如果你想让你的团队中的某个人了解分诊过程，则可以邀请他加入一个分诊会议，但叮嘱他，务必在你们讨论期间要像趴在墙上的苍蝇那样保持安静，并且向他强调协商过程的机密性。

很难进行下去，不是吗

如果一个或几个分诊团队成员不能就某个问题达成一致，会议无法进行下去，就给他们一些“银弹”吧！游戏规则是，你任何时候都可以用银弹来获取特权，让大家遵从你的意见，但是子弹用掉一颗就少一颗，用完为止。当有人在某个问题上不肯屈服的时候，可以问他：“你想用一颗银弹吗？”如果用，其他人都要支持他的决定。通常这个人会说：“不，不，这事没那么重要。”然后，会议可以继续进行下去。

作者注：几年来，这个关于分诊的栏目引来了大量的争论，特别是上面关于“银弹”的这段。有些人抱怨不应该使用“子弹”这个字眼，而要用“令牌”。更多的抱怨是：一个关键的团队决定可能由某个人通过使用他的“银弹”做出，这个很危险！但实际上，这种事情永远也不会发生。“银弹”是一种稀有资源，它用来帮助它的主人提升问题的重要性。大家不会轻易使用它。因此，如果有人在一个关键问题上滥用一颗“银弹”的话，总会有其他人使用剩下的“银弹”去对抗他。尽管如此，我还从来没听说有这种事情发生呢！
最后，该到数据库中去解决分诊会议讨论过的Bug了：
 记得使用“分诊”标签去表示这是一个分诊会议决定。
 记得解释清楚分诊团队所做决定背后的考量。
 不要去“解决”Bug（尤其是外部Bug），除非你再也不想看到它了。通常情况下，团队把有碍产品发布的Bug标为“外部”或“待办”，意思是说，“我们现在不想处理这个Bug，以后会另行安排。”但如果那个Bug被“解决”了，它就落在了“雷达”能够扫描到的有效区域之外，相应的问题也就被隐藏了起来。

作者注：你可以在第2章“我烦扰你了吗？Bug报告”中看到关于Bug、优先级、分辨率的话题。

谨小慎微

分诊被证明是你需要对团队履行的最重要的职责之一。良性的分诊会议几乎总是跟良性的项目和项目组直接相关。这种关系的真正美妙之处在于，积极、富有成效且愉悦的分诊会议将给你的工作、你的团队带来同样的效果。但跟解决团队和项目的全部问题比起来，解决分诊中遇到的问题要容易得多，牵扯的人也要少得多。
再好不过的是，你们使分诊会议得以改善，并步入正轨，这可能会成为你一整天最快乐的事。当分诊的焦点是Bug而不是人，大家意见统一而不是相互攻讦时，那么会议的紧张气氛就会消散，纷争与挫败就会以诙谐的氛围而代之。健康良性的团队在一起工作，他们开的分诊会议常常充斥着俏皮话、玩笑、矫情讽刺和令人发笑的误述。对你的分诊技巧做一些适当的调整吧——你们的笑声可能会传到走廊上，久久回荡！最好总是关着门。

2004年12月1日：“向死亡进军”

曾经在一个死亡行军的项目组呆过吗？也许你现在所做的项目正是。这类项目有很多种定义，但基本上都可以归结为，“在太少的时间内要做太多事”。因此，你被要求在一段很长的时期内，每天工作很长的时间，以消除两者之间的矛盾。死亡行军因为其漫长、艰辛和伤亡重而得名。（如果我的说法伤害到了在第二次世界大战中真正经历过死亡行军的那些人的亲属，我道歉。不过，遗憾的是，软件中随处可见不当文字的使用。）
很难搞明白，为什么这么多项目组继续进行死亡行军，即使他们几乎肯定会失败，有时候还很悲壮！毕竟，毫无疑问，你在走向死亡。我看不出有任何诱因所在。

译者注：关于死亡行军（Death March），典出第二次世界大战太平洋战场的菲律宾群岛。1942年夏季，日军相继猛攻巴丹半岛和哥黎希律岛，美菲联军大败，美国远东军司令麦克阿瑟携夫人乘潜艇逃出战场。接替指挥战局的温赖特少将遵照白宫旨意，认为坚持抵抗只会造成无谓的伤亡，便命令全部美菲军队无条件投降。然后，日军派人把温赖特将军押送到中国沈阳，关入监狱。同时下令美菲所有被俘人员做长距离徒步行军，从巴丹半岛的马利维尔斯奔向位于圣费南多的俘虏营，行程长达1 000多公里。此时正值炎夏，病疫流行，粮食匮乏，日军对战俘更是恣意虐杀；等到达目的地的时候，死伤人数竟达25 000余人。几个月之后，有3名美国士兵从日军战俘营中侥幸逃出，越海到达澳大利亚的布利斯坦，揭开了这次死亡行军的秘密。

暗箭伤人

愚蠢的管理层继续热衷着死亡行军，他们暗箭伤人，因此我要拿出其中的几支“暗箭”来曝曝光。

作者注：死亡行军不只在微软才有，也不是只有微软才普遍存在这样的问题。这是我当初加入这个公司时发现的一个令我吃惊的事实。早在1995年我加入微软之前，这个公司就已经以工作时间长而闻名了。对此我很担心，因为我有一个两岁的儿子，并且计划再要一个。但我的上司明确地告诉我，死亡行军并不是公司的制度。他的话是对的，但当微软或其他公司的管理层仍然对这种愚蠢而又不可思议的做法抱有幻想时，那就是另外一回事了。

 管理层神经太大条。管理者做事情不考虑后果。他们采用傻瓜才用的方法：太多的工作要做吗？那就加油干吧！最起码，管理者可以辩解说，他们正在做着事情，哪怕做的可能都是错事。

 管理层天真得难以置信。管理者不知道死亡行军是注定要失败的。不知何故，好像他们在过去的25年里都在睡觉，或者从来就没有读过一本书、一篇文章，或没有访问过任何网络站点。他们认为，每天至少多工作4个小时，并且每周多增加2个工作日，将会使生产力翻倍。数学可以这么算，但遗憾的是，人是非线性的，不能这么简单地加减。

 管理层不切实际。管理者认为，他们的团队能够克服难以逾越的难题。规则和纪录将被打破。他们有世界上最好的团队，他们的团队能够应对任何挑战。显然，他们不明白速度超过一头牛（很难）与快过子弹（不可能）之间的区别。

 管理层没头脑、不负责任。管理者知道死亡行军必将失败，这个过程会摧毁他们的团队，但他们还是会蛮干，逞英雄。他们通过请客吃饭、评选明星和高分考核来奖励英雄行为。因为管理者知道，我们的客户和合作伙伴在下一次复审结束之前，是不会被我们交付的“垃圾”吓跑的。我觉得这些管理者是最该被拖去让史蒂夫痛斥一顿的。

作者注：史蒂夫是指史蒂夫·鲍尔默（Steve Ballmer），我们敬爱的CEO。他大力提倡工作与生活的平衡，并且以身作则。我曾多次看到他在他儿子的篮球比赛中加油呐喊，或者和他妻子一起在外面看电影。

 管理层都是些毫无责任感的懦夫。管理者知道死亡行军很难避免，但他们缺少勇气说“不”。因为，如果他们随大流，他们就不用承担什么责任，这些懦夫也不会因为项目失败负多大责任。当然，项目一旦失败，他们的员工会恨他们，并且离开团队，但至少他们还可以和跟他们一样懦弱、可怜的朋友分享“战争”的故事。

很多人都撰稿论述过在软件项目中死亡行军的无效性，但不知何故还是有人“慷慨赴死”。我无法说服那些不切实际、不负责任的人，但我可以开导那些神经大条、天真的人，并且教懦弱的人一些方法。

对失败的祈祷

给无知者的一些启迪——死亡行军之所以会失败，是因为：
 一开始就注定要失败。很明显，你有太多太多的事情要做，但你的时间远远不够。你必败无疑！

 怂恿大家走捷径。当你处在压力之下时，没什么比找一些省事的方法逃离工作更自然的了。遗憾的是，捷径降低质量，并且增加风险。这对于小功能或短期之内的项目或许关系不大。但随着项目不断深入，那些风险和糟糕的质量会贻害无穷。

 没有太多的时间去思考。项目需要松弛的时间来产生效率。大家需要时间去思考、阅读和讨论。没有这种时间，你就只能凭着仓促的判断去做事情。而仓促的判断往往是错误的，导致糟糕的设计、计划和质量，引来以后大量的返工或成堆的缺陷。

 没有太多的时间沟通。你说得对，沟通不畅和误解是所有麻烦之源。很多其他方面运作良好的项目，就是因为沟通上的问题才失败。当人们每天都要工作很长的时间，他们就无暇顾及沟通，效率也很低。沟通不畅成了一个难以逾越的障碍。

 制造紧张、压力和机能障碍。当有压力存在时，适意首先消失了。大家都自顾不暇。意外事件不断被扩大和曲解，抱怨声越来越多，甚至出现更坏的情况，大家不再说话。

 士气受挫、动力受损。辛酸、压力及长时间与家庭和朋友疏远，都使人的精神和人际关系折损。最终当项目难逃失败，错过了交付日期，也没有达到质量目标，人们常常会抓狂。如果幸运的话，你只是在项目结束之后转到另一个项目组继续工作。如果不那么幸运，你可能要离职、离婚、生病甚至有轻生的念头。

顺便说一下，管理者常常分不清一些员工在工作上长时间的自愿付出和死亡行军之间的差别。死亡行军是完全不同的概念。它们之间的区别在于，死亡行军强制你付出很多的时间。而当人们自愿时，常常是因为他们真的喜欢。这段时间里他们很放松，没有任何压力或理由去走捷径。

作者注：这是常被人们忽略的最关键的一点。自愿的长时间工作跟死亡行军绝对是不同的。

 信心在进程中消失。稍微有点智商的人就能意识到，死亡行军是对出现的问题的一种补救。这样做对于我们的员工、客户及合作伙伴来说不是奉献，是个人能力出了问题。只是埋头工作，回避真正的问题，只会更有损于他人对我们合作能力的评价。

 不妥善解决问题。工作更长时间不能解决那个真正导致“在太少的时间内要做太多事”的问题。除非这个问题根除了，否则别指望项目除了变得更坏之外能有其他进展。

 降低你的标准。当你已经走了捷径，引入了糟糕的设计和计划，产生了大量的返工和缺陷，打乱了你的信息沟通，怂恿大家相互挑刺，挫伤了员工的士气，摧毁了我们对交付能力的信心，结果还是无法达到质量目标和按期交付（以前遗留下来的任何问题都没有得到解决）时，你就别无选择了。通常这会导致降低质量门槛，将计划延后，然后继续死亡行军。“干得好啊！”

转折点
那么，如果你发现自己正面临着“在太少的时间内要做太多事”的情况，你应该怎么办呢？从务实的角度出发，答案非常简单，就是要搞清楚，为什么你会要做这么多的事情，而你却只剩下这么少的时间了。

答案不是“因为那是管理层设定的日期和需求”。为什么管理层设定那些日期和需求呢？如果你完不成某个需求，或者不能在某个日期按时交付，管理层会做什么？他们会将计划延后吗？延后多少？他们会减少功能需求吗？哪些功能会被减掉？你是否还能在过程或方法上做更多的根本性改变，以求力挽狂澜？告诉管理层，你的目标是达到所有的需求并按期交付，但你必须为最坏的情况做好打算。

然后为最坏的情况做打算。按可接受的最迟交付日期及最少功能制定一个计划。如果在有效时间内还是因为任务太多不能完成，就全面拉响警报！你的项目已胎死腹中。如果你为最坏情况所做的计划是完全可行的，那就要全力以赴。告诫你的员工，勤勉者可以在考核时得到35以上的分数，但偷懒者的分数必定在30以下。

作者注：这些数字源自于微软老一代的评分系统，分数取值范围为25~45（分数越高，奖励越丰厚）。分数30是可接受的，不过大部分人都想追求得到35或者更高的分数。

不寻常之路

你所做的努力使得项目避免了死亡行军，并且赢得了宽松的时间来改善。你的团队很可能比最低要求走得更远，但他们做到这些并没有走捷径，也没有做糟糕的决定或自相残杀。你将按时交付当初承诺的东西，并且使你的合作伙伴和客户建立起信心。

这听起来倒是合情合理，但其实在情感上很难接受。为最坏的情况做打算感觉像要放弃一样。你像是在示弱，好像你无力应对挑战似的。多么具有讽刺意味啊！事实上，情况恰恰相反。
不面对危机是懦弱的表现。假装最坏的情况不会发生，也只是自欺欺人和不负责任。拿出你的勇气来，面对现实！做事机灵一点，别在最后还要把痛苦留给你的合作伙伴、客户和员工。相反，这样体现了你的价值，你的团队、你的生活、你的自尊毫发无损。

作者注：在最近长达9个月的项目中，我的团队在关键的依赖性服务上拖延了3个月时间才完成整个项目，同时我的团队将原本要4个月时间才能完成的主体功能模块缩减为1个月来完成。我们不能延迟时间表也不能削减软件功能模块（我们已将这两者向客户做出承诺）。我们并没有经历死亡行军，相反，我们直接投入到一个与依赖性服务相关的开发环境中同步进行工作，就像这些服务已经完工一样。这种策略不仅补回了之前过多消耗的时间，而且减少了返工次数，因为我们可以在工程创建的早期就将回馈反应给依赖性服务开发团队。在客户相当满意的情况下我们及时发布了软件。事情很艰难而我的伙伴们工作很努力，但是他们同样有宽余的时间并感到快乐，他们只是出于对发布高质量产品的渴望及为他们的同事提供帮助的心愿。在产品发布后，我们没有一个人离开团队。