研发团队绩效考核：告别加班时长陷阱，聚焦交付价值落地

作为很多技术管理者的惯性思维, 是去把加班时长以及代码行数作为研发绩效考核的核心指标, 这种考核方式表面看起来公平且可以量化, 然而实际上它违背了研发工作的本质规律, 最终使得团队整体产出发生下降, 造成核心人才出现流失。

真正具备效力的研发绩效考核, 所应着重关注的, 是「交付之后究竟产生了怎样的价值」, 并非「耗费了多长的时间」。

考核逻辑的根本转变

传统考核把研发人员视作流水线工人, 认定工作时长跟产出成正比例关系。这种想法放在重复性劳动情形里可能说得通, 然而在创造性工作当中却彻底行不通了。研发工作的关键在于解决问题, 并非耗费时间。

以价值作为核心的考核, 这就要求管理者去重新界定「什么是好的交付」, 准时上线仅仅属于底线范畴, 而真正具备价值的在于需求是否将业务问题予以解决, 在于系统是否变得更为稳定, 在于团队是否收获了能够复用的能力沉淀。

小团队的轻量化考核

对于那人数在十人以内的研发团队而言, 是不适合使用复杂量化体系的。这样的团队, 其规模较小, 协同起来较为灵活, 而且角色边界模糊, 要是进行过度精细化的考核, 反倒会增加沟通成本, 还会破坏协作氛围。

月度采用轻量化考核的简易模式, 全员考评在一小时内全程完成。核心紧密聚焦三项真实数据, 其中高优需求按时交付率要稳定处于八成以上, 迭代复盘的BUG率以及线上严重故障数量用于反映质量水平, 代码复用率还有重构成果用来衡量技术沉淀。

小团队不进行强制排名, 而是以SABc这种四级价值定级情形为主导。这样的方式留存了弹性空间, 在这同时, 能够让主动去攻坚、主动去优化的员工获取到正向激励, 以此来避免考核僵化从而对团队活力造成束缚。

中大型团队的标准化考核

对于十人以上规模的研发团队而言, 是需要更为规范的体系的。标准量化打分制此种方式, 是能够减少主观评判所产生的误差的, 是可以确保不同成员在同一尺度之下被公平评估的。

高优需求按时交付率所占权重为两成, 需求交付完成质量所占权重同样为两成, 这两项指标与业务目标达成直接产生关联。团队赋能与成长所占权重为一成, 其对技术分享、流程优化等具有长期价值的工作起到牵引作用。

不同的岗位, 所采用的是差异化的指标, 架构师着重关注系统性能提升的比例, 以及技术风险规避所产生的成效, 测试负责人留意线上故障率, 和技术债务治理的进度, 团队成员的考核在于迭代交付的稳定性, 以及流程优化落地的成效。

适配不同研发场景

核心考核团队所遭遇的需求变更常常频繁出现, 这属于敏捷开发的通常状态。考核规则清晰表明, 迭代过程中间的需求变更并不会被计算进扣分范畴, 变更致使的延期被归结为需求管控方面的问题, 而非研发的责任, 由此从根本源头解决了因需求随意变更致使研发承担责任的棘手痛点。

以外包团队的考核而言, 乃是以交付的结果作为导向, 并非对主动优化以及创新投入进行考核。这样的一项规则, 达成了交付质量和成本管控之间的平衡, 防止了因追求技术方面的完美, 进而超出预算的范围。

远程办公的团队, 打破了时间与空间的限制, 只要在迭代节点时, 能够按时交付, 并且质量达到标准, 协作也很顺畅, 那么不管工作的时段是怎样的, 都会计为满分, 彻底杜绝了形式化管控给远程团队带来的约束。

落地执行的关键步骤

许许多多考核体系, 其设计是合理的, 然而在落地之时却失效了, 究其实质核心原因在于, 在执行阶段出现了问题。隐性工作, 必然要进行量化计分, 架构优化工作、故障救火工作、跨部门支撑工作、新人带教等类型的工作, 常常不被人看见, 倘若不计入考核, 这就会致使老实人遭受不利的情况。

为避免一成不变的指标脱离实际需求, 考核指标得进行动态调整, 每季度依据团队阶段目标微调权重, 在业务攻坚期着重侧重交付速度, 于技术迭代期着重侧重质量与技术沉淀。

在落地的第一天, 将规则进行同步, 同时把旧指标予以剔除, 使得全员都能清楚明确价值导向考核的逻辑, 并且正式取消时长类别以及数量类别方面的指标。到了第二天, 按照团队规模来匹配模板, 对于小团队启用四级定级模式, 而大团队则开启量化打分模式, 同时依据岗位特点对差异化指标做微调。

针对研发管理中常见的痛点而言, 如项目出现延期情况, 代码质量较差, 存在无效加班现象, 技术债务不断堆积等, 以交付价值作为核心的考核体系从根源上予以了解决。这套方案对大小团队之间的差异进行了考虑, 也适配各类研发场景, 能够直接落地套用。

当前您所在的团队, 其所运用的研发绩效考核方式是基于何种维度的, 有没有出现把加班时长当作产出衡量标准的情况, 十分欢迎在评论区域分享您的实践经历或者所面临的困惑。