# 23 团队自毁 接下来我们需要的一章应该是“让你的团队凝聚起来”，文中应该给出能够形成好团队的不同处方，而且能够足以保证形成有凝聚力的团队。在规划本书时，这正是我们期望编写的章节。我们当时很自信。击中问题的核心，为读者提供实践工具以指导团队形成凝聚力，这有多难？我们可以竭尽所能，利用经验，通过缜密地逻辑分析，就能收获创造性的解决方法。在计划阶段，看起来就是这样…… 在计划和执行之间，我们面对现实碰了几次壁。第一，我们就是无法总结出 6 篇“处方”来形成计划的章节，我们一篇都没有。我们也打算降低自己的预期，但这也太离谱了。（“你能做 0 件事情让团队凝聚”？）这说明我们计划的篇章有问题。让团队凝聚这个想法根本就是错误的。你无法让团队凝聚，你只能对此抱有希望；要么双手合十进行祈祷，要么付诸行动以提高几率——但你不可能让它发生。整个过程实在是太脆弱以至于不可控制。 我们降低预期的第一步是改变措辞。我们停止谈论建设团队，而是改用培养。源于农耕的感觉似乎更合理。农业也不是完全能被控制的。你对土地施肥，然后播种，根据最新的科学方法浇水照料，最后你就只有等待啦：你可能会有所收获；也可能一无所有：要是最后开花结果了，你就心满意足了，但下一年你还得付出汗水和努力：这倒是跟团队的形成非常相似。 回到头脑风暴的模式：我们开始思考“能够让团队形成的 6 件事情”。依旧很棘手。最后，在绝望之余我们决定尝试逆向思考，Edward deBono 在《水平思考》(Lateral Thinking)中介绍过这一方法。当你试图解决问题时感觉被卡住了，deBono 建议，与其一根筋地寻求实现目标的方法，不如尝试寻找实现目标对立面的方法。这种方法能够让你理清阻碍你创造性思维的杂乱因素。所以，我们不再思考怎样让团队形成，而是转而思考是什么阻碍了团队的形成。这就简单多了。我们一下子思如泉涌，找到许多让团队无法形成或者破坏项目氛围的方法。把这些方法汇总为一条策略，我们给它取了一个代号，名为“团队自毁”。下面是团队自毁“技巧”的清单： * 防御式管理 * 官僚主义 * 物理分隔 * 时间碎片 * 牺牲产品质量 * 伪造截止日期 * 团伙控制 在这些“技巧”中，某些“技巧”看起来如此熟悉。它们随时随地如影随形。 ### 防御式管理 作为一名管理者，对于大多数风险采取防御动作再正常不过了：如果你要使用一件极容易失败的工具，你会准备一个备用品；如果你的客户总是犹豫矫情，你会多花时间来细化产品规格定义；如果你的合作商总是“忘记”承诺，每次会议后你会发布纪要。然而在一个领域里，防御一定会带来反效果：当你的人能力不足时，你不可能运用防御措施来保护自己。倘若你的员工能力达不到工作的要求，你就会失败。当然，如果确实不足以胜任工作，就应该去找新人。但是，一旦你已经决定使用这一组人，那么最佳战术就是信任他们。因为想保证成功而采取的任何防御性措施都只会让事情变得糟糕，即使短期能够给你一些宽慰，长期看一定没有帮助，相反会成为团队凝聚的毒药。 有一次，我给一个项目组讲授咨询师的演讲课程 9B，批评他们没能说服客户接受新系统的理念。他们都表现得有点尴尬。终于，一个人辩护道：“我们都知道应该让客户第一时间看到这些东西。但我们的老板严格规定，除非他批准，不能给客户看任何东西。”她继续解释说，那个月老板忙疯了，工作全部堆在他的收件箱里。团队还能说什么呢？他们只是在被屏蔽的情况下，突然知道他们产出的东西最后给客户展示时没有通过。 -TRL 这个老板不信任他自己的人。他过于担心团队会给客户看到不好的东西，他担心这些可能的错误会毁坏他自己的形象。只有他自己的判断是称职的；其他人都值得怀疑。 如果你是管理者，你当然会感觉你的判断比你手下的人要好很多。你拥有更多的经验，而且高于施加给他们的卓越标准；这也是你成了管理者的原因。在项目的任何时间点，如果你不去做判断，你的团队就更容易犯错误。但那又怎样呢？让他们去犯错吧。这并不代表你就不能（偶尔）去改变一个决定或者帮助项目调整方向。但如果大家认为不允许他们自己犯下任何错误时，你就传递了一个对团队不信任的信号。没有什么比这个信号更能够阻止团队形成了。 大多数管理者都认为自己善于判断他的下属何时值得信任，何时需要质疑。但就我们的经验来看，太多管理者在错误地使用不信任。他们都基于这样一条基本的假设，如果大家能够正确地运作，就可以自主地运作。这等于没有任何的自主权利。真正有意义的自主是走一条不同于管理者决定的道路。从更宽泛的意义上来看，这也是正确的：（在你的管理者或政府眼里）做正确的事情跟自主无关；有权做错误的事情才称得上是自由。 最显而易见的防御式管理方法是程式化的方法论（“我的人太笨了没法做出好系统”）和管理者的技术干涉。长远来看，这两种方法都会导致失败，而且是导致团队自毁的有效手段。不被信任的人不会有动力愿意在一起组成一个协作的团队。 ### 官僚主义 Caper Jones 在 20 世纪 70 年代和 80 年代都做过关于各类型系统开发成本的调查。一种类型叫“文案工作”，Jones 认为那是不需要动脑子的整理文档的工作，因为决定文档内容的工作都被归纳在其他活动中了，如分析、设计、测试计划等。换个角度看，他所谓的“文案工作”类型就是纯粹的官僚。Jones 得出的结论是，这种类型的工作是系统开发中的第二大类，大约超过 30%的花销都花在这上面。 令人失望的是，现在的一个趋势让越来越多的开发人员进入官僚体系里。可能这就是防御性管理流行的一个信号。虽然这种趋势是全球性的，但各个地区却不尽相同。我们知道一些公司的开发团队看起来就像是卡夫卡笔下的官僚主义噩梦，而有的公司却将文案工作压到了最少。 无须思考的文案工作就是一种浪费。我们应该向他们宣战，因为这些事情让人没法干活。但在这里我们的观点稍有不同，这是官僚主义在伤害团队的形成。团队需要相信他们为之组成的目标。目标可能是随机的，但一定需要有，而且至少有证据表明管理层也是认可的。仅仅告诉大家目标很重要，然后让大家花三分之一的时间做文案工作是不够的。文案写手不可能进入 SWAT 团队模式，也不可能视自己为追求成功的奋斗者。 ### 物理分隔 当家具警察为 Zippo-Flippo 模式化的办公系统辩护时，所有的依据就是“灵活性”。但当我们需要灵活一点让小组在一起的时候，他们不高兴了。“我们不能随意破坏环境，乱移动家具损坏这么好的地毯就为了把 4 个人安排在一起，他们不能短信联系吗？”结果就是原本可以紧密协作的团队被安排在不同的区域、楼层，甚至是不同的大楼。团队工作的交互可能没有什么大影响，但团队日常的交流就没有了。团队里的人可能跟不是一个团队的邻居更亲密些，就因为他们经常见面。由于没有团队的空间，没有团队的即时互动，也就没有形成团队文化的可能。（你肯定不能想象黑衣团队成员们不坐在一起还身穿黑衣；他们周围的人可能根本不理解他们的玩笑，从而认为他们是怪人，本来有趣的事情也就不复存在了。） 在物理上分隔需要紧密交流的人本来就不合理。邻桌的员工彼此成了噪声和打扰的来源。但当他们都在一个团队中时，他们倾向性地会同时进入安静模式，这样对流的打扰就少很多了。让团队成员在一起也给了大家日常互动的机会，而这是团队形成所必需的。 ### 时间碎片 我的一个客户是澳大利亚政府的一家机构。在一次咨询电话中，我得知每个员工平均要兼顾 4 个以上的项目。我向负责的委员抱怨了这件事情，他告诉我这很糟糕，但这就是现实。每个人的职责都成了碎片，因为他们的技能和知识造成他们是不可或缺的，没法把事情再分出去。他说这不可避免，我则认为这没有任何道理。我建议他制定一项政策，让每个人在同一段时间只能安排一个项目，然后要求大家按照政策贯彻执行。他决定尝试下。一年后，在我回访他们时，平均每个员工被分配的项目不到两个。 -TDM 碎片化对团队形成是有害的，而且也伤害效率。（或许你已经开始看到趋势了。）人们只能有效跟踪有限的人际互动。当一个人同时在 4 个项目里时，他就需要承受 4 倍的人际互动，就等于把所有时间都花在角色切换上了。 没有人可以同时是多个有凝聚力团队的一员。紧密协作的有凝聚力团队是排他的，碎片化的团队不可能形成凝聚力。糟糕的事情是我们容忍了太多没有必要的碎片化。我们其实可以做到不战而胜，简单说来就是定下目标，让大家在一段时间只做一项工作，从而减少碎片化，让团队真正有机会形成。 ### 牺牲产品质量 本节的标题是一个玩笑；没人会真正说自己的产品具有质量缺陷。他们会说这是成本压缩的产品，其实往往就是同一回事情。通常，缩短产品生产时间的方法到最后就会造成质量下降。产品的最终用户一般愿意接受这样的置换（低些的质量来换取尽早更便宜的交付）。但这是对开发人员良心的拷问，他们的自我价值及实现被破坏了，现实要求他们只能生产出质量低于他们力所能及的产品。 团队建立起来的自我认知在决定牺牲质量时就荡然无存了。开发出这样随意产品的同事根本就不想再看对方一眼，没有任何协作的成就感。大家都知道，只有停止做这样的事情才能得到解脱。项目结束后，大家都想尽量彼此分开，然后去做其他有意义的事情。 ### 伪造截止日期 在第 3 章中，我们论证了过紧的截止日期有可能会成为阻力。但我们也有足够多的例子说明一个紧张但合理的截止日期能够成为团队的合理挑战。但伪造截止日期是绝对不奏效的。当一个管理者摆出“我们必须在……之前完成”的姿态时，大家可能连眼皮都不会抬一下。他们经历过太多次了，知道这是什么样的游戏。 或许伪造截止日期曾经有效：员工可能单纯地相信了他们听到的。当老板说这项工作“绝对、必须在 1 月之前完成”，他们可能接受了，然后开始埋头苦干。当然只是可能，但现在完全不可能再这样了。你的员工很容易知道你是否在欺骗，如果你随便说一天作为产品必须推出的期限，大家会问：“为什么？如果我们晚了宇宙会停止吗？公司会垮掉吗？民族会消亡吗？西方文明会瓦解吗？” 在一个典型的伪造截止日期的谈话中，管理者宣布工作必须在某某日期前完成。这个日期显然是不可能的，而且大家都知道。这个日期等于白说（都认为截止日期没有绝对）。要按这个时间，工作根本就没有成功的希望，因而对员工来说信号很明确：老板是一个帕金森式的机器人，从来不尊重和关心他们。老板相信如果不加束缚，大家是不会有产出的。在这样的项目中，就别想有什么有凝聚力的团队了。 ### 团伙控制 在我们的一次研讨会上，参与者给出了达样的观察：“我们的管理者展示出理解团队的唯一时刻就是当他们开始解散团队的时候。”一些地方可能有不允许一个团队在完成项目后继续接下一个项目的规定。或者，有些公司会要求项目匀速减员，从而使公司能够顺利而有效地分配资源给新项目。这些都导致了团队最终会被解散。仍有其他的组织没有采取任何措施来遣散团队，从而错失了让团队能够融合的每个机会。 团队活动的愉悦以及团队互动产生的动力是我们建立互信的基础。商业组织怎么能够对这些事情无动于衷，或者对自己的团队漠不关心呢？部分原因出自不安全感，如我们在第 22 章中谈到的。另一部分原因是高层管理对团队显然的无知。如我们描述过的，团队现象发生在金字塔的最底端。对于我们常说的“管理团队”，这根本就不存在——在管理层从来没有有凝聚力的团队。即使管理者加入到真正的团队，也只是因为他们的双重职责：一面是管理，一面是小组的一员。他们被自己管理的员工认为是一个兼职队员。公司组织越往高层，有凝聚力的团队这个概念就越被人遗忘。 ### 重游伤心地 大多数组织并非有意破坏他们的团队。他们只是这样做了。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-si-bu-fen-gao-xiao-tuan-dui-yang-cheng/23-tuan-dui-zi-hui.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.