我们在M1所决定的新增特色，都是经过彻底的 分析，而且大家都有共识，愿意为了这个理想而承 受增加的工作负荷，所有的重要工作同仁都同意我 们为了这些特色，势必将进度延后。然而如果没有 这些特色，我们就无法改变使用者的习惯，也就失 去典范性功能特色的意义。为此我们的进度和人员都得重新调整，但所有的人都同意，发展这些特色是正确的决定。
的本质上述的结论对M1是有特殊含义的，我们把这种 经验称为”M1的本质“（M1-ness），以便与一般的病 态性团队行为有所区别。我们不认为这是”繁杂“（featuritis），因为我们确实地、彻底地、不遗余力地 分析过这些新增特色，这是与繁杂最大的差别。此外， 这次的设计翻案，确实是对原设计的缺失有重要的改 正，而这方面的贡献远超过纪律不良的负面影响。
基本上我们要了解， M1正好是把这类问题理清 的时机，M1可以让你发现原来设计时忽略或模糊的 地方、进度表上的弱点，以及再次凝聚团队共识，对 目标会有更清楚的概念。从这次有点惨烈的经验中， 我的结论是：从此以后大家对 M1都特别注意，修订 M1的目标必须有团队共识，而且确实可以达成。
法则里程碑不宜太多，才 好掌握有很多人主张，六星期到三个月是里程碑之间比较理想的时间间隔（ interval）。如果你的团队比较小（譬如十 到二十人左右），或是目标较小，就可以用比较多的里程 碑，因为里程碑对小型团队的额外负担（ overhead）会比 较少。而小型团队如果经历过比较多的里程碑，会迅速成 长和凝聚共同文化（请参考法则7），这是附带的好处。
但是以我的看法，任何团队的里程碑数目如果超过７ 个，就过多了，至少是个不寻常的现象。因为在一般情况 下，任何人都无法预测那么远的未来。我的经验是三到四 个里程碑，再加上要推出的那一个，应该是最理想的数目（请参考法则18）。
太多的里程碑反而难以掌握法则每一个里程碑应有专 属的宗旨每一个里程碑，无论大小，都应该有它成立的理由。
记得我们刚刚在谈论 M1的本质时，提过团队内部发生的 激烈争辩吧，我们希望达成 M1实质上的精神，不亚于我 们希望达成 M1形式上的目标。里程碑的宗旨就是设立它 的理由，可以被简短的一两句话表达，同时也能描述达到 这个里程碑对团队的意义。就理论上来说，任何对里程碑 的争论都可以回归到它的宗旨而获得解决。里程碑的宗旨 可以清楚地表达它的目标，我故意不称它为里程碑的目标， 因为里程碑的宗旨应该包括了团队与它的互动、团队的士 气，以及里程碑所隐含的信息，也就是包含了它全面的意 义。如果单从 M1的目标来看，大部分的人都无法产生去 达成它的动机，或是联想到它所代表的报酬， M1的目标 是一大串的菜单列，是我们要去做的工作（虽然目标也可 能是错的，谁教软件这么不确定呢）。一张清单不能引起 人们的热情、专注，以做出伟大的软件为理想。人们只有 为了有意义的事情才会愿意牺牲奉献，只有里程碑的宗旨 才能让人们愿意付出自己的心灵、精力去换取某种结果。
在Visual C++的开发过程中，有几个不错的里程碑宗 旨，值得参考。在典型的第一次里程碑，我们通常会把目 标放在”狗食理论“（dogfooding），意思是要使用开发中微软团队成功秘诀的产品，才知道应该如何进一步开发( Dogfooding is using the product under development to further the development effort.）。这是源自行销学的理论，原创者是史提夫?巴摩 (teve Ballmer），由微软将之发扬光大，他的名言是：”狗 食工厂应该试吃自己生产的狗食。只有亲身试用自己的产 品，才会真正了解自己的产品。“对于像 Visual C++这样 的程序开发工具，这个概念尤其重要，因为它就是用自己 早期的开发工具写出来的。对于我们团队而言，彻底实践 狗食理论的意义是，新版本一定要比旧版本更具生产力， 即使新版本尚未完工或还有错虫。表面上我们没有特别强 调狗食理论：管理者不会每天巡视办公室看看是不是大家 都在试用自己开发的软件。然而，全体开发团队都太清楚 狗食理论对我们的重要性：如果我们在每一个组件上都发 挥狗食理论的精神，我们的产品一定会变得愈来愈好。借 着经常使用自己开发的软件，我们找到了所有的错虫和瑕 疵，生产力提升了，也更懂得掌握设计的效率。
新版本的试用者通常是精挑细选过的。
另一点是我们在拟定里程碑的宗旨时会特别注意”什么时候将什么产品交给什么人“。为了保护我们自己的荣 誉，将新版本交付出去时会特别小心，通常对象都是选择 性的，因为在错误的时机交给错误的人会造成团队额外的 工作负担。因此，里程碑可以说是我们准备将中间产品交 给某些早期客户来试用。
所以，我们第一个里程碑的宗旨是：”所有的产品组 件都已经被开发团队试用过，并准备将中间产品交给微软 内部的单位试用。“简单的说法就是”内部试吃狗食“。而 后面一点的（就算是第三个吧）里程碑，它的宗旨也许是： ”所有的特色都已经完成，而且软件的使用者接口也不再 更动，准备交给一些外部顾客试用。“里程碑宗旨的关键点在于：
宗旨必须点出里程碑的精神所在。
判断这个里程碑有没有达到，是看里程碑的宗旨是 否被实现。
在开始工作以前，所有的人都已经充分明白并接受 这个里程碑的宗旨。
下载法则寻找自然出现的里程碑虽然很难精确地把软件开发过程依时间顺序通通记录下来，但有一些事情是必定会自然发生，而且对整个开发 活动就像是分水岭一样，有划分的作用，这就是自然出现 的里程碑。请注意我所谓自然出现的里程碑，是指”正常“ 的，而不是”常见“的，正常的是指开发过程本身没有重 大问题。以下是六种自然出现的里程碑：
产品设计趋于稳定。
中间产品被明确定义。
团队真正了解要花多少时间和努力才能完成目 标（通常这会发生很多次，而且多半是进度落后的时 候）。
产品设计被删减，或是资源增加，或是进度延误， 或是三者同时发生。
开发活动停止。
产品进入除错或稳定阶段。 这六个自然的里程碑不仅在整个开发过程中出现，也会在单一的里程碑中出现。稍后我们会用较大的篇幅详细 讨论，但现在请大家注意的是，每一个里程碑所意味的行 动，跟所有的里程碑加起来所意味的行动，应该是相同的， 跟整个技术计划所意味的行动，也应该相同。
微软团队成功秘诀健康的团队在每一个里程碑所表现的行为应该是可预 见的，称作”里程碑的自然模式“（metamilestone pattern）， 管理者应该予以重视和培养。如果里程碑的自然模式没有 出现，就代表团队出了问题，管理者应该采取某些治疗的 行动。到目前为止，我所观察到的自然里程碑可以归纳为 六种事件，但各种事件会持续多久则是无法预测的，比较 可以确定的是，前一个事件结束时，下一个事件一定要跟 着出现，前后事件之间可能会有重叠，或是几乎同时发 生；这些事件会依序发生或是同时发生，是取决于团队的 沟通频宽，在沟通性强的团队中，信息传递得像病毒一样 快，这六个事件就比较可能同时发生。
第一个里程碑：设计趋于稳定最开始的时候，由许多特色组成的产品设计是非常抽 象的，是一种令人又兴奋又迷惑的东西，兴奋是因为自己 的想法或创意即将实现，迷惑是因为不太确定它究竟是什 么模样。一切的人事物（技术计划、团队共识在里程碑之 前已经形成）都显示出有这些特色是要完成的，但真的问 起来，又没有人确切知道该由谁、在什么时候、做什么事 情，才能完成这些特色。这种情况我称之为”软件梦想综 合症“（the software dream syndrome）。在产品的设计阶段，这种细节不明的现象会不断地重复出现，直到详细的工作分配形成为止。 也许你会听到开发人员说：”喔，是的，我们当然要在第一个里程碑中加入footbar的功能；我正在弄出它大概 的模样给你瞧瞧。“而品保人员可能会说：”Widget的特色确定要在第二 个里程碑中开始动工，但我还不知道该由谁来负责开发。“在传统上，或者说至少是在有制度的公司内，对于 程序开发一般都要有几项文件的前置作业，包括需求描 述、档案或数据库规格定义、各种程序逻辑图等等，不 胜枚举。虽然这些文件有助于将程序要做的事情具体化， 容易厘清细节，但是基于以下的理由，我个人反对花时 间做这些文件：
在设计趋于稳定之前必会频频修改，因此使得文件 一再重做，结果保持文件的更新变成了一种道德或 服从命令，而不是因为事实上真有这个需要。
遵守很快就会过时的文件来做事，势必限制了弹性， 错失宝贵的机会，而且对健康的团队来说是负担的 加重。
文件的作用是在开发工作开始前，把所有的事情都确定下来，结果也会限制了程序的发展。与软件有关的很多事情是在开发过程中，才会确定该怎么做 的，而且这时候才能确定怎么做最好，有时候开发 人员会有意想不到的创意，为产品增色。所以，如 果将软件中未知的部分完全排除，就等于是宣告软 件的结束，而非开始。
在软件开发的过程中，最重要的事情不是做出你承诺 要做的事，而是在有限的时间、资源限制下，从各种可能 的方式中做出最明智的选择，使结果达到最佳化。
产品设计会藉助组员之间各种形式 ─电子邮件、规 格定义、产品模型、交谊厅的聊天、用白板的小组讨论─的沟通、讨论，而由变动渐渐趋于稳定，当产品设计 逐渐确定，下一个阶段就可以准备开始。管理者应该注意 是不是所有的争议都已经被共识所平息，检查是不是所有 的功能特色都包括在设计中，是不是所有的人对产品设计 的认知都很类似，如果答案是以上皆是，就可以进入下一 个阶段，否则产品设计还不能算是成熟。
第二个里程碑：中间产品被明确定义如果能用清楚、简明又可信的方式来表达中间产品， 没有含糊、复杂或诡异，就可以说”中间产品被明确定义“。
在项目正式进入开发阶段时，以及需要检验里程碑是否达成时，我们需要的都是明确的定义：产品究竟该是什么模 样、有什么工作要做完、由谁来负责完成、品质的要求到 什么程度，这些都需要有明确的估计值，虽然不必要和照 片一样的精确程度，但至少要像印象派画作一样的明确。 随着产品设计的确立，品保人员、项目经理、开发人 员和文件人员就可以组成特色小组了，特色小组各自将负责开发的特色具体化，更清楚地描述他们的需求和目的。 他们开始花大量时间讨论和沟通，因为他们有共同的目标 和工作，他们关心的是同一件事，而他们对产品设计的认 知也相同，于是，开发的细部工作项目逐渐在组员的心中 自然成形，为了将这些工作依时间先后顺序安排，并拟出 进度的草案，沟通和协商也许要重新展开。
第三个里程碑：团队真正了解要花多少时间和努力才能完成目标当然啦，在你完成开发工作之前，你永远无法得知真 正所需的时间。当产品设计定案，中间产品被明确定义， 组员会有一种幻灭似的失落感，第一、因为产品的外观似 乎不如想象中的美丽，第二、真正该做的事永远比想象中 的多，第三、团队发现自己需要更多的资源、较小的目标、更多的时间─或者以上皆是。
在这个时候，无论团队多么经验丰富、领导多么卓越， 总是有一股失望的气氛在弥漫着，那是一种抑郁而消沉的 感受，好像自己被击垮一样。其实这是个好现象，表示组 员们对事实有进一步的认识，往后才会因为明白事实而感 到自在。幻灭是成长的开始，”软件梦想综合症“于是消 失。在健康的团队中，对事实的认识会引发另一波行动的 高潮，在我的团队中，我们把它称作”战斗会议“（war room meeting ），我们会连续开好几个小时的会，来检讨 我们现阶段的状况，并研究出问题的对策。
团队中弥漫着一股失望的气氛，那是一种抑郁而消沉的感受，好像自 己被击垮一样。
在前三个自然里程碑中，最重要的事情是：解决那些 应该理清的未知。然而，当事情一旦被弄清楚，工作通常 是只会多不会少（模糊的面孔比较美丽吧），组员可能会 被平添的信息吓住，但是健康的团队会面对这种情况，设法克服恐惧。
第四个里程碑：产品设计被删减，或是资源增加，或 是进度延误，或是三者同时发生在这个阶段中，团队会利用”软件的三角形“（请参 考法则28）来解决所遇到的冲突。如果一切顺利，这时候 时间应该刚好是整个项目（或是某一个人为的里程碑）的 前四分之一。我们很有理由相信，愈是健康的团队，前三 个里程碑会走得愈快，并且会有充分的时间来解决三角形 告诉他们的冲突，或是重新建立共识，这差不多是该对里 程碑计划稍加修正的时候了。如果一切顺利，虽然对里程 碑的某些期望可能需要调整──也许是有些特色要取消、 也许得增加一些资源等等，里程碑的宗旨应该是到现在还维持不变。
在里程碑到达之前，谁也无法保证你能如期到达。
健康的团队会在此时展现出弹性和反应能力，以准确 地达到这个里程碑的要求。你不会希望里程碑延期，这是最后的手段；你也不愿意见到资源被无限地要求增加。在这时候，你最需要看见的是组员之间形成了无数的承诺， 培养出解决问题的效率，并准备好表现出最优异的里程碑 行为模式。
第五个里程碑：开发活动停止在某一个时间点，所有撰写程序的动作会全部停止， 也就是特色全部开发完毕，此时必须禁止一切修改，以便 软件进入完成和稳定阶段。开发工作完成后就不必再写或 改程序，这听起来好像是废话，但事实上有必要特别标出 这一个里程碑，因为原本预估的时间需求可能不对，这个 里程碑等于是计算耗用时间的依据。必须确定软件不再需 要开发活动，才算到达这个里程碑。
第六个里程碑：产品进入除错或稳定阶段如果你能估出”净除错能力“（net bug fix capacity）， 即”错虫清除率 “（ bug fix rate ）减去”错虫发现率“（bug find rate），而且”净除错能力“是正值，那就差不 多可以算出第六个里程碑要花多少时间。而且基于本次的 经验，对于以后类似的项目，就可以降低”错虫发现率“， 并达到更高的软件正确性。这时候你需要找出这些问题的 答案：有多少错虫？要多久才能把错虫全部清除？有多少比例的程序代码需要整个重新检讨（regression rate）？
当这些问题被认真地讨论时，你大概快接近里程碑的 尾声，而且所有能发现的错虫全都被清除了。你会发现利 用错误等级评估法（bug triage）来解决问题，会比随抓随 改的方式要轻松多了。
下载法则如果滑了一跤，别就 此倒地不起进度落后（ slip）？不要紧，这并不是世界末日，就像感冒发烧一样，令人不舒服，但也表示身体正在自我 治疗。
从另一个角度看，进度落后是团队从软件的梦幻中惊 醒，开始面对现实。好像一种醒悟，一种”现在，我懂了“ 的心情。进度落后像是从一个怪异的、层层包裹着你的梦 境，当你从第一层梦境中醒来，想道：”好吧，现在我醒 了，我刚才是怎么了？三个月来竟然蠢到完全没发现这个明显的错误—延误了footbar？啊！我终于醒了。“若把进度落后当成道德上的罪孽，人们就会全力拒绝面对它。
三个月之后，也许是三个星期之后，你又发现了一个 明显的延误，你又想道：”哇，这次我真的是醒了，现在， 我懂了。“每一次的觉醒都让你进入一个”真实“的世界， 但也许有一天你再次从这个”真实“的世界醒来，发现刚 才的”真实“其实不是真正的真实。
你可以把这种不断的觉醒当作成长的过程。当然，每微软团队成功秘诀一回觉醒都带给你更多的知识和经验，并让你更接近真实， 更丰富你的人生。这个多层梦境的醒悟计数器是每个新项 目从零开始，每一次觉醒加1，如果你已经有了n次觉醒的 经验，你就是从n开始你的醒悟计数器。
任何项目都有可能碰到进度落后和觉醒，但有些觉醒 不一定是跟随进度落后而来，这很有可能，但有点危险， 并且不是好事。以下是你对进度落后应有的正确观念：
进度落后与道德无关，请切记！这并不是失败或做 错事，应该受到责罚，这是创造智能财产过程中无 法避免的。千万不要有道德上的罪恶感或良心上的 负担，并且要求你的团队也要这么想。因为组员们 最怕被威权形象责备，他们会因此而陷入一种很微 妙的精神压力中，在讨论时拖拖拉拉不着边际，在 恐惧犯错和渴望荣耀之间挣扎，在责难和赞誉之间 游移，结果会尽全力摆脱这种压力，会胡思乱想， 因此而消耗所有的心力。所以，千万不要让任何人 对进度落后有道德上的联想，认为这是不应该或不 对的事情。
不要隐瞒事实。人在遭遇冲突或危险时，一定但愿 没这回事，而有逃避的倾向。在进度落后时，你和组员们都难免会不想谈它，但这时候特别要克服这种天性，发挥你卓越的领导力，把事情变得不一样。 不要瑟缩在你的办公室中。喃喃自语：”我不敢去 看，进度迟延了， 不，我不相信有这种事 “ 勇敢地走出去面对问题，你要打败问题，而不是逃 避问题。
化阻力为助力，利用进度落后来激发效率。对于进 度落后的认知是一种醒悟，组员们开始有重新振作 的精神，有最新的信息，有最新的看法，创意和想 象力也可能有新的境界，领导者必须得把这些新兴 的朝气导向最有效用的地方，不要管传统规矩的包 袱，进度落后是考验团队弹性的最佳时机。
进度落后不是问题，被进度落后吓倒才是问题。进度 落后并不代表产品的难度太高而无法开发。但是如果进度 已经落后却未被察觉，那表示组员们不思考、不观察、不 讨论，此时组织可说是濒临瓦解了。
善用你的迟延，这是最能看出你领导能力的时候，此 时也是组员最脆弱也最需要你的时候，在这个时候组员最 能把你的话听进去，此时组员的学习能力最强。如果你在 办公室内激动得大喊大叫，指天骂地，那就错失了赢得组员的心的大好机会。你必须说：”OK，进度落后了，让我们来看看问题出在那里？ 今天下午五点在会议室，我 们要检讨每一个细节，问题一定要设法解决！“当组员了 解到你不是企图卸责或算帐，而是真诚地想解决问题，就 会乐意把一切开诚布公地摊开来谈，大家一起研究问题， 从各种角度去设法克服问题。”进度落后“反而变成大家 宝贵的成长经验。
进度落后里程碑达到了吗？其实这个问题很难有完全客观的衡量标准。由于产品设计可能会变，而品质本身 就是无形的，所以里程碑的到期日也可能会变，因此， 里程碑到达与否，变成了一种人为的判断：当需要回 头修改的项目愈来愈少、里程碑的宗旨达成、组员对 于下一个里程碑跃跃欲试时，你差不多可以宣布里程 碑成功。当然这一刻是很难决定的。对于这个问题， 我只能举个反面的例子来说明这个观念：比方说你去 问路，人家的回答是：”你一直往前走，若是看到尖 塔教堂，就表示走过头了。“如果你已经接近里程碑， 但开发活动还在进行，就表示已经走过头了。身为领导者，你必须时时掌握软件的一切状态，必须知道在每一个阶段应该进行那些活动，又该停止那些活动。 曾经有一次（也许不只是曾经），我们接近M1了，但一切工作都陷入混乱，我们只剩下两星期，而软件 的情况却糟得难以想象：错虫数（ bugs count ）实在 太高了，虽然每个程序设计师的错虫率还在合理范围， 但加起来的错误率却高得惊人，从我们每天的错虫增 加数目显示出软件距离稳定还差得很远。
我们没有办法每天做软件建构（请参考法则32）， 虽然主要的产品组件多半都能建构成功，但就是有那 么几个不成的，表面上都能编译和连结（ compile & link），但就是建构不起来。这个问题大大地妨碍了 下一步骤工作：”猎犬测试“（sniff test）和程序代码 分析。当其中的一个定点问题好不容易被找出来解决， 这至少又花掉了一天的时间（请记得，在里程碑的后 期，一天就可能耗用是百分之十的资源）。
组员和领导者并没有感到特别紧张，通常在接 近里程碑的时候，组员们都知道自己已经尽力，但 不知怎地，就是觉得不对劲，里程碑的精神似乎不 见了。
事实上，这个问题的主要原因（也是一般常见的状况）是出在沟通和协调不良，起于至微而酿成巨 祸。当一只程序置入时，就改变了另一只程序的假设 前提，结果另一只程序就遇到了意料之外的状况。 A 小组依赖B小组的公用程序， A小组改好也测试过了 自己的程序，但前提是 B小组维持在第 n版，然而Ｂ 小组却改到了第n＋1版，虽然改得很少，但恰好是悠 关A小组的部分， B小组误以为不会影响 A小组的程 序，所以没有告知 A小组，结果A小组的程序就建构 不起来，因为它应该与B小组的第n版搭配，结果B小 组已经置入了第n＋1版的程序。 领导人应该制止这种情况吗？
绝大多数的项目经理一旦发现这种情况，第一 个反应是采取补救行动─ 成立特别小组来接管事 务。但是这么做可能会造成一些问题：最严重的是， 这种行动的代价甚高，虽然这么做一定会使组员非常 注意软件的状态和风险─我把这种活动称作”强烈 焦点“（radical focus）─你等于是用领导者的职权 来使组员就范，这种敲响警钟的方法不能太常用，否 则团队就会发生”狼嚎症状“（cry wolf syndrome ），懒得对老板太认真，老板只是叫得凄厉而已。
如果进度落后的情况太频繁，是很危险的。进 度落后变成正常的事，此时运用领导者的威严来提 高团队的危机感，这种手段只有在士气低落时才适 用，这时团队需要一点刺激，就是”强烈焦点“活 动：让小组在同一时间内担负几个小项目（大概不 超过两个），但是这几个项目的目标是南辕北辙、毫 不相干的。
而当”强烈焦点“展开时，即使是健康的团队也 多少会反弹，觉得领导人在”反授权“（disempower- ment），于是一切不顺利的牢骚都算在”当权官员“ 的帐上，把这项措施解释成不尊重团队和团队的决定。 防卫心理升起，而且开始情绪不平，甚至可能因此怨 恨起来。即使是最优秀的领导者在采取”强烈焦点“ 措施时都会遭遇一段抗拒期。在违反对方的意愿之下 教育他，虽然做得到，但要辛苦很久。
同时，你要和团队中最优秀开发人员的反抗权 威心理作战，他们可能不会很好沟通，而直接把你当 成笨蛋（请参考法则4）。在另一方面，你也有可能误 判士气的低落程度，这时候麻烦就大了，健康的团队会对你反弹，如果你死不认错就会丧失组员对你的尊敬和忠诚，要不就是你的自大使你愈走愈远；而团队 如果不是那么健康，不敢对你谏言，那你绝对会陷入 万劫不复的失败。
在你决定采用”强烈焦点“时，以上所谈的故 事都是你的成本和风险。你的”固定成本“至少是几 个工作天（大概一星期左右），而你必须抓住组员的 注意力，保持他们的兴趣，让组员明白你是玩真的， 让他们愿意告诉你心里的感受，让他们开始做点实际 的事情。在这个起步阶段所需的时间视团队的大小、 沟通的意愿与能力而定。
现在我们回到接近第一个里程碑时的原地踏步， 领导者要团队有什么样清楚的认识（ awareness）？ 如何做到这一点？然后会引起什么行为？
在我们的案例中，要团队清楚认知的是 M1迫在 眉睫，而且除非过了 M1这一关，否则我们不可能完 成产品；我们也希望让团队练习使软件”整装待发“、 完工交货；最后，我们希望团队经历一下不成熟的 团队合作所带来的可怕后果，而从中学到我们每一 个人都有等量的责任，也是全部的责任 -就是达成里程碑。
在我们的案例中，”强烈焦点“的施行是不合适 的，因为团队的问题不在士气低落，而且事后发现， 团队的反弹非常强烈。我们应该为真正的紧急情况保 留子弹。
那该怎么办？
很明显地，我们不可能让整个投资都押 M1这个 岌岌可危的一注，我们知道一定不能让问题持续下去。 我们现在正处于瓶颈，无法建构软件的不良效应正扩 散开来，这一点可以从超高的错虫率可以证明。大家 对程序的置入动作更谨慎，必须得仔细检查是否会妨 碍到别人的程序，也就是速度慢了很多。错虫数仍然 居高不下，为了除虫而做的修改仍然会发生前述版本 不同步的问题。当软件无法建构的状态持续太久，会 使得更多的程序搭配到别人的旧版本，结果使得软件 建构更加成功无望。我们很关心这种情况，组员对危 机的感受度似乎无法和工作的进度成正比。
团队合作是相互影响的。为了完成整体的工作， 你必须划分出局部的工作。你可能让三人或四人组成 一个小组，这一小撮人的影响力就会扩及全部的团队或工作，相对地，这一小组的失败也会扩散到全体，导致软件严重的伤害。此时你的重心集中放在问题根 源的小组，这会比企图整顿全体，结果却头痛医头脚 痛医脚地到处乱转要有效得多。
我们经过一番诊断和试疗，终于决定：在我们 做到每天都建构成功以前，禁止所有的程序置入。有 三个主要的原因迫使我们非这么做不可：第一、没有 协调妥当的置入动作，会使很多其他的小组受到影响， 最后使得大家都无所适从；第二、负责建构的小组经 验不足，因为建构的任务不久前才从开发部门转移到 品保部门；第三、有一个小组总是通不过测试，它是 问题的根源。
好吧，以上这些症状，告诉我们什么？这个团 队的心理状态到底出了什么问题？ 看看团队出了什么问题？
在起始阶段我曾经提过的一项理论：从软件能 够看出团队的心理状况（ psyche）。现在事情不对头 了，团队显然无法发挥应有的工作效能，此时你必须 问问自己，团队的这些行为是否透露出什么样信息？ 首先，我们来看软件始终无法建构的问题，协调不良的程序置入动作（surprise check-in）代表团队缺乏整体性的自我认知：小组之间缺乏交谈。每天的 开发目标和程序撰写都是纯组内的，小组之间的程序 开发动作太不协调，彼此相互掣肘。每一个小组单独 来看差不多都是朝着 M1的目标前进，但每个小组的 工作成果却无法组成产品。个别组员的贡献在组内都 很不错，但到了组外就完全看不出来。
第二个问题是建构小组的经验不足。品保人员 没有做过建构，以前都是由最资深的开发人员负责每 天的建构。这一群开发人员在技术上有足够的能力解 决任何建构失败的问题，因此开发人员已经习惯对于 建构小组期望过高。这一群资深开发人员像看门狗一 样为软件建构把关，解决任何问题，甚至指导其他人 关于程序开发的知识和技巧。而新接手的品保人员没 有办法对软件（和其他开发人员）照顾得那么细微， 没有技术能力来立刻解决建构失败的问题（例如 debug），而且这也不是品保人员的责任。另一方面， 品保人员正试着融入团队文化，过去是开发人员最大， 现在开始要在团队中建立品保人员应有的角色及工作 模式，品保人员一时还无法坚决地要求开发人员把程序改到什么地步。
因此，开发人员对于建构小组的”不良“工作 表现觉得失望，无形中，开发人员开始认为建构小组 都是笨蛋，他们已经习惯有资深高手替自己修缮程序， 程序设计设计师（尤其是那些负责核心部分的）已经 被宠坏了，忘记去思考自己的程序与整个软件的关系， 也不认为自己的程序必须处处配合别的程序才行，每 个人都认为我只管写自己的程序，建构成不成功不关 我的事。现在资深的保姆不再为大家打点这个清理那 个，每天都有高品质的程序是每位开发人员的责任。 建构小组的工作是把品质好的程序建构成品质好的软 件，维护可预测的建构程序和结果，找出瓶颈所在， 并且监督开发人员改正自己的程序。开发人员对于这 项责任归属一开始当然是不情不愿的，他们原本对于 建构失败的反应是”建构小组今天没把事情做好“， 现在，要把他们的观念转变为”是今天的程序不够好 而无法建构“。
第三个问题是有一组总是做不好，他们的程序 总是无法建构成功或趋向稳定，一直通不过测试。这 并不意外，这部分程序长久以来受到忽视，没有足够的开发和品保人员照料，项目经理根本没有为它付出关爱，也许每天的建构失败就是它的不平和控诉吧！ 这一部分程序对产品而言其实是挺重要的，只是不知 道为什么它老是被当成二等公民。于是我们重新分配 资源，拨出足够的人力来把它弄好，我们得补偿过去 对它的忽视和差别待遇。从团队的心理状态或产品本 身，都可以清楚看出我们过去没有给这一部分程序应 有的重视。
总而言之，团队没有协调好，责任没有划分清 楚，而且没有相互为对方的程序负责、全体共同对软 件负责的成熟心态，管理者也疏于分配资源到适当的 地方。等到我们把问题诊断清楚，收回”强烈焦点“ 的错误措施，开始真正对症下药的治疗行动。 让组员学习彼此互相配合很明显地，由于团队缺乏共同的任务认知，小 组与小组之间既不交谈，也不会朝共同的工作目标努 力，因此我们必须充分利用团队工作的扩散效应。也 就是说，如果你在某处解决了一个问题，就等于是对 全体解决了这个问题。项目经理是团队中理所当然的 领导者和灵魂人物，他必须有很好的管理者形象，负责找资源、保护团队、带领团队迈向成功，他同时也是执行长，在别人眼中他就等于产品的总括，每一个 人的事情都是他的事情。
项目经理或上级主管可以命令团队应该维持某 种程度的沟通，也可以用鼓励的方式达到更好的沟通 效果。然而，若是一开始组成团队就期望很有效率的 整体沟通，这野心太大了，失败的可能性会很高：因 为团队中的事情太多，组员与组员之间的关系太复杂， 而且随着团队人数的规模而呈指数成长。比较好的做 法是，让几位项目经理互相讨论他们的工作状况、目 标、希望以及长期或短期的技术计划，这种层次高、 人数少、没有隐藏的沟通虽然困难，但并非不可能。 然后让各项目经理去维持自己小组的沟通。用这种方 式，团队会很自然也很快地建立起整体的沟通，虽然 你不能命令或创造团队整体的沟通，但你可以起个头、 可以培养。
虽然项目经理会有很多位，各自负责不同的产 品领域，但其中有三位的专长和职权可说是综览全局： 一是三人中最年轻的，但资历比较丰富，曾经领导过 多次产品推出工作，另外两位比较年长，虽然从未担负过如此重任，但也是快速窜红的”新秀“。三人之间的沟通很差，其中一个原因是，最年轻的那位没有 给另外两位足够的引领，让他们能更进入情况。
部分原因是这三位项目经理分别辖属于不同的 老板。还有一个原因是在 M1的早期阶段，此时项目 经理们还未能充分掌握自己应该担任的角色，他们会 倾向萧规曹随，看看前一位担任此职务的人是怎么做， 以为自己照做就够了，或是他们以为有些事已经有前 人完成，自己毋需费心，而且三人彼此之间的沟通相 当少。这个问题反映在每天的建构上，我们必须将建 构失败的问题和三人之间的沟通问题一起分析，深入 了解二者的关系。
代罪羔羊最常导致建构失败的原因是程序置入时，版本 发生不协调，结果发生更难建构的连锁效应，另一个 无法建构的原因是置入的程序其实尚未完全确定没有 错误。项目经理当然不可能不知道本组现在正在修改 什么程序，项目经理（或至少是品保人员）应该把不 够完美的程序退回去给开发人员修改，并追踪修改的 进度。程序置入前的品质没有被重视和把关，当不严谨的程序进入了建构程序，或是开发程序应有的纪律没有被认真遵守，在心态上就已经开始散漫，开始推 诿塞责─”都是建构小组没有做好工作“。
推诿塞责是团队合作失败的必然现象，尤其在 责任感很狭隘、误解或扭曲的环境中，更容易泛滥成 灾。对道德标准高的某个人或某个群组，特别容易在 推诿塞责中受到伤害。代罪羔羊存在，就表示团队的 心态有问题，这是一种病态性的防卫反应，好像只要 有别人可以责怪，自己就可以没事，人们直觉地想找 个替死鬼，以便证明自己的表现没问题，而忽略了整 体的情况正在急速恶化（那不是我的错！）。推诿塞 责是将团队的整体问题与自己隔离，把问题简化、窄 化的一种企图。
推诿塞责当然是人类原始的、不成熟的恶习之 一，但对于团队的心理状况却有短期的改善功效。这 也就是为什么推诿塞责的现象这么普遍，而且是在短 期合作的团队中。然而，推诿塞责毕竟不是长久之计， 短期的好处实在没有什么大用，凡是聪明、有自信心 的人都不会采用推诿塞责的方式，只有比较年轻、比 较怕受伤害的人才会这样做。
很不幸，推诿塞责是会生根的恶习，它会扩散、传染出去，直到整个团队的工作绩效低落到大家都无 法忍受为止。区分”推诿塞责“和”合作无间“最明 显的指针是看看团队是否对于被当成代罪羔羊的牺牲 者视若无睹。大部分的受害者会觉得自己是被罗织入 罪，然后这种压力会造成受害者更强的防卫心理和 ”太极拳给他打回去“的行为。推诿塞责的目的是逃 避检讨问题，姑息问题的存在，找个代罪羔羊替自己 承担责任。推诿塞责的结果会像滚雪球般愈来愈严重， 太极拳大战会从小组打到管理者，再扩大到管理者的 管理者，最后会造成组织的致命伤。
推诿塞责对组织的破坏性可以分成两个层面。 那只成为众矢之的的倒霉羔羊会被自己的同仁当成坏 蛋，被排斥和被轻视的情况使他不得不学习各种保护 自己的方法，当然包括把责任踢回去，或是另外找个 人来当代罪羔羊的代罪羔羊。无论团队原来的工作效 能如何，绝对会因此而急剧下降。一旦第二只倒霉的 羔羊（很可能是宰杀第一只羊的人）也面临被指责的 危险，就会开始出现两种对组织具有破坏性的后果： 第一，因为把责任推给别人是这么的容易方便，所以真正的问题就更不会被人分析研究和解决，而且根本没有人会注意到，人们忙着拼命把责任向外推，结果 加速了推诿塞责的病情扩大，更快速地侵蚀组织原本 就偏低的工作效能；因此，只要有一个人变成倒霉的 代罪羔羊，就开始了相互推卸责任的恶性循环。
第二个破坏性的后果更加严重，因为内部互相 踢皮球，同事彼此之间关系的平衡遭到破坏，必然要 引来高层主管的干涉（讽刺的是，也许高层主管是为 了解决推诿塞责而加入战局的），于是局面变成各执 一词的两造双方，而高层主管要做出仲裁。判决的结 果很可能双方都不满意，因为实在太难找出适当的方 法解开这个结，当然会造成彼此的信任丧失，忠诚度 降低，对于主管的敬意也打了折扣。
任何领导人都必须对”推诿塞责“的情况有正 确的认知，它是一种团队心理的病征，尤其是正在扩 散的推诿塞责，更是团队工作效能的严重伤害，长期 下来必会危害整个组织。
在我们的案例中，项目经理应该有责任为建构 小组设立明确的目标，与他们一起建立团队对建构小 组应有的期望：现在不再有资深开发人员为大家修整程序，将软件建构成功是每一位开发人员的责任，而建构小组的责任则是把不够理想的程序退回去，并协 助开发人员找出程序无法建构的问题症结。
到最后我们为了解决这个问题，不得已将 M1的 时程延后几天或一星期。延期已经无法避免，但借着 延期的动作，让组员更清楚了解到我们的团队其实很 脆弱，即使初期曾经信誓旦旦，即使管理者对组员充 分信任而不采取强烈措施；让延期在组员心中刻下难 以忘怀的教训。现在，我们不得不采取扼阻的行动， 我们停止所有的开发动作，直到软件能建构成功为止。 而且除非程序经过确实的测试，不准任意置入。
于是我们让开发人员了解，他们的工作是多么 重要，万一有任何瑕疵，将会影响整个软件的建构， 所以程序在置入前一定得坚持完全没有错误。最后我 们加派人手给那个孤儿程序，让它很快地修改妥善， 不再妨碍建构。
沟通方式与效果事情的沟通方式等于暗示了事情的意义。一小 段没说什么特别事情的电子邮件，人们也不会对它特 别注意；而当面开会，则是最强力的沟通法，表示所谈的事情非常重要，或意味着事情不是我们这群人加上我们的顶头上司就能决定，得来点组际协调。 有关于程序置入程序的问题，被安排在”特别会议“（special war room meeting）中讨论。以我们公 司的文化，特别会议是不同于一般会议那样送个小开 会通知，该到的人到齐就行，特别会议意味着：第一、 与产品的推出有关；第二、一位以上的资深经理参 与；第三、讨论的主题非常重要，而且需要共识；第 四、虽然没有形式上的规定，所有的小组领导最好是 参加，因为这个决策必定事关重大。通常是由最高项 目经理来召开并主持这个会议，但其他的领导人也可 以召开这种特别会议。
请注意这和宣达命令的会议是完全不同的，如 果资深项目经理说我们要怎么怎么做，然后大家照章 行事，虽然也会讨论，但基本上是主持人所许可的讨 论范围。既然是宣达命令，已经没有什么讨论的空间， 讨论只是更确立决策或更了解决策的用意。如果与会 者中有人比决策者更聪明、更有想象力、对问题有更 深入的了解，或是有更好的办法，他会觉得挫折和气 愤，其他人则因为不能使用更好的办法而感到遗憾。
