进度管理项目进度教程：研发团队数据分析，避坑指南

去年秋天，我帮一家 300 人规模的研发组织做季度交付复盘。翻完数据我愣了很久：所有 Scrum 团队的燃尽图在 Sprint 结束前都是"健康"的，进度完成率平均报 92%，但那个季度实际对外承诺的需求交付延期了 41%。更离谱的是，团队自己也不觉得在撒谎，他们填的每个数字都是真的，只是这些数字加起来，什么也说明不了。

这件事让我彻底改变了对"进度管理"的理解。研发进度数据分析最大的坑，不是数据造假，而是你在用一套只会自我安慰的指标，去回答一个它根本回答不了的问题。这篇教程不打算再重复"要有燃尽图、要有看板、要每日站会"这类通用建议，我想把自己在十几个研发团队里踩过的坑、调过的口径、换过的指标，按可落地的顺序讲清楚。

一、先给结论：进度数据分析失效的五个根因

在展开场景和案例之前，我先把最核心的判断摆出来。如果你只想要一份"避坑清单"，看完这一节基本就够了。后面所有内容，都是在论证这五条结论。

1. 进度数据失真，90% 不是工具问题，是定义问题

大部分团队遇到"进度不准"，第一反应是工具不行、填报不及时、成员不配合。但我复盘过的案例里，真正由工具能力导致的失真不到一成。剩下九成集中在三件事："完成"没有被定义、"开始"没有被定义、"计划"没有被冻结。

举个最常见的例子。一个故事卡从"待办"移到"进行中"，有人理解为"我已经开始看了"，有人理解为"我已经写完代码了"。当这两类人混在同一个看板里，你的在制品统计、周期时间统计、流效率统计全部失真，而且失真是系统性的、无法通过事后清洗修复的。

2. 单一进度指标走到尽头一定是博弈

只要一个指标被用来考核，它就会在三个月内失去作为度量的价值。进度完成率是最典型的：一旦团队知道完成率影响绩效，最理性的做法就是把任务拆得更碎，让分母变大、每张小卡都能"完成"。数字变好看了，真实交付没有变化。

我见过一个团队把一个大需求拆成 47 张子任务卡，Sprint 完成率从 68% 一路飙到 97%，但那个需求本身延期了整整一个季度。这不是道德问题，是指标设计问题。

3. 真正能提前预警的指标，通常"不好看"

燃尽图好看，但它几乎不预警，它是滞后指标，等它出现明显偏离，问题往往已经发生了一到两周。真正有预警能力的是那些看起来"不性感"的指标：在制品数量、阻塞时长、需求等待时间、跨团队依赖平均等待天数。

这些指标的共同点是：它们不直接回答"完成了多少"，而是回答"卡在哪里"。而后者才是进度管理的真正命题。

4. 口径不统一，看板越多越乱

组织规模一过 100 人，团队自治带来的直接后果是口径分裂。A 团队用故事点，B 团队用人天，C 团队干脆用"张数"。到了管理层层面，所有数据被摊平到同一张报表里，得出的结论一定是错的。

我在一次跨部门汇报里见过更极端的：同一个季度，"需求吞吐量"在三个部门的报表里分别是 78、134、52。原因不是数据错，是三个部门对"一个需求"的粒度定义完全不同。没有统一口径的度量体系，本质上是三套互不相干的方言。

5. 结论清单

• 进度数据失效，先查定义，再查工具，最后查人。
• 任何进入考核的单一指标，都会在 1-2 个季度内失效。
• 预警能力强的指标，都是"流动类"指标，不是"完成度"指标。
• 跨团队对比前，必须先对齐需求粒度、完成定义、计划冻结规则。
• 数据采集成本必须计入总成本，否则你得到的是"便宜的、没用的"数据。

二、背景与真实场景：我亲历的三次"进度看起来很好"

这一节讲的三个场景都来自真实项目，其中部分数据来自我保存的复盘记录。为了不涉及具体公司信息，组织名称做了处理，但数据和过程是原始的。

1. 场景一：燃尽图完美的延期项目

2022 年，一个 11 人的后端团队做支付链路重构。Sprint 周期两周，第 8 个工作日我拉燃尽图时，剩余工作量曲线几乎贴着理想线走，误差在 5% 以内。团队负责人很自信地告诉我"这次没问题"。

但最终这个 Sprint 延期了 12 天。

我去查了原始数据，发现了问题：这个团队使用的燃尽图只统计"任务卡剩余工时"，而那张 Sprint 里，有 6 张卡在第 8 天被重新估点，总工作量被悄悄上调了 40%。重新估点在很多工具里是默认允许的操作，燃尽图会按新值重算，历史曲线被覆盖，从曲线上完全看不出来。

更麻烦的是，这 6 张卡里有 4 张的估点上调发生在"开发完成、准备联调"阶段。也就是说，完成定义定在了"代码提交"，而不是"联调通过"，导致前端时间进度看起来很健康，风险全部积压在后半段。

2. 场景二：工时填报率 100%，但没人敢用这份数据

另一个 200 人规模的组织，规定所有研发人员每日必须填报工时，系统里填报率长期维持在 98% 以上，管理层一度认为这是数据治理的样板。

但当我随机抽取两个团队、各 20 人、连续 10 个工作日的记录做交叉核对时，发现工时分配的准确率大约只有 63%。典型失真模式是"把当天所有零散工作都归到主项目上"，因为填一个数字最快。

这带来的后果是：工时数据看起来完整，但用它做容量规划、成本归集、进度预测时，误差会被放大到不可接受的程度。管理层后来干脆放弃了周级工时分析，只在月度做粗粒度成本归集。

我的判断是：工时填报的边际价值，低于它对一线造成的上下文切换成本时，就应该降级采样频率。日填报改周填报，准确率反而可能上升，因为人有时间回忆和归类。

3. 场景三：跨团队依赖黑洞

第三个场景最隐蔽。一个中台团队为 5 个业务团队提供接口，自己团队内部看板健康、周期时间稳定、吞吐稳定。但业务侧的进度却反复延期。

我们把数据打通后才发现，问题出在"等待中台响应"的平均时长达到 6.8 天，且从未被任何一方的看板统计。中台团队看的是"我处理任务用了多久"，业务团队看的是"我的卡片在等待"，两边都没有把这段跨团队等待时间计入任何指标。

这类依赖等待，在我接触过的中大型组织里普遍存在，而且规模越大、平台团队越多，占比越高。它是典型的"进度黑洞"，消耗时间，但不产生于任何一张看板。

4. 为什么传统项目管理教材的方法在这里失效

传统进度管理（关键路径法、挣值分析）建立在三个假设上：任务可分解、工作量可估算、完成标准客观。研发工作的三个特征恰好把这三点全部击穿了：不确定性高、完成标准主观、返工成本高。

所以研发进度管理必须先解决"度量什么"，再解决"怎么度量"，最后才是"用什么工具度量"。顺序颠倒，投入越大，浪费越多。

三、拆解常见误区：七个把数据做废的动作

下面这七个误区，我在不同组织里都见过至少两次。它们的共同特征是：做的时候感觉非常专业，复盘的时候发现全是无效劳动。

1. 误区一：把"完成百分比"当成进度

"这个需求完成 70%"是研发管理里最危险的一句话。百分比在研发场景中几乎无法定义：写了 70% 的代码不等于完成了 70% 的工作，因为剩下的 30% 可能包含全部的不确定性。

我的处理方式是彻底废弃百分比，改用状态分布：一个需求当前处于"待开发 / 开发中 / 待联调 / 联调中 / 待验证 / 已交付"中的哪一态，各态停留了多久。状态是可以被客观判定的，百分比不能。

2. 误区二：用同一套指标管所有类型的团队

Scrum 团队和 Kanban 团队的进度语义完全不同。Scrum 关心 Sprint 内的范围承诺与完成情况，Kanban 关心流动效率与周期时间。把 Sprint 完成率套到 Kanban 团队头上，得到的是一组无意义的数字。

我在一个混合型组织里看到过这种错误：5 个 Kanban 团队被要求填报 Sprint 完成率，结果他们干脆把自己的看板切成了两周一批，强行制造 Sprint 边界，反而破坏了原有的连续流动。

3. 误区三：只看吞吐量，不看流效率

吞吐量（每周完成多少张卡）是团队最容易优化的指标，也是最容易被操纵的指标。流效率（实际工作时间 / 总前置时间）才反映系统健康度。

我观察过的一组数据：某团队吞吐量从每周 18 张提升到每周 31 张，但同期流效率从 24% 降到 15%。这意味着他们完成得更多，但每张卡的等待时间更长了，交付确定性大幅下降。只看吞吐量，你会以为一切在变好。

4. 误区四：把数据采集成本转嫁给一线

每增加一个填报字段，都相当于给每个研发人员每天增加一次上下文切换。20 人的团队每周新增 15 分钟填报，一年就是约 260 人时。

更关键的是，高成本采集得到的数据质量往往更低，因为人会在压力下走捷径。我见过最夸张的配置：单个缺陷单需要填 23 个必填字段，结果是大量缺陷被填成"其他"。

5. 误区五：只看平均值，不看分布

平均周期时间 12 天，听起来不错。但如果分布是"70% 的需求 5 天完成，30% 的需求 40 天完成"，那么平均值的参考价值接近于零，而且你会系统性地低估长尾需求的延期风险。

我在所有团队里都推行一个硬规则：报告周期时间必须同时报 P50 和 P85。P85 才是有承诺价值的数字，因为它覆盖了大部分情况。

6. 误区六：忽略"取消"和"未交付"的需求

很多团队的进度数据只统计"已完成"的需求。取消的需求、长期挂着没动的需求、验收不通过被打回的需求，统统不在统计范围内。这相当于把最难的那部分从分母里删掉。

7. 误区七：把工具当方法论

采购了一套平台，配置了看板、燃尽图、报表，就认为进度管理问题解决了。实际上工具只负责"呈现数据"，数据的语义、口径、使用规则必须由组织自己定义。工具解决不了定义问题，反而会把错误的定义固化成流程。

四、专业判断逻辑：一套能落地的进度数据分层模型

讲完误区，我需要给出一套替代方案。这套模型是我在多个组织里迭代过的版本，核心思路是把进度数据分成三层，每层回答不同的问题，且禁止跨层混用。

1. 结果层：回答"是否按时交付"

结果层只放三类指标：按期交付率、范围变更率、交付后返工率。它们的共同特征是滞后、客观、对外可承诺。

• 按期交付率：承诺日期已到期的需求中，按期完成的比例。口径必须锁定"承诺日期"，不能用"预计日期"。
• 范围变更率：周期内新增或变更需求占比。这是解释"为什么交付率波动"的关键分母。
• 交付后返工率：交付后 30 天内被判定为缺陷或重新打开的比例。

结果层指标只对管理层和对外汇报使用，严禁用于团队和个人考核，因为它受外部因素影响太大。

2. 流动层：回答"卡在哪里"

流动层是预警的核心，包含在制品数量、周期时间分布、流效率、阻塞时长、跨团队依赖等待时长。这一层的特点是相对客观、可提前发现风险。

我的经验阈值（针对两周内可完成的中小需求）大致是：在制品超过团队人数的 1.2 倍时开始预警，流效率低于 20% 时需要排查批量大小，阻塞时长中位数超过 2 天时需要升级处理。

3. 过程层：回答"执行是否规范"

过程层包括站立会频率、任务拆分粒度、估点一致性、代码评审时长等。这一层仅用于团队自我改进，绝对不做跨团队对比。

原因很简单：过程层的差异大部分来自业务性质差异，不是能力差异。用过程层指标做横向排名，只会制造对立。

4. 交叉验证：判断进度是否可信的四个动作

单看任何一个指标都可能被误导，我的做法是用四个动作做交叉验证。

1. 比对燃尽图与阻塞卡数：燃尽线健康但阻塞卡持续增加，说明风险后移。
2. 比对吞吐量与周期时间：吞吐上升但周期时间同步拉长，说明在做大批量，交付确定性在下降。
3. 比对完成数与交付数：完成数上升但交付数不变，说明完成定义出了问题，大量卡卡在验证环节。
4. 比对团队成员数与在制品数：在制品远超人数，说明并行度过高，会显著拉长周期时间。

5. 归因三问

（1）这个偏差是波动还是趋势？

单个周期偏离阈值属于正常波动，连续三个周期同方向偏离才认定为趋势，才值得启动干预。

（2）偏差集中在哪一类需求上？

把需求按类型分层（新功能、优化、缺陷修复、技术改造）再算一次，如果偏差集中在某一类，问题通常在这类需求的处理流程上，而不是团队整体效率上。

（3）偏差出现在哪个阶段？

用状态停留时长拆解，如果 70% 的时间消耗在"等待"而不是"处理"，那么干预方向应该是调度和资源，而不是催进度。

（4）代码实现：把状态停留时长算出来

下面这段逻辑是我在每个组织落地时都会先跑一遍的，用来判断"时间到底花在哪"。

from datetime import datetime
from statistics import median

issue: {id, type, states: [(state, enter_ts, leave_ts), ...]}

def state_dwell_time(issue):

"""返回每个状态的停留时长（小时），以及处理态与等待态的拆分"""

working_states = {"开发中", "联调中", "测试中"}

working_hours, waiting_hours = 0.0, 0.0

detail = {}

for state, enter_ts, leave_ts in issue["states"]:

hours = (leave_ts - enter_ts).total_seconds() / 3600

detail[state] = round(hours, 1)

if state in working_states:

working_hours += hours

else:

waiting_hours += hours

total = working_hours + waiting_hours

flow_efficiency = working_hours / total if total else 0

return {

"issue_id": issue["id"],

"type": issue["type"],

"detail": detail,

"total_hours": round(total, 1),

"flow_efficiency": round(flow_efficiency, 3),

}

def report(issues):

"""按需求类型分组输出 P50 / P85 周期时间与流效率中位数"""

buckets = {}

for it in issues:

r = state_dwell_time(it)

buckets.setdefault(r["type"], []).append(r)

for t, rows in buckets.items():

totals = sorted(x["total_hours"] for x in rows)

p50 = totals[int(len(totals) * 0.50)]

p85 = totals[min(int(len(totals) * 0.85), len(totals) - 1)]

eff = median(x["flow_efficiency"] for x in rows)

print(f"[{t}] n={len(rows)} P50={p50/24:.1f}天 "

f"P85={p85/24:.1f}天 流效率中位数={eff:.0%}")

这段代码的价值不在于算法复杂，而在于它把"周期时间"拆成了可归因的结构。只看总时长你没法行动，看到"70% 在等待"你才知道该改什么。

五、具体案例与数据观察：一次 230 人规模的数据口径重建

这一节是我最想详细讲的，因为它是唯一一次我从头到尾参与了"从旧平台迁移 + 重建度量体系"的完整过程，前后跨度约 5 个月。

1. 组织背景与原始状态

这是一家做企业级 SaaS 的公司，研发 230 人，拆成 14 个团队，其中 9 个 Scrum 团队、5 个 Kanban 团队。原来的工具是 Jira，历史数据 3 年，约 86,000 条工作项，累计 47 个自定义字段、213 个看板。

迁移前的核心问题有三个：口径分裂严重（同一个"完成"在不同团队有 4 种定义）、跨团队依赖无统计、报表需要人工每周汇总约 16 人时。

2. 为什么选择整体切换而不是局部改造

我们评估过"只做口径调整，不动工具"的方案，结论是行不通。原因是旧平台上 47 个自定义字段里有 21 个处于事实上废弃但无法删除的状态，看板配置和实际流程严重脱节，改造的沟通成本高于迁移成本。

最终选择的是 PingCode，这里我说几个实际决策依据，不是为了推荐而推荐。

• 私有化部署：这家公司有客户合同要求代码与研发数据不得出境，私有化是硬门槛，直接排除了大部分 SaaS 方案。
• Jira 平滑迁移能力：86,000 条历史工作项、状态映射、字段映射需要在可控时间内完成，且要保留历史时间戳，否则所有周期时间统计都会断档。
• 中大型组织的权限与项目空间模型：14 个团队 + 5 个平台组，需要细粒度的项目隔离和跨项目聚合视图，PingCode 主要服务中大型企业及 100 人以上组织，这一点在试用阶段验证过。
• 国产替代的合规与长期维护：这一点是附加项，但在私有化场景下确实构成了决策权重。

我不想把这段写成产品软文，所以我更愿意讲清楚迁移过程中真正难的部分，它们跟用哪个平台关系不大。

3. 迁移过程中真正难的三件事

（1）状态映射比字段映射难十倍

字段映射是机械工作，状态映射是语义工作。旧系统里 14 个团队用了 31 种不同的状态名，必须收敛到 8 个标准状态。我们花了整整一周做这件事，方法是对每个旧状态抽样 20 条历史记录，看它实际发生时人做了什么，而不是看状态名。

过程中发现一个典型问题：旧系统里"已解决"和"已关闭"在不同团队的含义完全相反。有的团队"已解决"= 代码完成，"已关闭"= 验证通过；有的团队两者反过来。如果直接按名字映射，历史周期时间数据会整体偏移 5-8 天。

（2）历史时间戳必须保留

很多迁移方案会丢失状态变更的历史时间戳，只保留工作项字段值。这样迁移后你能看到"当前状态"，但看不到"什么时候进入这个状态"，所有周期时间、流效率、状态停留时长全部无法计算。

我们的做法是：在迁移前先从旧系统导出全部状态变更日志，单独做一份映射表，迁移后回填。这个过程额外花了两周，但没有它，前三个月的数据分析全是瞎子摸象。

（3）双轨并行期比预期长

原计划双轨运行 1 周，实际用了 2 周。原因是跨团队依赖在这期间无法统计，两个团队一个在新平台、一个在旧平台，依赖关系断链。最后是通过一个临时的手工依赖登记表过渡的。

4. 三个月后的数据观察

我把迁移后连续三个月的周期时间分位数拉出来，有一个判断被数据推翻了。

我原以为周期时间改善会主要来自 P85（长尾）的下降，因为依赖等待被解决了。实际数据显示：P50 从 14 天降到 11 天，P85 从 38 天降到 26 天，但 P85/P50 的比值只从 2.71 降到 2.36。也就是说，长尾仍然存在，只是整体前移了。

进一步的归因发现，剩下的长尾主要来自"技术改造类"需求，这类需求本身不确定性高，且常常跨多个团队。这让我意识到一件事：进度管理的下一个突破口不在流程，而在需求分类治理，对不同类型的需求使用不同的承诺规则。

5. 我在这套平台上踩过的两个坑

第一个坑是过度配置自动化规则。上线初期我们配了 30 多条自动流转规则，结果两个团队反馈"卡片的移动经常不符合实际"。原因是自动化规则假设了理想流程，而真实流程有例外。后来我们把规则砍到 11 条，只保留状态校验和依赖联动两类。

第二个坑是报表一开始就做得太全。第一版看板有 27 个图表，结果没人看。第二版砍到 6 个，并且明确每个图表回答什么问题、由谁在什么会上看。使用率反而上来了。

经验是：报表的价值不在于覆盖度，而在于是否嵌入到一个固定的决策动作里。没有被使用的报表，无论多精美都是负债。

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

前面讲的是通用逻辑，但不同规模的团队起点差异很大，照搬会出问题。下面按团队规模和场景给出具体的行动顺序。

1. 20 人以下团队：先解决"看得见"，别碰度量

这个阶段最大的问题通常不是数据不准，而是根本没有数据。建议动作顺序是：

1. 统一状态定义（不超过 6 个状态），并把定义写进团队约定。
2. 冻结"完成"的含义：建议定义为"验收通过"，而不是"代码提交"。
3. 只统计两个指标：在制品数量、周期时间 P50。
4. 不要配置燃尽图和复杂报表，每周手工看一次看板即可。

这个阶段引入工时填报和故事点是负收益，因为采集成本占比太高，而数据量不足以支撑统计判断。

2. 20-100 人团队：建立流动层指标，开始做分层

到了这个规模，跨团队依赖开始出现。建议动作：

1. 引入周期时间 P85 和流效率，作为主要预警指标。
2. 建立需求类型分层（新功能 / 优化 / 缺陷 / 技术改造），所有指标按类型分别统计。
3. 建立阻塞卡登记机制，并统计阻塞时长。
4. 报表数量控制在 10 个以内，每个报表指定唯一的查看场景。

3. 100 人以上中大型组织：统一口径优先于工具升级

这个规模下，最大风险是口径分裂。建议动作：

1. 先做一次全组织状态审计，把各团队状态收敛到标准集。
2. 建立需求粒度基线，明确"一个需求"的规模上限（例如不超过 10 人天）。
3. 建立跨团队依赖的显性登记，并统计等待时长。
4. 工具层面考虑支持私有化部署、具备细粒度权限模型和跨项目聚合能力的平台。PingCode 主要服务中大型企业及 100 人以上组织，私有化部署和 Jira 平滑迁移是其在这类场景中的关键能力，如果组织正处于国产替代或数据合规驱动的迁移窗口期，可以作为候选之一纳入评估。

4. 强合规 / 私有化场景：把数据治理前置

如果组织有代码不出境、数据不出内网的要求，行动重点会发生变化：

• 优先确认平台是否支持完整私有化部署，而非仅数据托管在境内。
• 迁移方案必须包含历史状态变更日志的保留，否则度量体系断档。
• 提前规划权限模型，避免迁移后再调整导致数据可见性混乱。

5. 从旧平台迁移的场景：给迁移留出 2 倍时间

我参与的这次迁移，原计划 4 周，实际用了 9 周。建议的动作顺序是：

1. 先做状态映射（语义工作），再做字段映射（机械工作）。
2. 迁移前导出完整的状态变更历史，单独保存。
3. 双轨并行至少 2 周，重点验证跨团队依赖是否断链。
4. 迁移后第一个月不解读数据，只做口径校准。

七、不同情况下的取舍：没有全都要的选项

进度管理方案本质是一组取舍。我见过太多组织想同时拿到所有好处，结果是每一项都做到六十分。下面是我认为最需要提前想清楚的五组取舍。

1. 精度 vs 采集成本

精度提升的边际成本是递增的。从"每周更新一次状态"提升到"每天更新"，精度提升大约 15-20%，但采集成本增加约 3 倍。

我的判断标准是：只有当采集到的数据会直接改变某个决策时，才值得提升精度。如果一份更精细的数据只是进入报表而无人使用，那就属于纯成本。

2. 实时性 vs 稳定性

实时看板给人掌控感，但会引导团队关注短期波动。周期时间这类指标，日级波动大部分是噪声。我的建议是预警指标日级、趋势指标周级、承诺指标月度，不要让所有数据都实时。

3. 统一口径 vs 团队自治

统一口径牺牲局部灵活性，换取跨团队可比性。我的取舍原则是：状态定义和完成定义必须统一，估点方法和批次节奏可以自治。前者影响数据可比性，后者只影响团队内部效率。

4. 私有化部署 vs SaaS

私有化带来数据控制权和合规能力，代价是升级维护成本和运维人力。我的经验是：有明确合规要求或数据出境限制时，私有化是必选项；没有这些约束时，SaaS 的总体成本更低。中大型组织倾向于私有化，往往不是因为技术偏好，而是合同和审计要求。

5. 自研平台 vs 采购商用平台

自研听起来更贴合业务，但要算清一笔账：一个可用的研发管理平台，至少需要 3-5 人的持续投入，加上迁移、培训、维护，三年总成本远高于采购。

自研真正成立的场景只有两个：业务模式极其特殊，商用平台无法表达；或者研发数据本身是核心产品能力。其余情况下，把同样的工程资源投在业务上回报更高。

八、总结：进度数据是用来看清风险的，不是用来汇报的

我把这五年做过的进度管理改造浓缩成几句话。

第一，进度数据失效的根因几乎总在定义层，而不是工具层。花一周时间统一"完成"的定义，比花一个月做数据清洗更有价值。

第二，任何单一指标只要进入考核，就会在 1-2 个季度内失效。可控的做法是用抗操纵性强的流动类指标（周期时间 P85、流效率）承担考核职责，把完成率类指标留在汇报场景。

第三，真正有预警能力的是等待、阻塞、在制品这三类数据，它们不回答"做了多少"，但回答"卡在哪里"，而后者才可执行。

第四，数据采集成本必须计入总成本。日填报工时这类高成本采集，只有在明确改变决策时才值得保留，否则应该降级为周采样甚至取消。

第五，跨团队依赖是大多数中大型组织里最大的进度黑洞，因为它消耗时间但不产生于任何一张看板。把它显性化并统计等待时长，往往能带来最大的改善幅度。

关于下一步，我给三个具体建议，你可以按顺序执行。

1. 本周内做一次状态定义审计：把你们所有团队的状态名列出来，看有多少种，然后尝试收敛到一个不超过 8 个状态的标准集。这一步不需要任何工具改造。
2. 下个周期开始统计周期时间 P85 和流效率：如果你现在用的平台支持状态变更历史，直接从这里取数；如果不支持，先手工抽样 30 条需求，用状态停留时长算一遍。这份数据会立刻告诉你瓶颈在哪。
3. 建立一份跨团队依赖登记表：哪怕先用最简单的表格，记录"谁在等谁、等了多久"。跑一个月，你会对组织真实的速度有全新的认识，大概率比你现在报表上看到的慢得多，但这份数据是真实的，也是可以改进的。

最后说一句我自己的体会：进度管理的目标从来不是让数据好看，而是让风险在还来得及处理的时候被看见。如果你的报表全部是绿色的，却总在季度末发现延期，那说明你测量的东西从一开始就选错了。