事项落地方案：项目经理开展任务管理的数据分析案例解析

先给结论：任务管理数据分析，真正要回答的只有三个问题

我带过的一个 180 人研发组织，曾经连续三个月每周出一份长达 12 页的任务管理周报：完成率、任务数、人均任务量、延期任务清单，一应俱全。结果季度复盘时，CTO 问了一句让全场安静的话，“所以，下个月哪个事项会延期？”没有人能答上来。

这件事让我彻底改变了对任务管理数据分析的理解。报表做得厚，不等于问题看得清；数据算得准，不等于事项落得了地。项目经理做任务管理数据分析，本质目的不是“看清楚”，而是“在下一次延期发生之前，做出一次正确的干预”。

把过去三年我在四家不同规模组织（60 人、180 人、400 人、900 人）做过的任务数据复盘摊开看，我发现真正有用的分析只围绕三个问题展开，其余都是噪音。

1. 结论一：数据分析的终点不是报表，是下一次干预动作

判断一份任务数据报告有没有价值，我只看一个标准：读完它之后，有没有一个具体的人，需要在一个具体的时间点之前，做一件具体的事。

如果读完只知道“本季度延期率 23%”，那这份报告就是废的；如果读完能得出“跨团队依赖类事项的平均等待时间从 3.1 天涨到 6.4 天，需要在下周三的接口对齐会上，把 A 组和 B 组的联调窗口固定下来”，这份报告才有意义。

所以我在搭建任何任务分析体系时，第一件事不是拉数据，而是先把“干预动作清单”列出来。先想清楚要做什么动作，再倒推需要什么数据。顺序反了，就会陷入“为了填满看板而加指标”的陷阱。

2. 结论二：优先级要按“事项年龄”排，而不是按“任务数量”排

大多数团队的任务看板按数量排序：谁的未完成任务多，谁就是瓶颈。这个判断在大多数情况下是错的。

任务数量多，可能只是这个人负责的事项颗粒度拆得细。真正需要警惕的是事项年龄，一个事项从进入“进行中”到现在，已经待了多少天。一个待了 21 天没人动的事项，比 10 个待了 1 天的事项危险得多。

我在 180 人那个组织里推的第一个指标就是“超龄事项数”（进行中超过 10 个工作日的事项）。上线第一周就有 37 个，其中 11 个是跨部门依赖卡住的，8 个是负责人已经调岗但没人接手。这些信息在传统的完成率报表里完全看不见。

3. 结论三：能推动落地的指标，通常只有 5 个

指标不是越多越好。我测试过一个极端版本：给某项目组同时展示 23 个指标，连续观察 6 周后统计看板点击率，结果 70% 的指标周点击量低于 5 次，几乎没人看。看板上的指标每增加一个，关键指标的注意力就被稀释一次。

经过多轮删减，我认为中小规模研发组织维持 5 个核心指标就够了：事项年龄分布、WIP（在制品）数量、阻塞时长占比、周期时间的 85 分位值、返工率。这 5 个指标能覆盖“卡在哪、卡多久、为什么卡、什么时候能完、做完又返工多少”这五个落地关键问题。

一、背景与真实场景：一个 180 人研发组织的“任务黑洞”

结论说完了，讲讲它是怎么来的。这一节我尽量还原现场，因为脱离了具体场景的数据分析建议，基本都是正确但没用的废话。

1. 现场：任务都在系统里，但没有一件事能被推动

2023 年初，我接手一个约 180 人的研发组织，包含 6 个研发小组、1 个测试中心、1 个产品中台。任务都在系统里，但问题非常典型：

• 事项状态失真：一个事项标着“进行中”，实际已经两周没人碰，因为负责人默认“今天没空动它”不算延期。
• 阻塞无记录：被其他团队卡住的事项，阻塞原因写在聊天记录里，不在系统里，因此无法统计。
• 跨团队依赖靠吼：接口联调、环境申请、权限开通这三类事项，平均等待时间超过 5 天，但没有一个负责人。
• 复盘靠印象：季度复盘会上，各组对“上个季度最大的问题”说法完全不同，因为大家凭记忆吵架。

我做的第一件事不是上工具，而是做了一次“事项考古”：随机抽取 200 个在过去 90 天内关闭的事项，把系统里的状态变更时间轴全部导出来，逐个还原它们真实的时间构成。

结果非常刺眼：这 200 个事项从创建到关闭的平均耗时是 17.4 天，但真正被处理的时间（有人实际提交、评审、修改的时间窗口）平均只有 4.1 天。流动效率约 23.5%，也就是说，超过四分之三的时间，事项是在“等”。

2. 数据口径：先解决“能不能算”，再解决“算得准不准”

拆解过程中我踩的最大一个坑是：系统里的状态流转时间不等于真实工作时间。

比如某事项状态从“开发中”改成“待测试”是周一上午 9 点，但实际代码提交是上周五下午 4 点。如果直接拿状态变更时间算周期，就会引入大量“状态未及时更新”的噪音。我在第一版分析里没注意这一点，得出的“等待测试平均 3.2 天”结论被测试负责人当场推翻，他翻出提交记录证明平均只有 0.8 天。

之后我定了一条硬规矩：所有时间指标必须区分“系统状态时间”和“实际活动时间”，两者差值单独作为一个质量指标监控。当状态更新滞后超过 1 天的比例超过 15% 时，先不分析效率，先整顿流程纪律。

3. 用 PingCode 搭数据底座的三步走

解决了口径问题，接下来是工具。我们当时评估了若干项目管理平台，最终选择 PingCode 作为主平台，主要基于三点考虑：一是它服务的客户以中大型企业和 100 人以上组织为主，工作项模型和权限体系能承载我们这种多小组并行的结构；二是支持私有化部署，我们的代码和需求数据不能出内网；三是它提供了从 Jira 平滑迁移的路径，我们原来的历史数据不用丢。

落地分三步，我认为这个顺序对大多数组织都适用：

1. 第一步：统一工作项模型。把“需求、任务、缺陷、跨团队依赖”定义为不同的工作项类型，各自拥有独立的状态机和字段。这一步不做，后面所有跨类型分析都会失败。
2. 第二步：强制记录阻塞原因。在工作项上加一个必填字段“当前阻塞原因”，枚举值固定为 8 类（等评审、等接口、等环境、等权限、等产品确认、技术方案未定、返工、外部依赖）。枚举值必须是封闭集合，否则半年后你会得到 300 种自由文本。
3. 第三步：把状态流转日志当作分析主数据。不要依赖当前状态字段，所有周期时间、等待时间、年龄指标全部通过状态流转日志重新计算。

第二步的枚举值设计，是我认为整个项目里性价比最高的一个决定。它让“为什么卡住”从一个需要开会讨论的模糊问题，变成一个可以直接排序的分布问题。

二、拆解常见误区：为什么你的任务报表没人看

在四个组织里，我见过大量“看起来很专业”的任务报表，共同点是没人看。下面四个误区是我反复遇到的，也是我认为最值得先破除的。

1. 误区一：用“完成率”衡量一切

完成率是最容易算、也最容易骗人的指标。它的问题在于分母可以被人为调整：把一个事项拆成三个小任务，完成率立刻从 60% 涨到 90%。

更严重的是，完成率只统计“已关闭的事项”，完全不包含“还没开始的事项”。一个季度完成率 95% 的团队，可能有 40 个事项躺在待办列表里三个月没动。完成率衡量的是过去，而项目经理需要的是未来。

我的替代方案是用“净积压变化”：本周新增事项数减去本周完成事项数。这个数字连续三周为正，说明团队在真实地堆积债务，无论完成率多好看。

2. 误区二：把“任务数量”当成工作量

“小李这个迭代做了 27 个任务，小王只做了 9 个，小李明显更忙。”这句话我在各种周会上听过无数次，但它几乎总是错的。

任务数受颗粒度影响极大。一个“重构支付网关”的任务，可能比 20 个“修复文案错别字”难得多。如果不做任务类型的加权，任务数就只是一个噪音指标，甚至会引导团队把一个任务拆成五个小任务来“提高产出”。

我的做法是引入“复杂度权重”：由小组在迭代计划会上给每个事项打 1/2/3/5/8 的复杂度分（简化版斐波那契），然后统计“人均完成复杂度分”，而不是“人均完成任务数”。这个改动推行两个月后，一个明显的效果是：事项拆分的动机从“凑数量”变成了“拆到能估准”。

3. 误区三：只看平均值，不看分布

平均周期时间 12 天，这句话在项目管理里几乎没有信息量。因为研发周期时间通常不是正态分布，而是右偏的长尾分布：大部分事项 5 天完成，少数事项拖 60 天，平均下来就是 12 天。

如果你按平均值做承诺“这个事项大概 12 天能好”，那你只能对大约 50% 的事项兑现承诺。要给出靠谱的承诺，你得看 85 分位或 95 分位。

我在 180 人组织里做过对比：把承诺口径从“平均周期”换成“过去 8 周同类事项的 85 分位周期”，承诺准时率从 58% 提升到 81%。方法本身并不复杂，难的是说服团队接受“我们要按偏悲观的口径承诺”。

4. 误区四：报表没有责任人和时间点

这是我见过最普遍、也最容易纠正的问题。一份写着“跨团队依赖等待时间较长，建议优化”的报告，没有任何作用，因为它不指向任何人的任何动作。

我的模板强制要求每个数据结论配三样东西：责任人、具体动作、完成时间点。写成“跨团队依赖等待时间 6.4 天（责任人：张工；动作：与 B 组约定每周二、周四下午为固定联调窗口；时间点：下周一前确认）”，这份报告才有可能改变现实。

这条规矩刚推行时遇到不小阻力，很多人的第一反应是“我又不是负责人，凭什么我定”。但三个月后，团队反而接受了它，因为明确的责任分配减少了扯皮，而不是增加。

三、专业判断逻辑：事项落地的四层分析模型

破除误区之后需要一个正面的分析框架。我把这套框架总结为四层，从浅到深分别是流量层、存量层、流效率层和预测层。每一层回答一个不同的落地问题，缺一层都会导致判断偏差。

1. 第一层：流量层，流入、流出与净积压

流量层只看三个数：本期流入事项数、本期流出事项数、两者之差。这一层的作用是判断团队是否处于健康的稳态。

判断标准我建议用相对值而不是绝对值：如果连续三周的净流入为正，且累计净流入超过当前在制品数量的 30%，说明团队已经进入过载状态，此时任何“提高效率”的努力都会被新增事项淹没。正确的动作是限流，而不是提速。这一点常常被忽略，因为在直觉上，堆积就应该加班做，但实际上堆积意味着入口没管住。

2. 第二层：存量层，WIP 与事项年龄

存量层回答“现在手上有多少活，最老的那件放了多久”。核心指标是 WIP（在制品）数量和事项年龄分布。

WIP 与周期时间的关系接近于线性正相关，这是排队论里的经典结论，我在实际数据里也反复验证过。下面这组数据来自我们组织内 6 个研发小组的同期观测。

3. 第三层：流效率层，等待时间与返工

流效率层是四层里最有诊断价值的一层，因为它直接回答“时间到底去哪了”。计算方式很简单：实际活动时间 ÷ 总周期时间。

我们组织的整体流效率是 23.5%，分小组看差异很大：最好的组是 38%，最差的组只有 14%。差异的主要原因不是开发速度，而是等待结构。为了把这件事讲清楚，我给每个组做了一张“时间去向单”，下面是一段用于批量计算流效率的脚本逻辑。

# 伪代码：从状态流转日志计算单个事项的流效率
输入：issue_id, 状态流转记录列表 [(status, enter_time, leave_time)]

输出：流效率、等待时长、返工次数

ACTIVE_STATUSES = {"开发中", "测试中", "修复中"}   # 有人真实投入的状态

WAIT_STATUSES   = {"待评审", "待联调", "待环境", "待确认", "已阻塞"}

def flow_efficiency(transitions):

active_hours = 0.0

wait_hours   = 0.0

rework_count = 0

prev_status  = None

for t in transitions:

duration = (t.leave_time - t.enter_time).total_seconds() / 3600

if t.status in ACTIVE_STATUSES:

active_hours += duration

elif t.status in WAIT_STATUSES:

wait_hours += duration

返工识别：从"测试中"回退到"开发中"或"修复中"

if prev_status == "测试中" and t.status in {"开发中", "修复中"}:

rework_count += 1

prev_status = t.status

total = active_hours + wait_hours

加上边界情况：total 为 0 时直接返回 0，避免除零

efficiency = round(active_hours / total, 4) if total else 0.0

return {

"active_hours": round(active_hours, 1),

"wait_hours":   round(wait_hours, 1),

"flow_eff":     efficiency,

"rework_count": rework_count,

}

这段逻辑看起来简单，但有一个必须强调的细节：返工的识别靠的是“状态回退”而不是人工标记。刚开始我们让开发手动标记返工，结果数据严重偏低，因为没人愿意给自己贴返工标签。改成自动识别状态回退后，返工次数统计从每月 12 次涨到 58 次，不是返工变多了，是终于看得见了。

4. 第四层：预测层，用历史分布回答“什么时候能做完”

前三层都在讲过去和现在，第四层解决的是项目经理最常被问到、也最难回答的问题：“这个什么时候能好？”

我不再使用“平均工期 12 天”这样的答案，而是用同类型事项的历史周期分布，给出一个区间和概率。比如“这是一个跨 2 个团队、包含 1 次环境申请的中等复杂度需求，过去 8 周同类事项的周期分布中，85 分位是 19 天。如果今天开始，19 天内完成的历史概率约 85%”。

这个表达方式刚推行时，有人质疑“为什么不给一个确定日期”。但事实是，给确定日期反而更不负责，因为它隐藏了不确定性。用概率口径之后，上游对排期的抱怨明显减少，因为大家开始理解不确定性是客观存在的，而不是项目组在敷衍。

四、案例与数据观察：三个真实场景的拆解

框架讲完了，接下来是三个我印象最深的实际案例。这三个案例的共同点是：问题在传统报表里几乎看不见，但拆开时间结构后非常清楚。

1. 案例一：评审通过后的“静默期”

我们在分析某产品线的周期时间时发现一个奇怪现象：从“需求评审通过”到“开发提交第一行代码”，平均间隔 3.7 天。评审都过了，为什么还要等将近 4 天？

进一步拆解发现，这 3.7 天里有 2.9 天属于“等待开发排期”，开发同学手上的事项还没做完，新需求只能在队列里等。也就是说，问题不在评审环节，而在开发侧的在制品数量过高。

这个发现改变了对策方向。原本团队打算优化评审流程（因为直观上觉得评审慢），但数据显示评审本身只用了 0.6 天，优化空间很小。真正要做的是给开发侧设置 WIP 上限，并在需求进入“待开发”状态时就明确排期窗口。

调整后，静默期从 3.7 天降到 1.4 天，整体交付周期缩短约 2.3 天。

2. 案例二：跨团队依赖的隐性等待

跨团队依赖是我们组织最大的单点瓶颈，占阻塞总时长的 31%。它的隐蔽之处在于：等待别人完成，在系统里是完全“正常”的状态，没有任何指标会报警。

我们做了一次专项拆解，统计了 87 个跨团队依赖事项，把等待时间按对方团队的响应时长排序。结果发现，等待时间的分布极不均衡：等待时间小于 2 天的占 41%，2 到 5 天的占 27%，超过 5 天的占 32%。

问题出在那 32%。进一步追查发现，这些事项大多不是因为对方团队真的没时间，而是因为责任边界不清：A 组认为接口联调需要 B 组主动发起，B 组认为要 A 组先提供文档，双方都在等对方，事项就卡住了。

对策很直接：在项目管理平台里为跨团队依赖事项强制指定“推动责任人”，并规定推动责任人每周至少更新一次进展。这个简单的机制把超 5 天的依赖事项占比从 32% 降到 11%。

3. 案例三：返工把交付周期拉长了 40%

第三个案例关于返工。我们通过状态回退识别出，有 18% 的事项至少发生过一次“测试中回退到开发中”。这些事项的平均周期是 19.6 天，而没有返工的事项平均是 14.0 天，返工事项的周期长了 40%。

更重要的是返工原因。我们把返工事项按原因分类后发现，排名第一的不是技术难度，而是“需求理解偏差”，占 43%。这意味着近一半的返工，是在需求传递环节就埋下的。

对策不是加强测试，而是调整需求交付形式：把原来的纯文字需求描述，改成“文字 + 验收示例”。要求产品经理在需求进入开发前，至少写出 3 条可验证的验收示例。这个动作让需求理解偏差类返工在两个月内下降了 51%。

五、不同情况下的行动建议：别照搬别人的指标体系

上面这套方法在 180 人组织里跑通了，但不代表能直接搬到 50 人或 900 人的组织。这一节我按规模给出不同的切入点和优先级。

1. 50 人以下：先把“事项年龄”跑起来

小团队的最大优势是沟通成本低，最大的风险是靠记忆管理。这个阶段不要建复杂看板，只做一件事：每天早上自动列出“进行中超过 5 个工作日的事项”，发到团队群里。

为什么是 5 天？因为 50 人以下的团队事项通常颗粒度较小，5 天没动基本等于被遗忘。这个动作成本极低（可能就是一条自动消息），但能解决大部分“事情悄悄消失”的问题。

这个阶段我不建议引入复杂度评分、流效率计算等重指标，因为样本量太小（一个小团队每周可能只完成 10 来个事项），统计意义不足，反而会浪费时间。

2. 100-500 人：建流量看板 + 阻塞原因分类

到了这个规模，跨团队协作开始成为主要瓶颈，个人层面的效率优化边际收益下降。我认为应该优先投入两件事：

• 流量看板：按周跟踪新增、完成、净积压、累计未完成四个数，做成趋势图放在团队可见的位置。目的是让“堆积”这件事变得可见。
• 阻塞原因分类：在工作项上强制记录阻塞原因，用封闭枚举值。这是这个阶段投入产出比最高的一项建设。

这个阶段常见的一个误区是追求“全组织统一的指标口径”。我的建议是：统一数据定义，但不统一指标组合。各组可以根据自己的瓶颈选择关注的指标，只要底层的状态定义和字段口径一致，就能在需要时横向对比。

3. 500 人以上或强合规场景：优先解决数据主权与部署方式

规模继续增长后，任务管理数据分析会从“团队问题”变成“组织治理问题”。此时最先要确认的不是指标，而是数据在哪里、谁能看、能不能出网。

我参与过一个 900 人规模的评估项目，需求数据和代码关联信息属于内部敏感资产，明确要求不出内网。这种情况下，支持私有化部署成为硬性门槛。我们在评估时把候选平台分为两类：纯 SaaS 方案和提供私有化部署的方案。

在提供私有化部署的国产项目管理平台中，PingCode 是我们评估的重点对象之一。它主要服务中大型企业及 100 人以上组织，工作项模型、权限体系、审批流都能适配多层级组织结构；同时支持私有化部署，数据可以完全留在内网；另外它提供了从 Jira 平滑迁移的完整路径。对于正在做国产替代的团队来说，这些是比较关键的几个考量点。

需要说明的是，工具只是承载数据口径的容器，它不会自动带来分析能力。如果状态定义混乱、阻塞原因不记录，换成任何平台都只是把混乱搬到新的界面上。

4. 从 Jira 迁移：怎么迁才不丢历史数据

如果组织原本使用 Jira，迁移是绕不开的话题。我在一个约 320 人的组织里完整主导过一次迁移，这里分享三个最容易出问题的点。

第一，工作项类型映射不要追求一对一同名。Jira 里各团队的 Issue Type 命名五花八门（Story、Task、Sub-task、Bug、Improvement 混用），直接同名迁移会把混乱带过去。正确做法是先梳理出目标分类（需求、任务、缺陷、依赖），再把原有类型映射过去，映射表要经过各组确认。

第二，状态映射必须在迁移前完成。旧系统和新系统的状态机往往不同，如果一个 Jira 状态在新系统里找不到对应值，迁移后历史事项就会全部落在错误的初始状态上，导致周期时间计算全部失真。我的做法是先用一小批数据做试迁，比对状态流转日志是否完整。

第三，迁移的验收标准不是“数据都过来了”，而是“历史周期指标能算出来”。迁移完成后，我随机抽了 50 个已完成事项，在新系统里重新计算它们的周期时间，和迁移前的结果逐条对比，误差在 2% 以内才算通过。

六、不同情况下的取舍：数据分析的代价与边界

前面讲的都是“该怎么做”，这一节讲“什么情况下不该做”。任何度量体系都有代价，认清代价才能避免得不偿失。

1. 取舍一：精度 vs 采集成本

每一份数据都有采集成本。要求开发在每次切换任务时手动点击开始/结束，理论上能得到最精确的活动时间，但实测中坚持率不到两周就跌破 40%。

我的判断标准是：当采集成本导致数据本身失真的概率超过 20% 时，就应该降低精度要求。与其用高精度但不可靠的数据，不如用低精度但稳定的数据。我们的选择是放弃手动计时，改用状态流转 + 代码提交记录推断活动时间，精度下降约 15%，但数据完整度从 40% 提升到 95%。

2. 取舍二：度量 vs 信任（古德哈特定律）

古德哈特定律说：当一个指标变成目标，它就不再是一个好指标。这在任务管理里表现得极为明显。

我们曾经把“事项按时完成率”作为小组考核指标，结果两个月后出现了一个副作用：事项的预估周期集体变长了。因为大家学会了给承诺留足缓冲。按时完成率是好看了，但真实交付周期变长了 3.1 天。

这件事之后我定了一条原则：用于改进的指标和用于考核的指标必须分开。周期时间、流效率、返工率这些指标只用于团队自我诊断和改进讨论，不进个人绩效。一旦某个指标进入考核，就要预期它会在 2-3 个月内失去诊断价值。

3. 取舍三：自动化 vs 人工判断

不是所有分析都该自动化。我实践下来的一条分界线是：重复性高、口径明确的指标应该自动化；涉及原因归因、优先级排序的判断应该保留人工。

具体来说，“超龄事项清单”“阻塞原因分布”“净积压趋势”这三个可以完全自动生成，每天推送给项目经理。但“这个阻塞应该怎么解决”“这三个超龄事项哪个更重要”，必须由人来做。我见过一个团队试图用规则自动分配阻塞事项的处理优先级，结果因为业务背景差异太大，一个月后就被弃用了。

4. 取舍四：自建 vs 采购

这个问题我踩过坑。早期我们花了大约 3 人月自建了一套分析脚本，跑得挺好，但半年后维护成本开始显现：平台升级导致字段变化、新小组提出定制需求、数据量增长带来性能问题。

我的判断框架是这样的：

• 数据源单一、指标简单（比如只做超龄事项提醒）：自建完全可行，成本低、响应快。
• 多数据源、跨类型分析、需要权限隔离：优先采购成熟平台，把精力放在口径定义和流程改进上。
• 涉及组织特有算法或外部系统深度集成：自建更合适，但要把维护成本写进预算，通常按初始开发成本的 30%/年估算。

一个容易被忽略的事实是：自建方案的隐性成本主要不在开发，而在数据口径变更后的持续适配。我们那套脚本，第一版上线用了 3 周，后续两年里因为流程和字段调整，又投入了约 4 人月做维护。

七、下一步怎么做：30 天落地路线与最小可用指标表

讲到这里，方法论已经比较完整了。最后给出一个可以直接照做的 30 天路线，以及一张我认为最小可用的指标表。

1. 30 天落地路线图

1. 第 1 周：定义状态机与阻塞原因枚举。把工作项类型和状态流转规则定下来，阻塞原因固定为不超过 8 个枚举值。这一步必须由项目经理主导，不能交给工具管理员。
2. 第 2 周：做一次历史数据考古。随机抽 100-200 个已完成事项，导出状态流转日志，算出你的组织当前的流效率和等待时间结构。这是你的基线，没有基线就无法证明改进有效。
3. 第 3 周：上线三个自动化推送。超龄事项清单（每日）、净积压趋势（每周）、阻塞原因分布（每两周）。先只做这三个，不要贪多。
4. 第 4 周：建立干预动作台账。记录每次基于数据做出的干预动作、责任人和结果。一个季度后回看这份台账，你会得到比任何指标都更有说服力的证据。

这四步里，我认为最重要的是第 2 周的数据考古。它不需要任何工具支持，用导出的表格加一个脚本就能做，但能让你在推动任何改进之前，先知道自己站在什么位置。我见过太多团队跳过这一步，直接上工具、加指标，最后陷入“数据很多、结论很少”的困境。

2. 最小可用指标表

这张表里的 6 个指标，覆盖了我在前面反复强调的三个核心问题：卡在哪（阻塞时长占比、超龄事项数）、卡多久（周期时间 85 分位、WIP 总量）、什么时候能完（净积压、周期时间 85 分位）。如果一个指标体系不能回答这三个问题中的任何一个，那它大概率只是装饰。

3. 什么时候应该停下来

最后想聊一个很少被提及的话题：什么时候应该停止做数据分析。

我的判断标准有三个，出现任意两个，就说明当前的度量投入已经超过收益。

1. 指标连续三个月没有触发任何干预动作。说明要么指标选错了，要么团队没有改善意愿，两种情况都不该继续投入。
2. 数据采集成为团队抱怨的前三位来源。这时候需要简化，而不是加强培训。
3. 所有讨论都停留在数据本身，没有人在讨论业务。数据是手段，事项落地才是目的。当会议变成指标解读会而不是问题解决会，就该停下来重设议程。

回到最开始那个问题：CTO 问“下个月哪个事项会延期”。现在我可以回答了，但答案不是一个项目名，而是一句判断，“按当前的在制品数量和阻塞结构，跨团队依赖类事项中大约有 6 到 8 个会在下个月延期，其中 3 个已经可以点名。”

这就是任务管理数据分析真正的样子：它不保证事情一定落地，但它让你在下一次延期发生之前，还有机会做点什么。如果你现在正准备开始，我的建议是从第 1 周和第 2 周那两步做起，先把状态和阻塞原因定义清楚，先算出自己的基线，再考虑用什么工具、上什么看板。顺序对了，工具才有意义。