2024 年 3 月，我参加过一个已经延期 47 天的企业级项目复盘会。翻看里程碑台账时，会议室里出现了很尴尬的一幕：12 个里程碑，9 个标记为"已完成"，2 个"进行中"，只有 1 个明确延期。但项目整体就是落后了一个半月。这个矛盾让我重新理解了里程碑管理，大多数团队记录的是"里程碑是否被宣布完成"，而不是"里程碑是否真的达成了可交付、可验证、可承压的状态"。
这篇文章不讲里程碑的定义，也不重复甘特图怎么画。我想讲的是：在真实的项目里，里程碑为什么经常"按时完成但整体失控"，以及项目负责人到底该用什么方法，把风险从后端逼到前端。文章会给出完整的落地清单，配合我在实际项目中沉淀的判断逻辑、数据观察和取舍建议。
一、核心结论：里程碑不是进度刻度，而是风险闸门
先把结论放在最前面。如果你只记住三句话，我希望是下面这三句。
1. 里程碑的价值发生在"到达之前"，而不是"到达之时"
很多项目负责人把里程碑当成一个汇报节点：到了那一天，宣布完成，然后继续下一个。这种用法的问题在于，里程碑变成了"进度确认"，而不是"风险检查"。
真正有效的用法是：里程碑是一个强迫团队提前暴露问题的装置。它的价值 80% 发生在里程碑前的 2 到 3 周，而不是里程碑当天。如果一个里程碑在当天才被判定为失败，那它已经不是一个管理工具，而是一份事故报告。
2. "完成"必须由出口标准定义，而不是由汇报口径定义
我见过太多里程碑的"完成标准"写成这样：完成开发、完成测试、完成上线。这种描述的问题是无法验证，做到什么程度算完成？谁有权判定完成？完成的证据是什么？
可用的完成标准应该包含三个要素：可验证的交付物、可量化的验收条件、唯一的判定责任人。缺任何一个，里程碑都会变成一场口径博弈。
3. 里程碑风险控制的最小单元是"依赖关系"，不是"任务"
任务延期通常只是表面现象。更底层的风险往往来自跨团队依赖、外部输入、审批链、环境准备、第三方交付。这些依赖如果不在里程碑层面被显式管理，就会以"突然延期"的形式爆发。
所以项目负责人真正要盯的，不是每个任务有没有推迟，而是每个里程碑之前，有哪些外部条件必须提前就位。
二、真实场景：里程碑失控的四种典型剧本
下面这四种场景都是我在实际项目里反复遇到的，不是理论分类。你可以对照自己的工作看看中了几个。
1. 剧本一：演示前 3 天"还差一点点"
这是最经典的场景。里程碑前一天，团队说"还差一点点，再给两天肯定行"。于是里程碑顺延两天，两天后又顺延三天。等到真正交付时，已经过去两周。
问题不在"差一点点"，而在于"差一点点"没有被量化。差的是哪个模块、什么功能、什么数据、什么环境、什么审批？项目负责人如果不逼出这个清单，顺延就会变成常态。
我的处理方法是：当团队说"差一点点"时，必须当场回答三个问题，剩余工作项清单、每项预估工时、最晚可接受完成时间。答不上来，就不算"差一点点"，而是"状态未知"。
2. 剧本二：里程碑被拆成子里程碑稀释
有些团队为了"好看"，会把一个里程碑拆成三个子里程碑，然后宣布前两个已完成，第三个在推进。这样台账上看起来进度良好，实际风险被掩盖。
我的判断是：子里程碑可以用来管理内部节奏，但不能用来替代主干里程碑的状态判定。如果主干里程碑未达成，子里程碑完成再多也不改变整体状态。
3. 剧本三：跨团队依赖无人认领
一个里程碑需要另一个部门提供接口、数据或环境，但双方都没有把这件事写进自己的里程碑。到了需要的时候，对方说"我们排期在下个季度"。
这类问题的根源是：里程碑的归属是单团队的，但依赖是跨团队的。只在自己的里程碑里管自己的事，依赖风险永远不会被提前处理。
4. 剧本四：里程碑完成后问题才爆发
还有一种更隐蔽的情况：里程碑确实"完成"了，但完成后两周内出现严重返工、性能问题或数据异常。这时候回头看，里程碑的完成标准里根本没有覆盖这些质量维度。
这类问题的本质是完成标准只覆盖了"功能存在"，没有覆盖"质量可用"。里程碑一旦这样定义，后面的技术债、返工和信任危机就都埋下了。
三、常见误区拆解：六个听起来正确、用起来失效的做法
下面六个误区，是我在评审和复盘会上最常听到的说法。它们都有一个共同特征：听起来很对，但执行起来会失效。
1. 误区一：里程碑越多越可控
有项目负责人把里程碑细化到每两周一个，结果每个里程碑都很浅，真正的风险节点被淹没在大量"例行节点"里。
里程碑的数量应该由风险密度决定，而不是由管理频率决定。一个 12 个月的项目，主干里程碑通常控制在 6 到 10 个比较合适。再多，管理成本会超过收益。
2. 误区二：用百分比汇报里程碑状态
"这个里程碑完成了 80%"。这句话几乎没有任何管理价值，因为剩下 20% 可能是 1 天，也可能是 6 周。更糟的是，百分比会制造一种"快完成了"的错觉。
我建议用离散状态替代连续百分比：未开始、进行中、存在明确风险、已阻塞、已完成。状态切换必须由完成标准触发，而不是由感觉触发。
3. 误区三：里程碑只跟进度挂钩
很多团队的里程碑只看时间，不看质量、成本和范围。这会导致一个常见结果：为了不延期，团队压缩测试、砍掉评审、降低质量标准。
健康的里程碑应该同时挂钩四个维度：交付物、验收标准、风险状态、决策点。时间只是其中一个维度。
4. 误区四：把评审会当成风险控制
开一场里程碑评审会，不等于做了风险控制。评审会通常只回答"现在到哪了"，而不是"下一步最可能在哪里出问题"。
真正有效的评审会应该有三个输出：当前风险清单、每个风险的处理责任人和时限、需要在本次会议上升级的决策项。没有这三个输出，会议就只是汇报。
5. 误区五：里程碑延期就加班补
延期就加班，是最省事也最危险的做法。短期看进度回来了，长期看质量下降、团队疲劳、下一个里程碑更容易出问题。
我的建议是：延期发生时，先做取舍决策，再谈加班。砍范围、调顺序、延期交付、增加资源，都是选项。加班应该是最后被选中的那个，而不是第一个。
6. 误区六：里程碑只对上级汇报，不对团队透明
如果里程碑只存在于管理层的 PPT 里，团队就不会真正把它当成约束。里程碑必须对执行团队可见、可追踪、可更新，才有约束力。
四、专业判断逻辑：里程碑风险控制的四层模型
讲完误区，接下来是我在项目里实际使用的判断框架。我把它叫做"四层模型"：定义层、依赖层、预警层、恢复层。每一层解决一类风险。
1. 第一层：定义层，把"完成"写成可验证的出口标准
这是最基础也最容易被跳过的一层。每个里程碑在启动前，必须先定义清楚出口标准。
我的做法是给每个里程碑填一张简短的卡片，包含以下字段：
- 里程碑名称与目标（一句话说清业务价值）
- 可验证交付物清单（文档、代码、环境、数据、审批件）
- 验收条件（量化指标，如响应时间、通过率、覆盖率）
- 判定责任人（唯一，且有权说"不通过"）
- 不通过时的处理规则（顺延、降级、重定义）
这张卡片的重点不是格式，而是强迫团队在里程碑开始前就把"完成"讨论清楚。事后争论的成本，永远高于事前定义的成本。
2. 第二层：依赖层，把所有外部输入前置到里程碑之前
依赖层的核心动作是：对每个里程碑，列出所有必须由外部提供的东西，并倒排时间。
倒排的逻辑很简单：如果里程碑在第 N 周，那么这个里程碑依赖的外部输入，通常需要在第 N-2 周就完成。这就是我常说的"依赖前置两个时间单位"原则。
依赖清单通常包括：
- 跨团队接口或服务
- 外部数据或样本
- 环境与权限
- 审批与合规文件
- 第三方供应商交付
- 关键人员可用性
每一项都必须有明确的责任人和最晚到位时间。没有责任人的依赖，等于没有依赖。
3. 第三层：预警层，用红黄绿触发条件替代感觉判断
预警层的目标是让风险在"还能补救"的时候被识别出来。我的做法是给每个里程碑定义三个状态和触发条件：
| 状态 | 触发条件（示例） | 必做动作 |
|---|---|---|
| 绿色 | 关键路径无阻塞，依赖已到位，验收条件达成度 ≥ 80% | 按周跟踪 |
| 黄色 | 存在 1 个未解决阻塞，或依赖未到位，或验收达成度 50%，80% | 48 小时内给出恢复方案 |
| 红色 | 存在 2 个以上阻塞，或关键依赖缺失，或验收达成度 < 50% | 24 小时内升级决策 |
关键不在于颜色本身，而在于触发条件必须是可观察的事实，而不是主观感受。例如"感觉有点紧"不能作为触发条件，"依赖未到位超过 3 天"可以。
4. 第四层：恢复层，提前准备 Plan B 和决策点
恢复层是很多人忽略的一层。它的核心问题是：如果里程碑无法按原计划达成，我们怎么办？
我的做法是要求每个关键里程碑至少准备一个 Plan B，并在里程碑前两周明确决策点：在哪个时间点、由谁、依据什么信息，决定是否切换到 Plan B。
没有决策点的 Plan B，只是一份心理安慰。真正的风险控制，是提前把"切换开关"设计好。
五、案例与数据观察：1200 人制造企业的里程碑改造
下面这个案例来自我参与跟进的一家制造业客户，团队规模约 1200 人，同时并行 7 条产品线。因为合规和数据主权要求，他们需要一套支持私有化部署的项目管理平台。选型时对比了多个方案，最终选择了 PingCode，它支持私有化部署，也支持从 Jira 平滑迁移，是中大型企业做国产替代时比较务实的一个选项。
1. 改造前的状况
改造前，他们的里程碑管理有三个明显问题：
- 里程碑状态用百分比汇报，管理层看到的是"整体完成 75%"
- 跨团队依赖没有统一台账，靠邮件和会议协调
- 里程碑延期后没有决策机制，默认加班补进度
结果是：7 条产品线中，5 条在过去一年内出现过超过 30 天的延期，其中 2 条超过 60 天。
2. 改造动作
我们没有一上来就换工具，而是先做流程梳理，再落到平台上。具体动作分四步：
- 把主干里程碑从平均 26 个压缩到 9 个，去掉例行节点
- 为每个里程碑补齐出口标准卡片，明确判定责任人
- 建立跨团队依赖台账，所有依赖前置 2 周跟踪
- 在 PingCode 中配置里程碑状态机、依赖关联和自动预警规则
第四步之所以重要，是因为流程如果没有平台承载，就会在几个月后自然退化。私有化部署让他们的数据留在内网，与内部权限体系对接，也让研发团队的迁移成本明显降低，原有 Jira 的工作项结构、字段映射和迭代节奏都能比较平滑地过渡过来。
3. 改造后的数据观察
改造运行了大约两个季度，我拿到了以下对比数据。这些数据来自该企业内部的项目管理例会材料，属于小样本观察，不作为行业结论。
4. 我从中提炼的三条经验
第一，里程碑数量做减法，往往比做加法更有效。从 26 个压到 9 个之后，管理层反而更能看清真正的风险点。
第二，依赖前置是投入产出比最高的一件事。它不需要额外工具，只需要在里程碑启动时多问一句"这件事靠谁、什么时候到位"。
第三，流程必须落到平台，否则会回弹。这家客户选择私有化部署的一个现实原因是数据合规，但更大的收益是让里程碑状态、依赖关系、预警规则变成了系统里的硬约束，而不是会上的口头承诺。
六、不同情况下的行动建议
里程碑管理没有一套通用答案，团队规模、项目复杂度、合规要求不同，做法差异很大。下面按三种典型情况给出建议。
1. 情况一：10 人以下小团队，单项目推进
小团队的最大优势是沟通成本低，最大风险是"觉得不需要管理"。
我的建议是：
- 主干里程碑控制在 3 到 5 个，不要更多
- 每个里程碑只写三条出口标准，但要可验证
- 每周一次 30 分钟风险同步，重点问"下一步最可能卡在哪"
- 工具可以用最轻的，甚至一张共享表格就够
小团队的重点不是流程，而是养成"提前暴露风险"的习惯。习惯建立起来，比工具重要得多。
2. 情况二：50 到 200 人中型团队，多项目并行
这个规模是最容易出现"管理真空"的区间：靠口头协调已经不够，但重流程又会拖慢节奏。
我的建议是：
- 建立统一里程碑台账，所有项目共用一套状态定义
- 跨团队依赖必须进台账，且有唯一责任人
- 建立红黄绿预警规则，明确升级路径
- 选择支持里程碑状态机、依赖关联和自动提醒的平台
这个阶段工具开始变得必要，因为依赖关系靠人脑已经记不住。平台的作用不是增加流程，而是让已有的约定不会因为人员变动而丢失。
3. 情况三：200 人以上多项目、多产品线并行
这个规模的项目管理，本质上是"组织级风险管理"。单靠项目负责人个人能力已经不够。
我的建议是：
- 建立组织级的里程碑标准模板和评审机制
- 里程碑风险纳入季度经营视角，与资源分配挂钩
- 平台需要支持私有化部署、权限隔离和大规模数据权限管理
- 建立"里程碑健康度"指标，而非单纯看是否延期
在这个规模上，PingCode 这类面向中大型企业、支持私有化部署和复杂权限的平台会更有优势。特别是当企业需要从 Jira 做平滑迁移时，字段映射、工作流兼容和团队习惯过渡是必须考虑的工程问题，不是换个界面那么简单。
七、不同情况下的取舍
管理动作本质上都是取舍。下面三组取舍，是我在项目里被问得最多、也最容易纠结的。
1. 取舍一：里程碑数量多 vs 少
多里程碑的好处是颗粒度细，坏处是管理成本高、关键节点被稀释。少里程碑的好处是聚焦，坏处是风险窗口变大。
我的判断标准是：里程碑应该设置在"不可逆决策点"上。不可逆的节点值得设里程碑，可逆的节点用常规迭代跟踪就够了。
2. 取舍二：手工管理 vs 平台管理
手工管理的优势是启动快、成本低；劣势是容易失真、不可追溯、依赖人。平台管理的优势是状态真实、可追溯、自动化；劣势是初期配置成本高、需要培训。
我的判断标准是：当跨团队依赖超过 5 条、并行项目超过 3 个时，就应该上平台。低于这个阈值，手工可以撑住；超过这个阈值，手工一定会出问题。
3. 取舍三：严格门禁 vs 敏捷流动
严格门禁能保证质量，但可能拖慢节奏；敏捷流动能保持速度，但可能积累风险。
我的判断标准是：门禁要设在"代价高的地方"，而不是所有地方。涉及合规、数据安全、核心架构、对外承诺的里程碑，必须严格门禁；内部迭代、可回滚的实验性节点，可以放宽。
八、落地清单：项目负责人可以直接照做的 12 个动作
前面讲的是逻辑和判断，这一节给一份可以直接执行的清单。我把它按"里程碑前、中、后"三个阶段组织。
1. 里程碑前：定义与前置
- 为主干里程碑写出口标准卡片，含交付物、验收条件、判定责任人
- 把所有外部依赖列成清单，明确责任人和最晚到位时间
- 依赖倒排至少前置 2 周，写进里程碑计划
- 定义红黄绿触发条件，并让团队知晓升级路径
- 为高优先级里程碑准备 Plan B 和决策点
2. 里程碑中：跟踪与预警
- 每周更新里程碑状态，用离散状态替代百分比
- 黄色状态 48 小时内给出恢复方案，红色状态 24 小时内升级
- 定期检查依赖到位情况，未到位的立即升级
- 评审会必须有三个输出：风险清单、责任人、决策项
3. 里程碑后：复盘与固化
- 里程碑达成或失败后进行 30 分钟快速复盘
- 把本次暴露的新依赖类型补充进标准模板
- 更新健康度指标，纳入下个里程碑的预警规则
这份清单看起来不复杂，但真正能坚持执行三个月的团队并不多。里程碑管理的难点从来不是方法，而是纪律。
4. 一段可以直接复用的里程碑卡片模板
里程碑名称：支付模块上线就绪
目标：核心支付链路可在生产环境完成全流程交易
可验证交付物：
支付服务部署包 v1.0
支付链路联调报告
压测报告（峰值 2000 TPS）
安全合规评审结论
验收条件：
交易成功率 >= 99.5%
平均响应时间 安全评审无高危问题
判定责任人：技术负责人（唯一）
依赖清单：
风控服务接口（责任人：风控组，最晚到位：T-2 周）
支付渠道沙箱权限（责任人：商务组，最晚到位：T-2 周）
生产环境白名单（责任人：运维组，最晚到位：T-1 周）
Plan B：先上线灰度通道，仅开放 5% 流量，其余流量延迟 2 周切换
决策点：T-1 周周一，由项目负责人依据压测和安全评审结果决定是否切换
这张卡片的价值在于：它把模糊的"完成"变成了可检查的条目，把隐性的依赖变成了显性的责任，把被动的延期变成了主动的决策。
九、总结与下一步
回到开头那个延期 47 天的项目。它真正的失败不是某一个任务没做好，而是整个里程碑体系没有承担起"风险闸门"的职责。9 个"已完成"的里程碑，只是让管理层更晚看到真相。
我在多个项目中反复验证的一个判断是：里程碑管理做得好的团队，不是里程碑从不延期，而是问题总在还有选择的时候被提出来。这才是里程碑管理的本质价值。
如果这篇文章你只带走一件事，我希望是：从下一个里程碑开始，先写出口标准和依赖清单，再排时间。顺序反过来，风险就会一直在后端堆积。
下一步你可以这样做：挑一个正在推进的关键里程碑，用本文的卡片模板重写一遍完成标准和依赖清单；然后给团队定一个红黄绿触发规则，从本周开始跟踪。做完这两件事，你就能明显感觉到风险暴露的时点提前了。
如果你的团队已经超过 100 人、并行多个项目、并且有私有化部署或从 Jira 迁移的需求，那么在流程梳理清楚之后，用 PingCode 这类平台把里程碑状态机、依赖关系和预警规则固化下来，会比继续依赖表格和会议更稳。工具不解决判断问题，但它能让正确的判断不至于因为人员流动和组织复杂度而失效。
常见问题解答（FAQ）
1. 一个项目到底设多少个里程碑才合理？该按什么标准拆？
我第一次当项目负责人时，为了显得管理精细，把一个 6 个月的项目拆了 27 个里程碑，结果每周都在开里程碑会，团队怨声载道，真正的风险反而没人看。后来换了个项目，又只设了 2 个，结果中期完全失控，等发现时已经来不及了。所以里程碑到底该设几个、怎么拆，我一直没找到靠谱的口径。
经验口径是里程碑数量约为项目总周数除以 4 到 6，即每 3 到 6 周一个，6 个月（约 26 周）的项目落在 5 到 8 个之间比较健康。
判断依据是：里程碑是给决策者和干系人看的检查点，不是任务清单，如果一个节点无法用一句话写清可验证的完成标准（交付物 + 验收人 + 判定标准），它就不该是里程碑，而是一个任务。落地做法分两步：先按阶段门拆，例如需求确认、方案冻结、开发完成并具备内测准入、UAT 通过、上线、上线后观察期结束；
再在每个阶段门下挂 1 到 2 个交付物型里程碑。设 27 个的典型问题不是工作量大，而是里程碑通胀，把每周例会当成了里程碑，导致风险信号被稀释，真正出问题的那一个被淹没在二十多个绿色里。一条自查标准：如果某个里程碑延期两天，团队没有任何人要调整计划，那它就不是里程碑。
2. 里程碑风险预警的阈值该怎么设？提前多久算危险？
我带的项目经常出现这种情况：周报上里程碑全是绿色，到期前三天突然变红，然后一路滑坡，最后只能靠加班硬扛。我一直在想，到底有没有一个能提前两三周就发出信号的判断口径，而不是等到延期当天才知道。
不要只看是否延期这个后置指标，要用领先指标，建议设三层阈值。绿灯：关键路径上的任务偏差不超过 5%，且前置依赖 100% 关闭。黄灯：偏差 6% 到 15%，或关键路径上有任务的负责人超过 48 小时未更新状态，因为信息真空本身就是风险信号。红灯：偏差超过 15%，或缓冲余量低于 1.2。
缓冲余量的算法是：（计划完成日减今日）除以（剩余预估工作量除以团队日均吞吐），这个比值小于 1.2 就意味着安全垫快被吃完了。判断依据是，里程碑延期从来不是突变而是渐变，通常在到期前 10 到 15 个工作日就已经能观察到三类信号：需求变更次数抬头、缺陷收敛速度变慢、关键人可用工时下降。
落地做法是每周固定一次 15 分钟的里程碑健康度巡检，只看三件事，缓冲余量、阻塞项数量及其停留时长、关键路径任务的更新新鲜度，任一项超标就升级到项目负责人层面，不要等到周报。
3. 里程碑风险控制清单落到日常，每天和每周具体该做什么动作？
项目管理的清单我看过很多，写的时候条条都对，真正执行起来就变成走过场，填完表格该延期的还是延期。我想知道有没有那种能真正跑起来、不靠自觉的落地节奏，最好是以周为单位、每次只要十几分钟的。
清单必须能在一分钟内填完，否则一定被跳过，这是我自己反复踩坑后最深的体会。建议按周固定三个动作。周一更新里程碑燃尽情况，标出本周必须关闭的阻塞项，且不超过 3 个，超过 3 个等于没有重点。
周三只做一件事：逐个问红灯项的负责人「你需要谁、在什么时候、做什么」，把口头承诺当场写进工具里的责任人和截止日期，没有落到系统里的承诺一律视为不存在。周五花 15 分钟做里程碑复盘，只记录三栏：本周新增风险、本周关闭风险、缓冲变化量。
每月做一次里程碑重新基线，如果累计偏差超过 20%，不要靠加班硬追，正式改期并同步给干系人，这比永远差一点更有可信度。判断依据是，风险控制的本质是缩短从发现到决策的时间，而不是消除所有风险。我自己的教训是，曾坚持每天站会汇报里程碑，三周后所有人都在念数字，真正的依赖风险反而没人提；
改成每周一次的阻塞项升级会之后，平均风险暴露时间从 11 天降到 4 天。工具上建议在某项目管理平台里把里程碑建成独立对象并关联任务与依赖关系，让缓冲余量自动算出来，靠人工汇报的数据一定会被美化。
4. 内部进度都正常，但被跨团队和供应商的依赖拖垮了里程碑，怎么管？
我们的研发进度一直达标，但经常卡在等接口、等审批、等第三方交付上，一等等两周，里程碑就直接废了。这种锅明明不在我这边，但延期的结果还是算在我头上，我特别想知道这类外部依赖到底该怎么提前控住。
把外部依赖当成里程碑的一等公民，而不是任务备注，这是最关键的转变。具体做四件事。第一，每个外部依赖登记四项信息：交付物、责任方、承诺日期、最晚接受日期，承诺日期与最晚接受日期之间的差值就是你的安全垫，差值少于 5 个工作日的依赖一律直接列为高风险。
第二，设置依赖冻结线：里程碑前 10 个工作日，所有上游依赖必须进入交付确认状态，未确认就默认按最坏情况排期，并在风险台账里升为红灯。第三，用双向确认代替单方催办：要求上游负责人每周书面确认一次能否按期，无回应即视为延迟，沉默不是默许。
第四，里程碑评审时只问一个问题：如果这个依赖晚 5 个工作日，我还有哪条路径能保住里程碑？答不上来就说明没有 Plan B，需要立刻准备分批交付、降级范围或先发布后补齐的替代方案。
数据口径上，如果外部依赖的平均等待时间占里程碑总时长超过 15%，就说明排期把不可控因素当成了可控因素，应该重排计划，或者在里程碑定义里直接写成条件式里程碑，例如「以某方交付某接口为前提的联调完成」，让前提条件对所有人可见。
核心关键词
文章包含AI辅助创作：里程碑管理方法大全：项目负责人里程碑风险控制落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/344030
读者评论
黄色红色的触发条件必须写成可观察事实这点很对，但落地时卡在'验收达成度≥80%'这类指标上，不同模块根本没法统一折算，最后又容易变成拍脑袋。这套方法对需求拆分的颗粒度要求挺高，需求本身还模糊的团队，可能得先把前面这步补上。
子里程碑稀释主干状态那条挺有共鸣，我们季度初把版本拆成四个子里程碑，汇报一路绿灯，主干实际延了两周。但执行时也有矛盾：子里程碑本来是给团队管内部节奏的，一旦上面只认主干，团队又觉得干得再多都不算数，这个分寸不太好拿。
四层模型看着完整，我更好奇依赖前置'两个时间单位'是怎么定出来的。跨部门或者牵扯外部供应商时，提前两周往往催不动，对方排期就是排期。另外案例是千人规模制造企业，换成几十人的研发团队，很多前提未必成立，希望能看到小规模团队的对照例子。