程序员的KPI考核,贵公司是如此吗?

程序员的KPI考核,贵公司是如此吗?_第1张图片

关于程序员的绩效考核,一直存在很大的争议!之前我在微信上问过很多公众号的伙伴,大家所在的公司对于KPI考核也是五花八门。

程序员的KPI考核,贵公司是如此吗?_第2张图片
程序员的KPI考核,贵公司是如此吗?_第3张图片
程序员的KPI考核,贵公司是如此吗?_第4张图片

程序员的绩效考核不容易制定在于:很难去量化工作,只有能量化的工作,KPI才能发挥最大的效用。

对程序员的考核,每个公司都不一样,大企业和小企业的KPI不一样,外包公司和自主研发产品的情况也不一样,需要具体情况具体分析。

加班&工时

考核工时,容易造成个别员工出现蹭加班时间的现象。

加班时间最多的,也不同等于贡献大,程序员的工作输出跟工作时间不一定成正比,此方法不适用于咱们程序员,但也有不少公司都在用。

程序员的KPI考核,贵公司是如此吗?_第5张图片

代码行数

要知道程序员追求的是代码的简洁,代码量越少越好。如果通过增加代码行数来达到KPI,简直是违背信仰。

何况做假也太简单了:多换行,多注释,少封装,复制源码等等奇葩的做法,代码简直想要多少行就有多少行。

这样做不仅是让程序很冗余,增加无意义代码,还让故障排除异常复杂,百害无一利,得不偿失,不可取。

“用代码行数来衡量编程的进度,就如同用重量来衡量飞机的制造进度。”—— 比尔·盖茨

程序员的KPI考核,贵公司是如此吗?_第6张图片

代码质量

代码质量主要是指代码的可读性,可维护性。

你编写的代码是简洁易懂还是晦涩难懂,代码规范是否符合团队规范,适度解耦还是高度耦合,技术选型是否合理,注释是否清晰准确,代码封装组织设计是否合理。

代码本身的质量决定了对后续开发的友好程度,毕竟代码不规范,同事两行泪。但这些需要内行人才能做出判断,一般由team leader复制审核代码,此方法不适用于非技术出身的考核人员使用。

熟悉业务

理解产品需求是程序员的基本工作,但是有的前端程序员不愿意花时间去深入了解,觉得自己对着产品原型和UI设计稿,也可以很好地完成页面开发,似乎也不需要看什么需求文档。 原型和设计稿是什么样子,我就做成什么样子的就行了。

这并不够,你不仅仅是简单地把页面实现出来,还需要深入了解产品业务,考虑产品每个模块之间的区别与联系,以此来进行代码的组织、封装和设计。

高质量的代码设计一定是具有可扩展性和可变更性的,来满足产品后续的迭代和需求的变更。

熟悉产品业务,也能帮助你减少项目bug的数量,bug的产生有时候不仅仅是技术问题,也有可能是业务需求理解偏差造成的。

工作态度

态度是否积极,是否跟对接的同事顺利沟通协作,这些也是考核的范围之一。通过上级和同事的评价,来评估一个程序员的工作态度是否达标。

全凭感觉来打分,虽然有些主观,但是也是最直观准确的。 能约束同事之间的沟通方式,提高沟通效率问题。毕竟再不好好说话,绩效是要被扣掉的。

程序员的KPI考核,贵公司是如此吗?_第7张图片

考勤

是否有迟到早退,是否全勤,但很多公司对于程序员采取的弹性上班,每个公司情况不一样,具体情况具体分析。

上述这几点都是专注于工作过程的考核,其实也可以对工作结果进行考核。 对于程序员,工作最直接的产出结果是什么?是代码,一个项目完整的代码,最直观的体现就是产品。

完成效率

能否在预计的开发周期完成开发任务,如果项目延期了,实际上线时间和计划上线时间偏差了多少,也是一个考核点。

你一定遇到过这样的场景,公司制定的研发周期往往整个项目的完成周期,其中包含了策划,需求评审,设计,研发和测试的时间在里面。 如果前期策划,评审和设计花费了大量的时间,开发和测试的时间就会被迫压缩,留给程序员的时间不多。

另外,即便前期定好的需求,谁也不保证在研发过程中不会有变更的可能,在研发过程中来改需求,无疑是最伤程序员士气的事。

所以,分清楚研发周期是整个项目的研发时间,还是写代码的时间;程序员研发过程中,需求的变更是否需要重新评估开发周期。

程序员的KPI考核,贵公司是如此吗?_第8张图片

完成质量

这里的质量是指项目上线后的出bug率,细致一点的还可以给bug的严重性分等级进行考核。毕竟出现错别字和功能上的bug所造成的影响不是一个级别的,可以分等级进行考核。

不过bug也要分是技术bug,还是业务bug,这点要事先分清楚。有时候你看到程序员在修bug,但是其实是给PM的需求漏洞擦屁股。

如果产品经理思考不周全,或者产品逻辑出现了自我矛盾,最终都是程序员要为此买单,程序员就像一个救火队长,加班加点修复漏洞。

程序员的KPI考核,贵公司是如此吗?_第9张图片

对于程序员这种脑力劳动的考核,工作性质有一定创造性,单纯强调只考核结果,会打压程序员本身的工作积极性。

举个例子:明明多花一点时间可以思考出的一个高效实现方法,结果为了尽快完成,用了一个实现起来最省时间但是可扩展性很差的方法,这对公司来说,实际上是一种损失。

反过来,如果单纯地考核工作过程也不合适。

比如:程序员过度追求高质量的代码,花大量的时间反复对代码进行优化和重构,延迟了产品的上线时间,也会影响整个公司的目标绩效达成。

至于程序员的绩效考核,没有一个绝对的标准,最合理的方式过程与结果两者兼备,根据团队设置不同的占比比例来综合考核:完成效率(30%),完成质量(30%),代码质量(20%),业务熟悉(10%),工作态度+考勤(10%)

我自己是一名Java架构师,目前整理了一份架构资料,送给每一位Java小伙伴。在日新月异的程序世界里,我们每一个人都是学生。加群712477306,群文件免费领取。

你可能感兴趣的:(程序员的KPI考核,贵公司是如此吗?)