二、管理懒惰与重度规范化问题
还有一个误区就是来自于规范化，为什么规范化也会形成干扰呢？规范化不是好事么？如果一个事情是很容易能看出来问题的，就不会叫做误区了。我们都能明白，日常生活中，最可怕的人就是面像和善的斯文败类了，对吧？因为你被表象迷惑了。继续举一个例子：比如某个团队复盘研发效率低下的问题，复盘的过程，会去追究为什么研发效率低？原因是他们的团队的同事在这些模块接口的调用用法之间老是搞错，或者找不到正确的用法，于是又另起炉灶开新的接口，形成各种垃圾代码山。或者说把接口用错，模块重度耦合，牵一发动全身，等等。这些都会制造很多的时间成本，而且还必然会导致一些质量问题。所以，面对这种情况，如果技术管理的主导者，自己的技术能力不够强悍而又厌倦了无休止的讨论后，会很容易能够想到的，不需要太动脑子的方法就是：“我们要增加注释，把接口的规范统一整理，把架构和目录统一整理，要让软件变得更加易读，架构更加清晰”。当然，这个内容本身是很正义的，听起来也貌似很美好。【注：他们大概率没有能力去想到，员工能力培养的方法问题，技术骨干的甄别技巧问题，以及，其实应该由技术总负责人自己亲自设计架构等核心因素… …】一个听起来很正义的事情要推行下去的话，是容易得到大家的支持的。但是真是去推行的时候就会发现问题了，因为没有去定义注释写到什么程度是合格的，架构清晰到什么程度是合格的，于是就需要有专人来做这样的规范。这个时候团队里面就会开始形成了分工，会有专人来负责这些规范化的事情，而负责规范化事情的同时，他的 KPI 和他的核心职责就是让规范足够的极致。这一下就开始完蛋了大家可以想象到一定会有过度的规范制定出来。因为既然有专人来干这个事情，就会有人把这种事情当做 KPI 或者 OKR。这种规则，即便严苛，但因为一开始这个是所有人都举手所赞成支持的事情，后面怎么可能自己又跳出来反对呢？所以，反对的声音都是很渺小的，于是他们的团队的成员就会形成一种：”我感觉这件事情有点不对，但是我又说不上来哪里不对“ 的感受。最后的结果是什么？就是会开始形成一些有意或无意的抗争，或者是执行怠慢。那么负责执行规范的人就会发现规范大家都很支持，却很难执行，因为大家有反抗情绪。他们的领导层往往会在事后，收到执行上出现困难的一些声音之后，开始举行一个反思会，或者说复盘会，去思考他们这么做是对的吗？他们很快会发现这件事情上，单就规则本身来讨论，它一定是一个正确的事情，所以他们没有办法去把复盘出来“这个事不需要继续进行”的结论。而且大概率会复盘出另一个结论，就是：“这件事情要继续做，而且是坚决的做，没有执行好是因为不够严格，规则还不够明细，奖惩措施没有落实到人。做得好的应当奖励，树立标杆，执行不好的人要有惩罚！”接下来，他们就会开始细化如何用更强制的措施让这个事情能够执行得更好，怎样甑别那些干扰的人，不愿意严格执行的人。而强制的措施最容易想到不太用动脑子就能想到的解决方法就是打分，打分就可以量化，就不用去个例化分析了，因为个例化分析太难了，团队的人那么多，情况那么多对吧？他们急切地希望制定很多的一刀切的规则标准，拿着这些一刀切的规则和标准去要求大家，这样才不会老是遇到争议。根据这些标准来量化大家做的事情，这个时候团队的失败就进入到中后期了，因为他们所有的时间和精力就开始围绕着分数去进行工作了。团队成员的目标倒是很明确了，把分数做高就对了。但是，这是整个团队的最终目标么？监管团队的人在制定规则，他的 KPI 他的思考变成了思考规则，而做事情的人变成了围绕分数去进行工作。本来我们是应该围绕着产品的成功去工作的，但是，这个产品如何才能成功这件事，是谁在负责？这个时候，已经几乎没有人负责了，只有领导大老板自己一个人在负责。但是他又想不明白有什么不对劲？因为他安排下去做的事情都是围绕着他的目标想要做好而推导出来的事情，最后却做得一团糟，所有人都在努力，却都没有围绕最终目标去做。其实背后的原理就来自于一个偷懒的行为：就是他们不想具体案例具体分析了，他们希望制定统一标准之后，大家统一地来套这个标准就好了，不要有谁去挑战规则。这个才是问题的症结。当然，实用主义也不是说我们就不要规则了。因为有些事情它的量级很高，量级很大，如果每一个问题都要具体案例具体分析，大家也累不过来。这种时候，是需要真正的技术领导者来统筹全局的，对问题的洞悉不应该来自于层层传递，而是本身的深度理解。例如大部分软件足够庞大后，会碰到多线程带来的稳定性问题，会引入层层叠叠的规范和规则，以及层层叠叠的架构保护措施。几乎无穷无尽，最后还是解决不干净线程问题。而我会要求企业微信的线程数量严格控制，io 都是一个线程，网络也都是一个线程，再加上 UI 主线程，常规情况下只有互不干扰的3个线程。当然，也允许特例，但是非常有限，都需要懂这套规则背后原理的人来审核。几年下来，企业微信这样一个几千万行的超大型软件系统，几乎不会遇到任何线程上的质量问题。这为我们的快速迭代提供了极大的助力。当然，这个只是无数措施中不起眼的一小条而已。最关键的是，主负责人，自己理解是否对。当然，团队里的核心人物数量有限，当事情的量级达到一定程度的时候，我们一定会迫不得已会用一些自动化的或者说一刀切的规则化的方式去做事情，这些规则化实施的时候，一定要遵循一个原则：就是这个规则面对一些个例的时候，要有一个方法去衡量边界，越界的，就必须有足够能力的技术 leader 来独立分析解决问题。要不然技术 leader 干什么呢？只管人不管技术就不是合格的技术 leader 了。规则不能贪多，不能一开始就妄图制定涵盖一切的规则。规则太多就没有办法做到每一条规则都完美化了。当我们定规则定得太快太多，又长时间不更新不回溯，它们就会形成我们前面讲的失败的案例的结果。所以规则要少要精，而且要时常复盘，对一些不能够完美化的规则，要及时地清理。不要太过懒惰地试图去批量的进行规范化，规范化一定要有节制。尤其是，有些事情，过去这样做是对的，今天，不这样做可能才是对的。
获取报价
销售热线
返回顶部
在线咨询
一键拨打