31

研发绩效(12.16)

 4 years ago
source link: http://blog.sina.com.cn/s/blog_493a84550102z644.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

qaIzm2V.jpg!web

临近年底,谈下研发绩效方面的话题。对于一个软件企业来说,对于产品线实际上绩效管理相对来说很简单,比如我们常说的合同签订额,收款额,按完工进度进行的利润率测算等,但是到了产品线研发团队内部,研发绩效管理就不能单纯的根据几个指标来进行考核。

比如谈到对研发人员的绩效考核,在很早我就谈到过最简单的主基二元考核方式,一个是工作态度,一个是工作能力,两个都不能少。同时一个是给到每个研发人员的绩效底线或工作业绩底线,一个是超额完成的情况。结合这些方面综合对研发人员进行评价。

严格来说我们应该是将产品线的经营指标分解到每个研发团队,再进一步分解到每一个研发人员,然后基于KPI考核指标进行考核,但是这种方式本身又过于量化和僵硬而无法执行。但是如果我们完全凭我们的经验进行绩效评估往往也不合理。

因此对于研发人员的绩效评估仍然应该是部分指标量化加上部分以项目和任务结果导向两个方面来结合,对于定量化方面的指标通常也就是我们说的本上的生产效率,包括了代码行产出,代码规范性,缺陷密度等,即生产率和质量的组合。既要快又要保证质量,两者也紧密结合。

如果仅仅单纯的评估代码行可能也有问题,比如有些人的代码本身质量不高,存在大量的代码粘贴拷贝情况,代码产出行数反而更多。因此代码行产生不一定确切,需要和其它评估指标一起使用,如我们可以根据新增需求或变更需求本身的功能点或工作量估算,同时还需要结合我们进行的代码review共同进行代码产生效率评估。

上面谈了这么多,简单来说就是对于研发人员的绩效考核本身要对应到他们实际的价值贡献上面来,你可能会看到一些研发人员本身每天都工作很忙,也经常加班,态度表现上肯定满分,但是做东西慢,做出来的东西质量也不行经常反复修改,那么实际上他们的价值贡献是很小的,不应该有好绩效。

最后研发人员的绩效考核本身还需要和研发人员本身的岗位等级和薪酬体系挂钩,简单来说就是一个高级开发人员本身拿高薪酬,其对应的绩效考核标准本身就应该高于一般开发人员。如果高级和一般人员的薪酬比是2比1,那么简单来说就是高级人员至少应该完成2倍的工作任务才算基本合格。这些我们在进行绩效考核和评估的时候也必须考虑到。

在2020年,对于研发团队的管理,一个工作重点就是加强研发绩效工作的量化,要做到这点也需要将我们研发人员的工作任务细分,落地到项目管理工具进行科学管理和跟踪,才方面进行分析和度量。同时进一步的实践敏捷开发方法论,加强需求收集到交付的全流程可视化跟踪能力。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK