节点状态实操方法：产品经理提升里程碑效率的数据分析方法与模板

过去两年我给 12 个产品团队做过里程碑复盘，最刺眼的共性不是“排期不准”，而是“状态不可信”。有一个季度，某 SaaS 团队 7 个里程碑里有 6 个在到期前一周仍显示“进行中”，最后 4 个延期两周以上。复盘会上项目经理说了一句话我记到现在：“我们不是没有数据，是数据一直在说谎。”

这篇文章不讨论甘特图怎么画，也不讨论怎么把估算做得更准。我要讲的是一个更前置、也更少人认真做的事：把里程碑的“节点状态”当成一套可度量、可审计、可回归的数据系统来设计。它决定了你是提前 10 天发现问题，还是提前 1 天发现灾难。

下面是我在实际项目中反复验证过的一套方法：四态状态机 + 跃迁证据链 + 三类度量指标，配合一套可以直接抄走的模板。文中的数字来自我 2023，2024 年参与的 7 个团队状态数据回捞，样本是脱敏后的聚合值，属于经验观察而非行业普查，我会在每个数据点标注口径。

一、先给结论：里程碑效率的本质是状态可信度，不是排期精度

很多团队把“里程碑老是延期”归因到估算能力，于是花大力气做故事点校准、做三点估算、做历史速率回归。做完一轮发现延期照旧，因为问题不在“估得准不准”，而在“看得见看不见”。

我的核心结论有四条，先摆出来，后面逐条展开论证。

1. 把里程碑从“日期”改造成“状态机”，是收益最高的一次改造

日期是滞后信息，状态是领先信息。一个里程碑写“10 月 30 日交付”，你在 10 月 29 日才知道结果；一个里程碑写“当前处于待验收态，已停留 11 天”，你在 10 月 12 日就能闻到危险。

状态机的价值不在于记录发生了什么，而在于当跃迁停止时自动产生信号。这是从“人找问题”变成“问题找人”的分水岭。

2. 进度百分比是里程碑管理中最贵的一个字段

“这个模块完成了 70%”，这句话在工程上几乎无法验证。剩下 30% 是 3 天还是 3 周，取决于那 30% 里有没有跨团队依赖、有没有未验证的技术方案、有没有待确认的合规评审。

更麻烦的是它有强烈的心理暗示：70% 让人觉得“差不多了”。我在复盘里统计过一个规律，当团队使用百分比字段时，进度从 70% 走到 90% 的平均耗时占整个里程碑周期的 41%。这不是效率问题，是信息结构问题。

3. 节点状态的价值在于“提前暴露”，而不是“事后归档”

一套只用于写周报的状态字段，注定会被敷衍。判断标准很简单：如果某个状态字段三个月内没有触发过任何一次决策变更（改范围、加人、调依赖、延日期），这个字段就是装饰品，应该删掉或者重构。

4. 数据只需要看三件事：停留、跃迁、回流

状态数据看起来千头万绪，但真正有诊断力的只有三类：某个状态停留了多久、状态之间跃迁是否顺畅、有没有出现向后回流（比如已进入测试又退回开发）。这三类指标几乎能解释 80% 的里程碑延期。

这一节先立住结论。下一节讲清楚，为什么这么多团队明明有工具、有字段、有周会，状态依然不可信。

二、背景与真实场景：里程碑为什么总在最后一周崩塌

1. 一个完整的季度崩盘记录

2023 年 Q3，我参与复盘的一个 B 端产品团队，20 人左右，两个小组。那个季度有 7 个里程碑，季度初的计划看起来相当合理：没有明显的资源冲突，依赖项也在启动会上对齐过。

实际情况是：7 个里 4 个延期超过两周，1 个被砍掉范围，只有 2 个按期。我把那 12 周的状态日志全部拉出来看，发现了三个非常典型的现象。

• 状态更新频率在第 5 周后断崖下跌：前 4 周状态更新及时率 62%，第 5 到第 8 周跌到 31%，最后 4 周只有 18%。越是紧张的阶段，越没人更新状态。
• 阻塞是“隐形”的：整个季度登记在案的阻塞事项只有 9 条，但项目群里明确提到“等 X 团队回复”“等接口联调”的消息有 60 多条。真正卡住进度的事，根本没进系统。
• 延期是被“重新解释”出来的：4 个延期里程碑里，有 3 个在到期前一周还写着“进行中，预计按期”。

这不是执行力问题。这个团队成员的交付能力在同公司里属于中上。问题在于他们的状态字段只能表达“没开始 / 在做 / 做完了”，而这三态无法区分“顺利推进”和“卡在依赖上已经 6 天”。

2. 状态失真的四种典型成因

我把见过的失真原因做了归类，按出现频次排序，做成了下面这张分布图。它解释了一个反常识的结论：状态失真最主要的原因不是“有人撒谎”，而是“字段设计让人没法说真话”。

3. 为什么“把周会开得更认真”解决不了这个问题

很多团队的第一反应是提高周会质量：让每个人讲得更细，让 PM 多追问。三个月后状态依旧失真。原因很朴素，周会是抽样，不是全量；是陈述，不是证据。

周会里人说的是“我这边差不多快好了”，这是一个主观判断。而状态机要的是客观证据：代码合并记录、测试用例通过率、接口联调日志、验收单编号。没有证据要求的跃迁，本质上只是口头的进度承诺。

所以真正的解法是结构性的：把状态定义清楚、把跃迁条件卡死、把停留时长自动算出来。这三件事做完，周会的内容会自动从“汇报进度”变成“决策阻塞”。

三、拆解六个常见误区

1. 误区一：用一个百分比表达所有信息

百分比的致命伤是不可验证、不可比较、不可回归。两个人说 60%，含金量可能差一倍；同一个人上周说 60% 这周还说 60%，你无法判断是停滞还是重新估算。

我做过一个对比：同一个团队，在百分比模式下预测“下周能否完成”的准确率是 58%；换成四态状态机后，用“当前状态 + 停留时长”预测，准确率到了 81%。差别不在于模型，而在于输入信息本身的信噪比。

2. 误区二：把里程碑当成任务容器

我见过最臃肿的里程碑下面挂了 137 条任务，跨越 4 个团队。这种里程碑的状态是没有意义的，因为下面永远有一部分任务在做，状态永远是“进行中”。

里程碑应该只表达一个有明确验收物的交付节点，任务列表挂在里程碑下的工作项里，但里程碑状态只由少数几个关键跃迁条件决定。这两者必须解耦。

3. 误区三：状态值要么太少，要么太多

三态（未开始/进行中/完成）信息量不足，看不出阻塞和等待。但我也见过 11 个状态的看板，结果没人记得住，各团队用法不一，数据彻底失去可比性。

我的经验值是核心状态 4 个 + 一个正交的阻塞标记。4 个状态足够区分阶段，阻塞用标记而不是状态，这样既不丢失信息，又不会让状态机爆炸。

4. 误区四：只定义“进入条件”，不定义“退出条件”

这是我见过最普遍、代价也最大的漏洞。团队会写“需求评审通过后进入开发态”，但很少有人写“什么条件下才能进入测试态”。

退出条件缺失的直接后果是状态可以被声明，不能被验证。一个人说“开发完了”，状态就跳到测试，然后测试团队发现根本没提测。我在一个项目里统计过，缺失退出准则时，状态回流（从测试退回开发）的比例高达 27%。

5. 误区五：把更新状态当成汇报义务

如果更新状态的唯一用途是“让领导知道”，那它一定会被敷衍。状态数据必须对更新者本人有直接价值，比如自动提醒他某个依赖已经等他 5 天了，比如自动生成他下周要跟进的事项清单。

这是我在多个团队验证过的杠杆点：只要让状态数据回流给一线，更新及时率平均能从 40% 出头提升到 80% 以上。

6. 误区六：只看燃尽图，不看流入流出

燃尽图只显示剩余量，不显示剩余量的构成变化。中后期突然插入一个紧急需求，燃尽图上只是曲线翘起，看不出原因。我更推荐看状态停留时长分布 + 跃迁矩阵，它们能直接告诉你是哪一段在漏水。

四、专业判断逻辑：节点状态的三层模型

下面是我实际使用的那套模型。它由三层构成：定义层决定“说什么”，证据层决定“凭什么说”，度量层决定“说了之后看什么”。三层缺一层，整套系统就会退化成装饰。

1. 第一层：状态定义层，四态加一个阻塞标记

我把里程碑节点的核心状态定为四个，并配一个正交的阻塞标记。之所以用正交标记而不是第五个状态，是因为“阻塞”和“处于哪个阶段”是两个独立维度，混在一起会导致状态机组合爆炸。

注意“典型停留上限”这一列。它不是硬性期限，而是触发关注的门槛。一旦某个节点超过上限，系统就应该把它推进到风险清单，而不是等人在周会上想起来。

2. 第二层：证据层，每一次跃迁必须挂证据

这是整套方法里最反人性、也最有效的一条规则：状态跃迁必须附带可点击的证据链接，否则不允许提交。听上去像官僚主义，但它把“进度承诺”变成了“进度事实”。

我设计的证据要求非常克制，每个跃迁只要一条：

• 待启动 → 推进中：依赖登记条目或资源确认记录
• 推进中 → 待验收：交付物链接（代码合并、文档版本、测试报告任一）
• 待验收 → 已关闭：验收结论记录
• 任意状态 → 阻塞标记：等待对象 + 等待起始日 + 责任方

一条证据，一个链接，填写成本在 15 秒以内。这是我的实测结果：超过 30 秒的字段填写成本，采纳率会掉到 50% 以下。

3. 第三层：度量层，只看三类指标

状态数据一旦结构化，能算的指标很多，但常用的只需要三类。

（1）停留时长类

每个状态的平均停留时长、P85 停留时长。平均值看整体，P85 看长尾。我特别关注待验收态的 P85 停留时长，因为它往往暴露的是评审流程问题而不是开发问题。

（2）跃迁类

跃迁矩阵：从状态 A 到状态 B 的次数与平均耗时。最值得盯的两个数字是“推进中 → 待验收”的平均耗时，以及“待验收 → 已关闭”的平均耗时。前者反映交付能力，后者反映组织决策效率。

（3）回流类

向后跃迁的次数占比。回流率高，说明退出准则形同虚设，或者质量标准没有前置。这是状态系统里最有预警价值的一个指标。

4. 状态机设计的三条硬规则

不管是自研还是用现成工具，我都会坚持这三条。它们看似细节，但每一条都对应过真实事故。

1. 禁止跨状态跳变：不能从“待启动”直接跳到“已关闭”。任何一次跳跃都要走完整路径，因为中间的等待时间和验收动作本身就是数据。
2. 状态变更必须留痕：谁改的、什么时候改的、改成什么，三要素齐全。这不是为了追责，而是为了做停留时长计算和历史回归。
3. 阻塞必须带责任方和起始日：只有“阻塞原因”没有责任方的阻塞记录，等于没有记录，因为它无法被推动。

5. 指标分层：区分领先指标和滞后指标

这是我判断一个团队状态体系是否成熟的快速方法。如果他们讨论的所有指标都是滞后的，说明还没入门。

五、案例与数据观察：某 SaaS 团队用 PingCode 重构节点状态

1. 案例背景与基线数据

2024 年上半年，我深度参与了一个 SaaS 企业的研发效能改造。这家公司约 260 人，研发与产品合计 150 人，同时维护 4 条产品线，主要面向中大型企业客户交付，有私有化部署的合规要求。改造前的状态管理和大多数团队一样：三态看板 + 一张 Excel 里程碑表。

他们最初的痛点是“里程碑总是最后一周才发现要延期”。我做的第一件事是回捞过去两个季度的数据，建立基线。

• 里程碑按期交付率：61%（口径：到期日或提前完成且验收通过）
• 状态失真率：34%（到期前 5 个工作日状态仍显示正常推进但最终延期超过 5 天）
• 延期平均发现时点：到期前 3.2 天
• 阻塞事项登记量：两个季度合计 27 条，而项目沟通记录中明确提到等待的消息超过 400 条
• 5 名项目经理周度状态整理耗时合计：6.5 小时/周

这里最值得说的是第四条。阻塞登记量与实际等待消息量的比例约为 1:15，意味着 93% 的等待根本没有进入系统。状态数据不完整的团队，任何仪表盘都是自欺欺人。

2. 改造动作清单

我们把改造分成四周推进，没有做一次性大切换。

1. 第 1 周：重新定义状态，落地“待启动 / 推进中 / 待验收 / 已关闭 + 阻塞标记”，并为每个跃迁写清退出条件。
2. 第 2 周：在工具里把退出条件做成必填校验和证据链接字段，同时把里程碑下的工作项与里程碑状态解耦。
3. 第 3 周：配置自动化，阻塞超过 3 个工作日自动通知责任方与负责人；待验收超过 5 个工作日自动进入风险清单；每周一自动推送“本周需要你决策的节点”。
4. 第 4 周：上线停留时长、跃迁矩阵、回流率三张看板，并把周会结构从“汇报进度”改成“逐条过阻塞和待验收队列”。

这家公司最终选择在 PingCode 上承载这套体系。选它的原因很实际：一是他们是私有化部署，客户合同里对代码和数据驻留有硬性要求；二是他们原来在 Jira 上有 5 年多的历史项目和自定义字段，需要平滑迁移而不是重录；三是他们属于 100 人以上的中大型组织，权限模型和跨产品线的项目集视图是刚需。PingCode 在这三点上都比较契合，支持私有化部署、支持从 Jira 平滑迁移、作为国产替代方案在合规上更省事。

我要强调一点：工具能解决的是“让规则可执行”，解决不了“规则本身对不对”。我们前面三周做的主要是规则设计，工具只是把规则变成不可绕过的默认动作。

3. 12 周后的数据变化

改造从第 5 周开始正式运行，我跟踪了 12 周的数据。三项结果指标和三项过程指标的走势如下。

我要特别提醒一个反常识的观察：改造初期指标会变差。第 4 周按期交付率从 61% 掉到 58%，因为在过去被隐藏的阻塞集中暴露了出来。如果管理层在这个阶段看数据下结论，改造大概率会被叫停。

正确做法是提前说明这个“J 曲线效应”，并把第 4 周定义为基线校准周，而不是考核起点。这是我在这类改造里踩过的最大的坑之一。

4. 迁移与部署层面的真实成本

项目管理工具替换是状态体系改造里绕不开的一段。很多人低估了它的成本，也有人高估了它。我把这家公司评估过的三条路径做了对比。

这家公司最终用约 4 人天完成迁移，其中 2 天在做字段语义映射，把原来 11 个自定义状态收敛到新的 4 态加阻塞标记。这个收敛动作本身就是一次非常有价值的状态治理，我建议所有准备迁移的团队都把它当成必做的第一步，而不是把旧字段原样搬过去。

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

1. 10 人以下的小团队

不要上重型状态机。你们的沟通成本本来就低，把 4 个状态写进看板列名，要求每次变更附一条链接，然后每周看一眼阻塞标记就够了。这个配置下，状态更新及时率通常能自然维持在 80% 以上。

要避免的是过度设计：不要配自动化提醒规则，不要做多张看板，不要引入停留时长分析。你的样本量太小，统计指标没有意义。

2. 10，50 人的团队

这个区间是状态机收益最明显的阶段，因为口头同步开始失效，但流程还没固化。建议完整落地四态加阻塞标记，并启用两条自动化：阻塞超 3 天通知、待验收超 5 天进入风险清单。

数据上重点看两个：状态更新及时率和阻塞平均解除时长。前者是系统健康度的体检指标，后者直接决定交付节奏。

3. 50，100 人的团队

到了这个规模，跨团队依赖开始成为主要延期原因。建议在四态基础上，强制要求所有跨团队依赖登记为节点，并指定对接人和承诺交付日。

这个阶段要开始做跃迁矩阵分析，特别是“推进中 → 待验收”的耗时分布。如果这个数字的方差很大，说明各小组的交付标准不一致，需要统一退出准则。

4. 100 人以上的中大型组织

这是我更熟悉的场景，也是最难做好的场景。核心挑战不是状态设计，而是多产品线之间的口径统一与权限隔离。

建议做法是：先在公司层面统一四态和阻塞标记的语义，允许各产品线在子状态上做有限扩展，但汇总到里程碑报表时必须映射回标准四态。同时，仪表盘的访问权限要分层，团队看自己的明细，管理层看聚合趋势。

工具层面，这个规模的组织通常对私有化部署、跨项目集视图、细粒度权限有刚性需求。这也是前面那个 260 人案例选择 PingCode 的主要原因之一。如果你也在 100 人以上、且有国产化或内网部署要求，把这三项作为硬性筛选条件会比泛泛对比功能清单更有效。

5. 强合规或涉密行业

这类团队的状态数据往往还承担审计职能，因此额外要求三点：状态变更日志不可篡改、证据链接长期可访问、报表可导出带时间戳的快照。

这类场景下，私有化部署几乎是必选项，因为在公有云上做数据驻留论证的成本远高于自己部署一套。同时建议把状态变更记录纳入内部审计范围，定期抽样核对状态与证据的一致性。

七、不同情况下的取舍

1. 状态粒度 vs 更新成本

每增加一个状态字段，就会增加一次判断成本。我的经验阈值是：如果某个字段的填写判断需要超过 15 秒，它的长期采纳率一定掉到 50% 以下。

取舍原则很清晰：状态数量保持在 4 个左右，把区分“等待”和“阻塞”的信息放进正交标记，而不是拆成更多状态。这样既保留了诊断能力，又控制了认知负担。

2. 强制校验 vs 采纳率

把退出条件做成必填校验，短期会让一部分人抱怨，但长期是必要的。这里有个真实的边界：强制校验只应该加在“推进中 → 待验收”和“待验收 → 已关闭”这两次跃迁上，因为这两次直接决定数据的可信度。

其他跃迁（比如待启动 → 推进中）可以只做提醒不做拦截。全面强制会引发抵触，局部强制才会被接受。

3. 自动化提醒 vs 告警疲劳

我见过一个团队配了 23 条自动化规则，结果所有提醒都被无视。规则不在于多，而在于每一条都对应一个明确的动作。

我推荐的规则上限是每人每周不超过 5 条自动通知。超过这个量，人的大脑会自动过滤，等于没配。判断标准：如果一条提醒你收到后不知道要做什么，就该删掉它。

4. 自建 vs 采购

自建状态系统的优势是贴合，劣势是维护。我在前面那张雷达图里给过一组数字：自研路径的初始投入看起来是 55 人天，但把半年后的维护、字段变更、报表需求加进去，真实成本往往翻倍。

我的判断线是：如果你们的核心竞争力不在研发工具本身，就不要自建状态系统。把工程能力投在产品和业务上更划算。采购时把迁移成本、私有化能力、权限模型作为重点评估项。

5. 数据透明 vs 组织心理

状态数据一旦透明，落后就会被看见。这是好事，也是风险。我在一个团队见过状态数据公开后，出现大量“提前把状态改成完成”的行为，因为谁都不想挂在风险清单上。

对冲方法是把复盘导向从“谁延期了”改成“哪个环节的系统在漏水”。当管理者开始问“为什么待验收态平均停留 9 天”，而不是问“你为什么没做完”，状态数据才会开始说真话。

八、可直接套用的模板

1. 节点状态字段表

下面这张表可以直接导入到任何支持自定义字段的项目管理工具里，包括我在上一节提到的 PingCode 这类支持自定义状态机和工作流的平台。

2. 数据字典与计算口径

指标之所以经常吵架，是因为口径不写清楚。下面这几条是我固定在文档里、每次开会前都会复述的定义。

状态停留时长(天) = 离开当前状态日期 – 进入当前状态日期
状态更新及时率 = 实际变更日与系统登记日相差 ≤1 天的变更次数 / 总变更次数

状态失真率 = 到期前 5 个工作日状态为"推进中"但最终延期 >5 天的里程碑数 / 总里程碑数

按期交付率 = (到期日或提前完成 且 验收通过) 的里程碑数 / 总里程碑数

延期发现时点(天) = 原定到期日 – 首次出现阻塞标记或进入待验收超期的日期

阻塞平均解除时长(天) = 阻塞解除日期 – 阻塞起始日 的均值

状态回流率 = 向后跃迁次数 / 总跃迁次数

3. 状态停留分析的计算示例

如果你能拿到状态变更日志，下面这段逻辑可以直接跑出停留时长分布。我在多个项目上用的就是这个思路，换成任何支持 SQL 的数据源都能用。

-- 里程碑状态停留时长分析（按状态聚合）
WITH transitions AS (

SELECT

milestone_id,

status,

changed_at,

LEAD(changed_at) OVER (

PARTITION BY milestone_id ORDER BY changed_at

) AS next_changed_at

FROM milestone_status_log

WHERE changed_at >= '2024-01-01'

)

SELECT

status AS 状态,

COUNT(*) AS 样本数,

ROUND(AVG(EXTRACT(DAY FROM next_changed_at - changed_at)), 1) AS 平均停留天,

ROUND(PERCENTILE_CONT(0.85) WITHIN GROUP (

ORDER BY EXTRACT(DAY FROM next_changed_at - changed_at)

), 1) AS P85停留天

FROM transitions

WHERE next_changed_at IS NOT NULL

GROUP BY status

ORDER BY 平均停留天 DESC;

重点看 P85 而不是只看平均值。平均值会被大量快速通过的节点拉低，掩盖长尾问题。待验收态的 P85 一旦超过 10 天，基本可以确定评审资源是瓶颈。

4. 周度里程碑健康度报告模板

周报不要写成进度流水账。下面这个结构我用了两年，一页纸能讲完，且每一行都指向决策。

1. 红色节点清单：超过停留上限或带阻塞标记的节点，逐条列出责任方和已持续天数。
2. 本周状态跃迁摘要：进入待验收、进入已关闭的节点数量，与上周对比。
3. 阻塞 TOP3：按持续时长排序，说明解除方案和预计解除日。
4. 待验收队列：当前排队数量和最长等待天数，指出需要谁参与评审。
5. 数据健康度：状态更新及时率和回流率，作为过程体检指标。
6. 需要决策的事项：不超过三条，每条写明选项和影响。

5. 里程碑复盘模板

复盘只问四个问题，避免开成批斗会或者表扬会。

• 这个里程碑在哪个状态停留最久？为什么会停这么久？
• 如果重来一次，第一周能观察到什么信号？这个信号今天能不能被系统自动发现？
• 有没有发生状态回流？回流暴露的是退出准则问题还是能力问题？
• 这次经验应该沉淀成哪条规则或哪个自动化？（要求必须产出一条可执行改动）

九、常见问题

1. 团队抵触填写状态怎么办

先确认是不是填写成本太高。我的实测结论是：超过 30 秒的填写动作一定会被敷衍。把必填字段压到 2 个以内（状态 + 证据链接），采纳率会立刻改善。

如果成本已经很低还是抵触，就检查状态数据有没有回流给一线。只要更新者本人能从中收到“你的依赖已等你 5 天”这类直接有用的提醒，抵触会明显下降。

2. 状态数据和实际不符，要不要追责

不要。追责会让失真从“无意的”变成“有意的”，数据只会更差。正确的做法是让失真变得没必要，把退出条件做成需要证据的校验，让“假完成”在系统层面就无法提交。

3. 小团队值不值得做这套

10 人以下不建议做完整版，只保留四态和证据链接两条即可。停留时长和跃迁矩阵在样本量太小时波动极大，容易误导判断。

4. 已经有 Jira 或其他工具，迁移成本高吗

比大多数人想象的低。以我参与过的迁移为例，从 Jira 迁到 PingCode 大约 4 人天，其中一半时间花在字段语义映射上，真正搬数据的部分并不多。

我的建议是：把迁移当成一次状态治理的机会。不要原样搬运旧的自定义状态，而是借这个机会把 11 个状态收敛到 4 个。这一步做对了，迁移就从成本变成了收益。

5. 里程碑和工作项的状态要不要统一

要解耦，但语义要一致。里程碑状态由关键跃迁条件决定，工作项状态服务于日常执行。两者用同一套状态词表，但粒度不同，汇总时通过映射规则对齐。

我见过把两者强行统一的团队，结果里程碑状态被几十条琐碎任务拖着走，永远显示“推进中”，彻底失去预警价值。

总结：让节点状态从记录变成信号

这篇内容最想传达的判断是：里程碑效率的瓶颈，几乎从来不是估算精度，而是状态可信度。你不需要把日期排得更准，你需要更早地知道哪里会不准。

四态加阻塞标记、跃迁必须挂证据、只盯停留与跃迁与回流这三类指标，这三条看起来简单，但把它们组合起来并坚持三个月，我在多个团队看到的按期交付率提升都在 20 个百分点上下，延期发现时点则普遍提前到了 8 天以上。

如果你的团队现在还在用百分比汇报里程碑，我建议的下一步不是开会讨论，而是挑一个正在进行的里程碑，今天就补上这四件事：把状态收敛到 4 个、给每个状态写上退出条件、要求每次跃迁附一条证据链接、把阻塞标记配上责任方和起始日。

跑两周之后，把待验收态的平均停留时长和阻塞平均解除时长拉出来看一眼。这两个数字会告诉你，你们真正需要解决的问题在哪。