把一位开发者的表现简化为单一数字,却不解释这个数字从何而来,这既不公平,对管理也毫无用处。正因如此,DevScore 由六个维度组成,每个维度回答关于工作的一个不同问题。0到100分的评分展示整体情况;各维度则解释其构成。
这六个维度分为两大类:自动信号,来自已有的工作流程(Git、工时记录、AI 工具);以及领导层评估,由团队的管理者和技术负责人给出。两者结合可以减少不公平的解读:没有背景信息的数字会误导,没有数字支撑的主观印象同样会误导。
自动信号
- 交付节奏:每个工作日的提交次数和每周的合并请求数量。衡量技术工作转化为可审查交付物的频率——健康的节奏能降低周期末出现意外的风险。
- 代码贡献:存活代码行(在产品中持续保留的代码行)与变更熵。衡量真正留下实质印记的贡献,包括重构中有价值的代码删除——而非单纯的数量堆积。
- AI 与智能体的采用:每周在公司提供的工具中消耗的 token 数量。衡量的是实际使用情况,而非交付的价值——因此需要与其他维度结合解读。
- 工时记录:每周记录的工时。没有可靠的记录,产能和成本就只能凭主观判断;有了记录,规划和可预测性才有依据。
领导层评估
- 技术能力(1至9分制):代码质量、架构设计、最佳实践和技术掌握程度,由技术负责人评估。变化缓慢——反映的是成熟度,而非某一时期的情绪状态。
- 行为表现(1至6分制):沟通、协作、责任感和条理性。衡量的是对团队运作的影响,而非个人受欢迎程度。自评不计入计算。
随职位调整的权重
没有任何维度拥有统一固定的权重。权重是可配置的,总和始终为100%,反映公司在不同时期、不同岗位上所看重的内容。对初级开发者的期望与对高级开发者的期望并不相同:职业生涯初期通常更看重交付节奏和工时(建立节奏感),而资深阶段则更看重代码贡献和技术能力(深度而非数量)。
健康参考区间与上限
每个信号都会与一个健康区间进行比较——这个区间有上限和下限——而不是与团队中表现最好的人比较。低于该区间,信号不足;在区间内,分数会逐步提升;超过区间则会饱和:更多的提交、更多的工时或更多的 token 都无法换来更高的分数。区间也可以按级别、合同类型和工作性质进行配置,并遵循治理规则:调整仅对后续的评估周期生效。
如何在实践中解读各维度
两个人的最终评分可能相同,但原因却完全不同。正确的解读方式始终是分析其构成:哪里表现稳定,哪里还有提升空间。而低分只是需要进一步了解的信号,而不是定论——它可能意味着遇到了阻碍、数据缺失,或是工作内容未被自动化指标充分捕捉。
想查看每个维度的详细说明,包括示例区间和按资历分配权重的逻辑?请访问 Devint 方法论页面。