梁鑫宜信高级架构师，开发平台负责人

专场20：云原生架构设计与应用实践

还记得现场梁鑫老师的开头语吗？

我不知道各位大拿有没有这种感觉就是：“离管理越近，与技术越远”。

你能够自己花时间去get技术的时间越来越少，很多时候变得知其然，贪求架构贪求效率，对技术没有更多时间了，很多时间被消耗到跟其他同事沟通啊，管理上的一些事情，如果你遇到一些非常精通技术的中层或是总监，话并没有说完！

其实当天我们现场有很多技术主管，都是从coding开始的，大家也都说了很多关于自己成长中的经历，

无外乎这几个关键词：

不升职，能力也不允许

升职，管理真没有挑战力

不难发现，大家是真心喜欢coding。

其实也接触很多高层，一些高管，股东，因为在ITPUB吗，老社区了，之前的老朋友们，都已经经济自由啦，大家有的还在坚持写代码很多是因为喜欢，大家不喜欢做管理，公司用程序运行最好了，人越多越不可控，人心是最难管理的。

这个问题，也许永远也没有正确答案，但是梁鑫老师新提供的内容，好像说明了一些什么！

（在这里是大家私交的空间，所以我没有做任何整理，大家确认的内容，我们是想发到另一个收费俱乐部里头，价位没这么高，受益范围会广一些，收得的费用，用做咱们之后的聚会班费，可好？）

1、离管理越近，离技术越远

做技术的人永远都会时常陷入一个非常端矛盾的事情中，就是随着你的级别越来越高，越来越多的管理沟通工作会占据你大部分的时间。

那意味着你不再有足够的时间能够深入的了解各种技术，不能再有足够的时间去阅读各种源码。当有新的产品出现时，你已经没有办法去深入它的源码层去学习它。更多的情况是从架构层面、设计层面、运行层面这些相对视角较高的地方去了解它。当遇到具体需要解决问题的时候，很多时候往往需要深入到源码层级的了解才能解决问题。你又没有时间去学习源码，怎么办呢？

一个技术leader有一个重要的职责就是培养优秀者，当你个人的精力不足以同时兼顾技术研究和管理沟通这多方面事情的时候，你如果已经

培养了多个优秀的技术人员，其实你不需要为你感到苦恼。你只需要从高阶层面去了解新产品，新技术就可以，把具体的代码研究工作下放，让团队里其他优秀的同事来做源代码的研究学习工作即可。最关键的是做一个技术的leader，不能只管理无技术。你仍然需要研究具体的源代码，只不过要减少到那些你个人专注的领域。也就是技术管理常要努力的T型人才的方向。

2、团队管理的行为——相信优秀者，跟踪胜任者，帮助欠缺者

随着时间的推移，可能一个技术leader管理的团队会越来越多，我通常喜欢把团队拆的非常非常小，一般两人或者三人，最多不超过四个人。再把工作拆的尽量小一些，但要保持某种独立。这种划分虽然保持着高效率，但当团队数量达到七、八个甚至十几个的时候，你就很痛苦了。你不再有足够的时间和精力去管控每个团队的工作，怎么办呢？

每一个团队都会有一个leader，这个leader往往都是你选拔和任命的。这些leader有些可能是你招聘进公司的，培养了很长的时间，有些可能是从别的团队调过来的，总之你会对这些leader有些基本的了解。很多管理者在这个时候都是通过固有模式的例会或者什么其他的方式来管控每个团队的工作。但我往往先把他们分成大致三类：优秀者，胜任者、欠缺者。对待优秀者，你可以放心的把事情交给他，采取散养的方式。只需要在事情开始之初把目标严格的定制下来，然后每到一个里程碑进行汇报即可。对待胜任者，就不可以完全散养，一般会按周或者双周进行例会。要通过各种工具对工作事项进行监督，每周要跟踪工作周报。还要督促团队leader也要向你一样进行管理工作，让他尽早从胜任者进步到优秀者。欠缺者未必是真正的欠缺，可能是由于经验不足，阅历不够等原因，当需要一个leader来管理一个小团队时，又没有足够能胜任工作的人。对于有潜力但还欠缺一点能力的同事，赋予这样的职责。对待这样的团队，很多事情就需要手把手来进行了，从技术研究、产品设计，架构设计、数据建模、页面设计、例会、工具等各个方面都要参与进去，当然可以根据实际情况确定参与的程度。

3、在任何一家公司，技术产品永远是适者生存，非强者生存。

技术人员经常会做出一些overdesign的事情。比如过度的考虑并发，过度的考虑性能，过度的希望采用新技术而忽视那些可能出现的一个个巨大的深坑。举一个小例子，有一个业务项目组在测试环境下做了一次压力测试，发现性能很不理想，平均响应时间超过2S，不能接受。要求平均响应时间压缩到1S内。我团队的两位同事跟进了这个case，他们决定用缓存服务器的方式增强查询效率。同时做了大量的研究和设计，选择memcached还是redis，怎么进行数据更新避免脏读等等。我知道这个事情后，问了他们两个问题：

1，测试环境的网卡是千兆的，生产环境是万兆的。

2，测试

环境的机器CPU都是2核或者4核的，生产环境至少都在8核以上。在你决定采用缓存服务器的方式前，能不能先在生产测测效率，当然要选择在晚间。

测试结果出来后不到0.2S，完全不需要做任何特殊的处理，给项目增加不必要的麻烦和潜在的风险。

在更大的项目中这样的例子就非常多了。有时候你考虑到百位的并发就够了，不需要再去考虑到千级万级的并发；有时候你的响应时间到秒级就可以了，不需要再追逐到毫秒级；有时候用HTTP就足够能handle业务了，就不需要非得RPC来解决问题。把这些不必要的因素刨除，追逐简单、直接、有效，反而更能创造出优秀的、适用的项目产品。

4，技术管理者的个人成长

从以上三个方面论述，作为一个技术管理者，不再纠结管理VS技术，学会把自己培养成一个T型人才。团队越来越多的时候，把团队leader分成优秀者、胜任者、欠缺者然后进行因leader施管理。同时在进行工作的时候要永远从实际场景出发，相信项目产品同样需要适者生存。更要坚持简单、直接、有效的做事原则。我认为理解了这几点对一个技术管理者的成长会有很大的帮助。