没有人会认为自己是一个主次不分的笨蛋，但实际上，团队合作过程中表现出来的综合智商就是低于个体智商的。 再加上，团队中，总是会掺杂一些“不知道自己不知道”的盲目者，最终会把团队带向歧途。

举一个在腾讯内，很典型很常见的例子。

本来有一个团队，可能原本他们是负责一款软件 App 的研发，在执行工作的过程中，发现自己缺少了一个基础组件。这个组件可能是一个 crash 率的监控组件，也可能是一个为了解决性能问题而诞生的性能监控组件，还可能是性能辅助工具或者日志工具组件，等等。所以他们就会安排员工自己去做这样一套工具组件出来。

当工具组件开发完成，也能够满足自己使用的同时，他们就会诞生一个想法，就是这个工具组件，在旁的团队是不是也需要？这样常见的工具，很大概率大家都会需要吧？如果我们把这个组件推广出去，我们的技术价值是不是就会扩大？研发同事是不是就有更多的晋升素材？大家似乎能从中捞到好处，而且是以技术的名义，看起来还很正义。这样的想法，大概率都是一拍即合的。

这个想法本身没有错，如果说我们有充分的时间精力，或者说我们确实做出了一个通用化的工具，且通用的价值也足够大的话，是可以去做这个事情，但是现实往往很复杂。有可能他的主项目处于人力紧缺的一个状态，有可能他们的业务正在生死边缘，都快做不下去了，有可能主业务那边还在拼命招人，却招不够，找不到合适的人才。但是，这边却又拎着一支技术队伍去做以通用化为目的的技术工具。那么最后的结果是什么呢？那就是浪费了更多的人力和时间。 

那这件事能不能够成功呢？

首先他还不一定能够成功，对吧？即便他能够成功，它也仅仅只是给别的团队提供了一个不一定很适用的工具。别的产品团队拿过去用，可能还会抱怨说这个工具不太好用。自己还得持续投入人力去不断完善。因为每个团队有自己软件架构的一些特色特点，用法特征，你做成通用化的，别人拿去不一定是最好用的，原本只做给自己用，完全以自己的使用方法习惯和团队的成员的特色去结合，是很好用的。但是他把它通用化之后，有可能自己也不一定好用了，别人也不一定是最适用的，虽然它可能有一定用途。即便最终有人用了，那旁的团队能给到他什么呢？能支持他的业务成功么？显然不太可能。

所以，我们要思考一下，我们在一家大公司里，做这样的一些小的基础工具产生的价值，和我们做出一个真正意义成功的产品的价值的对比，差异有多大？完全不在一个量级吧，一款产品的大成功是决定性的价值，而一个或者好多个通用的小工具，其价值能与之相提并论么？

还有一个误区就是来自于规范化，为什么规范化也会形成干扰呢？规范化不是好事么？如果一个事情是很容易能看出来问题的，就不会叫做误区了。我们都能明白，日常生活中，最可怕的人就是面像和善的斯文败类了，对吧？因为你被表象迷惑了。

继续举一个例子：比如某个团队复盘研发效率低下的问题，复盘的过程，会去追究为什么研发效率低？原因是他们的团队的同事在这些模块接口的调用用法之间老是搞错，或者找不到正确的用法，于是又另起炉灶开新的接口，形成各种垃圾代码山。或者说把接口用错，模块重度耦合，牵一发动全身，等等。这些都会制造很多的时间成本，而且还必然会导致一些质量问题。

所以，面对这种情况，如果技术管理的主导者，自己的技术能力不够强悍而又厌倦了无休止的讨论后，会很容易能够想到的，不需要太动脑子的方法就是：“我们要增加注释，把接口的规范统一整理，把架构和目录统一整理，要让软件变得更加易读，架构更加清晰”。当然，这个内容本身是很正义的，听起来也貌似很美好。【注：他们大概率没有能力去想到，员工能力培养的方法问题，技术骨干的甄别技巧问题，以及，其实应该由技术总负责人自己亲自设计架构等核心因素… …】

一个听起来很正义的事情要推行下去的话，是容易得到大家的支持的。但是真是去推行的时候就会发现问题了，因为没有去定义注释写到什么程度是合格的，架构清晰到什么程度是合格的，于是就需要有专人来做这样的规范。

这个时候团队里面就会开始形成了分工，会有专人来负责这些规范化的事情，而负责规范化事情的同时，他的 KPI 和他的核心职责就是让规范足够的极致。这一下就开始完蛋了。

大家可以想象到一定会有过度的规范制定出来。因为既然有专人来干这个事情，就会有人把这种事情当做 KPI 或者 OKR。这种规则，即便严苛，但因为一开始这个是所有人都举手所赞成支持的事情，后面怎么可能自己又跳出来反对呢？所以，反对的声音都是很渺小的，于是他们的团队的成员就会形成一种：”我感觉这件事情有点不对，但是我又说不上来哪里不对“ 的感受。

最后的结果是什么？就是会开始形成一些有意或无意的抗争，或者是执行怠慢。

那么负责执行规范的人就会发现规范大家都很支持，却很难执行，因为大家有反抗情绪。他们的领导层往往会在事后，收到执行上出现困难的一些声音之后，开始举行一个反思会，或者说复盘会，去思考他们这么做是对的吗？

他们很快会发现这件事情上，单就规则本身来讨论，它一定是一个正确的事情，所以他们没有办法去把复盘出来“这个事不需要继续进行”的结论。而且大概率会复盘出另一个结论，就是：“这件事情要继续做，而且是坚决的做，没有执行好是因为不够严格，规则还不够明细，奖惩措施没有落实到人。做得好的应当奖励，树立标杆，执行不好的人要有惩罚！”

接下来，他们就会开始细化如何用更强制的措施让这个事情能够执行得更好，怎样甑别那些干扰的人，不愿意严格执行的人。而强制的措施最容易想到不太用动脑子就能想到的解决方法就是打分，打分就可以量化，就不用去个例化分析了，因为个例化分析太难了，团队的人那么多，情况那么多对吧？

他们急切地希望制定很多的一刀切的规则标准，拿着这些一刀切的规则和标准去要求大家，这样才不会老是遇到争议。

根据这些标准来量化大家做的事情，这个时候团队的失败就进入到中后期了，因为他们所有的时间和精力就开始围绕着分数去进行工作了。团队成员的目标倒是很明确了，把分数做高就对了。但是，这是整个团队的最终目标么？

监管团队的人在制定规则，他的 KPI 他的思考变成了思考规则，而做事情的人变成了围绕分数去进行工作。

本来我们是应该围绕着产品的成功去工作的，但是，这个产品如何才能成功这件事，是谁在负责？这个时候，已经几乎没有人负责了，只有领导大老板自己一个人在负责。但是他又想不明白有什么不对劲？因为他安排下去做的事情都是围绕着他的目标想要做好而推导出来的事情，最后却做得一团糟，所有人都在努力，却都没有围绕最终目标去做。

其实背后的原理就来自于一个偷懒的行为：就是他们不想具体案例具体分析了，他们希望制定统一标准之后，大家统一地来套这个标准就好了，不要有谁去挑战规则。这个才是问题的症结。

当然，实用主义也不是说我们就不要规则了。因为有些事情它的量级很高，量级很大，如果每一个问题都要具体案例具体分析，大家也累不过来。这种时候，是需要真正的技术领导者来统筹全局的，对问题的洞悉不应该来自于层层传递，而是本身的深度理解。

例如大部分软件足够庞大后，会碰到多线程带来的稳定性问题，会引入层层叠叠的规范和规则，以及层层叠叠的架构保护措施。几乎无穷无尽，最后还是解决不干净线程问题。而我会要求企业微信的线程数量严格控制，io 都是一个线程，网络也都是一个线程，再加上 UI 主线程，常规情况下只有互不干扰的3个线程。当然，也允许特例，但是非常有限，都需要懂这套规则背后原理的人来审核。几年下来，企业微信这样一个几千万行的超大型软件系统，几乎不会遇到任何线程上的质量问题。这为我们的快速迭代提供了极大的助力。当然，这个只是无数措施中不起眼的一小条而已。最关键的是，主负责人，自己理解是否对。

当然，团队里的核心人物数量有限，当事情的量级达到一定程度的时候，我们一定会迫不得已会用一些自动化的或者说一刀切的规则化的方式去做事情，这些规则化实施的时候，一定要遵循一个原则：就是这个规则面对一些个例的时候，要有一个方法去衡量边界，越界的，就必须有足够能力的技术 leader 来独立分析解决问题。要不然技术 leader 干什么呢？只管人不管技术就不是合格的技术 leader 了。

规则不能贪多，不能一开始就妄图制定涵盖一切的规则。规则太多就没有办法做到每一条规则都完美化了。当我们定规则定得太快太多，又长时间不更新不回溯，它们就会形成我们前面讲的失败的案例的结果。