鹅厂研发人员的考核思路(借鉴自知乎大神).docxVIP

背景：最早部门研发内部并没有严格的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，避免出现最后核算的时候，确认不了是否能完成。