微软团队成功秘诀

你可能让三人或四人组成 一个小组，这一小撮人的影响力就会扩及全部的团队或工作，相对地，这一小组的失败也会扩散到全体，导致软件严重的伤害。此时你的重心集中放在问题根 源的小组，这会比企图整顿全体，结果却头痛医头脚 痛医脚地到处乱转要有效得多。
  我们经过一番诊断和试疗，终于决定：在我们 做到每天都建构成功以前，禁止所有的程序置入。有 三个主要的原因迫使我们非这么做不可：第一、没有 协调妥当的置入动作，会使很多其他的小组受到影响， 最后使得大家都无所适从；第二、负责建构的小组经 验不足，因为建构的任务不久前才从开发部门转移到 品保部门；第三、有一个小组总是通不过测试，它是 问题的根源。
  好吧，以上这些症状，告诉我们什么？这个团 队的心理状态到底出了什么问题？ 看看团队出了什么问题？
  在起始阶段我曾经提过的一项理论：从软件能 够看出团队的心理状况（ psyche）。现在事情不对头 了，团队显然无法发挥应有的工作效能，此时你必须 问问自己，团队的这些行为是否透露出什么样信息？ 首先，我们来看软件始终无法建构的问题，协调不良的程序置入动作（surprise check-in）代表团队缺乏整体性的自我认知：小组之间缺乏交谈。每天的 开发目标和程序撰写都是纯组内的，小组之间的程序 开发动作太不协调，彼此相互掣肘。每一个小组单独 来看差不多都是朝着 M1的目标前进，但每个小组的 工作成果却无法组成产品。个别组员的贡献在组内都 很不错，但到了组外就完全看不出来。
  第二个问题是建构小组的经验不足。品保人员 没有做过建构，以前都是由最资深的开发人员负责每 天的建构。这一群开发人员在技术上有足够的能力解 决任何建构失败的问题，因此开发人员已经习惯对于 建构小组期望过高。这一群资深开发人员像看门狗一 样为软件建构把关，解决任何问题，甚至指导其他人 关于程序开发的知识和技巧。而新接手的品保人员没 有办法对软件（和其他开发人员）照顾得那么细微， 没有技术能力来立刻解决建构失败的问题（例如 debug），而且这也不是品保人员的责任。另一方面， 品保人员正试着融入团队文化，过去是开发人员最大， 现在开始要在团队中建立品保人员应有的角色及工作 模式，品保人员一时还无法坚决地要求开发人员把程序改到什么地步。
  因此，开发人员对于建构小组的”不良“工作 表现觉得失望，无形中，开发人员开始认为建构小组 都是笨蛋，他们已经习惯有资深高手替自己修缮程序， 程序设计设计师（尤其是那些负责核心部分的）已经 被宠坏了，忘记去思考自己的程序与整个软件的关系， 也不认为自己的程序必须处处配合别的程序才行，每 个人都认为我只管写自己的程序，建构成不成功不关 我的事。现在资深的保姆不再为大家打点这个清理那 个，每天都有高品质的程序是每位开发人员的责任。 建构小组的工作是把品质好的程序建构成品质好的软 件，维护可预测的建构程序和结果，找出瓶颈所在， 并且监督开发人员改正自己的程序。开发人员对于这 项责任归属一开始当然是不情不愿的，他们原本对于 建构失败的反应是”建构小组今天没把事情做好“， 现在，要把他们的观念转变为”是今天的程序不够好 而无法建构“。
  第三个问题是有一组总是做不好，他们的程序 总是无法建构成功或趋向稳定，一直通不过测试。这 并不意外，这部分程序长久以来受到忽视，没有足够的开发和品保人员照料，项目经理根本没有为它付出关爱，也许每天的建构失败就是它的不平和控诉吧！ 这一部分程序对产品而言其实是挺重要的，只是不知 道为什么它老是被当成二等公民。于是我们重新分配 资源，拨出足够的人力来把它弄好，我们得补偿过去 对它的忽视和差别待遇。从团队的心理状态或产品本 身，都可以清楚看出我们过去没有给这一部分程序应 有的重视。
  总而言之，团队没有协调好，责任没有划分清 楚，而且没有相互为对方的程序负责、全体共同对软 件负责的成熟心态，管理者也疏于分配资源到适当的 地方。等到我们把问题诊断清楚，收回”强烈焦点“ 的错误措施，开始真正对症下药的治疗行动。 让组员学习彼此互相配合很明显地，由于团队缺乏共同的任务认知，小 组与小组之间既不交谈，也不会朝共同的工作目标努 力，因此我们必须充分利用团队工作的扩散效应。也 就是说，如果你在某处解决了一个问题，就等于是对 全体解决了这个问题。项目经理是团队中理所当然的 领导者和灵魂人物，他必须有很好的管理者形象，负责找资源、保护团队、带领团队迈向成功，他同时也是执行长，在别人眼中他就等于产品的总括，每一个 人的事情都是他的事情。
  项目经理或上级主管可以命令团队应该维持某 种程度的沟通，也可以用鼓励的方式达到更好的沟通 效果。然而，若是一开始组成团队就期望很有效率的 整体沟通，这野心太大了，失败的可能性会很高：因 为团队中的事情太多，组员与组员之间的关系太复杂， 而且随着团队人数的规模而呈指数成长。比较好的做 法是，让几位项目经理互相讨论他们的工作状况、目 标、希望以及长期或短期的技术计划，这种层次高、 人数少、没有隐藏的沟通虽然困难，但并非不可能。 然后让各项目经理去维持自己小组的沟通。用这种方 式，团队会很自然也很快地建立起整体的沟通，虽然 你不能命令或创造团队整体的沟通，但你可以起个头、 可以培养。
  虽然项目经理会有很多位，各自负责不同的产 品领域，但其中有三位的专长和职权可说是综览全局： 一是三人中最年轻的，但资历比较丰富，曾经领导过 多次产品推出工作，另外两位比较年长，虽然从未担负过如此重任，但也是快速窜红的”新秀“。三人之间的沟通很差，其中一个原因是，最年轻的那位没有 给另外两位足够的引领，让他们能更进入情况。
  部分原因是这三位项目经理分别辖属于不同的 老板。还有一个原因是在 M1的早期阶段，此时项目 经理们还未能充分掌握自己应该担任的角色，他们会 倾向萧规曹随，看看前一位担任此职务的人是怎么做， 以为自己照做就够了，或是他们以为有些事已经有前 人完成，自己毋需费心，而且三人彼此之间的沟通相 当少。这个问题反映在每天的建构上，我们必须将建 构失败的问题和三人之间的沟通问题一起分析，深入 了解二者的关系。
  代罪羔羊最常导致建构失败的原因是程序置入时，版本 发生不协调，结果发生更难建构的连锁效应，另一个 无法建构的原因是置入的程序其实尚未完全确定没有 错误。项目经理当然不可能不知道本组现在正在修改 什么程序，项目经理（或至少是品保人员）应该把不 够完美的程序退回去给开发人员修改，并追踪修改的 进度。程序置入前的品质没有被重视和把关，当不严谨的程序进入了建构程序，或是开发程序应有的纪律没有被认真遵守，在心态上就已经开始散漫，开始推 诿塞责─”都是建构小组没有做好工作“。
  推诿塞责是团队合作失败的必然现象，尤其在 责任感很狭隘、误解或扭曲的环境中，更容易泛滥成 灾。对道德标准高的某个人或某个群组，特别容易在 推诿塞责中受到伤害。代罪羔羊存在，就表示团队的 心态有问题，这是一种病态性的防卫反应，好像只要 有别人可以责怪，自己就可以没事，人们直觉地想找 个替死鬼，以便证明自己的表现没问题，而忽略了整 体的情况正在急速恶化（那不是我的错！）。推诿塞 责是将团队的整体问题与自己隔离，把问题简化、窄 化的一种企图。
  推诿塞责当然是人类原始的、不成熟的恶习之 一，但对于团队的心理状况却有短期的改善功效。这 也就是为什么推诿塞责的现象这么普遍，而且是在短 期合作的团队中。然而，推诿塞责毕竟不是长久之计， 短期的好处实在没有什么大用，凡是聪明、有自信心 的人都不会采用推诿塞责的方式，只有比较年轻、比 较怕受伤害的人才会这样做。
  很不幸，推诿塞责是会生根的恶习，它会扩散、传染出去，直到整个团队的工作绩效低落到大家都无 法忍受为止。区分”推诿塞责“和”合作无间“最明 显的指针是看看团队是否对于被当成代罪羔羊的牺牲 者视若无睹。大部分的受害者会觉得自己是被罗织入 罪，然后这种压力会造成受害者更强的防卫心理和 ”太极拳给他打回去“的行为。推诿塞责的目的是逃 避检讨问题，姑息问题的存在，找个代罪羔羊替自己 承担责任。推诿塞责的结果会像滚雪球般愈来愈严重， 太极拳大战会从小组打到管理者，再扩大到管理者的 管理者，最后会造成组织的致命伤。
  推诿塞责对组织的破坏性可以分成两个层面。 那只成为众矢之的的倒霉羔羊会被自己的同仁当成坏 蛋，被排斥和被轻视的情况使他不得不学习各种保护 自己的方法，当然包括把责任踢回去，或是另外找个 人来当代罪羔羊的代罪羔羊。