去年三月，我接手了一个已经延期两周的支付网关重构项目。复盘时发现一个让我后背发凉的事实：甘特图上17个里程碑里，有6个在系统里显示“进行中”，但实际已经卡了9天以上没有任何实质推进。项目经理每周一发周报，照着系统里的状态一填，管理层看到的是“整体可控”。问题不在于里程碑定得不对，而在于“节点状态”这个字段从来没有被当成一个需要设计的控制变量。
这就是我写这篇东西的原因。里程碑效率低，多数团队第一反应是“计划排得不合理”或者“人不够”，然后去买更贵的项目管理工具、上更复杂的排期模型，结果三个月后同样的延期再犯一次。真正被忽略的，是节点状态的定义、流转规则、判定标准和异常识别机制。这套东西设计得好，一个5人小组也能把里程碑命中率从60%拉到85%以上；设计得差，工具再贵也只是把错误的状态记录得更整齐而已。
一、先给结论：节点状态不是标记，是风险控制装置
我先把核心判断说清楚，后面所有内容都是围绕这几条展开的。
第一，里程碑的“状态”字段必须区分两类信息：进度事实和风险信号。大多数工具默认只给你三四个状态（未开始/进行中/已完成/已取消），这只能表达“事实”，不能表达“风险”。一个里程碑还剩3天但只完成了60%，和一个里程碑还剩3天但完成了95%，在传统状态字段里都是“进行中”，风险等级却差了一个数量级。
第二，节点状态的价值不在“记录”，而在“触发动作”。状态变化如果不能自动触发评审、升级、资源调配或范围削减，那它就是个装饰品。我见过太多团队把状态更新做成一项打卡任务，周五下午全员批量改状态，改完了没有任何人因此做任何决策。
第三，里程碑效率的本质是“偏差发现速度”，不是“执行速度”。一个团队如果能在里程碑偏差出现的第2天就识别出来，比第9天才识别出来，可用的补救手段多出至少4种（调整范围、加人、拆分、延期谈判）。发现得越晚，可选项越少，最后只剩“延期”一条路。
第四，节点状态的颗粒度要匹配里程碑的时长。一个3天的里程碑和一个3个月的里程碑，用同一套状态定义是荒谬的。短里程碑可以直接用百分比，长里程碑必须用阶段+交付物双维度。
这四条是我在十来个项目里反复验证过的。下面我把背后的真实场景和踩过的坑展开讲。
二、真实场景：状态失真为什么是系统性的
我最开始也以为状态不准是个别项目经理偷懒。直到连续跟了三个项目，把每周的状态更新记录和实际代码提交、文档产出、会议纪要做了交叉比对，才发现这是个结构性问题，跟勤快不勤快没关系。
1. 状态更新的动机被扭曲了
在一个典型的周报文化里，项目经理更新状态时面对的不是“事实是什么”，而是“这个状态写出去会引发什么反应”。
写“进行中”没人管，写“有风险”会被追问，写“延期”要写整改方案。于是理性选择就是永远写“进行中”，直到实在藏不住了再改。这不是道德问题，是激励结构问题。我统计过一个团队连续12周的里程碑状态更新，标注为“有风险”的记录只占全部更新的4.3%，但同期实际出现偏差的里程碑占比是23%。也就是说，真实的五分之四的风险从未被状态字段捕捉到。
2. 状态定义本身是模糊的
“进行中”到底是什么意思？任务已经分配了？有人开始看了？完成了30%？还是完成了80%？不同的人理解完全不同。
我做过一个小实验：让同一个项目的5个成员分别判断一个里程碑是否“进行中”。这个里程碑的情况是“接口设计文档已评审通过，后端开发尚未启动”。结果3个人选了“未开始”，2个人选了“进行中”。同一个事实，两种状态。这种模糊性在状态汇总到管理层时会被逐级放大。
3. 长里程碑缺乏中间校验点
一个跨2个月的里程碑，如果只有“未开始/进行中/已完成”三个状态，那么在它从“进行中”跳到“已完成”之前，你基本是瞎的。
我曾经负责过一个数据迁移里程碑，计划45天。前30天一切“正常”，第31天开发说“数据清洗比预想复杂”。最后延期22天。这22天不是第31天才产生的，是从第1天就在累积，只是没有任何中间节点逼着它显形。
4. 状态更新没有和时间绑定
状态字段里没有“这个状态是什么时候变成现在的”这个信息。一个里程碑显示“进行中”，你不知道它已经“进行中”了3天还是30天。没有持续时间，就没有异常检测的基础。
三、拆解误区：四种常见但错误的做法
下面这四种做法我几乎在每个项目里都能见到，它们的共同点是看起来在管状态，实际上没管住风险。
1. 用百分比表达状态
“这个任务完成80%”，这句话在项目管理里几乎是没有信息量的。首先，80%是怎么算出来的？是工时消耗了80%？还是交付物完成了80%？其次，一个任务从80%到100%往往比从0%到80%还难，剩下的20%可能包含集成、联调、验收这些高不确定性工作。
更危险的是，百分比进度会给人一种“进展平稳”的错觉。每周从50%到60%到70%，看起来很线性，实际上掩盖了后面可能存在的硬骨头。我见过一个项目连续5周报告“进度75%-85%”，第6周直接跳到“遇到重大阻塞”。
2. 状态只在周会上更新
周更的致命伤是滞后。周一开会更新状态，意味着上周四出现的偏差要到周一才被记录，再到周二才有人响应，中间损耗了5天。
对于时长在2周以内的短里程碑，5天的滞后可能占到整个里程碑周期的36%。这不是监控，这是事后悼念。
3. 所有里程碑用同一套状态定义
3天的里程碑和3个月的里程碑，风险特征完全不同。短里程碑的风险主要在“是否按时开始”，长里程碑的风险主要在“中间过程是否偏离”。用同一套状态字段，必然有一方被牺牲。
我的做法是至少分两套：短里程碑（≤2周）用“未开始/进行中/已完成/阻塞”四态，重点盯阻塞；长里程碑（>2周）用阶段制，比如“设计/开发/联调/验收”，每个阶段再叠加交付物完成度。
4. 状态更新不产生任何后续动作
最典型的浪费：花了大量精力把状态更新得很准，但状态变了之后没有任何人因此做任何事。状态从“进行中”变成“阻塞”了，没有升级机制，没有资源支持，没有范围重新评估。
状态更新的成本是真实的（每次10-20分钟，一个项目每周可能是几个小时的集体开销），如果它不触发决策，这个成本就是纯损耗。
四、专业判断逻辑：状态该怎么设计
我现在的做法是把节点状态拆成三层来设计，每一层解决不同的问题。
1. 第一层：事实状态（Where are we）
这一层只回答“当前处于哪个阶段”，不掺任何判断。我推荐用阶段制而不是百分比，因为阶段是可验证的，百分比是估算的。
一个典型的阶段集可以是：未启动 → 准备中 → 执行中 → 待验证 → 已完成。关键是每个阶段都要有明确的进入条件和退出条件。
比如“待验证”的进入条件是“所有交付物已产出且构建/编译通过”，退出条件是“验证人已签署”。这种定义让状态判断变成客观动作，而不是主观感受。
2. 第二层：健康度（How risky）
这一层独立于事实状态存在。同一个“执行中”状态，健康度可以是绿（正常）、黄（需关注）、红（需干预）。
健康度不能拍脑袋，要有计算规则。我用的是三个信号加权：
- 进度偏差：实际完成交付物数量 vs 计划应完成数量，偏差超过20%记黄，超过40%记红。
- 停滞时长：当前状态持续时间超过里程碑总时长的30%且无交付物产出，记黄。
- 依赖阻塞：该里程碑的关键前置依赖被标记为红，自动记黄。
三个信号里任意两个为黄即升红，任意一个为红即整体为红。这个规则不完美，但比人拍脑袋稳定得多。
3. 第三层：动作映射（What happens next）
这是最容易被忽略但最关键的一层。每一种状态+健康度组合，都要预先定义好触发什么动作。
比如“执行中+红”触发：24小时内召开范围评审会、48小时内产出补救方案、通知上级。“待验证+黄”触发：验证人优先级提升、并行准备验收材料。
没有动作映射的状态体系，等于没有状态体系。我甚至主张动作映射比状态定义本身更重要，因为状态定义错了顶多是信息不准，动作映射缺失则直接导致管理失效。
五、具体案例与数据观察：把状态体系落到工具里
我在这部分用一个真实项目的数据来讲，同时说明工具层面怎么落地。需要强调的是，工具只是载体，前面三层的设计才是核心。
1. 案例背景和改造前的状态
这是一个面向中大型企业的私有化部署项目，团队规模120人左右，跨6个小组，项目周期7个月，包含23个里程碑。改造前的状态管理就是典型的“周报+进行中”，23个里程碑里有14个长期停留在“进行中”，平均停滞时间11天。
第一期复盘时我们发现，这14个里程碑里有9个实际上已经出现偏差，但没有任何一个被标记为风险。管理层看到的整体进度是“按计划推进”。
2. 我们在工具里做的三件事
这个项目最终选用了 PingCode 来承载改造后的状态体系。选择它有几个具体原因：支持私有化部署（客户有数据合规要求）、支持从Jira平滑迁移（历史数据不用重录）、以及字段和自动化规则的自定义能力足够。对100人以上的组织来说，这种可配置性比开箱即用的好看界面重要得多，因为大团队的状态定义天然比小团队复杂。
第一件事：把单一状态字段拆成“阶段+健康度”两个字段。阶段用固定的5个枚举值，健康度用绿黄红三色。这两个字段分开后，一个里程碑可以处于“执行中+黄”，信息量比原来单纯一个“进行中”大得多。
第二件事：给每个阶段配置进入和退出条件。在工具里把这些条件写进字段的必填校验。比如把状态切到“待验证”时，必须填写交付物链接，否则保存失败。这个小小的强制动作，让状态更新的质量提升非常明显。
第三件事：配置自动化规则。基础规则用工具自带的自动化能力就能实现，大致逻辑如下：
规则1：停滞检测
触发条件：里程碑状态 = "执行中" AND 距离上次状态变更 > 7天 AND 无新增交付物
执行动作：健康度自动置为"黄" + 通知项目经理
规则2：依赖传导
触发条件：前置里程碑健康度 = "红"
执行动作：当前里程碑健康度自动升为"黄" + 通知当前负责人
规则3：红线升级
触发条件：里程碑健康度 = "红" AND 持续时长 > 48小时
执行动作：通知项目发起人 + 自动创建范围评审任务
这套规则跑起来之后，项目经理的状态维护耗时从每周3.2小时降到1.1小时，主要省在自动化判定和提醒上。
3. 改造后的数据变化
改造覆盖了23个里程碑中的后15个。对比前后两批数据，有几个指标变化值得说。
| 指标 | 改造前（前8个里程碑） | 改造后（后15个里程碑） | 变化 |
|---|---|---|---|
| 平均偏差识别滞后 | 8.4天 | 2.1天 | -75% |
| 里程碑按期命中率 | 62.5% | 86.7% | +24.2pp |
| 风险状态真实上报率 | 18% | 71% | +53pp |
| 项目经理状态维护耗时 | 3.2小时/周 | 1.1小时/周 | -66% |
| 平均延期天数（延期项目） | 12.6天 | 4.3天 | -66% |
需要说明的是，这个对比不是严格的对照实验，前后两批里程碑的复杂度和团队熟悉度也有差异，所以数字不应该被直接当作因果证据。但风险上报率从18%到71%这个变化，我认为主要归功于状态定义清晰化和“黄/红”不再等同于“承认失败”这件事。
4. 迁移和落地时的两个坑
第一个坑：历史数据迁移后状态对不上。原来的“进行中”迁过来之后要重新映射到新的阶段+健康度体系，这个映射规则需要在迁移前定好。我的建议是先导出全部历史状态，人工过一遍，形成映射表再迁。不要指望工具自动映射，因为原来的状态定义本身就是模糊的。
第二个坑：自动化规则上得太猛。我们一开始配了9条规则，结果通知轰炸，大家开始忽略提醒。后来砍到3条核心规则，反而有效。规则宁少勿多，每条规则都要能对应一个明确的动作。
六、不同情况下的行动建议
状态体系没有万能模板，团队规模、项目类型、工具基础不同，起步动作也应该不同。下面按四种常见情况给建议。
1. 团队小于15人，项目周期短
不要上复杂体系，会拖垮效率。建议只做两件事：把“进行中”拆成“进行中+阻塞”，并且规定阻塞状态必须在24小时内有人响应。
小团队的优势是沟通成本低，劣势是状态不透明时没有冗余机制兜底。所以重点放在“阻塞可视”上就够了。工具层面的要求也不高，能用看板区分出阻塞列即可。
2. 团队15-100人，多项目并行
这个区间是最需要状态体系的。建议上“阶段+健康度”两层结构，健康度可以先靠人工判断，但判定标准要写下来。
关键是统一所有项目的状态定义。我见过同一个部门下5个项目用5套状态命名的，汇总时完全没法看。这一步的投入产出比非常高，通常一次定义、长期受益。
3. 团队100人以上，或有强合规要求
这个规模必须考虑工具能力。字段自定义、自动化规则、权限隔离、私有化部署这几项要重点评估。
以中大型企业为服务对象的项目管理平台，通常在字段粒度和自动化配置上会比轻量工具强一些，能承载更细的状态体系。同时，私有化部署和从Jira平滑迁移这两项能力，对有历史包袱和合规要求的组织很关键，可以显著降低切换成本。国产替代场景下，这类平台也是需要纳入评估的选项。
但这个规模也要警惕另一个问题：流程过重。状态字段不是越多越好，我建议健康度的计算信号不超过4个，自动化规则不超过5条。多了之后没人看得懂，体系就死了。
4. 已经是“周报文化”的组织
这种组织改造状态体系的最大阻力不是工具，是习惯。建议从小切口开始：先选一个项目试点，把偏差识别滞后的数据做出来，用数据说服人比用理念说服人有效得多。
试点成功后，把对比数据放在部门会上讲。我自己的经验是，管理层看到“识别滞后从8天降到2天”这样的数字，比听十遍“我们要敏捷”都管用。
七、不同情况下的取舍
状态体系的每一点精确性都是用成本换来的，必须明确知道自己放弃了什么。
1. 精确度 vs 更新成本
状态字段越多、校验越严，数据越准，但每次更新的成本越高。一个5字段、带必填校验的状态更新，平均耗时是单字段的3倍左右。
我的取舍原则是：只对“会触发动作”的字段做强制校验，其他字段保持可选。健康度会触发升级和评审，所以必填且要算准；备注信息不会触发任何动作，谁爱写谁写。
2. 实时性 vs 团队负担
理想状态是实时更新，但要求全员实时更新状态等于要求大家每分钟都想着项目。这不现实，也会引发抵触。
我的做法是分层：短里程碑（≤1周）要求每日更新，长里程碑要求每周两次，关键里程碑（有强依赖或高风险）要求实时。用工具里的自动化提醒来兜底，而不是靠人记。
3. 统一标准 vs 项目差异
统一的状态定义便于汇总对比，但不同项目类型（研发、实施、数据迁移）的风险特征不同。强行统一，会让某些项目被迫使用不合适的字段。
我的取舍是统一“健康度”标准（因为要横向对比），但允许“阶段”定义按项目类型微调。健康度的三个信号是通用的，阶段命名可以不同。
4. 自动化 vs 人工判断
自动化规则稳定、不疲劳，但缺乏语境理解。一个里程碑停滞8天可能是因为在等外部审批，也可能是因为没人干活，自动化规则分辨不出来。
所以我的原则是：自动化负责“发现异常”，人负责“判断异常的性质”。健康度自动置黄只是提醒，最终是否升级为红，由项目经理确认。这样既保留了自动化的及时性，又保留了人的判断力。
八、可直接套用的状态体系模板
最后给一套我实际在用的模板，包含字段定义、健康度规则和自动化配置。可以直接复制到任何支持自定义字段的项目管理工具里。
1. 字段定义
| 字段名 | 类型 | 可选值/格式 | 是否必填 |
|---|---|---|---|
| 阶段状态 | 单选 | 未启动/准备中/执行中/待验证/已完成/已取消 | 是 |
| 健康度 | 单选 | 绿/黄/红 | 是 |
| 状态变更时间 | 日期时间 | 自动记录 | 自动 |
| 计划交付物数 | 数字 | 整数 | 是 |
| 实际交付物数 | 数字 | 整数 | 是 |
| 关键依赖 | 关联 | 关联到其他里程碑 | 否 |
| 阻塞描述 | 文本 | 自由文本 | 阶段为执行中且健康度为红时必填 |
2. 健康度计算规则
健康度优先自动计算，允许人工覆盖，但人工覆盖需要填写理由。
信号1：进度偏差率 = (计划交付物数 – 实际交付物数) / 计划交付物数
偏差率 < 20%：绿
20% ≤ 偏差率 < 40%：黄
偏差率 ≥ 40%：红
信号2：停滞时长 = 当前时间 – 状态变更时间
停滞时长 < 里程碑总时长 × 30%：绿
里程碑总时长 × 30% ≤ 停滞时长 < 里程碑总时长 × 50%：黄
停滞时长 ≥ 里程碑总时长 × 50%：红
信号3：依赖传导
所有关键依赖为绿：绿
任一关键依赖为黄：黄
任一关键依赖为红：红
综合规则：
任一信号为红 → 健康度红
两个及以上信号为黄 → 健康度红
任一信号为黄 → 健康度黄
全部为绿 → 健康度绿
3. 动作映射表
这张表是整个体系的核心，建议贴在项目看板上，让所有人知道状态变化意味着什么。
| 阶段状态 | 健康度 | 触发动作 | 责任人 | 时限 |
|---|---|---|---|---|
| 执行中 | 黄 | 项目经理核查原因并记录 | 项目经理 | 24小时 |
| 执行中 | 红 | 召开范围评审会，产出补救方案 | 项目经理+技术负责人 | 48小时 |
| 待验证 | 黄 | 提升验证人优先级，并行准备验收材料 | 验证负责人 | 24小时 |
| 待验证 | 红 | 升级至项目发起人，评估是否缩范围 | 项目发起人 | 24小时 |
| 任意阶段 | 红且持续48小时 | 通知上级，启动资源调配评估 | 项目发起人 | 48小时 |
4. 每周状态复盘清单
最后附一份我每周会过一遍的清单，只有8个问题，10分钟内能过完。
- 本周有哪些里程碑的健康度发生了变化？变化原因是什么？
- 有没有里程碑停滞超过7天没有交付物产出？
- 有没有里程碑被依赖传导为黄或红？
- 当前所有红灯里程碑的补救方案进展如何？
- 有没有里程碑的实际状态和计划状态出现结构性偏差（不是天数，是阶段）？
- 下周有没有里程碑即将到期但健康度不是绿？
- 有没有必要调整里程碑的粒度和依赖关系？
- 上一步的动作映射是否有未执行的？为什么？
这套模板我在三个不同规模的项目里用过，最小的团队12人，最大的超过200人。核心逻辑不变，只是字段和规则的复杂度按规模调整。记住一点：状态体系的目的是让偏差尽早显形并触发动作，任何不利于这个目的的复杂度都应该砍掉。
如果你现在就要开始，我建议的顺序是：先花半小时定义你们团队的阶段和健康度标准，然后挑一个正在进行的里程碑试运行一周，下周复盘时对比一下“偏差发现时间”有没有改善。不要一次性铺开全套体系，那大概率会失败。一个愿意先在一个里程碑上验证的项目经理，比一个制定了一整套完美方案却不落地的项目经理，成功率高得多。
常见问题解答（FAQ）
1. 里程碑的节点状态到底分几类，多久更新一次才有效？
我带项目时，周报里最常见的状态就是‘进行中’，直到评审前一天才发现关键依赖没交付。状态太粗，项目经理看不到风险；状态太细，团队又嫌填表麻烦。到底怎么定分类和更新频率，才能提前暴露问题？
我一般用 5 类状态，并要求状态必须绑定预测完成日期和置信度：未开始、按期推进、有风险但可控、已延期但有恢复方案、已失控需升级。不要只写‘进行中’。更新频率按风险而非按周：关键路径里程碑至少每周两次，跨团队依赖节点每个工作日由依赖接收方确认一次，非关键节点每周一次。
判断口径看三个数：预测完成日期是否晚于承诺日期、剩余工作量是否大于剩余时间、关键依赖是否已书面确认。任何一个为否，就从‘按期推进’降级。某项目管理工具里可以把状态做成受控下拉，再配一个‘状态变更原因’必填，避免随手改色。
这样做的核心不是汇报好看，而是让项目经理在里程碑到期前 5 到 10 个工作日就能决定是否加人、拆范围或升级。
2. 里程碑风险预警的红黄绿阈值怎么定，什么情况下必须升级？
我以前做预警表时，红色黄色全靠负责人感觉，结果所有人都不敢标红，最后风险都堆到我这里。尤其多团队协作时，A 团队说没问题，B 团队说等通知，到了截止日才发现谁都没动。到底阈值怎么定，升级线画在哪里？
不要用主观颜色，改成可计算阈值。绿灯：预测完成日期不晚于承诺日期，且关键依赖已确认，剩余缓冲大于总工期 15%。黄灯：预测日期晚 1 到 3 个工作日，或关键依赖未书面确认，或缓冲只剩 5% 到 15%。红灯：预测日期晚超过 3 个工作日，或关键依赖已逾期，或缓冲低于 5%，或完成标准未达成。
升级规则也要硬：红灯当天升级到项目发起人和相关职能负责人；黄灯在 2 个工作日内给出恢复方案，否则自动转红；依赖方超过 24 小时不确认，视同未承诺并升级。判断依据是‘可恢复性’而不是‘当前情绪’，即看剩余时间能否覆盖剩余工作加返工缓冲。
把阈值写进模板并在某项目管理平台里用公式字段自动算颜色，能减少扯皮。
3. 里程碑跟踪模板最少要包含哪些字段，才不会变成形式主义？
我们团队以前填过很长的项目表，字段几十个，开始两周后没人维护，最后模板变成摆设。我想要的是一张项目经理和团队都愿意每周更新的表，既能看状态又能追溯风险。到底哪些字段是必须的，哪些可以砍掉？
我的最小可用模板只保留 11 个字段：里程碑名称、完成标准、负责人、承诺日期、预测日期、状态、置信度、关键依赖、依赖确认状态、风险与恢复动作、升级对象。再加两个观察字段：上次预测日期和变更次数，用来识别反复滑期。完成标准必须可验收，比如‘通过 UAT 并签字’而不是‘开发完成’。
关键依赖要写到人和日期，不接受‘等对方提供’。风险与恢复动作要写下一步和截止时间，不能只写‘关注’。如果字段超过 15 个，通常说明你把任务管理和里程碑管理混在一起了；任务放任务板，里程碑表只做承诺与风险控制。
可以在某项目管理工具里建独立模板，设置必填项和状态变更日志，每周复盘只看预测日期和依赖确认状态的变化。
4. 怎么衡量里程碑效率有没有提升，复盘时看哪些数据？
我们开复盘会经常变成吐槽会，有人说自己团队很忙，有人说需求变更太多，但到底里程碑管理有没有变好，谁也说不清。我不想要感觉上的‘效率提升’，想要几个能对比、能向老板解释的指标。应该看哪些数据，口径怎么定？
我通常看 5 个指标，口径要提前固定。第一，里程碑准时率：承诺日期当天或之前达成完成标准的里程碑数除以到期里程碑总数，不把未到期算进去。第二，平均滑期天数：每个里程碑最后预测日期减首次承诺日期，只统计正数。第三，风险提前暴露率：在到期前 5 个工作日及以上被标黄或标红的里程碑占比。
第四，依赖按时确认率：关键依赖在约定确认日前完成书面确认的比例。第五，承诺变更次数：单个里程碑预测日期变更超过 2 次就要复盘。判断改进是否真实，不要只看准时率，因为砍范围也能提高准时率；要同时看准时率、平均滑期天数和范围变更率。
复盘时按‘数据、根因、动作、责任人、截止日’记录，下一次只验证动作是否关闭。这样里程碑效率才是可管理的，而不是会后归因于加班或态度。
文章包含AI辅助创作：节点状态实操方法：项目经理提升里程碑效率的风险控制方法与模板，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/335457
读者评论
三层设计里最关键的其实是动作映射，但落地卡点往往不在设计，而在谁有权调动资源。状态变红后24小时内开评审会，如果项目经理没有跨组调配权，会开完还是原地不动，几次之后团队就不信这套状态体系了。想请教一下，没有强矩阵授权的组织里，这一层到底怎么落？
用三个信号加权算健康度比拍脑袋稳定，这点认同。但前提是交付物颗粒度足够细，否则“计划应完成数量 vs 实际完成数量”只是另一种主观估算，还披了层客观外衣。我们之前试过类似规则，最后争议全集中在交付物怎么算“完成”上，反而多了扯皮成本。
偏差发现速度和补救手段那张图挺有说服力，但我们这类客户侧依赖多的项目，不少节点就是卡在等对方反馈，第2天发现也一样没牌可打。另外短里程碑周更确实滞后，我们改成每日站会口头过一遍状态只要5分钟，但字段还是没人维护，可能方向是减少字段而不是增加。