ThoughtWorks 徐昊：如何打造高效能团队 | GTLC

2021 年 12 月 4 日，TGO 鲲鹏会在厦门举办 GTLC 全球领导力峰会。本次峰会以“探索圈外的世界”为主题，聚焦科技发展趋势与科技人才管理，成功打造华南地区科技领导者盛会，这也是 TGO 鲲鹏会厦门在进行的诸多破圈环节中的一环。

会上，ThoughtWorks 全球技术策略顾问、中国区首席技术官（CTO）徐昊发表主题演讲《如何打造高效能团队》，揭示了 19 世纪以来我们如何打造高效能团队，以及 21 世纪知识管理面临的新挑战，从而表明要通过社交化传递打破知识壁垒，通过认知行为构成有效的认知杠杆，打造高效能团队。

以下内容为演讲实录，TGO 鲲鹏会编辑整理，有删减：

我曾经是厦门 Ruby User Group 的创始人。大家可能不知道，2005 年，全中国敏捷软件开发最大的项目就在厦门，是我们公司在珍珠湾做的。这也是我思考如何构造高效能团队的出发点。当时为了做这个项目，从全球飞来了很多技术专家，一年后项目基本扶上正轨，所以我们的人便慢慢撤掉。

后来这个客户也很成功，已经上市了。在这个过程中，我们从厦大招聘了毕业生来替换原有的咨询顾问和咨询师，以大概 1 : 4 的比例，团队规模翻了一倍。换句话说，我们用毕业生替换了有 10 多年经验的软件工程师，但在之后一年，我们持续监控了整个项目的进度，研发效能和质量并没有明显的下降。为什么？这是我今天想跟大家分享的故事。

我今天将会从三个方向来讲。第一，19 世纪以来我们如何打造高效能团队？第二，21 世纪我们会应对什么样的挑战？第三，应对这个挑战我们有两个可能尝试的方向。

1 19 世纪以来，我们如何构造高效能团队？

一旦人类开始进行大规模生产制造，就会出现一个问题，如何更高效的工作？这是一个很重要的话题。现在去看任何一个团队，你会发现有两个显而易见的特点，第一是团队里存在分工，开发、测试、BA、项目经理等等。第二是在项目中都会存在金字塔结构，一个项目经理或技术负责人，下面会带有多人团队。但这背后的原因比我们想象的要复杂很多。有两个人提出的基本想法有着非常卓绝的贡献。

第一个人是亚当斯密。

他在《国富论》的前两章中谈论社会分工，讲了一个非常简单的道理，我们怎么能够提高分工的效率？当有了分工，招聘的就不是一个具体的人，而是一个职业。职业是具有可替换性的，但个人是不具备的。为什么资本主义对人是一种意化？因为从基本上看，你在工作中就不再是个体的人，而是一类职业和角色的代表，这种职业和角色背后就是一种市场。如果今天到市场上招一个徐昊，可能招不到，因为只有我一个人；但如果想招有多少年经验，做过什么项目的人，会非常多。所以如何才能提高效率呢？分工。分工是让不同工种之间产物交换，这是我们习以为常的方法，但背后是很新的概念。分工的概念到现在不到 200 年，为什么能提高效率呢？思路也很简单，通过构建知识壁垒，进而交互和交换提高效率。

我们享受知识产物，但不用了解背后的原因，就好像去餐厅吃饭，不用知道大米、蔬菜如何种植，可以直接享受成果。如果有一件事情很难解决，我们会找一个专家，积累他的经验和技能，不要让这些经验分散掉，集中在几个人身上提高效率。这并不是新概念，而是亚当斯密在《国富论》中提出的想法。我们脑海中下意识会用分工的方法尝试提高效率，正是因为我们构建了知识壁垒。

第二个是提出金字塔结构的泰勒。

金字塔结构的时间更短，不到 100 年。100 年前我们当然也有，用中国历史上的帝制来讲大家会更为理解，但这不是一个有效的官僚体系。在团队中形成有效的金字塔结构，并且能够一起用于商业活动，是泰勒带来的。我们称他为管理学的创始人。管理这个岗位诞生于泰勒在 20 世纪初进行的管理实验。

我们听过一句话，做正确的事情和正确地做事情。这表示我们要分离有效性和效率，Effectiveness 和 Efficiency。所谓有效性，就是做什么事情是正确的；所谓效率，就是怎么做更快。泰勒告诉我们，没有办法让所有人既负责效率又负责有效性，所以要把它们分离开，让一部分人去负责有效性，另外一部分人去负责效率。其中又产生了一个很有意思的概念，对于有效性的控制，也就是现在的二线管理。当你去管理有效性的时候，可以转化为财务指标。对于效率，我们称之为一线管理，冲到一线，做生产结构的调整和效率的提升。我们觉得习以为常，是因为我们站在先哲的经验上。

2 21 世纪以来的挑战

《21 世纪的管理挑战》的作者彼得·德鲁克认为，所有管理实践建立的基础，都是在人力工作的基础上，在整个 19 世纪和 20 世纪，主要解决的问题是生产制造，说白了就是体力劳动。我们所有的管理实践是在管理体力工人的基础上建立的。而今天我们主要管理的是知识工作者，知识工作者的兴起是对于 21 世纪管理最大的挑战。挑战在于两点。

第一，知识工作者的工作内容是无法被直观看到的。

你认为工作产出是那些代码？不是的，产生的是知识。在知识没有被消费时，工作是没有价值的。举个例子，如果你在做业务分析，无论是产品经理还是 BA，你可以把业务分析的很好，但前提是别人可以听懂你在讲什么。写的再清楚、流畅，但别人看不懂，你的工作就没有价值。换句话说，知识工作者不能决定自己的价值，而是由消费者决定。知识工作者的效率来自协同效应。也就是你说的我懂，不用废话。大家都会发现团队团队磨合越久，工作会越来越顺畅，这是因为彼此之间的知识交互非常频繁，已经产生了协同效应，知识壁垒消除进而效率提高。而当你过分强调身份、角色划分的时候会影响团队效率，分工就无效了。

第二，效率和有效性是无法分离的。

因为知识工作者的真正价值是在消费过程中产生的，所以有效性和效率是无法分离的。很容易理解，我们 15 年前在厦门跟做敏捷开发，很困难，因为做一个产品投放到市场上，没有人可以保证一定成功，就算现在的互联网巨头也无法保证。今天有效性和效率的分离，使我们默认形成的金字塔结构失效了。换句话说，当要管理的人是知识工作者时，我们必须要承认旧的管理方法和管理理念已经完全失效了。

因为我们会管理三件事情：时间、工作内容和工作产物。工作内容在你的大脑中发生，不会以肌肉的形态外化出来被别人看到，喝咖啡的时候可能在工作，坐在电脑前却可能在摸鱼。工作内容是无法管理的，对于一般管理者来讲也不愿意去管理。作为一个知识管理者要管理属下的内容，那么你必须是一个专家。其实很多技术管理人已经丧失了一线经验，就导致很难管理工作内容。工作产出物对于正常的管理而言时间太长，没有办法对管理进行有效的反馈。所以，在这个我们常规管理的三个维度中只剩工作时间。这就是为什么在我们这个行业，会密集的出现“996”，其实是管理者的无能。因为他们所有的工具只有上个世纪基于体力工作者管理的经验总结下来的最佳实践，现在用来管理知识工作者，则会感到深深的无力。在这个过程中没有人赢，我们今天对于知识工作者的管理退化为奴隶制了，没有其他办法。这就是我们如今管理缺失从本质根本上带来的影响。

如何解决？我们必须要跳出现在的管理框架，不要用它来管理开发团队。否则肯定会失败。因为从本质上来讲出发点错了。在过去十年，我们探索了两个可能的方向，一个知识管理。既然，我们的工作方法是知识的产生，真正产生价值的时候是知识的消费，我们就要从日常工作中知识消费的角度去考虑处理。

这也就不得不提到三类知识：显性知识、隐性知识和不可言说知识。隐性知识是可以被显性化的知识，没有说出来时是隐性的，表达出来后就变成了显性。还有一类是不可言说知识，有一个庄子讲的寓言，他看到一个 60 岁的老人在马路上削车轮，就问道：“老大爷你这么大岁数，还在从事如此繁重的体力劳动，是为什么呢？”就好像你去问一个程序员还在一线写代码，是喜欢吗？当然不是。这个老人说，削车轮的秘密我可以告诉你，下刀慢容易圆，但是费力；下刀快省力，但不容易圆。这个过程中，我们要不快不慢，得心应手。这件事情我可以给你讲出来，但你肯定不会，因为不是说两句话就能明白的，我也无法教会我儿子，所以只能自己做。实际上在讲，能被记录下来的信息并有效传递的知识是有限的，就算以最大的意愿尝试对它进行显性化的描述，依旧如此，所以叫不可言说的知识。

工作中也会有“不可言说”吗，非常多。大到业务价值、产品愿景、架构，小到最佳实践，工作方法，都是不可言说知识。那么这该如何传递呢？主要通过社交化传递，Socialization，说白了就是聊天。提起工作，中国对于不可言说知识的研究历史比任何国家都长，我们的禅宗、佛教、道教都会有。在日本，寿司师傅会说，学习不是靠书本上，而是靠眼睛去偷。意思就是要在工作中观察师父怎么做，在过程中学会。很多工作中真正有用的知识和技能，都是通过不可言说的方式来传递的。

回到我们开场讲的故事，敏捷软件开发就是围绕着 Socialization 做的。大家会发现敏捷是“话非常多”的，因为每个迭代开始时，之前要跟客户先确认需求，再来 showcase，会持续很多站会。开发时要结对编程，开发拿卡时需要和 BA 沟通。社恐的人参与敏捷软件开发，可能都会被治好，因为它强迫你每天跟人说话、活动、社交。我们是知识工作，中间要传递大量的不可言说知识，所以必须要足够的社交化活动。

换个角度，你会发现软件开发是历史上第一个把知识管理当做项目管理的核心管理方法，管理知识消费的流程，给大家提供足够多的交互场景。不可言说的知识是通过循环性、有节奏的反馈和故意设计的社交活动传播的。所以，这才是敏捷方法真正能够工作的原因，而不是那些所谓的形式上的工作时间。其中格外要强调结队编程，之前我们在中国做敏捷开发，被误解最多的就是结队编程，为什么要两个人写一段代码？很简单，因为这个时候，任何一个人的产出马上就有另外一个人消费，他写的知识如果旁边的人都看不懂，那么不要期待过两个月他自己能看懂。而一坨不能维护的代码，对于今天的企业没有任何价值。所以要追求的是随着业务需求的可变性，如果不知道该如何管理，可以先思考团队中产生的知识是如何被消费的？质量和效率如何？这是第一个出发点。

第二是团队认知行为。什么样的团队是好的？就是大家经常开玩笑讲的一句话，我们要的是团队，不是团伙。团队里面一定要有支撑结构，对外展现出一定的认知行为，给他刺激后要有反馈。团队受到的刺激是需求的输入。产品要上线或者其中的事故都是刺激，团队要做的反应就是认知行为。

认知其实很简单，我们可以套现成的模型去理解。我们在很多地方都看到这张图，我们把它叫做“Cynefin Framework”，很多人以为这是对问题域的划分，并不是。他其实是对认知行为的划分，没有复杂问题，只有复杂的认知行为。

里面规范了五种认知能力，从低到高分别是失序、混乱、复杂、庞杂、简单。比如说对一个简单的问题，先 Sense，发现这个问题是什么，然后对这个问题进行分类，再 Respond。这上面就是我们对于简单问题的处理。比如 Obvious，表示需要处理的事务，明确知道处理方法，可以重复，而且有“最优”方案，“照方抓药”就可以了。Sense-Categorise-Respond，这种行为通常也被称作是“流程化”的，它也被称作“单纯官僚行为”。这也是我们之前在管理学界犯的最大的问题，认为所有的行为都可以通过这样的方法去做。的确，它是成本最低、效率最高的，但并不是所有的行为都能转化。我们的错误在于希望把所有的事情都变得 Obvious 化，追求定制高度重复，减少灰色地带等等。在软件开发中也会有。比如说在测试驱动开发中，生产代码的编写。Sense，我有一个小粒度测试失败了，然后 Categorise 当前组件的实现策略与方法，最后 Respond，依据实现策略成功实现。生产代码的编写，要在最高认知行为下进行，否则就没有效率。

接下来是 Complicated 庞杂，也是专家模式。方法也是先 Sense，有几个解决方案，然后 Analyse，再去 Respond。最近管理学界的一个新兴的思潮，叫做“技术官僚”，当一个有很深技术背景的专家处在做官僚的位置，他便知道有几套解决方案，从而挑选最合适的。所以大家都在想，怎样才能使更好的“技术官僚”进入管理岗位，提升整体管理的效率。例如驱动开发中的测试代码编写是非常难的，真正写测试要比写生产难得多。我们公司在做 TDD 的时候，都是经验深的人写测试代码，经验浅的人写生产代码，最资深的技术专家以不写生产代码为荣。对于组织而言 Obvious 和 Complicated ，直观简单的行为和专家模式应该占据我们日常工作的绝大部分比例，他们被称作有序的认知模式。

那么无序的状态 Complex，是 unknown-unknown 状态，行为模式就是 Probe-Sense-Respond。所以我们有很多的事情，是在做之前不可能知道对错，需要反思才可以。比如 Spike，我们去做一些技术实验检测，这个框架和工具没有用过，检测一下这个方案是否可行，尝试后才知道是不是需要被扔掉，这是小范围的。大范围则是你做的任何需求，因为直到上线之前，都是一个尝试，所以现在经常讲软件开发是没有需求的，只有假设，需要在市场中真正被实践之后才知道结果。

最后 Chaos，紧急情况。我更喜欢叫做应激模式，不管怎样需要先动起来。当处在应激模式的时候，90% 并没有解决真正的问题，甚至都没有进入到解决问题的环节，只是让心里获得安全感，因为你希望马上响应，采取行动，建立秩序，而这个时候做出的反应 80% 可能都是错的， 比如线上事故时，还没有解决问题就先把事故进行隔离，再来恢复等等。所以对于组织而言 Complex 和 Chaes 会占据日常工作的一部分比例，他们被称作无序的认知模式，我们需要降低它的比例，让它受控。

再举一个我们工作中最常见的 Complex 认知行为，调试，Debug。当一个人开始 Debug 的时候，说明他不知道这个代码发生了什么，要打一个断点先看一看，然后再做。作为程序员，或者管理程序员，要记住擅长 Debug 的程序员都不是好程序员。我已经有十年没有用过 Debug 了，因为它是一种低效的认知模式。一旦我们理解了这种行为模式之后，才能判断团队效率到底在哪，瓶颈可能在哪，我们可以从认知模式上把团队作为一个整体去管理，是一种更好的管理行为。

这同时还揭示了我们团队杠杆秘密，真正的杠杆是认知能力杠杆，并不是经验杠杆。有人可以在团队认知活动逐渐从无序变得有序，让认知逐渐提升的过程，这是我们真正产生杠杆的地方。19 世纪以来，我们常用的管理实践依托于构造知识壁垒和效果效率分离，这为 21 世纪知识工作者带来了新的挑战，我们要通过社交化传递打破知识壁垒，通过认知行为构成有效的认知杠杆，从而打造高效能团队。