微软团队成功秘诀

无论团队原来的工作效 能如何，绝对会因此而急剧下降。一旦第二只倒霉的 羔羊（很可能是宰杀第一只羊的人）也面临被指责的 危险，就会开始出现两种对组织具有破坏性的后果： 第一，因为把责任推给别人是这么的容易方便，所以真正的问题就更不会被人分析研究和解决，而且根本没有人会注意到，人们忙着拼命把责任向外推，结果 加速了推诿塞责的病情扩大，更快速地侵蚀组织原本 就偏低的工作效能；因此，只要有一个人变成倒霉的 代罪羔羊，就开始了相互推卸责任的恶性循环。
  第二个破坏性的后果更加严重，因为内部互相 踢皮球，同事彼此之间关系的平衡遭到破坏，必然要 引来高层主管的干涉（讽刺的是，也许高层主管是为 了解决推诿塞责而加入战局的），于是局面变成各执 一词的两造双方，而高层主管要做出仲裁。判决的结 果很可能双方都不满意，因为实在太难找出适当的方 法解开这个结，当然会造成彼此的信任丧失，忠诚度 降低，对于主管的敬意也打了折扣。
  任何领导人都必须对”推诿塞责“的情况有正 确的认知，它是一种团队心理的病征，尤其是正在扩 散的推诿塞责，更是团队工作效能的严重伤害，长期 下来必会危害整个组织。
  在我们的案例中，项目经理应该有责任为建构 小组设立明确的目标，与他们一起建立团队对建构小 组应有的期望：现在不再有资深开发人员为大家修整程序，将软件建构成功是每一位开发人员的责任，而建构小组的责任则是把不够理想的程序退回去，并协 助开发人员找出程序无法建构的问题症结。
  到最后我们为了解决这个问题，不得已将 M1的 时程延后几天或一星期。延期已经无法避免，但借着 延期的动作，让组员更清楚了解到我们的团队其实很 脆弱，即使初期曾经信誓旦旦，即使管理者对组员充 分信任而不采取强烈措施；让延期在组员心中刻下难 以忘怀的教训。现在，我们不得不采取扼阻的行动， 我们停止所有的开发动作，直到软件能建构成功为止。 而且除非程序经过确实的测试，不准任意置入。
  于是我们让开发人员了解，他们的工作是多么 重要，万一有任何瑕疵，将会影响整个软件的建构， 所以程序在置入前一定得坚持完全没有错误。最后我 们加派人手给那个孤儿程序，让它很快地修改妥善， 不再妨碍建构。
  沟通方式与效果事情的沟通方式等于暗示了事情的意义。一小 段没说什么特别事情的电子邮件，人们也不会对它特 别注意；而当面开会，则是最强力的沟通法，表示所谈的事情非常重要，或意味着事情不是我们这群人加上我们的顶头上司就能决定，得来点组际协调。 有关于程序置入程序的问题，被安排在”特别会议“（special war room meeting）中讨论。以我们公 司的文化，特别会议是不同于一般会议那样送个小开 会通知，该到的人到齐就行，特别会议意味着：第一、 与产品的推出有关；第二、一位以上的资深经理参 与；第三、讨论的主题非常重要，而且需要共识；第 四、虽然没有形式上的规定，所有的小组领导最好是 参加，因为这个决策必定事关重大。通常是由最高项 目经理来召开并主持这个会议，但其他的领导人也可 以召开这种特别会议。
  请注意这和宣达命令的会议是完全不同的，如 果资深项目经理说我们要怎么怎么做，然后大家照章 行事，虽然也会讨论，但基本上是主持人所许可的讨 论范围。既然是宣达命令，已经没有什么讨论的空间， 讨论只是更确立决策或更了解决策的用意。如果与会 者中有人比决策者更聪明、更有想象力、对问题有更 深入的了解，或是有更好的办法，他会觉得挫折和气 愤，其他人则因为不能使用更好的办法而感到遗憾。
  在会议的讨论过程中做出决策，比较容易得到高明的决策，执行起来也会有效得多。通常是有人发现重大 问题，而且已经想了又想，询问过专家的意见，也许 已经有了初步的行动方针，在会议中邀集众人的看 法；通常与会者已经在会前对这个问题有某种程度的 了解，甚至已经思考过一些解决方案，即使不在事先 排定的议程内，也可以提案讨论无妨。通常在这类会 议中，提出的意见或建议都是经过深思熟虑，初步的 行动方针被补充、被改良，共识在这种过程和气氛中 凝聚。与会者有意见的话，应该让别人都了解，然后 在大家都能认同这个解决方案的情况之下，齐心解决 问题。
  下载法则不要因为进度落后而 更改最后期限将来有一天我退休了，真希望能到学术界研究出有关进度落后的数学公式。目前我能确定的是，第一次的进度 落后往往是最严重的一次，之后因为经验的积累会使你更 能掌握进度，所以，当你第一次遇到进度落后时，千万得 有耐心。
  进度落后的程度是与计划的不确定性成正比。就好像 你在翻阅一本名叫未来的书，你无法预料未来是什么，直 到你走到那一步；随着时间过去，本来不确定的事会变成 已知，于是整个计划的不确定性会随着时间而降低，进度 就愈来愈能准确掌握。理论上，进度落后的程度相对于计 划的不确定程度，并不是数学上的趋近于零而永不等于零， 而是，如果不确定的程度为零，就不会发生落后。
  我相信应该有这么一个算法，用时间轴（ X）和不确 定性（ Y），给定有任两点进度落后的值，就可以投射出 理论上的项目完成日期。我相信这种算法，因为我没有 一次不用到它，虽然我无法提出精确的公式或证明。但 请你睁大眼睛注意，你所经历的进度落后是否一次比一 次轻微，如果是，表示你渐入佳境，如果不是，那你离 目标渐行渐远。
  微软团队成功秘诀在你知道自己什么时候能够完成以前，你往往会经历自己即将落后的煎熬。
  但是，千万不要为了减轻进度的延误，而将最后期限 向后挪，这种交易不划算，你会因此而信用扫地。一般来 说，早在你知道确切的可完成日期之前，你会知道项目已 经延误，这时候，整个团队乃至于全公司所有的人，包括 外界的新闻探子（如果他们知道的话），都会问你：”既然 每个人都知道延迟势难避免，何不干脆将到期日延后？“ 仅管有庞大的压力逼你延期，但原来正式的到期日仍然是 项目正式的最后期限，如果轻言更改，团队成员会因此隐 约觉得原来的日期设定不妥当，造成人心浮动。项目的正 式到期日并不是不能改变，但不可因为进度赶不上而将它 延后。
  在进度落后时，最最糟糕的办法是估计落后的时间差， 而将到期日向后顺延。这等于是将一件你确定已经做错的 事情（进度落后），往后再背负下去（进度还会再次落 后）；这个方法似乎是很方便的权宜之计（我们再也不必去想它），却是最极致的愚蠢。这时候你最确定的事情就是必须思考为什么会发生进度落后。 即使你现在已知的信息，比起你在项目初期设定期限时要丰富许多，但大概依然不足以让你决定新的时程表。 不过话又说回来，要说明在什么情况之下可以重设新期限 本来就是极困难的事。比较好的一般性原则是，除非你已 经很确定各个组件产生多少程度的落后，还欠缺什么样的 内容，发生落后的原因已经确实找出来，并且问题已经在 克服中，否则绝对不要轻言更改最后期限。当然，要做到 这个前提，必须全体团队的合作，正确的领导，以及全心 的投入，在能够精算出期限的数学公式（我预备退休后要 研究的）发表之前，你实在无法估算出正确的期限。你应 该很务实地将目标放在最近一次的里程碑上，并且你必须 做好心理准备，往后的里程还是充满不确定的因素。
  珍惜你的时间，把它善用在找出发生进度落后的原因 上，而不是计算我们该延期多久，你不会因为花时间解决 问题而耽误更多的时间，相反地，你会使团队以后走得更 快更稳，早一点达到目的。
  法则延误了这个里程碑， 就一定要如期到达下 一个里程碑我们必须明白，每一次的延误，就是你和团队信心的一次受挫，所以，延误这个里程碑时，最好的补救办法就 是无论如何绝不延误下一个里程碑。团队必须挽回对自己 的信心和对理想的承诺；因此，下一个任务必须准时完成 的意义更重大，团队需要重建信心。
  你知道进度落后的情形有多严重，也知道是什么原因 造成，你知道该如何改正问题，然后你建立一个比较近程 的、保守估算的下一个里程碑，这次绝不能再失误，然后 重新发布这个消息。如果你的时程表是以下三周内不做任 何事，那也很好，喔，实在太过头了，是不是？我的意思 是你一定得定下一个能够完成的里程碑，哪怕这个里程碑 在内容上没什么了不起，并且绝不失误地达成这个目标， 这个动作必须铿锵有力才行。绝不能再次延误，因为团队 需要藉这个机会重建自信。如期达成里程碑，这个目标的 成功，会带给团队鼓舞的力量，重新充满活力，相信自己 有能力达到对时程的承诺。这种心情是非常重要的，如果 团队相信自己能够如期达成里程碑，他们就会尽一切努力 去达成，这似乎是人类应有的工作方式。