成为会带团队的技术人建机制：规则流程越建越多，为何效果却越来越差？

本文主要是介绍成为会带团队的技术人建机制：规则流程越建越多，为何效果却越来越差？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

上一讲我带你围绕沟通的不同维度、场景，提出“在信任的基础上，让沟通简单且纯粹”的观点，今天这一讲，我们来聊一聊在团队中怎么建立与落地机制。

你有没有发现，在日常工作中，大到公司的 KPI 考核、战略目标设定，小到项目例会、事故应急处理、需求优先级调整，这些事情如何处理，谁来处理都是被提前定义好的。

从我的视角来看的话，这些规则和流程都是某种机制的具现化，通常我们为了解决某些问题、达成某些效果会定义一些规则，希望人和事物发展在规则内进行和处理，这就是一个建立机制的过程，而机制的落地的方式则是很多事物的组合（人、流程、工具、信息……）。

当我们简单地找到“机制是什么”的感觉之后，接下来就从三个方面展开“建机制”这件事儿（在这个过程中，我也会结合一些过往的小案例）：

机制发挥什么作用？达到什么效果？
如何考虑和设计机制？
机制在团队中如何落地？

机制发挥什么作用？

一般而言，我们为了长期、持续、一致地拿到某个结果或者处理某些问题，就会设计对应的机制和流程。平时，你最容易接触到两类机制。

与管理相关： 比如为了信息互通，约定每周固定时间通过邮件、会议、IM 等方式，将提前定义好的信息做一个汇总交互（表现为周报、周会等），这就是机制的一种具现。
与技术相关： 比如为了多人协同，制定开发流程、Bug 处理、发布上线流程，甚至在日常实际开发的工作中，往往也先定义 API 契约，然后在联调测试时再真正实现验证，这些约定、契约、流程都是对应机制在落地时的具体表现。

所以通俗来讲，“建机制”就是当你要长期持续地处理一些问题时，需要跟解决该问题的相关人针对怎么处理问题达成一致，然后按照约定的方式去执行（回想一下前面学过的内容，其实前几讲就与机制相关，不管是稳定性中的应急机制、发布机制，还是技术债务中债务 CheckList，其实都是在设计处理问题的机制）。

站在团队的角度，建机制尤为重要，你要通过机制让团队有统一的行为与规则，让组织像人一样，言行举止有规律可循。

听起来很容易，可要设计一个有效、持续发挥作用的机制并不简单。你不但清晰地认识到所处的环境和要解决的问题，还要让团队成员认可并实践，毕竟大部分机制的执行还是依赖于个人。

那你要怎么建立机制呢？

如何设计一个好的机制？

我们不能否认，每个团队都会存在一些“特别不合理”的机制，比如因为问题和环境已经发生变化，但是原有机制没有随之更新，显得格格不入，不合常理；又比如为了解决 1 个问题所建立的机制又源源不断地制造了新的问题。

这时，你不要着急着推翻重来，而是要置身其中，明确“解决什么问题，想要得到什么结果”，先了解问题、梳理思路然后再想办法调整和优化。另外，既然建机制是管理动作的一种，那么就要遵循我一直强调的“简单、容易理解、便于操作和完整闭环”。在这里我围绕建立机制总结了三个关键点。

规则统一，不自相矛盾

一些机制是通过技术自动化实现的，比如系统出现异常自动告警，但管理工作中大部分机制是靠“共识契约”运行的，所以机制定义明确、清晰、统一尤为重要。比如定义“每周任务安排”的机制，规定：每周一下午2:30，团队成员以先认领再分配的方式确认本周内容，并商定交付时间、标准，在会后将结论统一记录并公布（通过 PM 工具或者邮件、文档等方式）。

反之，如果该机制的运行时间、参与者、结论非明确或不固定（比如有时周一、有时周三，有时 3 个人、有时 5 个人，那么该机制就没有任何实操的价值了）。所以，机制内容要尽量统一和固化，让成员有清晰且一致的认识。

简单有效，便于增删

不要设计需要成员用 10min 理解的机制，机制的设计一定要围绕某一个要解决的问题，否则 Cover 的场景越多、条件越复杂，用的时候就会面临很多困难，机制本身也很难真实地发挥作用。比如一个处理慢 SQL 的机制，在如何定义慢 SQL 时，如果有 N 种满足条件需要人为处理，那么执行起来就会很困难。所以，你可以先定义 2~3 个条件，比如时长超过 xxx 毫秒，调用次数超过 xxx 次，先让机制跑起来可以处理问题，再慢慢优化。

紧盯整体结果，机制的 ROI 要足够高

有些机制看起来能解决某类问题，但当你放大到一个团队或部门之后，为了解决该问题所付出的代价甚至超出了问题本身带来的影响，那么就得不偿失了。另外，日常工作中“捡芝麻丢西瓜”的情况并不少见，有的 Leader 为了最大程序掌握团队的开发工作，要求每人每天按照一定的格式书写日报，然后由他进行汇总。

也许这个机制确实会帮团队发现一些问题，但也会增加低价值工作量，成员大量的时间在做计划和总结却没有精细化执行，很多时候为了解决 A 问题却产生了 B、C、D 等问题。

所以，机制的设立一定要站在整体和长期的视角去看，去看它对每一个人和团队的影响。

在现实工作中，树立机制的维度你可以围绕 4 点：奖罚（你可以参考 10 讲的内容）、反馈（线上问题的处理很典型，当发现线上出现异常时，怎么把相关信息反馈到对应的负责人）、沟通（形式非常多，比如会议、周报、OneOne）、决策（需要很多人针对某一个问题给出具体的答案，比如决定某一个技术方案）。

机制要怎么落地？

当你设计好一个机制想要它发挥作用时，需要所有相关人形成统一的共识，通常可以将团队成员拉到一起开会讨论，会上主要聊 3点内容。

先说 why： 即机制的内容是什么？为了解决什么问题？你在设计机制时是如何思考的？
共识的要与不要： 和大家讨论我们要不要这样做？看看大家是怎么想的，通过对话和引导形成一定的结论，有些内容需要保留，有些不合理需要剔除，促成结论最为重要。
承诺行为举止： 确认机制之后，需要让结论形成对各自行为的约束。比如不同的成员认领不同的角色和任务，或者在 IM 中一起公告规则，总之每个成员要与机制的参与感。

案例详解

以上就是“建机制”主要的理论内容，接下来我以信息互通的会议设计和开发流程中的CodeReview 为例，和你进一步看一下机制的具现应该是怎样的。

会议是往往是重要信息沟通、讨论、同步的首选方式，很多重要机制的落地都会涉及会议的方式，这里我单独把技术涉及的周期性会议罗列出来。

你可以看到基于不同的目的所举行的会议在时间、参与人、内容上都有所差别。作为技术Leader 要先掌握怎么开会，以及开什么样的会，合理的会议安排不仅让事情更加有条理，也便于团队成员参与。

各类会议的设计

看完会议之后，我们再看一个更完整的案例，如何做 CodeReview ？ 如果我们站在想推行CodeReview 的思路去看，就需要设计一个机制让大家能把 CodeReview 做下去。

先考虑目的， CodeReview 主要是解决两方面的问题：提高代码质量；帮助开发同学认识到如何写出更好的代码。不同的侧重点设计出来的机制也有所不同，按照我的理解，CodeReview 的主要作用还是帮助大家成长，打造团队内的技术提升氛围，次要才是促进产品质量的提升。

确定了核心想要达成的效果，接下来就可以着手确定机制的内容，这里面要考虑几个方面的内容：可能会遇到的问题（阻力）、机制实施的成本、机制运行的时机和周期、站在一个机制参与者的角度考虑他要做什么。

具体 CodeReview 的机制方案可以参考下图：

当然，再好的机制也不是万能的，CodeReview 并不适合所有的团队，比如：团队成员对其产生很大的分歧，产生极大的内耗；需求和业务已经应接不暇，生存很困难；团队处于创新和尝试的阶段，并不稳定。我想强调，任何一个机制都不会存在永久化收益，不是说在 A 团队的机制，放到 B 团队就一定会好。

总结

希望团队内所有成员都按照统一的方式去合力解决一个问题非常困难，而建机制在某种程度上就是为了解决“群策而不群力”的问题。另外，每一个机制的创建都存在成本，如果一个组织内名存实亡的机制过多，那么大家对机制的认识和执行都会越来越差，最终团队会一盘散沙、毫无凝聚力。反之，设计良好的机制会让团队整体的执行力提升，并且最大程序的将每个人的能力与特长整合起来。