微软团队成功秘诀

向来不习惯自治 的组员突然要组织起高难度的特色监督小组，一定会觉得非常不安。特色监督小组的功能在这样的情况之下很难发挥，问题反而很可能雪上加霜。 特色监督小组本身也充满了矛盾和冲突，因为在很多人的心中，所谓的团队只不过是虚伪矫情的共识和假装一 团和气罢了。
  特色监督小组惟一不可磨灭的贡献是创意，代价是无 数不眠的夜、对拒绝的害怕、对个人勇气的磨炼。于是， “冲突”便成了特色监督小组的标志，虽然它也是成长的 动力。
  所以，项目的初期往往看不出来特色监督小组的重要 性，因为没有什么挑战性，特色监督小组看起来像是管理 阶层在搞的流行玩意。
  最后特色监督小组还是会发挥很大的效用，只要它能 被适当的组织和赋予足够的权力。它有资源、有创意、有 管理者支持，能够发挥惊人的力量，在关键时刻，他们会 发现自己竟然能够搞定这么多、这么重要的事情。
  当然在特色监督小组内也有它的问题。很多头脑优秀 而充满创意的人不敢提出他们的构想，有一种内在的负面 力量阻止他们将自己的天份表现出来。大多数人都会害怕 在团体中被排斥，这种心理源自于做个乖小孩的童年经验：
  由于父母很少会限制小孩的发展，因此小孩对于“不要这样”的信息特别敏感，为了保护自己，尽量表现得与大家 一样，服从于大多数平庸者的价值体系，而不太敢表现自 己的才能。然而，与众不同才是软件开发的成功要素。
  这种自我设限的负面行为，虽然在一般的生活环境中 是正常现象，但在正常的软件开发环境中却是病态。一般 人都会为了在阶级系统中求生存而学会“善伺上意、察颜 观色”，自然而然地会去迎合管理者的态度而改变自己的 行为。然而，管理者也会不知不觉地发出“停止！不要这 样”的信号（也许是出自盲目的策略或单纯的固执，就像 父母对孩子的行为教育一般），导致属下害怕功高震主、 得不偿失。管理者应该率先鼓励人们尽量发挥，对于优异 的组员表示肯定和支持，至少对于不同的意见采取开放的、 正面的态度。
  另一方面，每个人对于这种意见自由也会有不同的反 应。每个人感受到自己被充分授权，一肩挑起一件大事的 成败责任，会自然地把这种情绪传达给团队中的其他成员。 这种个人自由（ personal liberation）在不同的时机会以不 同的样貌呈现，也会以不同的方式强化，每个人都不一样， 但这并不容易被观察出来。每个人都需要被挑战、被鼓励、被栽培；弹性和耐性使个人形成团体，而以自己的脚步共同成长。这种成长过程虽然艰辛，却是成为优秀智能工作 团队的先决条件。
  在特色监督小组中容易发生奇怪的对话，像是谁能决定什么事，除了控制 之外到底该有什么样的管理角色是管 理者应该担当的。
  我也同时注意到，每个人对横向组织（特色监督小组） 的参与程度，恰好与他原功能组织（例如系统文件等角色） 的成功程度成反比。如果整体组织的功能表现不彰时，其 中某个功能部门的表现还算不错，致使这个部门的表现显 得突出，那么在整个组织效能改善之后，原来的疏离感反 而使得这个部门的人较不容易融入横向组织中。
  我们再来谈谈特色监督小组可能面临的外部问题。参 与者本身所隶属的功能部门管理者（如开发经理、品保经 理等等之类的各式经理）有他原来的部门目标，现在要抽 调人力参加特色监督小组，当然不免有些挣扎。也许其原属的功能部门不是那么有创意，但在这“疯狂的特色监督小组”成立之前，他们对组织也有一定的贡献，或多或少 都对特色监督小组抱持着对立的态度，毕竟，他们已在原 来的专门领域建立起一定的责任感和权威性，现在要他们 加入一个陌生的组织，做一些自己不擅长事情，而且在原 本未被授权的环境中，他们凭者能力取得一席之地，但现 在不需要了，却在新环境中被授权却更多，使得他们对原 有的成功价值产生怀疑，因而使他们更难适应新的环境。 管理者知道如何以传统的方式推出软件产品，当他看到特色监督小组刚成立时所作的尝试，会觉得太幼稚了， 会感到非常地担心：“他们这样做是错的，应该由我来做， 或是由我来教他们如何做。”这真的是善意的关心，管理 者无法忘记自己对产品的责任，会怀疑特色监督小组是不 是疯了（我自己就曾经这么想），竟然让这些没有经验的 笨蛋决定技术与产品的发展方向，并且管理者从前犯过的 错误他们现在一样照犯！
  管理者学习在“鼓励属下”与“控制属下”之间取得 平衡，于是发生奇怪的对话，像是谁能决定什么事？除了 控制之外到底该有什么样的管理角色？如果不是管理者该 做的决定，那么他要如何负责？如何自处？如何定位？
  当年我也曾经怀疑过，和其他多位资深经理怀疑我们为什么要大费周章地成立特色监督小组，我曾经在深夜醒 来，自问我们究竟为什么要这样自找麻烦，想出这种疯狂 的主意使每个人都全心投入。渐渐地，我们了解到管理者 的角色应该是教导、挑战、鼓励，并肯定这个创意思考的 过程。如果我们的观点是对的，事实自然能够证明它。在 授权给特色监督小组的同时，经理挑战组员假设的前提， 让他们能够自我检视自己的动机和行为，协助他们达成共 识和化解冲突，并让他们明白管理者了解他们，会支持他 们的决定。我们训练组员自己去追求效能，这是非常基本 的要求，因为我们要让组员自行负责，让组员有能力决定， 并且以自认最理想的方式去实现。
  权威是来自学识，而非职位。
  当然，这整个过程是循序渐进的，就某种意义来说， 它仍然不断地在发展。有很多时候，小组希望由经理直接 替他们做决定和设立目标；也有些时候是经理不当地命令 小组做事。传统性的功能组织和横向特色监督小组之间，没有全然的界线。但是在这一切都在转变中，我清楚地感觉到大家都朝着正确的方向在进步。 在一个理想的项目中，基本上有两种角色存在：创造者（creator）和推动者（ facilitator）。创造者是一些专业 人员，例如开发程序、行销、软件品保和文件撰写；而推 动者则负责凝聚团队共识和维持最佳的开发环境。在这里 可以无忧无虑地尽情发挥创意，有充足的资源解决问题和 实现理想，组织的运作非常有效率。推动者就是项目经理 或一般的管理者，他们的能力不直接显示在产品中，但却 是推动产品成功的保姆。
  推动者必须像创造者一样对最后的成果负责，而创造 者也必须像推动者一样对团队共识负责。让两种角色互相 负责是很好的做法，可以互助互补。传统阶层式组织的重 要性逐渐降低，权力来自于知识，而非地位，这是一项革 命性的突破，值得所有的软件开发组织深思。
  管理者的角色是舵手下载法则项目经理的职责项目经理是软件开发团队的一份子，他的职责是：
  领导大家定义出一个成功的产品。
  引导大家对产品注入深切的期望和信念。
  带领团队将理想实现，变成可预见的产品诞生。 要定义“项目经理是什么”，倒不如从定义“项目经理不是什么”，还比较简单些。一位项目经理实际所扮演 的角色并不是一般人直觉上想到的工作性质而已。
  项目经理并没有（或只有很少的）正式的权力或地位， 至少刚开始时是如此，所以项目经理通常会为此感到非常 地焦虑。笨蛋项目经理可能以为他的工作是写出软件规格， 让其它人去写程序、测试程序、撰写文件等等，最后完成 项目经理心目中理想的成品。在最好的情况下，别人会认 为他天真；在最坏的情况下，别人会认为他愚蠢、成事不 足败事有余。在项目经理可以对团队有任何的价值之前， 不应该有任何直接的控制权；幸好，一个健全的开发团队 不会让这种事情发生，组员会适时阻止项目经理不当地直 接控制。
  当然这类事件会导致在项目经理心中有些气愤和挫 折，因而要求上级授予更多的权力，如果上级愚蠢到真的 这么做，就会导致更严重的愚蠢事件（请参考法则 9：要权威，不要霸权）。
  通常是等到情况已经坏到无可救药时，项目经理才会明白“政治”只 是合法的借口。
  对于这类项目经理的挫折感，我见过很多不同类型的 反应。最常见的一种是项目经理开始对他真正的角色─ 领导─做出负面的、反叛性的行为，这种行为通常是通 过对“政治垃圾”（political bullshit）的厌恶来表现。除了 对科技要有一定的知识之外，软件开发团队的领导人还得 具备对人性高度敏锐的观察力，必须能够看出在团队外在 行为背后那些隐藏着的情绪因素。可想而知，有些专案经 理为了避免那些剪不断理还乱的人性问题，开始寻求比较 “清爽”的自我形象，而在软件公司中免不了的科技挂帅 文化，很容易视“政治”为畏途。当然，驾驭技术要比掌 握人性要简单多了。