任务管理关注人教程：实施团队数据分析，避坑指南

去年我参与了一个 320 人研发组织的任务管理数据复盘，三份报表放在一起看，结论互相打架：按工时填报，团队平均饱和度 87%，看起来人人满负荷运转；按迭代目标达成率，过去 6 个迭代有 4 个延期；按评审与缺陷流转，等待时间最长的 5 个人里，有 3 个恰恰是工时榜上排名靠前的人。

这不是数据错了，是视角错了。绝大多数团队做的任务管理数据分析是"关注事"的，燃尽图、需求吞吐、缺陷趋势；而"关注人"的数据分析要回答的是另一组问题：谁被卡住了、卡了多久、卡在谁那里、这是偶发还是结构性。这篇教程把我在 3 个不同规模团队里踩过的坑、验证过的口径、以及可复用的落地路径完整写出来，包括实施顺序、指标清单、避坑清单和取舍逻辑。

一、先给结论：关注人的数据分析，到底该看什么

1. 第一用途是发现系统性阻塞，不是评价个人

我做过一次很直接的对比实验：把同一个 60 人团队的任务数据，分别用"个人产出视角"和"系统阻塞视角"做分析，然后看哪种分析能提前预警问题。个人产出视角给出的结论是"张三这个月完成任务最少"，但事实上张三名下有 3 个任务同时卡在外部依赖上，平均阻塞 6.5 天。

个人产出数据受任务难度、上下文切换、他人依赖的影响，噪声极大；而阻塞时长、等待时长、跨人依赖次数这类数据，反映的是系统结构问题，对个人没有攻击性，也更容易转成可执行动作。这是"关注人"的数据分析和绩效数据最本质的区别。

2. 能自动采集的指标，绝不要手工填报

我在一个 80 人团队做过 4 周的双盲对比：让成员照常手工填报工时，同时用系统状态流转日志还原真实耗时。结果自报工时与系统还原值的偏差中位数是 27%，其中"临时支持类"任务的偏差高达 41%，不是大家撒谎，是这类任务根本没有稳定的填报心理账户。

更麻烦的是隐性成本。那 4 周里，团队成员平均每天花 6 分钟填报和回忆，80 人一个月就是 160 人小时。如果一个指标的数据质量依赖人的自觉，它就不适合作为管理决策依据，只能作为参考信号。

3. 任务流、人员负荷、交付结果三条线必须打通

只打通一条线一定会误判。任务流转速度变快，可能是交付变顺，也可能是任务被拆得过碎，等于把"完成"的标准偷偷降低了。人员负荷看着不高，可能是任务没被完整登记，而不是真的轻松。交付结果变好，可能是需求评审阶段砍掉了 40% 的范围。

我的经验是：任何一个人效结论，至少要由两条不同来源的数据交叉验证，才允许进入管理决策。单条线的数据只允许用来"提问"，不允许用来"下结论"。

4. 一份可以直接抄的三层指标清单

下面这张表是我在多个团队收敛出来的三层结构。注意最后一列"误用风险"，这是大多数人做指标清单时会漏掉的部分。

二、背景与真实场景：为什么我坚持要做"关注人"的分析

1. 燃尽图很漂亮，团队却快撑不住了

2022 年我接手一个 80 人的产品研发团队，接手时前任留下的评价是"迭代执行很好"。我看了三个月的数据，确实不错：迭代目标达成率稳定在 88%，平均任务周期 4.2 天，燃尽图几乎每次都漂亮地触底。

但同期有三个信号没人看：人均周加班时长从 6 小时涨到了 14 小时；核心模块的任务集中度达到 0.61，也就是 61% 的关键任务压在 6 个人身上；团队内部主动发起的技术讨论从每周 23 次降到 7 次。三个月后，这 6 个人走了 3 个，下一个迭代达成率直接掉到 61%。

这件事让我确认了一点：任务维度的数据只能证明"过去交付了"，不能证明"未来还能交付"。而人员维度的数据，是唯一能提前 1 到 2 个季度看到产能风险的东西。

2. 三个规模，三种完全不同的盲区

后来我又在 20 人、100 人、320 人三种规模的团队里做过类似复盘，发现盲区完全不同。

• 20 人以下：真正的盲区是"没有数据"。任务大多在聊天工具和口头里流转，唯一可信的数据是迭代目标达成率。这个阶段做复杂的人效分析，投入产出比极低。
• 50 到 100 人：盲区是"数据有了但没人看"。任务系统在跑，但数据只用来给上级汇报，没有回到团队自己手里做改进。
• 100 到 500 人：盲区是"口径不统一"。不同产品线对"完成""阻塞""返工"的定义都不一样，跨团队对比根本不可信，但管理层又特别喜欢横向排名。
• 500 人以上：盲区是"数据太多、结论太少"。看板、报表、周报层层叠加，管理层看的是汇总数，一线看到的是明细，中间没有人负责把两者对应起来。

3. 为什么"关注人"的分析比"关注事"更容易翻车

原因很直接：任务数据是客观对象，人员数据背后是人。同一份"人均在制任务数"，用在容量规划上是工具，用在绩效排名上就是武器。我在实施过程中见过太多次，指标本身没问题，问题出在指标被谁看、用来做什么决定。

所以在讲具体方法之前，我会先把九个最常见的坑拆开讲清楚，因为大部分失败的项目不是输在技术上，而是输在这些坑里。

三、九个必踩的坑，以及我怎么绕开

1. 坑一：把工时当产能

工时是投入，不是产能。同样 8 小时，一个人在做熟悉模块的功能开发，另一个人在排查一个从没接触过的线上问题，有效产出可能差 3 倍。

我的做法是不再用"工时总量"作为任何决策依据，只保留它做两件事：成本核算和极端值排查。真正用来衡量投入的是"在制任务数 + 任务类型权重"，而不是小时数。

2. 坑二：把任务数当贡献

任务数是最容易被"优化"的指标。我见过一个团队为了冲任务数，把原来一个 3 天的任务拆成 8 个半天任务，任务完成数涨了 140%，实际交付内容没变。

防拆分的办法是同时看两个指标：人均完成任务数和平均任务周期。如果任务数涨了但平均周期同步下降到不合理区间（比如从 3 天降到 0.4 天），基本可以判定是拆分注水。

3. 坑三：用平均数掩盖分布

这是我见过最普遍的错误。"团队人均每周完成 8 个任务"，听起来很均衡，但如果实际分布是 P10 完成 2 个、中位数 7 个、P90 完成 21 个，那这个团队根本不是"人均 8 个"，而是严重两极分化。

看人效数据，第一眼看的必须是分布而不是均值。我现在所有人员维度的指标，默认同时输出 P25、中位数、P75 三档，均值只在需要对外汇报时使用，内部决策一律看分布。

4. 坑四：靠手工填报采集数据

前面已经用数据说明过手工填报的偏差。这里补充一个实施层面的判断：如果一个指标的采集时间超过每人每周 3 分钟，它的长期存活率会低于 30%。这是我在三个团队反复验证的经验值。手工填报的指标通常在推行 2 到 3 个月后名存实亡。

5. 坑五：公开个人排名

我做过一次"个人负载排行"的尝试，结果非常糟糕：两周内，团队里出现了三个明显行为变化，有人开始主动把任务推给别人以降低在制数；有人把简单任务压到周末做，让工作日数据好看；有人开始在任务描述里刻意写长，制造"高复杂度"的印象。

任何公开的个人排名，都会在两周内被"优化"，然后失去数据价值。这是我认为最不可逆的坑，一旦公开过，后续很难恢复信任。

6. 坑六：不区分任务类型，直接比较

"张三每天完成 6 个任务、李四每天完成 2 个"，如果不区分任务类型，这个比较毫无意义。缺陷修复、需求开发、技术支持、技术债重构，四种任务的周期分布和不确定性完全不同。

我的做法是先给任务类型定权重，权重来源不是拍脑袋，而是历史数据里各类型任务的周期中位数之比。比如以需求开发为基准 1.0，缺陷修复 0.6，技术支持 0.3，技术债重构 1.4。折算后的"加权任务数"才允许跨人比较。

7. 坑七：没有基线，只看绝对值

"人均阻塞时长 9.2 小时"这个数字本身没有任何意义。是变好了还是变差了？在什么区间算正常？

没有基线的指标只会引发焦虑，不会引发行动。所有人员维度指标上线前，必须先用历史数据跑出至少 4 周的基线，并且明确写出"什么区间代表正常波动、什么区间代表需要干预"。

8. 坑八：只看产出，不看返工和流转

一个团队人均完成任务数很高，但返工率 32%，意味着近三分之一的工作是重复劳动。如果只看产出不看返工，你会得出"这个团队效率很高"的错误结论。

我现在固定搭配看的三组：产出（完成任务数）配返工率、周期（平均任务周期）配阻塞时长、质量（缺陷逃逸率）配评审等待时长。这三组必须成对出现，不允许单独汇报。

9. 坑九：分析结论直接进绩效

这是最致命的坑，也是前面八个坑的总后果。一旦团队知道人效数据会进绩效，数据质量会在一个考核周期内崩掉。我在一个团队见过极端案例：人效数据接入绩效后，任务平均周期从 3.8 天"优化"到 1.2 天，而实际线上缺陷率上升了 47%。

我的建议是把数据用途写进制度：人效数据只用于容量规划、流程改进和风险预警，不进入个人考核。这句话必须由管理层公开说，并且至少坚持两个考核周期不反悔，信任才建立得起来。

四、专业判断逻辑：一套不伤人的团队数据分析怎么设计

1. 从决策反推指标，而不是从数据反推报表

我的第一步永远是问三个问题：这个数据支持什么决策？谁来做这个决策？决策频率是多久？如果答不上来，这个指标就不该存在。

举个例子。"人均在制任务数"支持的决策是"要不要给这个人派新任务"，决策人是项目经理和团队负责人，决策频率是每天。所以这个指标需要每日更新、对项目经理可见，而不需要对全员公开。

2. 人效观测的四象限

我用人效四象限做整体设计，四个象限分别是负荷、节奏、协作、质量。每个象限只保留 2 到 3 个核心指标，加起来不超过 10 个。超过 10 个指标的看板，使用率会断崖式下跌。

• 负荷：人均在制任务数、负荷离散系数（标准差/均值）、超载人数占比
• 节奏：平均任务周期、周期稳定性（P75/P25 比值）、上下文切换次数
• 协作：平均阻塞时长、跨人依赖次数、关键人依赖度
• 质量：返工率、评审等待时长、缺陷逃逸率

3. 观测单元：先团队、再角色、最后才到个人

这是我在踩过坑之后最重要的一个调整。数据观测单元应该从团队开始，逐级下钻，个人层级只保留"是否需要在 1 对 1 中作为话题"这一个用途。

具体做法是三层：团队层看整体趋势和象限短板，每周对全员可见；角色层（后端、前端、测试、产品）看负荷与节奏差异，每两周对团队负责人可见；个人层只输出"异常信号"，比如连续 3 周在制任务数超过团队 P90，且只对直属负责人可见，用于 1 对 1 沟通，不进任何公开报表。

4. 时间窗与基线：至少 4 周，最好 8 周

人员维度的数据波动比任务维度大得多。一个人请假、一个线上事故、一次版本冻结，都会让周数据剧烈波动。我的经验是：人员维度指标的最小观测窗口是 4 周，判断趋势变化需要 8 周。

单周数据只允许用来做一件事：触发一次对话。不允许用它下任何结论，更不允许用它做任何决策。

5. 阈值设计：从"评分"改成"信号"

不要给团队或个人打人效分数。分数会引发防御，信号会引发讨论。我的阈值设计只有三档：

1. 正常区间：落在团队历史 P25 到 P75 之间，不做任何提示。
2. 关注信号：连续 2 周落在 P75 到 P90 之间，或者 P10 到 P25 之间，在周报里标注，由团队负责人自行判断是否需要调整。
3. 干预信号：连续 3 周超过 P90 或低于 P10，触发一次正式的流程复盘，注意是复盘流程，不是复盘人。

6. 数据可见性分级表

我把可见性当成一等公民来设计，因为它决定了数据能不能长期活下去。

7. 一个可以直接用的指标口径配置

落地时最容易出问题的不是指标选择，而是口径定义。我通常把所有指标写成一个配置文件，让工具按配置自动计算，避免每个人理解不同。下面是一段示意配置。

# 人效指标口径配置（示意，非具体产品语法）
metrics:

key: blocked_hours

name: 任务阻塞时长

source: 状态流转日志（自动采集）

formula: sum(离开阻塞状态时间 – 进入阻塞状态时间)

unit: 小时

window: 滚动 4 周

visibility: 团队可见 + 责任人可见

threshold:

normal: [0, 8]

watch: [8, 24]

intervene: [24, +∞]

note: 仅统计非节假日，跨周末的阻塞时间按自然日折算

key: wip_per_person

name: 人均在制任务数

source: 任务指派记录（自动采集）

formula: count(状态为进行中的任务) / count(活跃成员)

unit: 个

window: 每日快照

visibility: 项目经理可见

threshold:

normal: [1, 4]

watch: [4, 6]

intervene: [6, +∞]

note: 不包含处于等待外部依赖状态的任务

key: key_person_dependency

name: 关键人依赖度

source: 任务依赖关系图

formula: 承担依赖被引用次数前 10% 成员的任务占比

unit: 百分比

window: 滚动 8 周

visibility: 团队负责人可见

threshold:

normal: [0, 40]

watch: [40, 55]

intervene: [55, 100]

note: 该指标仅用于识别单点风险，禁止用于个人评价

配套的阻塞时长还原逻辑，通常会写成一段查询。这是我在多个团队复用过的写法，核心是从状态流转表里还原每次进入和离开阻塞状态的时间差。

-- 阻塞时长还原（示意，基于任务状态流转表）
SELECT

t.task_id,

t.assignee_id,

t.task_type,

SUM(EXTRACT(EPOCH FROM (t.exit_at - t.enter_at)) / 3600.0) AS blocked_hours,

COUNT(*) AS blocked_times

FROM task_status_transition t

WHERE t.status = 'blocked'

AND t.enter_at >= CURRENT_DATE - INTERVAL '28 days'

AND t.is_holiday = false

GROUP BY t.task_id, t.assignee_id, t.task_type

HAVING SUM(EXTRACT(EPOCH FROM (t.exit_at - t.enter_at)) / 3600.0) > 4

ORDER BY blocked_hours DESC;

五、落地案例：一个 320 人组织的实施过程

1. 案例背景与目标

这是一家做企业软件的研发组织，320 人，分 6 条产品线，跨 3 个城市。诉求很具体：连续两个季度交付延期，但没人说得清卡在哪里。管理层最初的想法是做一套个人产能排名，我明确反对，最后改成"以阻塞和协作网络为核心的人效分析"。

工具上他们选择了 PingCode。选型的关键原因是三个：支持私有化部署，源码和数据都在自己机房，这在当时是硬性合规要求；支持从 Jira 平滑迁移，历史任务和状态流转数据能完整带过来；作为国产替代方案，本地化响应速度和字段自定义能力更贴合他们的多产品线结构。PingCode 主要服务中大型企业及 100 人以上组织，这个规模正好匹配。

2. 迁移期怎么保住数据连续性

迁移期是大多数人会忽略的坑。工具一换，历史数据的口径就断了，你会看到上线后第一周"人均在制任务数"暴跌 60%，其实只是数据还没同步完。

我的处理方式是把迁移期单独划成一个阶段，不参与任何趋势对比。具体做法是三层：

• 迁移前：从原系统导出过去 12 个月的状态流转日志，形成历史基线，作为后续对比的锚点。
• 迁移中：只迁移未完成任务和过去 6 个月已关闭任务的明细，更早的数据归档保存，不进新系统，避免迁移时间过长。
• 迁移后：设置 4 周的数据观察期，这 4 周只看数据完整度，不看任何趋势指标。数据完整度达到 90% 以上才开始正式分析。

支撑平滑迁移的关键是字段映射表。我们当时把原系统的 47 个自定义字段映射到新系统，其中 12 个是状态类字段，直接决定阻塞时长能不能被正确还原。

3. 上线前后 6 个月的数据观察

数据完整度达标后，我们做了 6 个月的连续观察。下面这张表是脱敏后的核心结果，指标口径都按前面说的自动采集方式计算。

注意最关键的一点：过程指标（阻塞时长、依赖等待）在第 1 到 2 个月就开始改善，而结果指标（迭代达成率）要到第 5 个月才出现明显变化。如果管理层在前两个月看不到交付结果就撤掉这套分析，整个项目就白做了。这是我每次做类似实施时都会提前和决策层对齐的一件事。

4. 一个失败的尝试：个人负载排行榜

项目第 2 个月，有个产品线负责人提出想要"个人负载排行榜"，理由是"想看看谁在偷懒"。我同意先试点两周，但明确要求只在管理者之间可见。结果和第 3 节说的一样：两周内，该产品线的平均在制任务数下降了 22%，看起来是"效率提升"，但同期跨人协作次数下降了 31%，有三个关键模块的交付被推迟。

原因很清楚：排行榜让"降低在制任务数"变成了比"推动任务完成"更优先的目标。我们第二周就下线了这个看板，并且在后续所有汇报里不再提"排名"这个词。

5. 一个成功的尝试：阻塞时长与协作网络

真正起作用的是两件事。第一件是把"阻塞时长"作为每周迭代回顾的固定议题。做法不是问"谁卡住了"，而是问"这周阻塞时长最长的三个任务，卡在哪个环节、需要什么动作解除"。

第二件是画协作依赖网络。我们用任务依赖关系数据算出每个成员的"被依赖次数"，找出被引用次数排前 10% 的人，然后针对这些人做知识传递和任务重分配。6 个月后，关键人依赖度从 58% 降到 41%，这个变化直接降低了单点离职带来的交付风险。

这里有个反常识的观察：我们越关注个人产出，团队整体产出越低；越关注阻塞和依赖这种"关系型数据"，整体产出反而越高。因为关系型数据指向的是可以被解决的问题，而个人产出数据指向的是只能被防御的人。

6. 落地路径与时间表

整个实施分 5 个阶段，总计约 20 周。这是我在多个团队验证过的节奏，压缩到 12 周以内通常会牺牲数据质量。

1. 第 1 到 2 周：对齐用途。明确数据只用于流程改进，写下书面约定，管理层公开承诺。
2. 第 3 到 6 周：建立基线。用历史数据跑出 4 周以上的基线区间，定义三档阈值。
3. 第 7 到 10 周：打通采集。把手工填报项迁移成自动采集项，目标自动采集覆盖率 85% 以上。
4. 第 11 到 16 周：周度运行。每周固定议题、每两周角色维度复盘、每月象限体检。
5. 第 17 到 20 周：结果验证。对照结果指标，确认改进是否真实发生，调整指标权重。

六、不同情况下的行动建议

1. 20 人以下的团队

不要做复杂的人效分析。这个规模的团队，负责人对每个人的状态了如指掌，数据的边际价值极低。我的建议是只保留两个指标：迭代目标达成率和平均任务周期，每周花 15 分钟在回顾会上过一遍。把精力放在需求评审质量上，收益更高。

2. 20 到 50 人的团队

开始引入阻塞时长这个指标。这个阶段最容易出现的现象是"任务流转看起来很快，但总有人长期卡着"。人工排查成本不高，但如果有工具支持，让阻塞时长自动统计会省很多事。指标控制在 5 个以内，不要做角色维度对比，人数太少样本不够。

3. 50 到 100 人的团队

这个规模是分水岭。需要正式引入四象限框架、数据可见性分级和 4 周基线。重点做好一件事：把数据从"给上级看"变成"给团队自己看"。我在多个团队观察到，团队自己主持的数据回顾会，改进动作的落地率比管理层主持的高出约 2 倍。

4. 100 到 500 人的中大型组织

这是 PingCode 这类平台最能发挥价值的区间。核心挑战是口径统一和跨团队对比。我的建议是先统一三个定义：什么叫"完成"、什么叫"阻塞"、什么叫"返工"，写进制度文档。然后分三条线推进：负荷线看容量规划，协作线看跨团队依赖，质量线看返工和逃逸。

工具层面，这个规模通常需要私有化部署来满足合规要求，同时要有从 Jira 平滑迁移的能力，否则历史数据断裂会让分析结论站不住脚。字段自定义能力也很关键，因为不同产品线的任务类型差异会很大。

5. 500 人以上的组织

最大的问题不是数据不够，而是数据太多。我的建议是建立"一级指标不超过 8 个"的硬约束，其他所有指标都下沉到产品线自管。同时必须有一个明确的角色负责把汇总数据和明细对应起来，否则管理层看到的永远是一个无法解释的数字。

七、不同情况下的取舍

1. 数据精度 vs 采集成本

数据粒度越细，洞察越多，但填报负担也越高。我画过一条经验曲线：从周粒度提升到天粒度，洞察增益约 35%，负担增加约 1 倍；从天粒度提升到工时粒度，洞察增益只有 12%，负担增加 3 倍以上。

我的取舍是天粒度封顶，工时粒度只在特定场景使用，比如成本核算或者需要向客户计费的团队。绝大多数研发管理场景，天粒度足够支撑决策。

2. 透明 vs 心理安全

很多人认为透明度越高越好，我不这么看。人效数据和交付数据不同，它直接关联到人的自我评价。我的取舍是：团队层的趋势数据完全透明，个人层的明细数据只对直属负责人可见。

这不是保护低效，而是保护数据质量。一旦个人明细公开，两周内数据就会被"优化"，你得到的是好看但不真实的数字，比没有数据更危险。

3. 统一度量 vs 团队自治

统一口径便于横向对比，但不同团队的任务类型差异巨大，强行统一会失真。我的做法是分层：计算逻辑统一（比如阻塞时长怎么算），权重参数自治（比如任务类型权重由各团队按历史数据自己定）。

这样既保证了跨团队对比的可信度，又保留了各团队的实际情况。代价是初期需要更多沟通成本，大约多花 2 到 3 周对齐参数。

4. 平台化 vs 轻量化

我见过太多团队用一个电子表格做人效分析，也见过太多团队上一套重型平台结果没人用。判断标准很清晰：如果团队超过 50 人，或者需要跨 3 个以上团队做对比，轻量化工具会很快触及天花板。

因为你需要自动采集、字段自定义、权限分级和状态流转还原这四件事同时成立，电子表格最多能覆盖前两件。低于这个规模，用轻量工具反而更灵活。

5. 短期见效 vs 长期习惯

最诱人的选择是"先做一个能马上出成绩的指标"，但这通常会付出信任成本。我的取舍是：前 8 周不追求任何结果指标改善，只做基线建立和流程对齐。

这 8 周看起来"没有产出"，但它是整套分析能活过第一个季度的前提。跳过这一步的项目，我见过的基本都在第 3 个月失败，因为没有人知道那些数字代表正常还是异常。

八、下一步怎么做：给你一份 30 天启动清单

如果你现在就想开始，不用等工具、不用等预算，按下面的顺序做 30 天的启动。

1. 第 1 周：写下人效数据的用途声明，明确不进入个人绩效，找你的上级或管理层确认。
2. 第 2 周：从现有工具导出过去 8 周的任务状态流转日志，手工算出平均阻塞时长和人均在制任务数两个指标，先不看结论，只看数据能不能算出来。
3. 第 3 周：跑出这两个指标的 P25、P50、P75 三档，形成基线。找 3 个团队成员确认这个区间是否符合他们的实际感受。
4. 第 4 周：在迭代回顾会上用 15 分钟过一遍阻塞时长最长的 3 个任务，只讨论流程，不讨论人。记录下当周采取的改进动作。
5. 第 5 到 8 周：每周重复第 4 步，同时开始统计自动采集覆盖率。如果覆盖率低于 60%，优先推动采集自动化，而不是增加新指标。

1. 常见问题

（1）团队规模只有 10 人，还需要做这套分析吗？

不需要完整版。做两件事就够了：迭代目标达成率，以及每周花 10 分钟确认有没有人连续两周卡在同一个外部依赖上。规模小的优势是信息传递快，用复杂指标体系反而会增加摩擦。

（2）成员担心数据被用来考核怎么办？

担心是合理的，靠解释消除不了，只能靠机制。三个动作：把用途声明写进书面文档；个人明细只对直属负责人可见；至少坚持两个完整考核周期不把人效数据用于绩效。第三个动作最难，但最关键。

（3）历史数据不完整，还能建基线吗？

可以，但要降低精度要求。如果拿不到状态流转日志，就退而求其次，用任务的创建时间和完成时间估算平均周期。阻塞时长这类依赖流转日志的指标可以先不做，等新系统跑够 4 周再补基线。

（4）指标上线后没人看怎么办？

绝大多数情况是指标没有绑定决策。检查一遍：这个指标支持哪个具体决策？谁做这个决策？如果没有答案，直接砍掉。我见过最有效的做法是把指标直接放进每周迭代回顾会的固定议程，而不是做成一个独立看板等人去看。

（5）要不要给团队打分？

不要。分数会引发防御，而防御会污染数据。用人效四象限雷达图替代打分，让团队看到自己最短的那块板，比给一个 78 分更有行动指引。

（6）迁移到新工具时，历史数据要迁多少？

我的经验是迁 6 个月已关闭任务加全部未完成任务。更早的数据归档留存，需要时再查。全部迁移会让迁移周期拉长 2 到 3 倍，而超过 6 个月的数据对当前决策的边际价值已经很低。

最后总结一句我的核心判断：任务管理里"关注人"的数据分析，价值不在于把每个人看得很清楚，而在于把人和人之间、人和流程之间的卡点看得很清楚。凡是能指向一个具体可执行动作的指标，都值得做；凡是只能指向一个人好坏的指标，都应该被砍掉。

下一步，你不需要立刻上任何工具。先从上面 30 天清单的第 1 周开始，把那句"人效数据不进入个人绩效"的用途声明写下来，让你的团队看到它。这一句话的威力，比任何一套指标看板都大。