第13章 团队绩效到个人绩效

前面的体系主要讲了团队和项目的绩效，但一个实际的问题是：团队成功了，如何评价每个人的贡献？如何把团队目标拆解到个人？

这一章我们讨论：团队绩效和个人绩效的关系、如何识别不同类型的贡献、如何避免搭便车、如何给个人提供反馈。

团队绩效与个人绩效的关系

首先要明确一个原则：

团队绩效是基础，个人绩效是补充。

这意味着：

• 团队整体没有做好，个人不能被评价为高绩效
• 团队整体做好了，个人贡献有差异是正常的
• 个人绩效不能脱离团队目标单独评价

很多组织的问题在于：过度强调个人绩效，导致团队协作破裂。大家都只关注自己的指标，而不关心团队整体目标。

正确的顺序

1. 先对齐团队目标
2. 明确每个人在团队目标中的角色
3. 用团队目标牵引个人行为
4. 最后评价个人贡献，但以团队绩效为基础

错误的顺序

1. 先给每个人定 KPI
2. 大家各自为战
3. 团队目标没人真正关心
4. 最后用"协作不好"的理由惩罚所有人

个人贡献的三种类型

个人贡献不应该只看"写了多少代码"或"完成了多少任务"，而要看对团队的真实价值。我们可以把个人贡献分为三类：

类型 1：直接贡献

定义：直接完成了有价值的任务或交付物

例子：

• 完成了核心功能开发
• 解决了关键技术问题
• 交付了重要的项目
• 发现并修复了严重缺陷

评价方式：

• 任务的重要性（是不是关键问题）
• 完成质量（有没有留下后遗症）
• 效率（花了多少时间，成本如何）
• 结果（有没有真正解决问题）

类型 2：协作贡献

定义：通过帮助他人、推动协作，让团队整体变得更好

例子：

• 跨团队推动问题解决
• 帮助新同事成长
• 组织技术分享
• 推动团队规范和流程改进
• 在会议上提出有价值的意见，帮团队少走弯路

评价方式：

• 受帮助的人的反馈
• 团队协作效率是否提升
• 是否帮助团队避免了问题
• 是否促进了信息流动

类型 3：能力贡献

定义：通过技术突破、架构设计、人才培养，提升团队的长期能力

例子：

• 设计了优秀的架构
• 沉淀了可复用的组件或工具
• 培养了新人
• 建立了技术壁垒
• 推动了团队的技术升级

评价方式：

• 架构或方案的质量
• 复用率（有多少团队在用）
• 被培养人的成长
• 长期效率提升
• 技术壁垒的坚固程度

为什么需要区分这三类

很多组织只奖励"直接贡献"，这会导致：

• 没人愿意做协作的事情
• 没人愿意做长期能力建设
• 大家都抢容易出活的任务，回避难但重要的事情
• 强者不愿意帮助弱者，担心影响自己的绩效

好的绩效体系应该同时奖励这三类贡献。

个人贡献的评价方法

评价个人贡献，不能只靠"老板拍板"，也不能只看"任务完成率"。我们需要一套更全面的方法。

方法 1：目标对齐检查

在评价前，先问几个问题：

1. 这个人的工作是否对齐了团队目标？
2. 他做的事情是不是团队真正需要的？
3. 有没有做了很多"看起来很忙"但不创造价值的事情？

这一点最重要——如果工作本身不对齐团队目标，做得再多也不算高绩效。

方法 2：贡献类型分析

用上面的三类贡献分析：

• 直接贡献：做了哪些直接有价值的事情？
• 协作贡献：帮助了谁？推动了什么？
• 能力贡献：沉淀了什么？提升了什么？

不要只看其中一类。有些人直接贡献少，但协作贡献大；有些人不做具体任务，但能力贡献大。

方法 3：360 度反馈

收集多方面的反馈，而不只是上级评价：

• 上级反馈：整体评价、目标对齐、工作质量
• 平级反馈：协作质量、帮助他人、信息共享
• 下级反馈：指导、培养、成长机会
• 跨团队反馈：协作质量、响应速度、问题解决
• 用户/客户反馈：问题解决质量、满意度

注意：

• 反馈要有具体事实，不要只是"这个人很好"或"这个人不好"
• 不要用"票数"决定绩效，反馈是参考，不是投票
• 要允许被评价人解释和澄清

方法 4：行为质量判断

和之前的研发绩效逻辑一致，个人绩效也不应该只看结果，要看行为质量：

方法 5：贡献强度判断

区分"只是参与了"和"真正承担了"：

• 主导者：对结果负责，推动事情前进
• 参与者：做了分配的任务，但不整体负责
• 旁观者：基本没参与，或只是边缘参与

关键是看"责任"，而不是看"头衔"。有些人没有管理头衔，但真正承担了关键问题；有些人有管理头衔，但只是挂名。

如何避免搭便车

团队协作中最常见的问题是"搭便车"——有些人不怎么干活，但最后也分享了团队的成功。如何避免？

原则 1：明确角色和责任

不要把任务含糊地分配给"团队"，而要明确：

• 谁对什么负责？
• 每个角色的期望是什么？
• 谁是主责，谁是协作？

例子：

• 不好的分配：“大家一起把这个项目搞定”
• 好的分配：“张三主责架构设计，李四主责后端开发，王五主责测试，赵六主责跨团队协调”

原则 2：任务要有明确的交付物和验收标准

每个任务要有：

• 明确的交付物
• 清晰的验收标准
• 时间节点
• 责任人

不要用"尽量做"“做好一点"这样模糊的描述。

原则 3：公开透明的贡献记录

团队可以定期（如每周）记录：

• 谁做了什么？
• 解决了什么问题？
• 遇到了什么困难？
• 帮助了谁？

记录不需要很复杂，但要公开透明。这样谁在贡献、谁在搭便车，大家心里都有数。

原则 4：用行为质量替代"完成率”

有些人看起来"完成了很多任务"，但都是简单任务；有些人看起来"完成率不高"，但解决了真正关键的问题。

不要只看"完成了多少任务"，要看：

• 任务的重要性和难度
• 完成质量
• 是否推动了团队目标

原则 5：低绩效不是配额，是诊断结果

不要为了"绩效分布"强行打低分，真正的低绩效是：

• 长期没有有效产出
• 不承担责任
• 低质量行为（无验证、不闭环、隐瞒风险）
• 破坏团队协作
• 透支长期能力

如果团队整体都在高质量贡献，就不需要为了"强制分布"制造低绩效。

从团队目标到个人目标的拆解

团队目标不能直接"切"给每个人，而要通过角色和贡献来拆解。

步骤 1：明确团队目标和关键成功因素

先回答：

• 团队这个阶段的核心目标是什么？
• 要达成这个目标，关键成功因素是什么？
• 哪些事情必须做，哪些事情可做可不做？

步骤 2：明确每个角色的定位

每个角色在团队目标中的定位：

• 这个角色的核心价值是什么？
• 这个角色要解决什么问题？
• 这个角色如何为团队目标做贡献？

步骤 3：与个人对齐目标

和每个人一起讨论：

• 团队目标是什么？
• 你在这个目标中可以扮演什么角色？
• 你想做什么？擅长做什么？
• 我们如何定义"做得好"？

不要：上级直接把目标"压"给下级。 要：一起讨论，达成共识。

步骤 4：定期检查和调整

目标不是定完就完了，要定期检查：

• 进展如何？
• 目标是否需要调整？
• 优先级是否变化？
• 遇到了什么困难，需要什么帮助？

建议频率：每周同步进展，每月对齐目标，每季度做较大调整。

个人反馈的方法

绩效评价不能只是"年底打分"，而要持续反馈。

反馈原则

1. 及时：问题发生后尽快反馈，不要等年底
2. 具体：用具体事实，不要用抽象评价
3. 对事不对人：评价行为，不评价人格
4. 双向：允许对方解释和讨论
5. 有建设性：不仅说"不好"，还要说"如何改进"

反馈框架

可以用 SBI 模型：

• Situation：场景（在什么情况下）
• Behavior：行为（你做了什么/没做什么）
• Impact：影响（导致了什么结果）

例子：

• 不好的反馈：“你这个人协作不好”
• 好的反馈：“上次项目联调时（Situation），你遇到问题没有及时同步给测试团队（Behavior），导致测试时间被压缩（Impact）”

反馈频率

• 每周：一对一同步进展，有问题及时说
• 每月：月度小结，对齐目标
• 每季度：季度绩效评价，更全面的反馈
• 每半年：薪酬、晋升、角色调整等重大决策

不要：一年才反馈一次，到那时问题已经很严重了。

一套可落地的个人绩效评价模板

个人绩效评价表

绩效结论类型

个人发展计划

绩效评价不是为了"打分"，而是为了成长。对于每个人，要制定发展计划：

• 当前的优势是什么？如何继续发挥？
• 当前的短板是什么？如何提升？
• 下阶段的目标是什么？
• 需要什么支持和资源？
• 如何衡量进步？

总结

团队绩效到个人绩效的核心原则是：

1. 团队绩效是基础：团队不好，个人不能算好
2. 识别三类贡献：直接贡献、协作贡献、能力贡献都要奖励
3. 看行为质量：不只是看结果，还要看结果是怎么来的
4. 公开透明：贡献要记录，反馈要及时
5. 为了成长：绩效评价不是为了排序，而是为了帮助每个人成长

当个人目标真正对齐团队目标，当三类贡献都被认可时，团队会更有战斗力，每个人也会更有成就感。