阿里高级技术专家:如何量化考核技术人的KPI?

新闻
对技术人来说,技术是成长的“核心”。然而,在实际工作协作中,技术的重要性常常被业务所掩盖,造成先业务后技术的现象。

针对这个痛点,阿里高级技术专家张建飞提出了自己的解决思路,希望能与大家一起探讨、交流。

为什么需要技术 KPI?

在业务技术团队,有一个不好的趋势就是团队越来越业务,越来越没有技术味道。

每个人都在谈业务,技术大会上在谈业务,周会上在聊业务,周报里写的是业务项目......

唯独少被谈及的是技术本身。此处并不是说业务不重要,而是说理解业务和把控业务需求是技术人员的 base,而不是全部。

将就的代价

这种技术味道的缺失对技术团队来说是非常可惜的,也不利于技术人员的成长和发展。

因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。

相反,这种业务代码的堆砌,从短期看也许是“较快”实现了业务需求,但是从长远来看,这种烂系统的增加会极大的阻碍业务的发展,形成一个个的黑洞应用,而工程师被裹挟在业务需求和烂系统之间,疲于应对,心力交瘁。

这种将就将导致系统腐化,技术债越垒越高,像肿瘤一样消耗你所有的能量。

我不是药神,只能尝试开出一药方:那就是在不影响业务的情况下(特别是相对稳定的业务,请拒绝业务方的时间倒排),Tech Story 应该和 User Story 有同等的重要性,要把重构优化提到和业务需求相等的优先级去处理。

我们不仅要对业务需求负责,我们更要对应用的质量,系统的可维护性负责。

因为我们技术人员是应用的父母(有些是亲生父母,有些是养父母),你不照顾它们,不治理它们,它们就会生病,你忍心看到这样的局面吗?

[[245345]]

技术管理者者(TL)的失职

造成这种局面,我们的技术管理者,我们的 TL 要负有主要责任。如果一个 TL 从来不关注系统架构和设计,从来不写 Code,对技术没有热情也不学习,甚至其本身技术就很烂。

那么在这个 TL 领导下的技术团队,又怎么会有技术味道,团队成员又怎么能进步和成长?

现在很多的 TL 每天都混迹在各种会议上,很忙,做着各种沟通协调的事情,可是我们真的需要这么多的会议、这么多的沟通吗?

如果沟通的结果只是做业务和 PD 对团队的传话筒,没有业务创新,没有用技术和数据系统化的解决业务问题,没有在技术方向和架构上给团队指引,没能切实的帮助系统优化、团队提效,请问这样的沟通给业务带来了什么价值,给团队带来了什么价值?

还是沉下心来,多看看书,哪怕非技术的书也好。多写写代码,哪怕跟业务无关的代码也好。

所以,我们要回归技术本身。我们不需要这么多“高高在上”、“指点江山”的技术 Manager。

而是需要能真正深入到系统里面,深入到代码细节,给团队带来实实在在改变的技术 Leader。

[[245346]]

技术 KPI 的量化

提升技术氛围,打造工程师文化不能仅停留在口头上,可搭配一定的强制手段,比如和技术人员的利益绑定。这种绑定就需要我们能对技术贡献进行一个相对公平的分解和量化。

技术 KPI

基于此,我将技术人员的 KPI 分解为业务贡献、技术贡献和团队贡献三个大的部分。

其详细内容如下:

  • 业务贡献:包括需求把控,业务项目和业务创新。
  • 技术贡献:包括设计重构、技术影响力、Code Review、创新提效和代码质量。
  • 团队贡献:包括招聘、新人培养和团队氛围。

那么技术贡献中的这几个维度要怎么理解呢,解释的话我就不多说了,用我们工作中的一些案例来描述一下吧。

应用质量:

  • 你负责或者共同负责的应用质量分(可以从代码重复率,圈复杂度,分层合理性等维度考察)。
  • 你做了哪些提升应用质量分的工作。

设计重构:

  • 我在客户通项目中,对 CRM 销售域进行了领域建模和设计,并且抽象合理。
  • 我发现 Infrastructure 中 package 分类不合理,进行了重新设计并重构完成。
  • 我发现现在系统中错误码比较混乱,我梳理制定了新的错误码规范,并完成了代码重构。

技术影响力:

  • 在团队内分享 10 篇干货,点赞数 1000。
  • 团队分享策略模式,得到同学好评 。
  • 我接受邀请,在行业会议上分享了 SOFA 架构。

Code Review:

  • 我在 Review 某某代码的时候发现,可能存在线程不安全的隐患。
  • 我在 Review 某某代码的时候发现,存在设计不合理的现象,此处使用责任链可以很优雅的解决问题,并具备一定的扩展性。

创新提效:

  • 我发现本地测试启动 Pandora Boot 比较浪费时间,所以写了一个 TestContainer 大大提升了自测效率。
  • 我发现有一些 boilerplate 代码不需要写,所以对乐观锁、分页进行了 annotation 支持,简化了代码。
  • 在某个项目或者技术点上面,我产出了一篇专利:基于领域模型的业务配置化。

代码质量:

  • 提测后的 Bug 数,线上故障数(系统可以提取,不用自己填写) 
  • 我完善了某某模块的单元测试,并多次在自动化回归中发现问题。

KPI 答疑

对于上面的 KPI 大部分的技术同学是表示认可的,当然质疑的声音也很多,我这里挑一些典型的回答一下。

Q:技术 KPI 的提出,会不会导致技术同学只关注技术不做业务项目了? 

A:关于绩效,肯定是综合看业务贡献,技术贡献和团队贡献。但是作为一个重要参考和风向标,技术 KPI 是有积极意义的。

Q: 你这个设计重构怎么量化?

A:这个很难用系统标准化,更多的还是要依赖 TL 的专业能力进行评分,但即使是这样,也比以前什么都没有完全黑盒要强。至少在传达一个信息,我们鼓励好的设计,鼓励不断地重构优化。

Q:我们现在的业务需求已经在堆积,一线同学根本没有时间去做重构优化。

A:这个问题开篇其实已经说过了,你是要不断地裹挟在业务需求和烂代码里面呢,还是花时间 improve,然后更快地支持业务。这个权衡应该不难做,关键是要看决心和能力。

对于很多业务,我没有看到推迟几天上线就会影响业务格局的业务场景,所以作为技术团队,我们就应该在 User Story 之外,加上我们的 Technical Story,把完成业务需求和系统重构都当成我们的核心任务

责任编辑:武晓燕 来源: 阿里技术
相关推荐

2018-08-27 16:41:07

KPI技术人

2020-08-03 08:48:18

技术人阿里专家

2020-01-08 10:18:31

阿里技术人互联网

2018-04-02 10:00:27

技术快速成长

2020-01-18 10:37:44

技术人转型管理

2018-07-23 16:05:44

大数据进化技术

2021-02-01 07:40:55

架构师阿里技专家

2018-06-12 07:19:31

技术数据程序员

2021-01-28 19:58:48

技术团队效能

2020-01-21 08:54:46

应用架构Domain

2019-09-23 09:46:58

能力模型技术

2019-07-10 09:19:26

技术开发编程

2019-08-14 08:52:40

业务代码运营

2017-09-13 10:51:25

技术人基础知识互联网技术

2020-01-09 08:36:35

Testing指标零假设

2020-11-02 08:24:34

Leader技术团队

2009-03-22 21:29:11

多核技术

2019-02-18 08:24:09

技术应用架构

2019-08-29 10:31:47

2023-08-10 14:02:15

点赞
收藏

51CTO技术栈公众号