微软团队成功秘诀

  第一个里程碑：设计趋于稳定最开始的时候，由许多特色组成的产品设计是非常抽 象的，是一种令人又兴奋又迷惑的东西，兴奋是因为自己 的想法或创意即将实现，迷惑是因为不太确定它究竟是什 么模样。一切的人事物（技术计划、团队共识在里程碑之 前已经形成）都显示出有这些特色是要完成的，但真的问 起来，又没有人确切知道该由谁、在什么时候、做什么事 情，才能完成这些特色。这种情况我称之为”软件梦想综 合症“（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开始你的醒悟计数器。