所有程序员的未来都是走向管理？

所有程序员的未来都是走向管理吗？

成为技术Leader需要掌握什么技能？

如何提高团队效率？

程序员的技术出路，走向管理后又会面临的很多问题，这是很多程序员都会经历的焦虑。

3月23日，养码场第8期CTO私享会在巴比特创立方举办，十几位CTO、技术管理者就【打造高效技术团队】这一主题进行分享、讨论。

现场的精彩，场主想分享给不能到场的养码人

吐

血

整

理

记得分享

威佩CTO 俞圆圆

高效团队技术leader必备的5点角色认知和责任

技术原点：

At the end of the day你还是一个工程师

当我们从一个工程师进化到管理者的时候，往往会有2大误区：

1、当你作为管理者的时候，你会认为管理能力的重要性，远远重于技术。 2、你会认为，管人（People management）的重要性远远重于管事(Project Management)的能力。

不能把学而优则仕，学而优则管当做常态。我并不是很赞成盲目努力，譬如让技术优秀的人去做管理岗，因为这样的结果很可能是，你将失去1个优秀的工程师，得到1个三流的管理者。

做到管理岗位就会高大上？这是一种挺大的误区。而重点其实是我们带给团队怎样的技术观和价值观。

首先，我们自己（技术Leader）保持自律。

譬如每年学习一种新的编程语言，每年深入关注一个新的技术领域，每年自己编码完成一个软件作品。

其次，了解到技术能力的的迭代和进化，对于整个技术团队的必要性。

我所看到的成功企的技术管理者，往往都是在技术领域上精益求精、不断提高自己。

会有很多人说：“我平时的管理工作挺忙的，实在没有时间去写代码，去学习技术。”大家可能听说过Google的Jeff Dean，带着3千人，但每周会给自己留半天或一天时间敲代码。

不管我们承担了多少的技术工作，还是要具体技术提高的能力，对技术的坚持，是我们应该传递给团队的价值观之一。

技术方向：721法则

技术方向是一个很核心的内容。而首先，需要明白技术和业务，是技术的2面。

1. 业务，或者说工程（Engineering），在不同时空复杂度的要求下，它会不断演变出新的技术（Technology）挑战来。 2. 警惕过度追逐没有实际问题可解决的技术热点，对于团队中类似“一直在做业务，技术没有进步”这样的困惑能胸有成竹地回答。

如何平衡业务和技术，可以参考721的法则。

团队70%的研发能力和研发资源要投入到公司的主线业务上去，这是公司现金流的主力；

20%的资源需要提供到技术攻坚上去，这类问题应该是已知且有解决方案的，只是比较有难度和深度，需要花多一点时间；

以上90%都属于一定要做的事情，需要can do的态度，而最后10%是未必能解决的，可以say no，因为它们解决的是高风险的领域，我们并不知道这个东西能否带来产出和效果，属于创新探索型工作。

很多时候，在投入最后的10%的时候，技术主管会受到很大的压力，因为财务部门希望把钱投在有营收的事情上，而业务部门希望所有的研发围绕着业务、客户的需求。这时候，作为团队的技术领导者，需要自己的坚持和参考，这件事情是否值得去冒一些风险。

“

技术的领导者需要做些前瞻性的投入，不能等到需求方倒逼。

”

比如，2017年，我们就注意到了Apache Flink实时数据处理框架。虽然流计算在Storm,、Spark Streaming等典型框架中也有体现，并不算新鲜的概念，但随着Flink在社区不断得到认可，2018年阿里开始做批流共进的计算引擎：Blink，基于Flink，但又继承了批处理能力(batch processing), 所以Batch processing+Flink = Blink，将批处理和流处理结合在一个框架里是比较有特色的。

因此，虽然当时还只是简单的技术框架，没有太多实际的业务场景，但是我们已经预感到在18年下半年开始会逐渐地有相关业务需求出来，所以我们就先一步地做了基础调研和资源投入，果然，在今年开年就基于之前的基础落地了实际的场景。

技术决策：依赖“常识”做判断

做正确的事

技术面试的时候：你对候选人不了解，你也很可能对他擅长的技术背景不那么精通； 技术选型的时候：流量、负载、容错性、可扩展性等等，都是未知但却必须考虑的因素； 技术攻坚的时候：不同的技术团队遇到的不同领域的技术难题需要你去指导解决。

技术决策里面，往往要面临的最大的挑战是不确定的情况，因为没有预先准备好的知识体系。这个时候，我们需要做到依赖常识去做一些判断，做一些正确的决策。

好的技术团队文化：重视逻辑、讲究常识、说人话、互相间尽可能平视的视角、不唯上只唯实。

“常识”工具盒

1. 评估候选人的能力（比如责任心，抗压力，创造力），而不是知识 2. 做任何决策，先问问评估成败的核心指标是什么 3. 核心指标宜少不宜多 4. 指标要尽量可量化 5. 先抗住再优化，边重构边生活 6. 持续迭代，而不是过度设计 7. 化繁为简 8. 其他人听不懂的一定不是好的技术方案 9. 让懂的人和不懂的人都能坦然地表达自己的“有知”和“无知” 10. 有违价值观底线的方案坚决不采纳 11. 先统一思想，再约束行动

技术外沿&技术人才

作为一个团队的Leader，我们要关心的不仅仅是团队的业务发展和技术深化，还有这之外的一些问题：专科申请、外部技术和影响力的建设、内部技术氛围的建设，企业基础IT的建设、成本管控等……

因为并不是所有的企业，尤其是初创企业，都具备这些职能，但作为技术的负责人，你需要主动担当。面对一些对团队有利的事，我认为：

1、有条件需要执行地坚决些； 2、如果没条件就需要创造条件执行。

最后，找到并留存技术人才，同样是Leader应该关心的，你就是团队最重要的HR主管。有人会有顾虑：招了人、投了钱去培训员工，他们走了怎么办？

没有人为企业打工一辈子，不过我希望的是，不管你是在团队呆1年还是10年也好，在团队的时间里，你是有收获的。而当你决定离开，找寻新的机会时，你是希望这个团队给你带来新的东西，帮助你提升到一个更高水平。

这样，企业完成了另一部分的社会责任，而培训是企业需要做的义务和责任。

“

Keep looking don’t settle.

”

微脉技术负责人 周志章

技术管理-提升技术团队效率

看起来人人都很高效，但组织效率不一定高

工具是组织效能的一部分，行动力也是

鼓励高效，就必须区分加班和磨洋工

如何提升技术团队效率？可以从以下几点着手：

• 建设或引进效率工具

工具也是我来到微脉做的第一件事情。开始的时候最大的感受就是：不快，说白了就是没有太多的工具。

因此，我们提出并做了微脉的四化 – 可视化，自动化，自助化，智能化。目前已经成型的三大工具 – 任脉/督脉/代码生成工具。

效能工具，就是让效率和能力得到提升的工具。

任脉：打通医疗行业血脉的自动化发货工具

打个比方，一些底层一线人员，往往不需要做太多的决策，但想要coding（如建一个分支），需要先邮件汇报，这个申请和回复的过程是比较久的。但是为了效率，通常来讲，5分钟需要解决所有问题，这时候，工具（任脉）就可以实现一键操作并且可以回溯查询。

通过工具，微脉实现了1个Q完成百来个需求点，是上半年的2倍。这就是工具带来的高效。

• 让架构设计贯穿始终

产品经理让你做什么你就做什么？这样的结果很可能就是技术在原地打转。

而架构可以确保以最低的代价完成项目需求，持续的架构治理是不重复造轮子的关键。这是做传统企业提升，对产品负责人来说最重要的点。

• 比业务快半步：业务判断

前瞻性：做好技术储备，提前规划产品，建立架构共识； 模块化：UI模块化，模块化建站，代码生成器，通用模块池； 评审单元：控制内审，控制变更。

• 梯队/能力建设

梯队占比：经营层 2% + TL层 8% + 执行层 90%。合理的梯队建设是提升组织效率的法宝之一，不一味地追求扁平化。

一方面，10%的人挡掉 90% 的干扰， 2%的人挡掉90%的政治任务。一方面，10%做前期的业务，技术沟通探索，这样执行层的90%就可以做确定性的事情。

能力建设

1）人才培养：

a. 借事修人，闭关项目 b. 因人成事，老带新 c. 教学相长，培训体系

2）招聘2大原则：

a. 中等偏上（人才标准） b. 成就原则，5k成本预算招到工资3k的人，但是你其实发现他的能力是价值6000元的人。这种情况下，招聘者成就了人，应聘者则感觉是平台成就了自己。

针对90后招过来，管不了，留不住的问题。

我认为首先要事实求是地讲话，而不是夸大其词。其次，90后的知识体系，可能和我们并不一样，给他定个高目标，剩下的事，就是他做的开不开心的问题。因岗位设置职能，在架构线和职能线上进行调整。

最后，满意度=期望值*体验。技术负责人也要学会做PR，从而得到员工的认可。

汰换：

1、对比相对 2、因岗设人

最后，需要设置行动目标并保持优化。那么，什么是目标？被公司喊得最多的诉求就是业务目标，被研发喊得最多的诉求就是技术目标。技术负责人需要对这两种目标做一定的平衡。

“

你的意见很高效，你的团队也会很高效

”

希望以上对你有所帮助