技术KPI的量化

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


技术KPI


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

业务贡献:包括需求把控,业务项目和业务创新。

技术贡献:包括设计重构、技术影响力、Code Review、创新提效和代码质量。

团队贡献:包括招聘、新人培养和团队氛围。

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

应用质量:

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

你做了哪些提升应用质量分的工作。

设计重构:

我在客户通项目中,对CRM销售域进行了领域建模和设计,并且抽象合理。

我发现Infrastructure中package分类不合理,进行了重新设计并重构完成。

我发现现在系统中错误码比较混乱,我梳理制定了新的错误码规范,并完成了代码重构。

技术影响力:

在团队内分享10篇干货,点赞数1000。

团队分享策略模式,得到同学好评 。

我接受邀请,在行业会议上分享了SOFA架构。

Code Review:

我在review某某代码的时候发现,可能存在线程不安全的隐患。

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

创新提效:

我发现本地测试启动PandoraBoot比较浪费时间,所以写了一个TestContainer大大提升了自测效率。

我发现有一些boilerplate代码不需要写,所以对乐观锁、分页进行了annotation支持,简化了代码。

在某个项目或者技术点上面,我产出了一篇专利:基于领域模型的业务配置化。

代码质量:

提测后的Bug数,线上故障数(系统可以提取,不用自己填写) 

我完善了某某模块的单元测试,并多次在自动化回归中发现问题。

KPI答疑


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

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

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

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

Q:我们现在的业务需求已经在堆积,一线同学根本没有时间去做重构优化。
A:这个问题开篇其实已经说过了,你是要不断地裹挟在业务需求和烂代码里面呢,还是花时间improve,然后更快地支持业务。这个权衡应该不难做,关键是要看决心和能力。对于很多业务,我没有看到推迟几天上线就会影响业务格局的业务场景,所以作为技术团队,我们就应该在User Story之外,加上我们的Technical Story,把完成业务需求和系统重构都当成我们的核心任务。

 

展开阅读全文

没有更多推荐了,返回首页