BAT与一些创业公司是如何进行研发管理和绩效考核的？ - 知乎 - 苏芬

腾讯鹅一只，一直在腾讯研发质量这块，这几年转为pm，可以简单介绍下我们的一些历程。

有木有人给我多点几个赞啊，这样才有动力继续分享啊

背景：最早部门研发内部并没有严格的kpi，研发主要是一些不好度量的指标，研发核心tl会绑定业务kpi，所以主要以支撑业务为主，但会出现技术做得好不好无法度量的情况，后面逐渐在推kpi量化。
但研发的量化不能完全按数量指标来，否则就把创意性工作变成纯粹搬砖，目前我们的KPI度量体系度量已经有2年了。我简单说下当初的思路和历程：

思路 ： 先定方向 ，再结合工作内容，确认目标，实际运行过程中，定时review，优化度量方式，到现在跑得比较顺了。

我逐个来解说下：

每半年都有一个大致的工作方向，以及我们上半年的一些工作痛点，结合这两大块，理出可以跟进的事情；但不管怎么梳理，研发的主要工作都是支撑业务需求，拓展系统能应对各自变化和业务量级
所以工作目标分成，日常工作的效率及质量，预见及应付变化，团队建设，团队联动（帮助跨组项目）

一.日常工作的效率及质量 保证有质量的对业务需求的快速支撑

日常工作，其实比较关键的是快速保证质量的支撑业务需求，也就是一直追求的敏捷开发，所以制定指标
研发质量指标包含 业务需求响度，系统可用性，开发关键流程质量。 对于前端，业务后端团队这里占比回比较高。
A。系统可用性，挑选业务流程的关键路径，涉及影响这里的故障的都算作影响系统可用性，有个这算公式
B。需求影响度 结合月度计划度量月度计划的完成度，要求上是P0的完成是80%，P1的完成度是60% ，可以接受调整，开发与业务直行对齐
C。关键流程质量 通过数据度量来反推关键流程的执行质量， 例如转测试，发布回退这些；

这三个维度可以度量作为开发是否能够快速，高效高质量的支撑日新月异的互联网需求，通俗一点就是 敏捷支撑各种变更需求，但需要保证质量。
业务完成度，按月核算阅读计划需求是否完成。业务pm度量合算，接受双方协调好的变更。主要在研发对业务的支撑度，版本质量，系统可用性，

还一个很关键的，日常模块的性能指标压测值 。保证线上服务稳定且性能持续优化，前端一般用访问测速值

二. 技术侧主导项目 主要是预见及应付变化事项

业务快速发展，团队成员也需要成长，所以每年按项目形都需要推动不少纯技术优化的项目。
主要包含三类：
1.新技术研究引用，主要通过业务需求多少使用新技术占比度量
2.事件形项目，以项目上线为度量标准
3.模块重构，性能优化形项目 单机压测值来度量

大多数开发的日常除了做需求，就是重构优化了，但这也是资源总是冲突的地方，业务侧挑战为什么一直需要重构优化，但线上大流量爆发的时候，就是系统优化的不够。所以这是个重要但不紧急的事情；
重要不紧急的事情需要列入日常，否则最后就变成重要紧急了~ 所以这其实是关键项目

三.合作事项 大型项目需要跨组联调的很多，但如果不在各自kpi项目里面 其实有时候会比较难推动，所以增加这么一向。

四 团队建设 这个重要性不必多说，团队的稳定和发展是基石，技术leader一般不擅长，所以帮大家定了几个基本基调，剩下就是各自发挥 。

说完事项，我们说占比。一般业务需求多的团队，第一项目占比会大写，后端支撑团队，第二项占比会大。 这里结合时实际情况来优化调整

接下来说最重要的部分：过程度量和review

目前来说，我们是一个月review一次，review的过程接受跟进实际情况的部分调整，但这里得拉大家一起讨论处理。另外，对于大型项目，review的过程也可以发现kpi目标的制定是否有可度量的方式，如果不行，那需要再次细化kpi，避免出现最后核算的时候，确认不了是否能完成。

大致就这些，不知道说清楚了没有~

Original url: Access

Created at: 2018-09-29 20:14:19

Category: default

Tags: none

未标明原创文章均为采集，版权归作者所有，转载无需和我联系，请注明原出处，南摩阿彌陀佛，知识，不只知道，要得到

请先后发表评论
  • 最新评论
  • 总共0条评论