第12章 不同团队类型的绩效权重

前面的体系建立了通用的四维绩效结构（验证、里程碑、质量、沉淀），但不同类型的研发团队，工作性质差异很大，不能用完全一样的权重。

这一章我们讨论：如何为算法团队、工程团队、平台团队、硬件团队等不同类型的团队设计差异化的绩效评价方式。

为什么需要差异化

不同团队做的事情不一样，评价重点自然也不一样：

如果用同一套权重评价所有团队，会出现：

• 用交付速度考核算法团队 → 压制探索
• 用探索自由度考核平台团队 → 没人愿意做苦活累活
• 用软件逻辑考核硬件团队 → 忽略硬件的特殊约束

团队类型与绩效权重设计

1. 算法团队

核心特征：

• 高不确定性，需要大量实验
• 价值可能来自一次关键突破，而不是稳定输出
• 失败是正常的，关键是从失败中学习

绩效权重：

推荐 KPI：

• 关键假设验证完成率
• 实验迭代速度
• 算法性能提升幅度
• 方法论文档产出
• 模型复现成功率

不应该：

• 用"按期交付"要求算法探索
• 因为一次实验失败就否定团队
• 只看最终结果，不看学习过程

2. 工程交付团队

核心特征：

• 需求相对明确，路径相对清晰
• 需要稳定、高效、高质量交付
• 风险往往来自过程失控

绩效权重：

推荐 KPI：

• 迭代交付速度
• 需求按期完成率
• 严重缺陷数量
• 缺陷闭环周期
• 线上事故数量和影响
• 自动化覆盖率

注意：

• 不要只看速度，要看速度和质量的平衡
• 不要只看交付，要看是否沉淀能力
• 允许调整，但调整要有理由

3. 平台团队

核心特征：

• 价值往往不直接体现在业务指标上
• 需要长期投入，短期效果不明显
• 价值体现在其他团队的效率提升上

绩效权重：

推荐 KPI：

• 接入团队数量
• 复用率（多少团队在用）
• 接入成本（从开始到能用需要多久）
• 平台稳定性（SLA）
• 用户满意度（使用平台的团队的反馈）
• 平台能力的使用深度

注意：

• 不要用业务指标直接考核平台团队（这不公平）
• 要关注平台对其他团队的实际帮助
• 要平衡"做功能"和"做可复用的能力"

4. 硬件团队

核心特征：

• 迭代成本高（改一次可能需要几周甚至几个月）
• 质量要求严（出问题可能是硬件召回，代价巨大）
• 与软件团队、供应链团队协同复杂

绩效权重：

推荐 KPI：

• EVT/DVT/PVT 节点达成率
• 严重问题数量和闭环情况
• 良率提升
• 成本控制（BOM 成本是否达标）
• 可制造性问题发现数量

注意：

• 硬件不能像软件那样"快速迭代"，验证一定要充分
• 质量权重更高，因为硬件问题的代价太大
• 要关注供应链协同，不是只关注设计

5. 测试团队

核心特征：

• 价值在于"发现问题"，而不是"证明没问题"
• 需要平衡质量和效率（测太多会慢，测太少会漏）
• 工作往往"隐形"——不出事没人觉得重要

绩效权重：

推荐 KPI：

• 关键问题发现数量（严重程度高的）
• 漏检率（线上问题中有多少是应该测出来的）
• 测试自动化覆盖率
• 测试执行效率
• 测试用例复用率

注意：

• 不要只看"发现了多少问题"，要看发现了多少"关键问题"
• 不要因为漏检就完全否定团队（漏检是难免的，要看漏检的是什么问题）
• 要奖励"帮助开发减少问题"，而不是"发现越多问题越好"

6. 产品团队

核心特征：

• 连接用户需求和技术实现
• 需要平衡"用户想要什么"和"技术能做什么"
• 价值体现在产品成功上，但成功有很多外部因素

绩效权重：

推荐 KPI：

• 关键假设验证完成率
• 用户满意度
• 核心业务指标（如留存、转化，但要谨慎使用）
• 需求变更率（不是越低越好，要看变更是否合理）
• 产品文档质量

注意：

• 不要只看业务结果（有很多外部因素），要看过程质量
• 不要因为产品失败就否定团队，要看团队是否从失败中学习
• 要奖励"真实面对问题"，而不是"包装数据"

跨团队项目的绩效分配

现代研发很少是单一团队能完成的，往往需要多个团队协作。如何分配跨团队项目的绩效？

原则 1：区分"主责团队"和"协作团队"

原则 2：共同评价，不拆分结果

不要把项目结果简单拆分给各个团队（如"功劳各占 30%"），这样容易导致：

• 团队只关注自己的一亩三分地
• 遇到边界问题互相甩锅
• 为了自己的指标牺牲整体利益

更好的做法：

1. 先评价项目整体绩效（目标达成、过程质量）
2. 再看每个团队在项目中的贡献（不是拆分结果，而是看行为质量）
3. 评价团队时问：
   • 这个团队是否真的推动了项目前进？
   • 是否主动承担了边界问题？
   • 协同质量如何？
   • 是否沉淀了可复用的东西？

原则 3：收集跨团队反馈

评价协作团队时，不能只听主责团队的，也不能只看自己说的，要收集多方面的反馈：

• 主责团队对协作团队的反馈
• 协作团队之间的互相反馈
• 上下游团队的反馈
• 用户或客户的反馈

这样评价才更全面、更公平。

团队类型与阶段的组合

团队类型还要和之前的阶段模型（0->1/1->10/1->100）结合起来，形成更细的分类：

示例：算法团队在不同阶段

示例：硬件团队在不同阶段

总结

不同团队类型的绩效设计，核心原则是：

1. 理解团队的核心价值：这个团队存在的意义是什么？
2. 匹配阶段：团队当前是在探索、验证还是规模化？
3. 差异化权重：不要用同一套权重考核所有团队
4. 关注行为质量：不只是看结果，还要看结果是怎么来的
5. 收集多方面反馈：尤其是跨团队协作时

当绩效评价方式真正匹配团队的工作性质时，团队才会被激励去做真正重要的事情，而不是去"刷指标"。