评估开发者并没有唯一正确的方式 — 存在不同的流派,每一种都在优化不同的目标。在采用某个模型之前,有必要了解每个流派在实践中真正激励的是什么,因为每一项指标都会塑造行为:团队交付的,正是模型所奖励的。
强制排名
强制排名(stack ranking)将团队成员相互比较,并按曲线分布团队。问题在于结构本身:即使整个团队都在进步,依然会有人排在最后。这种模型激励内部竞争,抑制协作,并惩罚优秀的团队 — 在一个出色的团队里处于中游,反而不如在一个弱队里表现突出。
数量指标
把提交次数、代码行数或工时直接当作生产力的衡量标准,会碰上古德哈特定律:一旦某项指标变成目标,它就不再是一个好指标。数量很容易被注水 — 拆分提交、冗余代码、随意记录的工时 — 于是模型开始奖励的是动作,而不是价值。
系统化框架
像 DORA 和 SPACE 这样的方法衡量的是交付系统本身:交付周期、部署频率、故障率、团队满意度。它们非常适合诊断组织层面的瓶颈 — 但设计之初就不是为了评估个人。它们无法支撑管理者需要进行的对话:一对一沟通、晋升决策、职业发展规划。
主观评估
360度评估和绩效问卷能带来丰富的人文背景信息,但也存在已知的偏差:近因效应(只看重最近一个月,而非整个周期)、亲近效应(露面越多的人评价越好)以及光环效应(一项优点会影响对其他方面的判断)。仅依靠主观评估,会让绩效评估变成一场人气比拼。
绝对评分与参考区间
Devint 所采用的流派综合了以上各种方式,并纠正了它们各自的缺陷:来自真实工作流程的自动信号、结构化的领导层评估,以及与健康区间的比较 — 而非与同事比较。当整个团队都在进步时,这种进步会如实体现为集体性的提升。而饱和上限则化解了刷分行为:一旦超出该区间,额外的数量并不会提高分数。
如何选择模型
关键问题不是“哪种模型更精确?”,而是“这种模型激励的是什么行为?”。一个不错的检验方法:
- 如果整个团队一起进步,模型能如实体现出来 — 还是会人为制造出一个垫底的人?
- 能否通过注水数量来提高结果 — 还是存在上限?
- 该模型能否支撑个人层面的对话(一对一沟通、晋升)— 还是只能用于系统诊断?
- 解读结果时是否结合了客观证据与人的判断 — 还是只依赖其中一方?
如果想深入了解 Devint 所采用的流派 — 具体的维度、权重与区间 — 请查看完整的方法论。