技术领导力实战-许晓斌.pdf

技术领导力实战

阿里巴巴工程师/许晓斌/2023.02

自我介绍

•软件行业从业15年，包括微服务架构、DevOps、云原生等领域

•软件管理工作5年

•目前就职于阿里巴巴-TRE（技术风险与效能部）

负责运维与构建基础设施平台

•《Maven实战》作者

技术领导力

它非常重要！

可悲的现实：大部分技术领导者是不称职的。

技术领导反模式

•闷头干模式

延续独立贡献者的工作方法，所有方案自己做，所有代码自己写。

•路由器模式

上级任务往下转发，任务结果收集汇报。

•高压模式

对上过度汇报，对下持续增加，辅以不科学的价值宣导。

•不决策模式

不对任何需求sayno，或者决策全部下放，并让下属承担决策后果。

•有业务无工程模式

高度关注短期业务交付，不管工程质量。

不称职领导力的根源

经济上升期互联网行业蓬产生大量技术

技术开放勃发展管理者

被新的技术管总结

理者学习“成功经验”

虽然成功与他们的管理能力基本没什么关系

如果技术领导者只能做好一件事

重视人才意味着什么？

•你每周花几个小时做招聘/面试/1-on-1沟通？

•你是否对每次面试都严格要求？会不会因为项目压力降低要求？

•你能欣赏和你不同的想法和观点吗？

•你有信心充分地授权，并敢于为此负责吗？

我的面试Tips：•工程能力（在线编码，历史代码等）

•职业发展目标对齐

•沟通简单，逻辑清晰

战略目标如何落地

OKR

何为OKR

•OKR应该体现团队为谁服务（forwho），即围绕价值阐述。

反例：罗列技术指标和用户会有什么变化无关。

•OKR应该体现聚焦（即取舍），资源有限，集中精力办大事。

反例：罗列8个O，20个KR。

•OKR应该要尽可能量化（不必100%），用来校准方向，且量化不应被用来

考核绩效。

反例：全是形容词，看不到数字。

反例：主管拿着OKR告诉员工做到xxx绩效就是yyy。

•OKR的承接应该遵循SingleThreadedLeadership原则。

反例：OKR的负责人没有，或者OKR的负责人有一堆。

•OKR应该公开，且根据实际情况沟通调整。

反例：一线员工看不到主管的OKR，看不到更高层级主管的OKR。

被广泛低估的一件事

工程文化

为何工程文化重要？

•软件系统是极高复杂度的系统，复杂度失控，质量失控，会导致系统

崩溃。

•研发人员是知识工作者，是“手艺人”，良好的工程文化能激发他们的

工作热情，反之则会消磨热情。

毕竟，谁愿意在代码�山上工作呢？

建设工程文化的方法

•要求代码开放，要求codereview，要求unittest。

•搭建CI看板。

•技术领导者每天参与codereview。

•绩效考核/晋升考核中纳入“技术素养”的要求。

•定义阶段性技术目标，降低系统复杂度（如：下线服务，架构治理）

如果技术管理者不亲力亲为，工程文化往往会被牺牲。

案例：故障Review的重要性

•技术管理者应该仔细Review团队中的每一个故障，因为从中可以看到：

1.系统架构是否存在问题（例如：存在不合理依赖）

2.研发流程是否存在问题（例如：代码提交没有单元测试覆盖）

3.运维应急能力是否存在问题（例如：是否第一时间操作扩容）

即：多数故障是工程能力不足的症状表现。

润物细无声的一件事

建设开放透明的文化

不开放透明的例子：

•A同学把自己写的代码设置为private，他人不知道其工程能力，老板也不在