微软团队成功秘诀

 第三派意见认为，我们是因为赶不上 M1的时间 而狗急跳墙，他们认为这是我们不当地允许在 M1目 标中出现多余的功能，现在则企图掩饰这些成本。我 们在鱼目混珠，模糊焦点，我们在欺骗自己，自以为 有团队纪律，自以为表里一致，事实上我们缺乏控制功能特色的能力，而不敢承认无法达成M1的事实。 最后，终于有人指出，我们根本不是在”繁杂“（featuritis），繁杂是不知不觉、毫无目标地乱加特色， 而且是小型特色，但是这些特色对团队共识和产品目 标没有关连。在我们新的设计中所增加的特色，本来 就是产品该有的，只是很不巧，这些特色都很小，以 致在原本的设计中被忽略了，但是这些小特色加起来却对产品有重大的影响，而如今在 M1的开发阶段发现了它们，以致不得不宣告 M1的延误。然而如果此 时没有发现这个问题，最后产品还是会因此而迟延。 就像疾病特别容易侵袭原本不健康的身体，”繁 杂“特别会伤害原本就不太健康的团队──也许是市 场中的落后者，或是对自身没有清楚认知的团队。在健康的团队中，对于进度的落后自然会产生一种不安， 但只有强烈的热忱和信念才会使团队相信这些新增特 色的重要性，而且困难终究会被克服。另一方面，太 多的不确定性和工作负荷，会削弱团队的免疫系统， 开始信心动摇，而不敢肯定这些新增的特色到底是不 是产品不可或缺的重心，还是又一个败笔。而此时若 是市场或顾客也产生变化，使得团队疯狂地大量新增 特色或是重新定义产品，最后必导致失败。
  我们在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）， 管理者应该予以重视和培养。如果里程碑的自然模式没有 出现，就代表团队出了问题，管理者应该采取某些治疗的 行动。到目前为止，我所观察到的自然里程碑可以归纳为 六种事件，但各种事件会持续多久则是无法预测的，比较 可以确定的是，前一个事件结束时，下一个事件一定要跟 着出现，前后事件之间可能会有重叠，或是几乎同时发 生；这些事件会依序发生或是同时发生，是取决于团队的 沟通频宽，在沟通性强的团队中，信息传递得像病毒一样 快，这六个事件就比较可能同时发生。