Get a handle on "normal" 培养正常的团队运作 法则38建培养正常的团队运作
253 在整个发过程中，前前后后的里程碑应该如何定义才 适当？有没有一种原则或特征来判断在每一个里程碑中的 团队行为是正常或病态？如何看出团队的领导有没有问 题？无论如何，一定要先知道什么是正常的团队运作，才 能做出诊断、治疗和预防。
诊 断
在软件开发过程中最困难的活动之一便是诊断─准确判断出团队行为和产品状态在不同时间所发 生的一切问题。因为创造软件的过程本来就是动态的， 充满合宜与冲突、愤怒与喜悦，团队的行为是变幻莫 测，基本上不能以组员的心情愉快与否、日程落后与 否、或是表面上的行为与事件来判断整个团队行为是 否正常。这种变幻莫测的本质，也使得领导人很难预 测治疗行动的结果。曾经有一次，我参加的一个团队因为时间表定 得太过自信，而且工作目标也定得高到几乎接近完成， 结果眼看着就要延误第一个里程碑（以下简称 M 1）， 此时大家都很紧张，幸而我们还算是个够健康的团队， 我们也知道前面的成功不代表后面一定成功，我们愿
254
意虚心检讨。 诊断有无繁杂在M 1阶段，这个团队深受目标过度膨胀所苦。 在M 1阶段的开发工作，使我们发现到有一些关键性 的功能特色，特别是典范性的功能特色（请参考法则3），显然在设计上有不够周详的地方，没有办法充分 支持我们所要传达的信息，这样的设计事实上无法达 到我们要改变使用者习惯的目的。于是我们激烈地争 论、辩证、思考，几乎使团队分裂。最后我们终于得 出结论，一个震憾性的超强新设计方案，大家都会为 它而振奋─但也大大增加了全体团队的工作负荷。 原本是改良目标，对软件有益的行动，却造成 了一个不良的副作用：只剩下三个星期就到 M 1了， 组员们还不能确定要不要开发新设计的特色？在旧设 计中是不是有些特色要取消？组员们搞不清楚这些特 色的优先级，如果要采用新的设计方案，由谁来做、何时做等等问题。旧设计也许不理想，但毕竟是我们 好不容易才凝聚起来的共识，就这样被打破再重新设 立目标吗？管理者在这样的情况下是否能坚持授权共 决的原则（特别是这些功能特色原本是他们主张的）， 法则38建培养正常的团队运作
255 而且不认为我们是在找麻烦？像这类不确定的问题多 得列不完。不难想象，这些问题使我们距离 M 1的目 标愈来愈远。
互相纠结的功能特色
256
就算没有工作量的增加，这种提高目标的事情 本身就极具争议性。在我们讨论新的设计方案时，显 然没有想到它会带来这么多的问题，所以不知不觉地 增加了许多特色，这等于是破坏了我们对团队的承诺。 不错，以团队的纪律来说我们可能很糟，但是我们确 实对新设计方案中的每一项特色都做过彻底的分析， 研究它对每个人或每件事的影响，并且取得了新的共 识，大家都同意这些新增的特色每一个都很重要，没 有包括这些的设计将造成产品的缺陷。我们的结论是 牺牲掉其他比较次要的特色，重新配置我们的人力， 尽量减少对进度的不利影响。现在，我们面临了翻案的后果：在决定采用新 设计的争论之后，我们回归到开发计划的现实，我们 的M 1订错了，而且时间上显然岌岌可危。我们集合 公司内所有的项目经理和品保人员，对现状做一个彻 底的评估，这次讨论的结果，可以说明在软件开发中 的一切事情都无法预知，但却是可以被管理得宜的 ─我喜欢这一点。 争论不休 有一些人认为，我们其实可以稍微放宽一些 M 1 法则38建培养正常的团队运作
257 的期望，依照旧设计做出 M 1的目标，在不影响原定 目标的前提之下，少做几个特色。毕竟这是第一个里 程碑，如果在实质意义上无法达到，至少要在形式上 做到。第二派意见认为，有无达到 M 1太难定论，一开 始目标就定得不够明确，那么即使 M 1目标的字面意 义也会有不同的解释。虽然基本上我们同意 M 1是应 该达成，但实质上我们却用新的设计且违背了原意。 第三派意见认为，我们是因为赶不上 M 1的时间 而狗急跳墙，他们认为这是我们不当地允许在 M 1目 标中出现多余的功能，现在则企图掩饰这些成本。我 们在鱼目混珠，模糊焦点，我们在欺骗自己，自以为 有团队纪律，自以为表里一致，事实上我们缺乏控制功能特色的能力，而不敢承认无法达成M1的事实。 最后，终于有人指出，我们根本不是在“繁杂”（featuritis），繁杂是不知不觉、毫无目标地乱加特色， 而且是小型特色，但是这些特色对团队共识和产品目 标没有关连。在我们新的设计中所增加的特色，本来 就是产品该有的，只是很不巧，这些特色都很小，以 致在原本的设计中被忽略了，但是这些小特色加起来
258
却对产品有重大的影响，而如今在 M 1的开发阶段发 现了它们，以致不得不宣告 M 1的延误。然而如果此 时没有发现这个问题，最后产品还是会因此而迟延。 就像疾病特别容易侵袭原本不健康的身体，“繁 杂”特别会伤害原本就不太健康的团队──也许是市 场中的落后者，或是对自身没有清楚认知的团队。在 健康的团队中，对于进度的落后自然会产生一种不安，但只有强烈的热忱和信念才会使团队相信这些新增特 色的重要性，而且困难终究会被克服。另一方面，太 多的不确定性和工作负荷，会削弱团队的免疫系统， 开始信心动摇，而不敢肯定这些新增的特色到底是不 是产品不可或缺的重心，还是又一个败笔。而此时若 是市场或顾客也产生变化，使得团队疯狂地大量新增 特色或是重新定义产品，最后必导致失败。我们在M 1所决定的新增特色，都是经过彻底的 分析，而且大家都有共识，愿意为了这个理想而承 受增加的工作负荷，所有的重要工作同仁都同意我 们为了这些特色，势必将进度延后。然而如果没有 这些特色，我们就无法改变使用者的习惯，也就失 去典范性功能特色的意义。为此我们的进度和人员 法则38建培养正常的团队运作
259 都得重新调整，但所有的人都同意，发展这些特色 是正确的决定。 M1的本质上述的结论对M 1是有特殊含义的，我们把这种 经验称为“M 1的本质”（M 1 - n e s s），以便与一般的病 态性团队行为有所区别。我们不认为这是“繁杂”（f e a t u r i t i s），因为我们确实地、彻底地、不遗余力地 分析过这些新增特色，这是与繁杂最大的差别。此外， 这次的设计翻案，确实是对原设计的缺失有重要的改 正，而这方面的贡献远超过纪律不良的负面影响。 基本上我们要了解， M 1正好是把这类问题理清 的时机，M 1可以让你发现原来设计时忽略或模糊的 地方、进度表上的弱点，以及再次凝聚团队共识，对 目标会有更清楚的概念。从这次有点惨烈的经验中， 我的结论是：从此以后大家对 M 1都特别注意，修订 M1的目标必须有团队共识，而且确实可以达成。 下载
法则 39
A handful of milestones is a handful 里程碑不宜太多，才 好掌握 法则39建里程碑不宜太多，才好掌握
261 有很多人主张，六星期到三个月是里程碑之间比较理 想的时间间隔（i n t e r v a l）。如果你的团队比较小（譬如十 到二十人左右），或是目标较小，就可以用比较多的里程 碑，因为里程碑对小型团队的额外负担（o v e r h e a d）会比 较少。而小型团队如果经历过比较多的里程碑，会迅速成 长和凝聚共同文化（请参考法则7），这是附带的好处。但是以我的看法，任何团队的里程碑数目如果超过７ 个，就过多了，至少是个不寻常的现象。因为在一般情况 下，任何人都无法预测那么远的未来。我的经验是三到四 个里程碑，再加上要推出的那一个，应该是最理想的数目 （请参考法则18）。
太多的里程碑反而难以掌握 下载
法则 40
Every little milestone has a meaning (story) all its own 每一个里程碑应有专 属的宗旨 法则40建每一个里程碑应有专属的宗旨
263 每一个里程碑，无论大小，都应该有它成立的理由。 记得我们刚刚在谈论M 1的本质时，提过团队内部发生的 激烈争辩吧，我们希望达成 M 1实质上的精神，不亚于我 们希望达成M 1形式上的目标。里程碑的宗旨就是设立它 的理由，可以被简短的一两句话表达，同时也能描述达到 这个里程碑对团队的意义。就理论上来说，任何对里程碑 的争论都可以回归到它的宗旨而获得解决。里程碑的宗旨 可以清楚地表达它的目标，我故意不称它为里程碑的目标， 因为里程碑的宗旨应该包括了团队与它的互动、团队的士 气，以及里程碑所隐含的信息，也就是包含了它全面的意 义。如果单从M 1的目标来看，大部分的人都无法产生去 达成它的动机，或是联想到它所代表的报酬， M 1的目标 是一大串的菜单列，是我们要去做的工作（虽然目标也可 能是错的，谁教软件这么不确定呢）。一张清单不能引起 人们的热情、专注，以做出伟大的软件为理想。人们只有 为了有意义的事情才会愿意牺牲奉献，只有里程碑的宗旨 才能让人们愿意付出自己的心灵、精力去换取某种结果。在Visual C++的开发过程中，有几个不错的里程碑宗 旨，值得参考。在典型的第一次里程碑，我们通常会把目 标放在“狗食理论”（d o g f o o d i n g），意思是要使用开发中
264
的产品，才知道应该如何进一步开发(Dogfooding is using the product under development to further the development e ff o r t .）。这是源自行销学的理论，原创者是史提夫·巴摩(teve Ballmer），由微软将之发扬光大，他的名言是：“狗 食工厂应该试吃自己生产的狗食。只有亲身试用自己的产 品，才会真正了解自己的产品。”对于像Visual C++这样 的程序开发工具，这个概念尤其重要，因为它就是用自己 早期的开发工具写出来的。对于我们团队而言，彻底实践 狗食理论的意义是，新版本一定要比旧版本更具生产力， 即使新版本尚未完工或还有错虫。表面上我们没有特别强 调狗食理论：管理者不会每天巡视办公室看看是不是大家 都在试用自己开发的软件。然而，全体开发团队都太清楚 狗食理论对我们的重要性：如果我们在每一个组件上都发 挥狗食理论的精神，我们的产品一定会变得愈来愈好。借 着经常使用自己开发的软件，我们找到了所有的错虫和瑕 疵，生产力提升了，也更懂得掌握设计的效率。
新版本的试用者通常是精挑细选过的。 法则40建每一个里程碑应有专属的宗旨
265 另一点是我们在拟定里程碑的宗旨时会特别注意“什 么时候将什么产品交给什么人”。为了保护我们自己的荣 誉，将新版本交付出去时会特别小心，通常对象都是选择 性的，因为在错误的时机交给错误的人会造成团队额外的 工作负担。因此，里程碑可以说是我们准备将中间产品交 给某些早期客户来试用。所以，我们第一个里程碑的宗旨是：“所有的产品组 件都已经被开发团队试用过，并准备将中间产品交给微软 内部的单位试用。”简单的说法就是“内部试吃狗食”。而 后面一点的（就算是第三个吧）里程碑，它的宗旨也许是：“所有的特色都已经完成，而且软件的使用者接口也不再 更动，准备交给一些外部顾客试用。” 里程碑宗旨的关键点在于： 宗旨必须点出里程碑的精神所在。 判断这个里程碑有没有达到，是看里程碑的宗旨是 否被实现。 在开始工作以前，所有的人都已经充分明白并接受 这个里程碑的宗旨。 下载
法则 41
Look for the natural milestones 寻找自然出现的里程碑 法则41建寻找自然出现的里程碑
267 虽然很难精确地把软件开发过程依时间顺序通通记录 下来，但有一些事情是必定会自然发生，而且对整个开发 活动就像是分水岭一样，有划分的作用，这就是自然出现 的里程碑。请注意我所谓自然出现的里程碑，是指“正常” 的，而不是“常见”的，正常的是指开发过程本身没有重 大问题。以下是六种自然出现的里程碑： 1. 产品设计趋于稳定。 2. 中间产品被明确定义。3.团队真正了解要花多少时间和努力才能完成目 标（通常这会发生很多次，而且多半是进度落后的时 候）。4. 产品设计被删减，或是资源增加，或是进度延误， 或是三者同时发生。 5. 开发活动停止。6. 产品进入除错或稳定阶段。 这六个自然的里程碑不仅在整个开发过程中出现，也会在单一的里程碑中出现。稍后我们会用较大的篇幅详细 讨论，但现在请大家注意的是，每一个里程碑所意味的行 动，跟所有的里程碑加起来所意味的行动，应该是相同的， 跟整个技术计划所意味的行动，也应该相同。
268
健康的团队在每一个里程碑所表现的行为应该是可预 见的，称作“里程碑的自然模式”（metamilestone pattern）， 管理者应该予以重视和培养。如果里程碑的自然模式没有 出现，就代表团队出了问题，管理者应该采取某些治疗的 行动。到目前为止，我所观察到的自然里程碑可以归纳为 六种事件，但各种事件会持续多久则是无法预测的，比较 可以确定的是，前一个事件结束时，下一个事件一定要跟 着出现，前后事件之间可能会有重叠，或是几乎同时发 生；这些事件会依序发生或是同时发生，是取决于团队的 沟通频宽，在沟通性强的团队中，信息传递得像病毒一样 快，这六个事件就比较可能同时发生。 第一个里程碑：设计趋于稳定最开始的时候，由许多特色组成的产品设计是非常抽 象的，是一种令人又兴奋又迷惑的东西，兴奋是因为自己 的想法或创意即将实现，迷惑是因为不太确定它究竟是什 么模样。一切的人事物（技术计划、团队共识在里程碑之 前已经形成）都显示出有这些特色是要完成的，但真的问 起来，又没有人确切知道该由谁、在什么时候、做什么事 情，才能完成这些特色。这种情况我称之为“软件梦想综 合症”（the software dream syndrome）。在产品的设计阶段， 法则41建寻找自然出现的里程碑
269 这种细节不明的现象会不断地重复出现，直到详细的工作 分配形成为止。也许你会听到开发人员说：“喔，是的，我们当然要 在第一个里程碑中加入f o o t b a r的功能；我正在弄出它大概 的模样给你瞧瞧。”而品保人员可能会说：“Wi d g e t的特色确定要在第二 个里程碑中开始动工，但我还不知道该由谁来负责开发。” 在传统上，或者说至少是在有制度的公司内，对于 程序开发一般都要有几项文件的前置作业，包括需求描 述、档案或数据库规格定义、各种程序逻辑图等等，不 胜枚举。虽然这些文件有助于将程序要做的事情具体化， 容易厘清细节，但是基于以下的理由，我个人反对花时 间做这些文件： 在设计趋于稳定之前必会频频修改，因此使得文件 一再重做，结果保持文件的更新变成了一种道德或 服从命令，而不是因为事实上真有这个需要。 遵守很快就会过时的文件来做事，势必限制了弹性， 错失宝贵的机会，而且对健康的团队来说是负担的 加重。 文件的作用是在开发工作开始前，把所有的事情都
270
确定下来，结果也会限制了程序的发展。与软件有 关的很多事情是在开发过程中，才会确定该怎么做 的，而且这时候才能确定怎么做最好，有时候开发 人员会有意想不到的创意，为产品增色。所以，如 果将软件中未知的部分完全排除，就等于是宣告软 件的结束，而非开始。 在软件开发的过程中，最重要的事情不是做出你承诺要做的事，而是在有限的时间、资源限制下，从各种可能 的方式中做出最明智的选择，使结果达到最佳化。产品设计会藉助组员之间各种形式─电子邮件、规 格定义、产品模型、交谊厅的聊天、用白板的小组讨论─的沟通、讨论，而由变动渐渐趋于稳定，当产品设计 逐渐确定，下一个阶段就可以准备开始。管理者应该注意 是不是所有的争议都已经被共识所平息，检查是不是所有 的功能特色都包括在设计中，是不是所有的人对产品设计 的认知都很类似，如果答案是以上皆是，就可以进入下一 个阶段，否则产品设计还不能算是成熟。 第二个里程碑：中间产品被明确定义如果能用清楚、简明又可信的方式来表达中间产品， 没有含糊、复杂或诡异，就可以说“中间产品被明确定义”。 法则41建寻找自然出现的里程碑
271 在项目正式进入开发阶段时，以及需要检验里程碑是否达 成时，我们需要的都是明确的定义：产品究竟该是什么模 样、有什么工作要做完、由谁来负责完成、品质的要求到 什么程度，这些都需要有明确的估计值，虽然不必要和照 片一样的精确程度，但至少要像印象派画作一样的明确。 随着产品设计的确立，品保人员、项目经理、开发人 员和文件人员就可以组成特色小组了，特色小组各自将负责开发的特色具体化，更清楚地描述他们的需求和目的。 他们开始花大量时间讨论和沟通，因为他们有共同的目标 和工作，他们关心的是同一件事，而他们对产品设计的认 知也相同，于是，开发的细部工作项目逐渐在组员的心中 自然成形，为了将这些工作依时间先后顺序安排，并拟出 进度的草案，沟通和协商也许要重新展开。第三个里程碑：团队真正了解要花多少时间和努力才 能完成目标当然啦，在你完成开发工作之前，你永远无法得知真 正所需的时间。当产品设计定案，中间产品被明确定义， 组员会有一种幻灭似的失落感，第一、因为产品的外观似 乎不如想象中的美丽，第二、真正该做的事永远比想象中 的多，第三、团队发现自己需要更多的资源、较小的目标、
272
更多的时间─或者以上皆是。 在这个时候，无论团队多么经验丰富、领导多么卓越，总是有一股失望的气氛在弥漫着，那是一种抑郁而消沉的 感受，好像自己被击垮一样。其实这是个好现象，表示组 员们对事实有进一步的认识，往后才会因为明白事实而感 到自在。幻灭是成长的开始，“软件梦想综合症”于是消 失。在健康的团队中，对事实的认识会引发另一波行动的 高潮，在我的团队中，我们把它称作“战斗会议”（w a r room meeting），我们会连续开好几个小时的会，来检讨 我们现阶段的状况，并研究出问题的对策。
团队中弥漫着一股失望的气氛，那 是一种抑郁而消沉的感受，好像自 己被击垮一样。
在前三个自然里程碑中，最重要的事情是：解决那些 应该理清的未知。然而，当事情一旦被弄清楚，工作通常 是只会多不会少（模糊的面孔比较美丽吧），组员可能会 被平添的信息吓住，但是健康的团队会面对这种情况，设 下载
法克服恐惧。 微软团队·成 功 秘 诀法则41建寻找自然出现的里程碑
273
第四个里程碑：产品设计被删减，或是资源增加，或 是进度延误，或是三者同时发生在这个阶段中，团队会利用“软件的三角形”（请参 考法则2 8）来解决所遇到的冲突。如果一切顺利，这时候 时间应该刚好是整个项目（或是某一个人为的里程碑）的 前四分之一。我们很有理由相信，愈是健康的团队，前三 个里程碑会走得愈快，并且会有充分的时间来解决三角形 告诉他们的冲突，或是重新建立共识，这差不多是该对里 程碑计划稍加修正的时候了。如果一切顺利，虽然对里程 碑的某些期望可能需要调整──也许是有些特色要取消、 也许得增加一些资源等等，里程碑的宗旨应该是到现在还 维持不变。
在里程碑到达之前，谁也无法保证 你能如期到达。
健康的团队会在此时展现出弹性和反应能力，以准确 地达到这个里程碑的要求。你不会希望里程碑延期，这是
274
最后的手段；你也不愿意见到资源被无限地要求增加。在 这时候，你最需要看见的是组员之间形成了无数的承诺， 培养出解决问题的效率，并准备好表现出最优异的里程碑 行为模式。 第五个里程碑：开发活动停止在某一个时间点，所有撰写程序的动作会全部停止， 也就是特色全部开发完毕，此时必须禁止一切修改，以便 软件进入完成和稳定阶段。开发工作完成后就不必再写或 改程序，这听起来好像是废话，但事实上有必要特别标出 这一个里程碑，因为原本预估的时间需求可能不对，这个 里程碑等于是计算耗用时间的依据。必须确定软件不再需 要开发活动，才算到达这个里程碑。 第六个里程碑：产品进入除错或稳定阶段如果你能估出“净除错能力”（net bug fix capacity）， 即“错虫清除率”（bug fix rate ）减去“错虫发现率”（bug find rate），而且“净除错能力”是正值，那就差不 多可以算出第六个里程碑要花多少时间。而且基于本次的 经验，对于以后类似的项目，就可以降低“错虫发现率”， 并达到更高的软件正确性。这时候你需要找出这些问题的 答案：有多少错虫？要多久才能把错虫全部清除？有多少 法则41建寻找自然出现的里程碑
275 比例的程序代码需要整个重新检讨（regression rate）？ 当这些问题被认真地讨论时，你大概快接近里程碑的尾声，而且所有能发现的错虫全都被清除了。你会发现利 用错误等级评估法（bug triage）来解决问题，会比随抓随 改的方式要轻松多了。 下载
法则 42
When you slip, don't fall 如果滑了一跤，别就 此倒地不起 法则42建如果滑了一跤，别就此倒地不起
277 进度落后（s l i p）？不要紧，这并不是世界末日，就 像感冒发烧一样，令人不舒服，但也表示身体正在自我 治疗。从另一个角度看，进度落后是团队从软件的梦幻中惊 醒，开始面对现实。好像一种醒悟，一种“现在，我懂了” 的心情。进度落后像是从一个怪异的、层层包裹着你的梦 境，当你从第一层梦境中醒来，想道：“好吧，现在我醒 了，我刚才是怎么了？三个月来竟然蠢到完全没发现这个 明显的错误—延误了footbar？啊！我终于醒了。”
若把进度落后当成道德上的罪孽， 人们就会全力拒绝面对它。
三个月之后，也许是三个星期之后，你又发现了一个 明显的延误，你又想道：“哇，这次我真的是醒了，现在， 我懂了。”每一次的觉醒都让你进入一个“真实”的世界， 但也许有一天你再次从这个“真实”的世界醒来，发现刚 才的“真实”其实不是真正的真实。 你可以把这种不断的觉醒当作成长的过程。当然，每
278
一回觉醒都带给你更多的知识和经验，并让你更接近真实， 更丰富你的人生。这个多层梦境的醒悟计数器是每个新项 目从零开始，每一次觉醒加1，如果你已经有了n次觉醒的 经验，你就是从n开始你的醒悟计数器。任何项目都有可能碰到进度落后和觉醒，但有些觉醒 不一定是跟随进度落后而来，这很有可能，但有点危险， 并且不是好事。以下是你对进度落后应有的正确观念： 进度落后与道德无关，请切记！这并不是失败或做 错事，应该受到责罚，这是创造智能财产过程中无 法避免的。千万不要有道德上的罪恶感或良心上的 负担，并且要求你的团队也要这么想。因为组员们 最怕被威权形象责备，他们会因此而陷入一种很微 妙的精神压力中，在讨论时拖拖拉拉不着边际，在 恐惧犯错和渴望荣耀之间挣扎，在责难和赞誉之间 游移，结果会尽全力摆脱这种压力，会胡思乱想， 因此而消耗所有的心力。所以，千万不要让任何人 对进度落后有道德上的联想，认为这是不应该或不 对的事情。 不要隐瞒事实。人在遭遇冲突或危险时，一定但愿 没这回事，而有逃避的倾向。在进度落后时，你和 法则42建如果滑了一跤，别就此倒地不起
279 组员们都难免会不想谈它，但这时候特别要克服这 种天性，发挥你卓越的领导力，把事情变得不一样。 不要瑟缩在你的办公室中。喃喃自语：“我不敢去 看，进度迟延了，不，我不相信有这种事” 勇敢地走出去面对问题，你要打败问题，而不是逃 避问题。 化阻力为助力，利用进度落后来激发效率。对于进 度落后的认知是一种醒悟，组员们开始有重新振作 的精神，有最新的信息，有最新的看法，创意和想 象力也可能有新的境界，领导者必须得把这些新兴 的朝气导向最有效用的地方，不要管传统规矩的包 袱，进度落后是考验团队弹性的最佳时机。 进度落后不是问题，被进度落后吓倒才是问题。进度落后并不代表产品的难度太高而无法开发。但是如果进度 已经落后却未被察觉，那表示组员们不思考、不观察、不 讨论，此时组织可说是濒临瓦解了。善用你的迟延，这是最能看出你领导能力的时候，此 时也是组员最脆弱也最需要你的时候，在这个时候组员最 能把你的话听进去，此时组员的学习能力最强。如果你在 办公室内激动得大喊大叫，指天骂地，那就错失了赢得组
280
员的心的大好机会。你必须说：“O K，进度落后了，让我 们来看看问题出在那里？今天下午五点在会议室，我 们要检讨每一个细节，问题一定要设法解决！”当组员了 解到你不是企图卸责或算帐，而是真诚地想解决问题，就 会乐意把一切开诚布公地摊开来谈，大家一起研究问题， 从各种角度去设法克服问题。“进度落后”反而变成大家 宝贵的成长经验。
进度落后 里程碑达到了吗？其实这个问题很难有完全客 观的衡量标准。由于产品设计可能会变，而品质本身 就是无形的，所以里程碑的到期日也可能会变，因此， 里程碑到达与否，变成了一种人为的判断：当需要回 头修改的项目愈来愈少、里程碑的宗旨达成、组员对 于下一个里程碑跃跃欲试时，你差不多可以宣布里程 碑成功。当然这一刻是很难决定的。对于这个问题， 我只能举个反面的例子来说明这个观念：比方说你去 问路，人家的回答是：“你一直往前走，若是看到尖 塔教堂，就表示走过头了。”如果你已经接近里程碑， 但开发活动还在进行，就表示已经走过头了。身为领 法则42建如果滑了一跤，别就此倒地不起
281 导者，你必须时时掌握软件的一切状态，必须知道在 每一个阶段应该进行那些活动，又该停止那些活动。 曾经有一次（也许不只是曾经），我们接近M1了，但一切工作都陷入混乱，我们只剩下两星期，而软件 的情况却糟得难以想象：错虫数（ bugs count）实在 太高了，虽然每个程序设计师的错虫率还在合理范围， 但加起来的错误率却高得惊人，从我们每天的错虫增 加数目显示出软件距离稳定还差得很远。我们没有办法每天做软件建构（请参考法则32）， 虽然主要的产品组件多半都能建构成功，但就是有那 么几个不成的，表面上都能编译和连结（ compile &l i n k），但就是建构不起来。这个问题大大地妨碍了 下一步骤工作：“猎犬测试”（s n i ff test）和程序代码 分析。当其中的一个定点问题好不容易被找出来解决， 这至少又花掉了一天的时间（请记得，在里程碑的后 期，一天就可能耗用是百分之十的资源）。组员和领导者并没有感到特别紧张，通常在接 近里程碑的时候，组员们都知道自己已经尽力，但 不知怎地，就是觉得不对劲，里程碑的精神似乎不 见了。
282
事实上，这个问题的主要原因（也是一般常见 的状况）是出在沟通和协调不良，起于至微而酿成巨 祸。当一只程序置入时，就改变了另一只程序的假设 前提，结果另一只程序就遇到了意料之外的状况。A 小组依赖B小组的公用程序，A小组改好也测试过了 自己的程序，但前提是 B小组维持在第 n版，然而Ｂ 小组却改到了第n＋1版，虽然改得很少，但恰好是悠 关A小组的部分， B小组误以为不会影响 A小组的程 序，所以没有告知A小组，结果A小组的程序就建构 不起来，因为它应该与B小组的第n版搭配，结果B小 组已经置入了第n＋1版的程序。 领导人应该制止这种情况吗？绝大多数的项目经理一旦发现这种情况，第一 个反应是采取补救行动─成立特别小组来接管事 务。但是这么做可能会造成一些问题：最严重的是， 这种行动的代价甚高，虽然这么做一定会使组员非常 注意软件的状态和风险─我把这种活动称作“强烈 焦点”（radical focus）─你等于是用领导者的职权 来使组员就范，这种敲响警钟的方法不能太常用，否 则团队就会发生“狼嚎症状”（cry wolf syndrome）， 法则42建如果滑了一跤，别就此倒地不起
283 懒得对老板太认真，老板只是叫得凄厉而已。如果进度落后的情况太频繁，是很危险的。进 度落后变成正常的事，此时运用领导者的威严来提 高团队的危机感，这种手段只有在士气低落时才适 用，这时团队需要一点刺激，就是“强烈焦点”活 动：让小组在同一时间内担负几个小项目（大概不 超过两个），但是这几个项目的目标是南辕北辙、毫 不相干的。而当“强烈焦点”展开时，即使是健康的团队也 多少会反弹，觉得领导人在“反授权”（d i s e m p o w e r- m e n t），于是一切不顺利的牢骚都算在“当权官员” 的帐上，把这项措施解释成不尊重团队和团队的决定。 防卫心理升起，而且开始情绪不平，甚至可能因此怨 恨起来。即使是最优秀的领导者在采取“强烈焦点” 措施时都会遭遇一段抗拒期。在违反对方的意愿之下 教育他，虽然做得到，但要辛苦很久。同时，你要和团队中最优秀开发人员的反抗权 威心理作战，他们可能不会很好沟通，而直接把你当 成笨蛋（请参考法则4）。在另一方面，你也有可能误 判士气的低落程度，这时候麻烦就大了，健康的团队
284
会对你反弹，如果你死不认错就会丧失组员对你的尊 敬和忠诚，要不就是你的自大使你愈走愈远；而团队 如果不是那么健康，不敢对你谏言，那你绝对会陷入 万劫不复的失败。在你决定采用“强烈焦点”时，以上所谈的故 事都是你的成本和风险。你的“固定成本”至少是几 个工作天（大概一星期左右），而你必须抓住组员的 注意力，保持他们的兴趣，让组员明白你是玩真的， 让他们愿意告诉你心里的感受，让他们开始做点实际 的事情。在这个起步阶段所需的时间视团队的大小、 沟通的意愿与能力而定。现在我们回到接近第一个里程碑时的原地踏步， 领导者要团队有什么样清楚的认识（ a w a r e n e s s）？ 如何做到这一点？然后会引起什么行为？在我们的案例中，要团队清楚认知的是 M 1迫在 眉睫，而且除非过了 M 1这一关，否则我们不可能完 成产品；我们也希望让团队练习使软件“整装待发”、 完工交货；最后，我们希望团队经历一下不成熟的 团队合作所带来的可怕后果，而从中学到我们每一 个人都有等量的责任，也是全部的责任-就是达成M 1 下载
里程碑。 微软团队·成 功 秘 诀法则42建如果滑了一跤，别就此倒地不起
285
在我们的案例中，“强烈焦点”的施行是不合适 的，因为团队的问题不在士气低落，而且事后发现， 团队的反弹非常强烈。我们应该为真正的紧急情况保 留子弹。 那该怎么办？很明显地，我们不可能让整个投资都押 M 1这个 岌岌可危的一注，我们知道一定不能让问题持续下去。 我们现在正处于瓶颈，无法建构软件的不良效应正扩 散开来，这一点可以从超高的错虫率可以证明。大家 对程序的置入动作更谨慎，必须得仔细检查是否会妨 碍到别人的程序，也就是速度慢了很多。错虫数仍然 居高不下，为了除虫而做的修改仍然会发生前述版本 不同步的问题。当软件无法建构的状态持续太久，会 使得更多的程序搭配到别人的旧版本，结果使得软件 建构更加成功无望。我们很关心这种情况，组员对危 机的感受度似乎无法和工作的进度成正比。团队合作是相互影响的。为了完成整体的工作， 你必须划分出局部的工作。你可能让三人或四人组成 一个小组，这一小撮人的影响力就会扩及全部的团队
286
或工作，相对地，这一小组的失败也会扩散到全体， 导致软件严重的伤害。此时你的重心集中放在问题根 源的小组，这会比企图整顿全体，结果却头痛医头脚 痛医脚地到处乱转要有效得多。我们经过一番诊断和试疗，终于决定：在我们 做到每天都建构成功以前，禁止所有的程序置入。有 三个主要的原因迫使我们非这么做不可：第一、没有 协调妥当的置入动作，会使很多其他的小组受到影响， 最后使得大家都无所适从；第二、负责建构的小组经 验不足，因为建构的任务不久前才从开发部门转移到 品保部门；第三、有一个小组总是通不过测试，它是 问题的根源。好吧，以上这些症状，告诉我们什么？这个团 队的心理状态到底出了什么问题？ 看看团队出了什么问题？在起始阶段我曾经提过的一项理论：从软件能 够看出团队的心理状况（ p s y c h e）。现在事情不对头 了，团队显然无法发挥应有的工作效能，此时你必须 问问自己，团队的这些行为是否透露出什么样信息？ 首先，我们来看软件始终无法建构的问题，协 法则42建如果滑了一跤，别就此倒地不起
287 调不良的程序置入动作（surprise check-in）代表团队 缺乏整体性的自我认知：小组之间缺乏交谈。每天的 开发目标和程序撰写都是纯组内的，小组之间的程序 开发动作太不协调，彼此相互掣肘。每一个小组单独 来看差不多都是朝着M 1的目标前进，但每个小组的 工作成果却无法组成产品。个别组员的贡献在组内都 很不错，但到了组外就完全看不出来。第二个问题是建构小组的经验不足。品保人员 没有做过建构，以前都是由最资深的开发人员负责每 天的建构。这一群开发人员在技术上有足够的能力解 决任何建构失败的问题，因此开发人员已经习惯对于 建构小组期望过高。这一群资深开发人员像看门狗一 样为软件建构把关，解决任何问题，甚至指导其他人 关于程序开发的知识和技巧。而新接手的品保人员没 有办法对软件（和其他开发人员）照顾得那么细微， 没有技术能力来立刻解决建构失败的问题（例如d e b u g），而且这也不是品保人员的责任。另一方面， 品保人员正试着融入团队文化，过去是开发人员最大， 现在开始要在团队中建立品保人员应有的角色及工作 模式，品保人员一时还无法坚决地要求开发人员把程
288
序改到什么地步。因此，开发人员对于建构小组的“不良”工作 表现觉得失望，无形中，开发人员开始认为建构小组 都是笨蛋，他们已经习惯有资深高手替自己修缮程序， 程序设计设计师（尤其是那些负责核心部分的）已经 被宠坏了，忘记去思考自己的程序与整个软件的关系， 也不认为自己的程序必须处处配合别的程序才行，每 个人都认为我只管写自己的程序，建构成不成功不关 我的事。现在资深的保姆不再为大家打点这个清理那 个，每天都有高品质的程序是每位开发人员的责任。 建构小组的工作是把品质好的程序建构成品质好的软 件，维护可预测的建构程序和结果，找出瓶颈所在， 并且监督开发人员改正自己的程序。开发人员对于这 项责任归属一开始当然是不情不愿的，他们原本对于 建构失败的反应是“建构小组今天没把事情做好”， 现在，要把他们的观念转变为“是今天的程序不够好 而无法建构”。第三个问题是有一组总是做不好，他们的程序 总是无法建构成功或趋向稳定，一直通不过测试。这 并不意外，这部分程序长久以来受到忽视，没有足够 法则42建如果滑了一跤，别就此倒地不起
289 的开发和品保人员照料，项目经理根本没有为它付出 关爱，也许每天的建构失败就是它的不平和控诉吧！ 这一部分程序对产品而言其实是挺重要的，只是不知 道为什么它老是被当成二等公民。于是我们重新分配 资源，拨出足够的人力来把它弄好，我们得补偿过去 对它的忽视和差别待遇。从团队的心理状态或产品本 身，都可以清楚看出我们过去没有给这一部分程序应 有的重视。总而言之，团队没有协调好，责任没有划分清 楚，而且没有相互为对方的程序负责、全体共同对软 件负责的成熟心态，管理者也疏于分配资源到适当的 地方。等到我们把问题诊断清楚，收回“强烈焦点” 的错误措施，开始真正对症下药的治疗行动。 让组员学习彼此互相配合很明显地，由于团队缺乏共同的任务认知，小 组与小组之间既不交谈，也不会朝共同的工作目标努 力，因此我们必须充分利用团队工作的扩散效应。也 就是说，如果你在某处解决了一个问题，就等于是对 全体解决了这个问题。项目经理是团队中理所当然的 领导者和灵魂人物，他必须有很好的管理者形象，负
290
责找资源、保护团队、带领团队迈向成功，他同时也 是执行长，在别人眼中他就等于产品的总括，每一个 人的事情都是他的事情。项目经理或上级主管可以命令团队应该维持某 种程度的沟通，也可以用鼓励的方式达到更好的沟通 效果。然而，若是一开始组成团队就期望很有效率的 整体沟通，这野心太大了，失败的可能性会很高：因 为团队中的事情太多，组员与组员之间的关系太复杂， 而且随着团队人数的规模而呈指数成长。比较好的做 法是，让几位项目经理互相讨论他们的工作状况、目 标、希望以及长期或短期的技术计划，这种层次高、 人数少、没有隐藏的沟通虽然困难，但并非不可能。 然后让各项目经理去维持自己小组的沟通。用这种方 式，团队会很自然也很快地建立起整体的沟通，虽然 你不能命令或创造团队整体的沟通，但你可以起个头、 可以培养。虽然项目经理会有很多位，各自负责不同的产 品领域，但其中有三位的专长和职权可说是综览全局： 一是三人中最年轻的，但资历比较丰富，曾经领导过 多次产品推出工作，另外两位比较年长，虽然从未担 法则42建如果滑了一跤，别就此倒地不起
291 负过如此重任，但也是快速窜红的“新秀”。三人之 间的沟通很差，其中一个原因是，最年轻的那位没有 给另外两位足够的引领，让他们能更进入情况。部分原因是这三位项目经理分别辖属于不同的 老板。还有一个原因是在 M 1的早期阶段，此时项目 经理们还未能充分掌握自己应该担任的角色，他们会 倾向萧规曹随，看看前一位担任此职务的人是怎么做， 以为自己照做就够了，或是他们以为有些事已经有前 人完成，自己毋需费心，而且三人彼此之间的沟通相 当少。这个问题反映在每天的建构上，我们必须将建 构失败的问题和三人之间的沟通问题一起分析，深入 了解二者的关系。 代罪羔羊最常导致建构失败的原因是程序置入时，版本 发生不协调，结果发生更难建构的连锁效应，另一个 无法建构的原因是置入的程序其实尚未完全确定没有 错误。项目经理当然不可能不知道本组现在正在修改 什么程序，项目经理（或至少是品保人员）应该把不 够完美的程序退回去给开发人员修改，并追踪修改的 进度。程序置入前的品质没有被重视和把关，当不严
292
谨的程序进入了建构程序，或是开发程序应有的纪律 没有被认真遵守，在心态上就已经开始散漫，开始推 诿塞责─“都是建构小组没有做好工作”。推诿塞责是团队合作失败的必然现象，尤其在 责任感很狭隘、误解或扭曲的环境中，更容易泛滥成 灾。对道德标准高的某个人或某个群组，特别容易在 推诿塞责中受到伤害。代罪羔羊存在，就表示团队的 心态有问题，这是一种病态性的防卫反应，好像只要 有别人可以责怪，自己就可以没事，人们直觉地想找 个替死鬼，以便证明自己的表现没问题，而忽略了整 体的情况正在急速恶化（那不是我的错！）。推诿塞 责是将团队的整体问题与自己隔离，把问题简化、窄 化的一种企图。推诿塞责当然是人类原始的、不成熟的恶习之 一，但对于团队的心理状况却有短期的改善功效。这 也就是为什么推诿塞责的现象这么普遍，而且是在短 期合作的团队中。然而，推诿塞责毕竟不是长久之计， 短期的好处实在没有什么大用，凡是聪明、有自信心 的人都不会采用推诿塞责的方式，只有比较年轻、比 较怕受伤害的人才会这样做。 法则42建如果滑了一跤，别就此倒地不起
293 很不幸，推诿塞责是会生根的恶习，它会扩散、 传染出去，直到整个团队的工作绩效低落到大家都无 法忍受为止。区分“推诿塞责”和“合作无间”最明 显的指针是看看团队是否对于被当成代罪羔羊的牺牲 者视若无睹。大部分的受害者会觉得自己是被罗织入 罪，然后这种压力会造成受害者更强的防卫心理和“太极拳给他打回去”的行为。推诿塞责的目的是逃 避检讨问题，姑息问题的存在，找个代罪羔羊替自己 承担责任。推诿塞责的结果会像滚雪球般愈来愈严重， 太极拳大战会从小组打到管理者，再扩大到管理者的 管理者，最后会造成组织的致命伤。推诿塞责对组织的破坏性可以分成两个层面。 那只成为众矢之的的倒霉羔羊会被自己的同仁当成坏 蛋，被排斥和被轻视的情况使他不得不学习各种保护 自己的方法，当然包括把责任踢回去，或是另外找个 人来当代罪羔羊的代罪羔羊。无论团队原来的工作效 能如何，绝对会因此而急剧下降。一旦第二只倒霉的 羔羊（很可能是宰杀第一只羊的人）也面临被指责的 危险，就会开始出现两种对组织具有破坏性的后果： 第一，因为把责任推给别人是这么的容易方便，所以
294
真正的问题就更不会被人分析研究和解决，而且根本 没有人会注意到，人们忙着拼命把责任向外推，结果 加速了推诿塞责的病情扩大，更快速地侵蚀组织原本 就偏低的工作效能；因此，只要有一个人变成倒霉的 代罪羔羊，就开始了相互推卸责任的恶性循环。第二个破坏性的后果更加严重，因为内部互相 踢皮球，同事彼此之间关系的平衡遭到破坏，必然要 引来高层主管的干涉（讽刺的是，也许高层主管是为 了解决推诿塞责而加入战局的），于是局面变成各执 一词的两造双方，而高层主管要做出仲裁。判决的结 果很可能双方都不满意，因为实在太难找出适当的方 法解开这个结，当然会造成彼此的信任丧失，忠诚度 降低，对于主管的敬意也打了折扣。任何领导人都必须对“推诿塞责”的情况有正 确的认知，它是一种团队心理的病征，尤其是正在扩 散的推诿塞责，更是团队工作效能的严重伤害，长期 下来必会危害整个组织。在我们的案例中，项目经理应该有责任为建构 小组设立明确的目标，与他们一起建立团队对建构小 组应有的期望：现在不再有资深开发人员为大家修整 法则42建如果滑了一跤，别就此倒地不起
295 程序，将软件建构成功是每一位开发人员的责任，而 建构小组的责任则是把不够理想的程序退回去，并协 助开发人员找出程序无法建构的问题症结。到最后我们为了解决这个问题，不得已将 M 1的 时程延后几天或一星期。延期已经无法避免，但借着 延期的动作，让组员更清楚了解到我们的团队其实很 脆弱，即使初期曾经信誓旦旦，即使管理者对组员充 分信任而不采取强烈措施；让延期在组员心中刻下难 以忘怀的教训。现在，我们不得不采取扼阻的行动， 我们停止所有的开发动作，直到软件能建构成功为止。 而且除非程序经过确实的测试，不准任意置入。于是我们让开发人员了解，他们的工作是多么 重要，万一有任何瑕疵，将会影响整个软件的建构， 所以程序在置入前一定得坚持完全没有错误。最后我 们加派人手给那个孤儿程序，让它很快地修改妥善， 不再妨碍建构。 沟通方式与效果事情的沟通方式等于暗示了事情的意义。一小 段没说什么特别事情的电子邮件，人们也不会对它特 别注意；而当面开会，则是最强力的沟通法，表示所
296
谈的事情非常重要，或意味着事情不是我们这群人加 上我们的顶头上司就能决定，得来点组际协调。有关于程序置入程序的问题，被安排在“特别 会议”（special war room meeting）中讨论。以我们公 司的文化，特别会议是不同于一般会议那样送个小开 会通知，该到的人到齐就行，特别会议意味着：第一、 与产品的推出有关；第二、一位以上的资深经理参 与；第三、讨论的主题非常重要，而且需要共识；第 四、虽然没有形式上的规定，所有的小组领导最好是 参加，因为这个决策必定事关重大。通常是由最高项 目经理来召开并主持这个会议，但其他的领导人也可 以召开这种特别会议。请注意这和宣达命令的会议是完全不同的，如 果资深项目经理说我们要怎么怎么做，然后大家照章 行事，虽然也会讨论，但基本上是主持人所许可的讨 论范围。既然是宣达命令，已经没有什么讨论的空间， 讨论只是更确立决策或更了解决策的用意。如果与会 者中有人比决策者更聪明、更有想象力、对问题有更 深入的了解，或是有更好的办法，他会觉得挫折和气 愤，其他人则因为不能使用更好的办法而感到遗憾。 法则42建如果滑了一跤，别就此倒地不起
297 在会议的讨论过程中做出决策，比较容易得到高明的 决策，执行起来也会有效得多。通常是有人发现重大 问题，而且已经想了又想，询问过专家的意见，也许 已经有了初步的行动方针，在会议中邀集众人的看 法；通常与会者已经在会前对这个问题有某种程度的 了解，甚至已经思考过一些解决方案，即使不在事先 排定的议程内，也可以提案讨论无妨。通常在这类会 议中，提出的意见或建议都是经过深思熟虑，初步的 行动方针被补充、被改良，共识在这种过程和气氛中 凝聚。与会者有意见的话，应该让别人都了解，然后 在大家都能认同这个解决方案的情况之下，齐心解决 问题。 下载
法则 43
Don't trade a bad date for an equally bad date 不要因为进度落后而 更改最后期限 法则43建不要因为进度落后而更改最后期限
299 将来有一天我退休了，真希望能到学术界研究出有关 进度落后的数学公式。目前我能确定的是，第一次的进度 落后往往是最严重的一次，之后因为经验的积累会使你更 能掌握进度，所以，当你第一次遇到进度落后时，千万得 有耐心。进度落后的程度是与计划的不确定性成正比。就好像 你在翻阅一本名叫未来的书，你无法预料未来是什么，直 到你走到那一步；随着时间过去，本来不确定的事会变成 已知，于是整个计划的不确定性会随着时间而降低，进度 就愈来愈能准确掌握。理论上，进度落后的程度相对于计 划的不确定程度，并不是数学上的趋近于零而永不等于零， 而是，如果不确定的程度为零，就不会发生落后。我相信应该有这么一个算法，用时间轴（X）和不确 定性（Y），给定有任两点进度落后的值，就可以投射出 理论上的项目完成日期。我相信这种算法，因为我没有 一次不用到它，虽然我无法提出精确的公式或证明。但 请你睁大眼睛注意，你所经历的进度落后是否一次比一 次轻微，如果是，表示你渐入佳境，如果不是，那你离 目标渐行渐远。
300
在你知道自己什么时候能够完成以前， 你往往会经历自己即将落后的煎熬。
但是，千万不要为了减轻进度的延误，而将最后期限 向后挪，这种交易不划算，你会因此而信用扫地。一般来 说，早在你知道确切的可完成日期之前，你会知道项目已 经延误，这时候，整个团队乃至于全公司所有的人，包括 外界的新闻探子（如果他们知道的话），都会问你：“既然 每个人都知道延迟势难避免，何不干脆将到期日延后？” 仅管有庞大的压力逼你延期，但原来正式的到期日仍然是 项目正式的最后期限，如果轻言更改，团队成员会因此隐 约觉得原来的日期设定不妥当，造成人心浮动。项目的正 式到期日并不是不能改变，但不可因为进度赶不上而将它 延后。在进度落后时，最最糟糕的办法是估计落后的时间差， 而将到期日向后顺延。这等于是将一件你确定已经做错的 事情（进度落后），往后再背负下去（进度还会再次落 后）；这个方法似乎是很方便的权宜之计（我们再也不必 法则43建不要因为进度落后而更改最后期限
301 去想它），却是最极致的愚蠢。这时候你最确定的事情就 是必须思考为什么会发生进度落后。即使你现在已知的信息，比起你在项目初期设定期限 时要丰富许多，但大概依然不足以让你决定新的时程表。 不过话又说回来，要说明在什么情况之下可以重设新期限 本来就是极困难的事。比较好的一般性原则是，除非你已 经很确定各个组件产生多少程度的落后，还欠缺什么样的 内容，发生落后的原因已经确实找出来，并且问题已经在 克服中，否则绝对不要轻言更改最后期限。当然，要做到 这个前提，必须全体团队的合作，正确的领导，以及全心 的投入，在能够精算出期限的数学公式（我预备退休后要 研究的）发表之前，你实在无法估算出正确的期限。你应 该很务实地将目标放在最近一次的里程碑上，并且你必须 做好心理准备，往后的里程还是充满不确定的因素。珍惜你的时间，把它善用在找出发生进度落后的原因 上，而不是计算我们该延期多久，你不会因为花时间解决 问题而耽误更多的时间，相反地，你会使团队以后走得更 快更稳，早一点达到目的。 下载
法则 44
After a slip, hit the next milestone, no matter what 延误了这个里程碑， 就一定要如期到达下 一个里程碑 延误了这个里程碑，就一定要如期到达下一个里程碑
303 我们必须明白，每一次的延误，就是你和团队信心的 一次受挫，所以，延误这个里程碑时，最好的补救办法就 是无论如何绝不延误下一个里程碑。团队必须挽回对自己 的信心和对理想的承诺；因此，下一个任务必须准时完成 的意义更重大，团队需要重建信心。你知道进度落后的情形有多严重，也知道是什么原因 造成，你知道该如何改正问题，然后你建立一个比较近程 的、保守估算的下一个里程碑，这次绝不能再失误，然后 重新发布这个消息。如果你的时程表是以下三周内不做任 何事，那也很好，喔，实在太过头了，是不是？我的意思 是你一定得定下一个能够完成的里程碑，哪怕这个里程碑 在内容上没什么了不起，并且绝不失误地达成这个目标， 这个动作必须铿锵有力才行。绝不能再次延误，因为团队 需要藉这个机会重建自信。如期达成里程碑，这个目标的 成功，会带给团队鼓舞的力量，重新充满活力，相信自己 有能力达到对时程的承诺。这种心情是非常重要的，如果 团队相信自己能够如期达成里程碑，他们就会尽一切努力 去达成，这似乎是人类应有的工作方式。 下载
法则 45
A good slip is a net positive 把延误当作宝贵的学 习机会 法则45建把延误当作宝贵的学习机会
305 把进度落后当成一种宝贵的学习经验：你曾经不明白 的事情，现在明白了，此时正是分析、了解、思考和消化 的最佳时机。这时候学到的心得是最深刻的，也许很难用 言语描述。如果你只是用刻板的印象去看待进度落后，把 它当作是一件坏事，那这个进度落后的事实不能让你进步， 进度落后会成为你深怀恐惧却时常发生的事。虽然有这么多不确定的因素会造成进度落后，延误几 乎是必然发生，甚至已经被视为正常。有很多软件开发工 作本质上是具有实验性的，新的平台、新的操作系统、新 的程序技术，往往使得每一个新项目都充满不确定性。延误既然不可避免，为了防止酿成大祸，你必须衡量 各种可能造成延误的因素。最理想的情况是，你事先已经 知道一个以上的不确定因素，并且让所有的工作人员明白 进度本身必须包括这些风险，让大家知道我们如何评估这 些不确定因素对进度的影响，如何估算风险所占的时间， 这项预估能力是团队的知识与技巧，对未来大有帮助的。 你同时必须懂得判断人们是不是在做“对”的事情，进度 的落后经常的原因是，人们花太多时间在研究一些比较外 围或衍生出来的特色，事实上这些工作对产品的核心信息 没有什么帮助。
306
如果延误是你突然的发现，那就表示沟通的渠道不 畅通，你必须加强团队的沟通能力，你必须搬出一大堆 详细的信息给团队成员看，让他们对这个问题有具体而 真实的体会，延误暴露了团队的弱点，但也提供了毫无 保留的检讨机会。你必须确定每个人的每个角色都得到 了需要的指点。延误也是重新评估未来相对于什么目标该有什么资源 的好机会，日后对该有的产品功能特色，会更加务实地捡 选，对于不利于团队工作效率的特色将尽量不予纳入目标， 对于资源与特色相互的作用也能更准确估算。 总之，能够让团队学习的延误，绝对是件好事。 下载
法则 46
See the forest 见树亦见林
308
如果本项目有六个模块，各有 9 0 %的部分已经完成， 那么你已经完成了5 4 %。每个模块完成了九成，听起来是 个挺不错的成绩，但不能当成整个项目完成了百分之九十， 它们之间不是相加的关系。你必须“见树亦见林”。如果 任何一个模块完成比率是零，那么整个项目的完成率也是 零。 用这种数学运算去计算整个项目的完成率是非常正确 的，因为每一个组件对产品都是相等的重要性，假定你的 团队是平均分配工作，那么任何一位失败就是团队全体的 失败。必须注意的是，没有一件事情是能够有百分之百把握 的，如果是，那很可能发生“骄兵必败”的后果。今天的 英雄可能明天会惨遭滑铁卢，我每每对曾经跃升的明星和 它坠落的速度震惊不已。你必须设法让组员了解声誉得来 如此不易，却是如此脆弱易碎，不堪一击。团队必须时时 刻刻惕励自己，不要任意把别人当作笨蛋，不要狂妄自大， 不要自我膨胀，不要让自己心中的魔鬼打败自己。 下载
法则 47
The world changes, so should y o u 世界在变，所以你也 得跟着改变
310
成功的软件开发工作有一项重要的特质，就是能够从 每天涌进的新信息中，做出正确的决策。你不必过度拘泥 于计划和进度，那是人造的事实，难免有失真的时候。改 变是机会之母，如果你对学校课堂中教你的知识不能活用， 你会失去许多机会，会很难适应这个迅速变迁的环境，你 会把改变或机会当成是障碍，当成计划和进度的干扰，而 不是充满潜力的转机。软件开发也是一个不断改变的有机体，通常一个大得 不得了的困难，事实上代表着团队对于开发出好软件的强 烈欲望。在你作出直觉反应之前，在你把它当成问题去消 灭之前，花点时间挖掘这种心理状态背后的玄机，试着把 这股能量导入正确的方向。问题本身可能表达着许多意义， 你必须运用你的观察力、想象力、第六感，决定如何将软 件开发的过程导引顺畅。绝对记住你是在领导一群人的心， 共同进行创造性的工作。如果可预测性愈高，代表创造性 愈低，所以，每件事情都得保持弹性。当然，你不会希望轻率改变，任何改变都不可导致你 偏离方向，过度的改变会使人无所适从。弹性不代表随便（r a n d o m n e s s），弹性是延展性、适应性，是自然地改变， 而随便则是突然地、毫无关连的胡乱改变。如果外界没有 法则47建世界在变，所以你也得跟着改变
311 变化，随机的改变一下也许会有点灵光乍现的好处，但维 持原状则更加保险。只有在改变能够加强整体效率时才能 接受它，改变的目的是让团队的工作最佳化，而不是导入 更多的复杂性。我们这样举例说吧，也许有一天，你想增加一个里程 碑，没有明显的理由非得这么做不可，但是有确定的迹象 显示这是目前的发展方向所趋，这时候增加里程碑可能增 加了进度落后的风险，但也可能增加产品推出后的机会。 我特别提出这个例子，是因为我的团队最近经常遇到类似 的困扰，虽然我们一直以准时推出产品为荣，但是环境的 变化使我们愈来愈觉得必须与众不同，必须有所突破，在 原定计划中加入一个新的里程碑，做一点特别的东西。每 一个项目都像是新生的孩子，每个项目都是独特的，你必 须顺应项目独有的特质，配合它定出最适当的里程碑，并 且充分支持它，用它的语言去表达它，而不是像切蛋糕般， 切成你想要的样子。
虽然你想做些改变，你未必有勇气 实行。
312
伟大的软件必定只有一个中心思想，至于品质能够实 现到什么程度，依赖领导者能否带领团队融合无数个小而 重要的改变。如果你能在混乱中辨识出对项目最有意义的 改变，并且引导团队去适应它，将它融入团队的精神中， 将来就会在产品中表现出这项改变，呈现在顾客眼前。抗拒变化是失败的策略，你必须学习找出无法抗拒或 是对产品有利的改变，拥抱它、适应它，最后这项改变会 带给你丰富的收获。这是困难的心路历程，你需要刚铁般 的意志，因为你得依赖自己独有的远见，你所看见的没有 任何人能看见，你会很寂寞，每每在深夜被怀疑缠绕而不 得安眠。虽然你实在很想做些改变，你未必有足够的勇气 付诸行动，你等于是在挑战着人们的期望，而且你自己的 感觉也会因此而被左右，你不敢确信这些改变是好的。你 会面临艰难的抉择，在改变与不改变之间饱受折磨。然而，不论改变有多大的阻力，只要是必须的改变， 你就得排除万难接受它，否则你会被它摧毁。对我而言，即使只是把这些想法写下来，都令我感到 惊慌害怕，但这实在是我在软件开发的过程中，确确实实 的经验体会啊！
Part 第三篇 推出时期
Three
推出时期
315 对于软件开发团队来说，没有什么比产品准备推出（Ship Mode）更令人兴奋的了。大多数人认为产品 在经过这个阶段后，就可说是诞生了，但我还是倾向于将 此一时期细分为三个小阶段：激活、推移和完成（ o n s e t , transition, endgame）。这三个小阶段没有明确的间隔，彼 此也有重叠的部分，但三者的工作重点却不相同，而每个 团队必定都会一一经历，才能将产品推出。每个人对这三 个小阶段的区分方式也可能不尽相同，但对于将整个产品 推出的催生阶段，每个人都会有类似的看法或感受。
产品的推出：激活激活产品推出（ship mode: onset）是一段漫长而渐进 的过程，就好像婴儿出生前的阵痛。这时候团队开始为产 品的推出做一切繁杂的准备工作，就好像分娩前产妇要练 习呼吸，身体的机能也会为出生的那一刻作准备一般。在 产品推出的那一刻，团队必须全神贯注、倾全力使它顺利 出门，实在是个紧张而痛苦的时刻。假定我们有四或五个里程碑，大概到 M 3时产品就应 该大致成形，M3的到达就是产品推出的第一次“模拟考”。 往后的第四个和第五个里程碑，应该更强调产品推出时的
316
练习，不但是产品本身愈来愈接近推出时该有的模样，里 程碑的到达也应该更像是产品的真正推出。通常进入激活阶段的第一个征兆是，一部分认真思考 的组员开始焦虑：“我们真的能做到吗？”这并不表示团 队害怕自己做不来，而是一些先知先觉者开始思考许多该 做的事、可能降临的困难，想到那么多那么杂的事情要做， 觉得千头万绪，简直不知如何是好，尤其是开始焦虑的人 还是少数时。逐渐地，恐惧甚至惊慌，像是野火般蔓延到 整个团队，也许领导者在公开场合也流露出这种内心的情 绪。在整个团队都染上这种紧张的情绪时，领导者反而可 以松一口气，因为现在每个人的心里都关心着同一件事， 产品的推出是每个人现在强烈的心愿，大家有一种携手同 心的感觉，我们正在共同为一个伟大的产品而努力的感觉， 经过了那么辛苦的开发终于要有成果的感觉。
有些组员会怀疑，领导者大概是乐 观过了头。

返回书籍页