去年第三季度，我接手了一个横跨研发、供应链、财务、客服四个部门的系统切换项目。预算 280 万元，计划 14 周上线，参与人数峰值 37 人，外部还挂着 3 家供应商。上线前 12 天，我在一次例行对齐会上问了一个看似多余的问题：”当前这个阶段，还差哪三件事才算真正完成？”会议室里 9 个人，给出了 6 个不同的答案。
那一刻我确认了一件事：跨部门项目的阶段效率问题，绝大多数不是执行力问题，而是阶段边界没有被定义清楚。后来我把这个项目完整复盘了一遍，把踩过的坑和验证有效的做法整理成了一套清单，并在此后 6 个跨部门项目上复用，阶段周期平均压缩了 23%。这篇文章就是那套方法的完整拆解。
一、先给结论：阶段任务管理真正管的不是任务，而是阶段交接
1. 三个反常识结论
先说结论，再展开论证。第一，跨部门项目的阶段效率损耗，绝大多数发生在阶段与阶段的交接处，而不是阶段内部。大多数团队把精力花在”阶段内怎么干得更快”，但真正吞掉时间的是”上一个阶段到底交出了什么、下一个阶段到底能不能接得住”。
第二，阶段任务的粒度不是越细越好，而是要与”可验证的交付物”对齐。我见过一个团队把”需求评审”拆成 14 个子任务，结果子任务全部关闭了，但需求文档里仍然有 7 处未定义字段。任务清单的完成，不等于阶段目标的完成。
第三，跨部门阶段效率提升，工具只能贡献约三成，剩下七成来自出口准则和唯一责任人机制。这个比例不是拍脑袋得出的，我在后文的案例里会给出改造前后的完整数据对比。
2. 阶段效率可以被量化的四个抓手
如果一个管理动作不能被度量，它很快就会退化成口号。我在实践中只保留四个抓手，多了团队维护不住。
- 阶段出口准则达成率：本阶段所有出口检查项中，在评审时一次通过的比例。
- 交接返工次数：下游阶段因上游交付物不合规而退回的次数，按阶段统计。
- 阶段周期偏差率：实际阶段周期与计划周期的偏差百分比。
- 跨部门等待时长：任务处于”等待其他部门输入”状态的累计时长，这是最容易被忽视、但杀伤力最大的指标。
3. 这套方法不适合谁
必须说清楚边界。如果你的团队是 5 人以下的单一职能小组，阶段任务管理这套东西会明显过度设计。成员之间靠即时通讯和每日站会就能完成同步，硬上阶段出口准则只会增加填表负担。
如果你做的是纯探索性研究项目，阶段目标本身就在不停变化，那么强出口准则也会失效，这时候应该用”时间盒 + 假设验证”代替”阶段出口评审”。这套方法真正发挥价值的场景是：跨 3 个以上部门、周期超过 8 周、交付物需要多方验收的项目。
二、背景与真实场景：跨部门项目的阶段为什么必然卡顿
1. 一个 14 周项目的完整复盘
回到开头那个系统切换项目。项目结项后，我把 14 周的日志、任务状态变更记录、会议纪要全部拉出来做了一次时间回溯，结果相当扎心。
计划 14 周，实际用了 19 周，超期 5 周。这 5 周里，真正因为技术难题导致的延误只有 4 天。其余时间去了哪里？11 天消耗在”上游交付物不合规被退回”，9 天消耗在”跨部门等待一个本该 2 天内给出的确认”，7 天消耗在”阶段评审会上才发现某部门的验收口径和另外两个部门不一致”。
这三件事有一个共同点：它们都不发生在阶段内部，而发生在阶段与阶段的接缝上。
2. 阶段交接处的三种信息损耗
我把这些接缝上的损耗归成三类，后来的每个项目我都按这三类去排查。
第一类是语义损耗。“数据迁移完成”这句话，研发的理解是”脚本跑通了”，供应链的理解是”历史台账能在新系统里查到”，财务的理解是”期初余额和总账对得上”。同一句话，三种验收标准，评审会上必然吵架。
第二类是责任损耗。跨部门任务最常见的状态不是”未开始”，而是”进行中但实际停滞”。因为每个部门都认为这事主责在对方，于是任务在系统里挂着，没人真正推进。
第三类是节奏损耗。研发是两周一个迭代，财务是每月结账周期，供应链是按订单节奏走。三种节奏叠加在一起，如果没有明确的阶段时间盒约束，项目就会自动向最慢的那条节奏对齐。
3. 为什么”加人加会”救不了阶段效率
项目超期后，最容易做出的两个动作是加人和加会。我在这个项目上也犯了同样的错误，结果是反效果的。
参与人数从 28 人加到 37 人之后，跨部门协调会议从每周 2 次增加到每周 5 次，单次时长从 45 分钟拉长到 90 分钟。会议时长增加了 400%，但阶段出口准则达成率只从 58% 提升到 63%，几乎可以视为噪声。
原因很简单：会议同步的是”状态”，而阶段卡顿的根因是”标准”。状态可以天天同步，标准如果不明确，同步一万次也不会自动收敛。
4. 阶段延误原因的帕累托分布
我把这个项目以及后续 6 个项目共 128 次阶段延误事件做了归因统计，结果符合典型的帕累托分布：前三类原因占据了绝大多数延误。
三、拆解八个常见误区
1. 误区一：把阶段等同于甘特图上的一段时间
甘特图上的阶段是一条色块，有开始时间和结束时间。但真实的阶段应该是一个”状态机”，有明确的入口条件和出口条件。
判断标准很简单：如果你无法用一段不带形容词的话描述”什么情况下这个阶段算完成”，那这个阶段就还只是时间块，不是管理单元。比如”设计阶段完成”是无效的；”设计阶段完成 = 架构评审通过 + 接口文档发布且被 3 个下游部门签字确认 + 关键性能指标在测试环境验证通过”才是有效的。
2. 误区二：用会议同步代替阶段出口准则
很多团队觉得”我们每周都开会同步，信息很透明”。但会议同步的是当下状态，出口准则约束的是交付质量，两者解决的不是同一个问题。
我做过一个对照：同一个组织内的两个项目组，A 组每周 3 次同步会无出口准则，B 组每周 1 次同步会加明确出口准则。12 周后 A 组的阶段返工次数是 17 次，B 组是 5 次。会议数量更少的 B 组，阶段质量反而更好。
3. 误区三：阶段评审变成签字仪式
阶段评审一旦变成”大家看一眼 PPT 然后签字”，它就失去了全部价值。有效的阶段评审必须有一个硬动作：逐条核对出口准则，任何一条不通过就明确给出”不通过 + 补齐时限 + 责任人”。
我在项目上推行过一个”三不原则”：出口准则未逐条核对不通过评审、不通过项没有责任人和时限不结束会议、连续两次不通过必须升级到项目决策层。执行之后，评审会的平均时长反而缩短了，因为大家不再泛泛讨论。
4. 误区四：任务拆得越细越好
任务拆解有一个容易忽略的反向效应：粒度越细，任务之间的依赖关系数量呈非线性增长，协调成本会迅速超过执行收益。一个阶段拆成 10 个任务时依赖关系可能是 12 条，拆成 40 个任务时依赖关系可能超过 90 条。
我在三个项目上做过粒度对照，结论是：当一个任务的预估工时低于 4 小时，它对阶段目标的贡献就很难被验证，反而容易制造”看起来很忙”的假象。
5. 误区五：跨部门任务的责任人越多越安全
“这个任务研发、产品、测试都参与，大家都负责。”这句话听起来很稳妥，实际是灾难的开始。多人负责等于无人负责，这在跨部门场景下是必然规律。
我的做法是每个阶段任务只设一个唯一责任人，其余为协作人。责任人对交付物的完整性负责，协作人对各自的输入部分负责。如果一件事真的需要两个部门共同担责，那就拆成两个任务，用依赖关系连接，而不是塞进一个任务里。
6. 误区六：工具上线等于管理升级
这是我在多个中大型企业里反复看到的现象：采购了一套项目管理平台，全员培训，账号开通，然后阶段效率一点没变。
工具能承载流程，但不会自动生成流程。如果出口准则没定义、责任人没唯一化、阶段边界没画清，那么把这些混乱搬到工具里，只会让混乱变得更可视化而已。顺序必须是：先定义规则，再用工具固化规则。
7. 误区七：所有阶段用同一套模板
可行性研究阶段和上线运维阶段的出口准则，绝对不应该是同一套。前者关注假设是否被验证、投入是否合理；后者关注稳定性、回滚方案、监控覆盖。
我在项目上通常把阶段分成三类：探索型阶段（输出结论和假设，允许模糊）、交付型阶段（输出可验收物，必须精确）、稳态型阶段（输出运行指标，必须可度量）。三类阶段用三套模板，评审形式也不同。
8. 误区八：只度量进度，不度量交接质量
进度百分比是最容易统计、也最容易骗人的指标。任务状态改成”已完成”，进度就是 100%，但它是否可以被下游直接使用，这个信息完全没有体现。
我建议每个阶段至少增加一个交接质量指标。最简单可落地的做法是”下游一次接收通过率”，即下游阶段第一次收到交付物就直接接受、无需退回的比例。这个数字一旦被统计出来，团队的行为会立刻发生变化。
四、专业判断逻辑：阶段任务管理的四层模型
1. 第一层：阶段边界，用入口准则和出口准则锁定
这是最底层、也是投入产出比最高的一层。每个阶段必须写清两件事：进入这个阶段需要满足什么，离开这个阶段需要交付什么。
出口准则的写法有一个硬要求：每条准则都必须是可验证的，不能包含”完善””优化””基本完成”这类词。如果一条准则无法用”是/否”来判定，它就等于没有。
2. 第二层：任务粒度与依赖结构
在边界清晰之后，才轮到任务拆解。我的经验区间是：阶段任务的平均粒度控制在 4 到 16 小时之间，跨部门依赖关系数量控制在任务数量的 1.5 倍以内。
超过这个比例，说明任务拆得太碎或者依赖设计不合理。这时候应该做的是合并任务或者重新划分阶段，而不是继续往工具里加任务。
3. 第三层：唯一责任人机制
唯一责任人要满足三个条件：有决策权、有资源调配权、能对交付物质量签字。如果一个人只是”名义上的负责人”但调不动资源，那他承担责任就是不公平的，协作也不会真正发生。
我在每个阶段开始时都会做一次”责任可见性检查”：把阶段出口准则逐条列出来，每条后面只写一个名字。如果某条准则后面写不出名字，或者写了两三个名字，这个阶段就先别启动。
4. 第四层：度量与反馈闭环
最上面一层是度量。但度量不是目的，反馈闭环才是。指标一旦统计出来，必须在一个固定节奏里被使用，否则很快就会失效。
我的做法是：阶段交接指标每两周在项目例会上过一遍，连续两次异常就触发一次根因分析。指标只有被用来做决策，才会被团队认真对待。
5. 判断优先级：先修边界，再修粒度，最后修工具
四层模型有一个明确的修复顺序，顺序错了会浪费大量时间。
如果阶段边界不清楚，先补出口准则；边界清楚但交付质量差，去调任务粒度和责任人；如果前两层都没问题但统计困难、协作不透明，这时候才轮到上工具。我见过太多团队反过来做：先买工具，然后困惑为什么效率没提升。
五、案例与数据观察：一家 300 人硬件企业的阶段管理改造
1. 改造前的基线状况
这家企业约 300 人，研发、硬件、供应链、质量、财务五个部门参与同一个产品迭代项目。改造前他们的状况很有代表性：三个并行项目，阶段计划全部靠项目经理手工维护在表格里，跨部门任务用邮件加微信群流转。
我拿到的基线数据是：阶段出口准则达成率 58%，跨部门任务平均等待时长 3.7 个工作日，阶段周期偏差率 +31%，缺陷逃逸到下游阶段的比例 24%。这四个数字，基本可以概括一个跨部门项目的所有痛苦。
2. 改造的三个动作
我们没有一上来就上工具，而是先做了三件事。
- 重写出口准则。把 5 个阶段的 41 条准则全部重写，去掉所有形容词，改成可判定句式，每条准则后面标注唯一的验收责任人。
- 建立阶段交接看板。把跨部门依赖关系可视化，任何一个任务进入”等待其他部门输入”状态超过 1 个工作日，自动升级提醒。
- 引入项目管理平台承载规则。前两步用表格跑了两周，规则稳定之后才迁移到工具上，让平台负责自动化流转和度量统计，而不是代替团队思考。
3. 工具选型：为什么最终选择了私有化部署的方案
这家企业的硬件研发数据涉及核心工艺参数，IT 部门明确要求数据不出内网。同时他们原本已经积累了几年的研发流程数据和大量历史任务，迁移成本必须可控。
最终他们选用了 PingCode，主要基于三点判断。第一，PingCode 支持私有化部署，数据留在企业内网，满足合规硬要求。第二，PingCode 支持从 Jira 平滑迁移，历史项目、工作项、状态流和自定义字段可以成批映射过来，避免了”重新建一遍历史”的巨大浪费。第三，PingCode 主要服务中大型企业及 100 人以上组织，在跨部门、多项目并行的场景下有相对完整的阶段与需求管理能力，作为国产替代方案是比较稳妥的选择。
需要客观说明的是，工具本身并没有解决这家企业最核心的问题。真正带来变化的是出口准则重写和责任人机制，工具的作用是让这两件事可以被稳定执行、被持续度量。
4. 迁移过程的四个关键动作
从原有工具迁移到新平台，我总结出四个必须做好的动作，缺一个都会在后期返工。
- 字段映射表先行。把原工具的所有工作项类型、状态、自定义字段列成一张表，逐项决定”映射、合并还是废弃”，不要边迁边想。
- 分批迁移，先迁一个完整阶段。不要一次性全迁。先迁一个完整阶段的全部数据，跑通一轮真实评审，确认状态流转正确后再批量执行。
- 保留历史只读区。历史项目的价值在于可追溯，不在于可编辑。迁移完成后设为只读，避免新旧数据混淆。
- 迁移后做一次数据对账。核对工作项总数、状态分布、关联关系数量三项，任何一项对不上都要回溯。
5. 出口准则的配置示例
下面是我在项目上实际使用的阶段出口准则定义片段。写成结构化格式，是为了让它既能被人阅读，也能被工具解析。
stage: 设计验证阶段
entry_criteria:
架构评审通过，评审记录已归档
关键物料供应商已完成首轮技术确认
exit_criteria:
name: 接口文档发布并确认
verification: 三个下游部门负责人在系统内完成确认操作
owner: 系统架构师
evidence: 接口文档版本号 + 确认记录
name: 关键性能指标达标
verification: 测试环境实测数据达到设计目标值 ±5%
owner: 硬件测试负责人
evidence: 测试报告 ID
name: 成本预算复核
verification: BOM 成本与立项预算偏差不超过 3%
owner: 财务成本会计
evidence: 成本复核单编号
rollback_condition:
任一 exit_criteria 连续两次评审未通过
关键物料供应商发生变更
escalation:
阶段周期偏差超过 15% 时升级至项目决策层
这份配置的关键不在于格式，而在于每一条都能被判定、都有唯一责任人、都要求留下证据。当一条准则无法被判定时，它就不是准则，只是一句愿望。
6. 12 周后的数据对比
改造执行 12 周后，我们重新采集了四项核心指标。结果比我预期的要好，但有几个数字需要谨慎解读。
需要特别说明的是缺陷逃逸比例从 24% 降到 9%，这个改善有一部分来自出口准则增加验证项，也有一部分来自下游团队变得更愿意退回不合规交付物。后者其实是文化变化，而不是流程变化，这一点在很多方法论文章里被忽略了。
7. 迁移前后的效率斜率变化
如果只看改造前后的两个点，容易高估效果。我更喜欢看斜率：改造后第 3 周、第 6 周、第 12 周的指标变化趋势，更能说明改进是否可持续。
六、不同情况下的行动建议
1. 30 人以下团队：不要上阶段管理，先做任务透明化
这个规模的团队，跨部门其实指的是两三个小组之间的协作。上完整的阶段出口准则和评审机制，收益低于成本。
建议只做一件事：把任务状态、责任人、截止时间放在一个所有人能看到的地方，并且约定每天更新一次。做到这一点，阶段效率问题基本能解决七八成。剩下的问题通常不是管理问题，而是排期冲突问题。
2. 30 到 100 人团队：出口准则加唯一责任人，两件事就够
这个规模开始出现真正的跨部门协作，但还没到需要复杂治理的程度。我的建议是抓两件事：每个阶段写清 5 到 8 条可判定的出口准则，每条准则指定唯一责任人。
不要急着引入复杂工具。先用表格或轻量看板跑通规则，规则稳定运行 4 到 6 周之后，再考虑用平台承载。这个顺序能帮你避免”工具上线了但没人用”的尴尬。
3. 100 人以上中大型企业：平台承载规则，规则先于平台
到了这个规模，靠人肉维护跨部门阶段信息基本不可能。多项目并行、多部门参与、外部供应商协同，信息量会迅速超过手工处理的极限。
这时候需要一套能承载阶段定义、依赖关系、超时提醒和度量统计的平台。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，是比较典型的国产替代选择。但请务必记住，平台负责让规则稳定运行，规则本身仍然需要你自己定义。
4. 强合规行业：把证据链当成第一等出口准则
金融、医疗、汽车电子这类行业，阶段管理的重点不是速度，而是可追溯。每一份交付物都必须能回答”谁在什么时候基于什么依据做的决定”。
我的建议是：把”证据完整性”作为所有阶段的通用出口准则，权重不低于交付质量本身。同时在工具选型上，优先考虑支持私有化部署、支持审计日志、支持字段级权限控制的方案。
5. 多供应商协作：把等待时间当成一等公民指标
外部供应商不归你管，也没法参加你的每日站会。这种场景下，跨部门等待时长会显著拉长。
我的做法是把供应商相关的等待单独建模：为每个外部依赖设置明确的”输入截止时间”和”超时升级路径”，并且把供应商响应时长单独统计，作为选型依据。连续两个阶段响应超时的供应商，在下一轮合作中应该被重新评估。
6. 紧急救火项目：砍掉流程，只保留出口准则
救火项目最忌讳的是一边赶工一边补流程。这时候应该做减法。
我的做法是：阶段数量压缩到 2 到 3 个，评审形式改为 15 分钟站会逐条核对，其他所有文档和流程一律暂停，但出口准则一条都不能少。因为救火项目最怕的不是做得慢，而是返工。
七、不同情况下的取舍
1. 强流程 vs 轻流程：用返工成本做判断
流程强度的选择不应该是偏好问题，而应该是成本问题。判断标准是：一次阶段返工的成本，是否显著高于流程执行成本。
如果一次返工意味着重新采购物料、重新做认证，成本可能是几十万元级别，那强流程是划算的。如果一次返工只是重跑一次脚本，成本两小时，那强流程就是负担。我见过太多团队用同一套流程强度去管理成本差异上百倍的两类任务。
2. 自建 vs 采购：算清三年总拥有成本
自建工具看起来省钱，实际成本被严重低估。自建的成本包括开发人力、后续维护、权限与安全、移动端适配、报表能力，以及最容易被忽略的，当业务规则变化时需要重新开发和测试的持续投入。
我的经验判断是：如果团队规模在 100 人以上、跨部门场景复杂、且没有专职的工具研发团队，采购成熟平台的总拥有成本通常更低。如果团队有强定制需求且已有平台研发能力，自建才有合理性。
3. 私有化部署 vs SaaS：合规要求是硬约束
这不是一个可以权衡的选项。如果行业监管或企业内控要求数据不出内网，那私有化部署就是硬约束，其他因素都要让位。
如果合规允许，SaaS 的初期成本和升级便利性更好。我的建议是：先由 IT 和信息安全部门出具明确的数据边界结论，再谈工具选型，不要反过来先选工具再补合规论证。后者在审计时几乎必然返工。
4. 迁移期并行 vs 一次性切换：取决于历史数据量
两套系统并行运行，好处是风险低，坏处是数据双写、状态不一致、团队精力分散。我的经验分界线是历史工作项数量。
- 历史工作项少于 5000 条：建议一次性切换，用两到三周的缓冲期完成，避免长期双写带来的混乱。
- 历史工作项在 5000 到 50000 条之间：分批迁移，按项目或按阶段切分，每批迁移后做完整对账。
- 历史工作项超过 50000 条：建议只迁近 12 到 24 个月的数据，更早的数据归档为只读快照，不做结构化迁移。
5. 度量粒度：周 vs 天，取决于阶段长度
度量频率不是越高越好。如果阶段周期是 8 周，按天度量会产生大量噪声，团队会疲于解释正常波动。
我的原则是：度量周期约为阶段周期的 1/8 到 1/4。8 周的阶段按周度量，2 周的阶段按天或隔天度量。这样既能及时发现偏差，又不会让团队陷入指标焦虑。
6. 阶段数量：多而短 vs 少而长
阶段划分得越多，控制点越密，但也意味着更多的评审成本和更多的接口。阶段划分得越少，灵活性越好，但风险暴露得越晚。
八、落地清单：可以直接照着做的 21 项动作
1. 第 1 周：定义与对齐
- 列出项目全部阶段，为每个阶段写出入口准则。
- 为每个阶段写出 5 到 8 条出口准则，删除所有不可判定的形容词。
- 为每条出口准则指定唯一验收责任人，写不出名字的准则暂缓执行。
- 把出口准则发给所有下游部门负责人，收集反对意见并当场解决。
- 确定本项目的度量指标和度量频率。
2. 第 2 到 4 周：试运行与修正
- 用一个完整阶段做试运行，全部准则走一遍真实评审。
- 记录每一处”准则含义被误解”的位置，作为下一轮修订输入。
- 建立跨部门依赖关系清单，标注每个依赖的输入方和截止时间。
- 设立等待超时提醒规则，建议阈值为 1 个工作日。
- 试运行结束后做一次规则修订，把口头共识变成书面准则。
3. 第 5 到 8 周：工具承载与推广
- 选择支持阶段定义、依赖管理、超时提醒和度量统计的平台。
- 如果涉及历史数据迁移，先做字段映射表，再分批执行。
- 迁移后核对工作项总数、状态分布、关联关系数量三项。
- 把已稳定运行的准则固化到平台中，配置自动化流转。
- 为新加入项目的成员准备一页纸的阶段规则说明。
- 培训重点放在”如何判定一条准则是否通过”，而不是工具按钮位置。
4. 第 9 到 12 周：固化与迭代
- 按约定频率采集四项核心指标，形成趋势曲线。
- 每两周在项目例会上过一遍指标，连续两次异常触发根因分析。
- 把阶段评审时长、返工次数等过程指标也纳入观察。
- 复盘一次”哪条出口准则从未拦住过问题”，考虑删除，保持清单精简。
- 把验证有效的做法写进组织级模板，供后续项目直接复用。
九、总结：阶段效率的胜负手不在阶段内部
写到这里，我想把最核心的判断再强调一次。跨部门项目的阶段效率，胜负手不在阶段内部怎么干，而在阶段与阶段之间怎么交。语义损耗、责任损耗、节奏损耗这三件事，构成了绝大部分阶段延误。
第二个判断是顺序问题。先定边界，再定粒度，再定责任人，最后才上工具。这个顺序颠倒过来，投入的钱和时间大概率会变成沉没成本。我见过太多团队先花几十万采购平台，然后发现没人说得清出口准则是什么。
第三个判断是度量问题。进度百分比是给上级看的指标，交接质量才是给团队用的指标。如果你只能新增一个指标，我会选”下游一次接收通过率”。这一个数字会倒逼出口准则变得可判定，也会让责任归属自然浮现。
下一步怎么做？如果你的项目正在超期，我建议今天下午就做一件事：把当前阶段的出口准则写出来，然后拿给三个下游部门的负责人看，问他们”如果这几条都满足了，你们能不能直接开工”。如果三个人的回答不一致，你就找到了当前最大的效率漏洞，而且它今天就能被修。
如果你的团队已经在用工具但效率没变化，那就从第 1 周的清单重新走一遍，重点检查出口准则里还有没有形容词。管理方法的价值不在于它有多完整，而在于它是否能被判定、被验证、被坚持执行。
常见问题解答（FAQ）
文章包含AI辅助创作：阶段任务管理方法大全：跨部门团队项目阶段效率提升落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/333533
读者评论
唯一责任人这条我认同，但落地时卡的往往不是设不设，而是这个人有没有跨部门调资源的权限。我们只改了责任人字段，任务照样挂着，后来把阶段责任人写进各部门负责人的季度目标里才好转。管理平台里标个名字很容易，真让人动起来是另一回事。
下游一次接收通过率我用了两个迭代周期，确实管用，但前提是上游先写清验收口径，否则它很容易变成部门之间互相投诉的凭据。另外统计本身有成本，我们最后只留了交接返工次数和跨部门等待时长两项，再多没人看。
到16小时这个粒度区间在软件类项目里站得住，但涉及外部供应商的阶段基本不适用。一个送样验证光排产就等两周，任务拆得再细也压不下去。这类阶段的改进重点可能不是拆解，而是把等待时长单独拎出来管。