重构技术管理

技术做久了，做什么事情都想用技术思维来解决一个问题。技术思维是一种务实、直接，以问题为导向，什么问题都想用技术手段来解决的思维方式。接下来尝试用技术方案来重构一下我们的技术管理工作，部分方案也可适用于所有管理工作。

主从

主从是一种常用的高可用方案，可有效避免单点故障。管理者很容易成为单点故障，一方面是企业的成本因素考虑；更重要的一个原因是有些管理者自身想让自己成为单点故障，这样他在企业的重要性就更大。美国总统就是一个一主多从的架构，在1947年通过的“美国总统继任法案”中，是规定了一个十多个从节点的继承顺序。

华为在决定管理者是否能晋升的一个标准就是是否培养出合格的接班人。如果管理者把自己硬生生逼成单点故障，其实也是截断了自己晋升的道路。

去ESB，拥抱注册发现

SOA和Micro Service的一个区别是SOA通常采用中心化的企业服务总线ESB的方案，而Micro Service更多是使用注册中心的方案。

ESB的方案就是不同部门，不同团队之间不互相沟通，都喜欢找各自的领导来当服务总线。A部门的男生喜欢B部门的一个女生，他不能直接去表白，必须是男生找他的领导，他的领导找B部门的领导，B部门的领导再转达给女生，如此循环往复。最后这些管理者就把自己的工作干成了传话筒，深陷其中，不能自拔。

注册中心的方案就要优雅高效多了，A部门的男生喜欢B部门的女生，男生找一下他的领导，他领导和女生的领导了解一下情况，如果是单身可撩，就组个局，把人都叫上，注册发现的工作就完成了。如果你担心事情搞砸，你可以定时跟踪一下进展，有问题的话你可以指导，补救，千万不要想着你的团队不行，你自己上。

我在做技术管理这两年，发现好的管理者都是采用注册发现的方案，毕竟自己在公司人脉更广，影响力更大，引荐一下，双方沟通会更顺畅。极少数管理者，真的就是乐于当ESB传话筒，因为他担心跨部门员工无法沟通，我觉得是多虑了，你把任务交给他后，他干的有可能你自己干还好。

避免随机读和线程切换

人是无法一心二用的，这个在美国的流言终结者节目中做过实验了，而且人的线程切换成本极其高，比CPU的线程切换，磁盘的随机读写还要高。技术人员专注工作时，就跟武林高手在修炼神功一样，轻则功力倒退，重则伤及七经八脉，走火入魔。

管理者经常拿重要紧急四象限来说事，结果在工作中却不想着如何才能避免线程切换和随机读写。这种工作效率及其低下。我有时候在思考一个问题时，思路刚刚理顺，突然来个人，硬生生打断我，问我是喜欢吃橘子还是喜欢吃苹果，等我回答完后，我整个人就感觉恍如隔世，我是谁，我刚在干嘛。

一个优秀的管理者应该避免团队成员时间的碎片化，保证沉浸式工作时间。为什么精英都是时间控这本书建议上午为沉浸式工作时间，你别看10点到12点只有两个小时，这两个小时的工作效率能超过下午4个小时。

采用最终一致性

在几百人的团队，如果你想保证强一致性，那势必会造成低效，因为什么事都需要一个人决策，那就是N多事情都在等着一个人来决策。采用最终一致性是一个相对合理的方案，我们需要赋予团队一定的决策权，允许出现短暂的不一致情况，通过周例会等方式达到最终一致性，有问题也可以回滚。

分而治之

架构之道，一言以蔽之，分治而已矣。我们常用的分层架构模式，设计原则里的单一职责，接口隔离，二分查找、快排等，都是把大问题化成小问题，再去解决小问题。管理问题是一个很复杂的问题，互相影响，相互制约。我们可以把管理问题进行分层

•业务执行（以交付为导向，短期利益）•体系建设（长期利益，技术体系，管理体系）•团队管理（人员培养、文化建设）•工具支撑

举个例子，我们在评价软件质量时，会用缺陷密度（缺陷数除以代码行数）来进行评价，有些人就反对说，那会有些团队故意多写代码来降低缺陷密度。如果是这样，那所有的管理制度都不能执行，或者就得把管理制度定成几十万字的大部头，所有的可能性都罗列进去。多写代码是两个问题，故意多写和无意多写代码，故意多写冗长代码是人品问题，应该从招聘和考核来解决；无意多写冗长代码是能力问题，应该通过代码规范、指导、自动化代码检查、pr来解决。

自动化

手动完成，一个小时它也是O(n)复杂度，用程序自动完成，3天它也是O(1)复杂度。重复性的周期性工作，应该用程序来自动完成。

本文分享自微信公众号 - 程序员阿水（gh_124d28263603）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。