微软团队成功秘诀

  有一种很不好的情况是（我真的遇到过这种情况） ”落井下石“：比较快的小组发现比较慢的小组在开发关键 性技术时遇到困难，可能会使整个里程碑延后时，反而主 张在这一部分加入更多的特色。避免这种情况的办法是， 领导者必须让整个团队共同担负达到里程碑的责任，除非 每一人都达到了里程碑，否则就等于没有人达到里程碑。
  法则完成每个里程碑后，心 平气和地检讨每完成一个里程碑后，紧接着应该做一次检讨，这并不需要花很多的时间，却能让团队下一次更好。当我们认 为做到了百分之百，是不是真的没有任何遗漏？好的检讨 绝不是指责任何人拖累进度。项目经理可以召集一个会议， 每一个特色小组中至少有一人参加，或是请大家有任何心 得都不要客气，发个电子邮件告诉项目经理，检讨会最后 的结果再由项目经理发电子邮件给每一个人分享。尤其是 做得特别好的事情，应该在检讨会中强调，大家以后就更 知道怎么做会最好。在每个里程碑之后立即做一次检讨， 是一个群体学习的最好方法。
  在里程碑之后责难某人或某小组拖累大家的进度，是 愚蠢的自我伤害。讨论进度延误的目的仅限于：研究下次 如何避免，加强大家对延误的警觉心，以及万一延误时最 好的补救方法。进度延误的不利后果发生在属于大家的软 件事业，不是管理者该去判断或核准的。延误势必增加公 司的经营成本，团队成员不会天真到以为自己不受影响， 所以管理者不必刻意惩罚，只要让团队明白延误对大家的 伤害，下次就会特别小心了。
  责难任何人拖累大家的进度是愚蠢的行为，就好像责怪叶子不可以从 树上掉下来一样没有意义。
  对于个别组员而言，延误进度是不好，但也具有某些 教育意义。一般来说，只要是健康的团队，不论成员的素 质高低或是延误的情形严重与否，发生延误的组员都会觉 得不好意思，而主动试着解决它，他会尝试修正对自己的 期望，改善自己的工作效率或工作方法。管理者应该帮助 他，责难他是愚蠢的行为，就好像责怪某一片叶子怎么可 以从树上掉下来一样没有意义。
  如果你在每一次的里程碑之后都做了足够的反省，而 且你的组员都吸收了里程碑给他们的教育，你的团队一定 会逐渐成熟，最后每一次的里程碑都会准确无误地达成。
  下载法则把握里程碑的实质意 义与精神里程碑的做法在成本上是比较高的，而且团队得承受比较大的痛苦，但这是惟一能够确保开发成功的方式。团 队成员为了协调出里程碑的衡量准则，所付出的时间精力 就是里程碑的额外成本；为了能具体标示出里程碑不得不 修改特色，团队的理想被打了点折扣，内心多少有点失望 心痛。而更多的痛苦是来自于设法使大家都专注在里程碑 上，协调大家对里程碑产生一致的价值观，为了里程碑愿 意付出额外的时间和努力，即使真正的推出时间还早得很， 我们却要劳师动众地练习、经历这个大家都辛苦的中间产 品”假推出“。
  然而”零缺点里程碑“所带来的好处远超过这一切所 付出的代价，每个人所获得的经验和成长也远超过这些痛 苦。实施零缺点里程碑可以让软件评核的过程在开发初期 就开始，藉此可以带来团队的共识；对事实的了解和包容 成了最高的团队价值，因为有太多人对人、群组对群组的 信赖和承诺，不是实践就是食言。里程碑内容的定义，就 是大家对自己工作的期望。从某个意义来说，里程碑就代 表了团队承诺的信赖度。
  经过项目初期的几次里程碑之后，在团队中已经培养 出对里程碑的使命感，能够准确地判断自己可以实现什么微软团队成功秘诀承诺，在这样的时间限制之下，那些事情可以完成，那些 不能。我曾经经历过几次”字面上的里程碑“，团队把里 程碑当作形式和教条，而不去实践里程碑的实质意义和精 神，这是很糟糕的。以我的经验，凡是健康的团队，都会 对”一致性“（请参考法则 29）有很强烈的感受力，会极 力避免任何欺骗自己或逃避现实的事情，完全自发地希望 一切都是真实的，而不是被迫遵守任何传统的教条或规定。 健康的团队喜欢里程碑和组员之间有一致性，不要形式化 的里程碑，或是过度严格而做不到的里程碑。说实话这是 一个成功开发团队的重要品德，我曾经看过组员之间互相 挑战对方，是不是在欺骗自己承诺做不到的事；在健康的 团队中，组员能够”嗅“得出来彼此是否在说大话。
  我曾经听过组员之间彼此挑战，是否在初期的里程碑目标上太过高估 自己。
  在项目初期的里程碑，把要求放低一点是可以接受的， 比较困难的特色不要求在这个里程碑中完成、品质水准不必那么高、资源可以多用一些，这些都不要紧，可以当作团队成长的代价。反而是忽视已经发生的问题而不予补救， 或是对于团队成长的问题自欺欺人，才是致命的大错误。 只有在项目初期不断自我检验，团队才能成长，在往后的 里程碑中才能学会掌握软件成功的诀窍。
  下载法则培养正常的团队运作在整个发过程中，前前后后的里程碑应该如何定义才适当？有没有一种原则或特征来判断在每一个里程碑中的 团队行为是正常或病态？如何看出团队的领导有没有问 题？无论如何，一定要先知道什么是正常的团队运作，才 能做出诊断、治疗和预防。
  诊断在软件开发过程中最困难的活动之一便是诊断─准确判断出团队行为和产品状态在不同时间所发 生的一切问题。因为创造软件的过程本来就是动态的， 充满合宜与冲突、愤怒与喜悦，团队的行为是变幻莫 测，基本上不能以组员的心情愉快与否、日程落后与 否、或是表面上的行为与事件来判断整个团队行为是 否正常。这种变幻莫测的本质，也使得领导人很难预 测治疗行动的结果。
  曾经有一次，我参加的一个团队因为时间表定 得太过自信，而且工作目标也定得高到几乎接近完成， 结果眼看着就要延误第一个里程碑（以下简称 M1）， 此时大家都很紧张，幸而我们还算是个够健康的团队， 我们也知道前面的成功不代表后面一定成功，我们愿意虚心检讨。
  诊断有无繁杂在M1阶段，这个团队深受目标过度膨胀所苦。 在M1阶段的开发工作，使我们发现到有一些关键性 的功能特色，特别是典范性的功能特色（请参考法则），显然在设计上有不够周详的地方，没有办法充分 支持我们所要传达的信息，这样的设计事实上无法达 到我们要改变使用者习惯的目的。于是我们激烈地争 论、辩证、思考，几乎使团队分裂。最后我们终于得 出结论，一个震憾性的超强新设计方案，大家都会为 它而振奋─但也大大增加了全体团队的工作负荷。 原本是改良目标，对软件有益的行动，却造成了一个不良的副作用：只剩下三个星期就到 M1 了， 组员们还不能确定要不要开发新设计的特色？在旧设 计中是不是有些特色要取消？组员们搞不清楚这些特 色的优先级，如果要采用新的设计方案，由谁来做、 何时做等等问题。旧设计也许不理想，但毕竟是我们 好不容易才凝聚起来的共识，就这样被打破再重新设 立目标吗？管理者在这样的情况下是否能坚持授权共 决的原则（特别是这些功能特色原本是他们主张的），而且不认为我们是在找麻烦？像这类不确定的问题多得列不完。不难想象，这些问题使我们距离 M1的目 标愈来愈远。
  互相纠结的功能特色就算没有工作量的增加，这种提高目标的事情本身就极具争议性。在我们讨论新的设计方案时，显 然没有想到它会带来这么多的问题，所以不知不觉地 增加了许多特色，这等于是破坏了我们对团队的承诺。 不错，以团队的纪律来说我们可能很糟，但是我们确 实对新设计方案中的每一项特色都做过彻底的分析， 研究它对每个人或每件事的影响，并且取得了新的共 识，大家都同意这些新增的特色每一个都很重要，没 有包括这些的设计将造成产品的缺陷。我们的结论是 牺牲掉其他比较次要的特色，重新配置我们的人力， 尽量减少对进度的不利影响。
  现在，我们面临了翻案的后果：在决定采用新 设计的争论之后，我们回归到开发计划的现实，我们 的M1订错了，而且时间上显然岌岌可危。我们集合 公司内所有的项目经理和品保人员，对现状做一个彻 底的评估，这次讨论的结果，可以说明在软件开发中 的一切事情都无法预知，但却是可以被管理得宜的─我喜欢这一点。
  争论不休有一些人认为，我们其实可以稍微放宽一些的期望，依照旧设计做出 M1的目标，在不影响原定目标的前提之下，少做几个特色。毕竟这是第一个里 程碑，如果在实质意义上无法达到，至少要在形式上 做到。
  第二派意见认为，有无达到 M1太难定论，一开 始目标就定得不够明确，那么即使 M1目标的字面意 义也会有不同的解释。虽然基本上我们同意 M1是应 该达成，但实质上我们却用新的设计且违背了原意。