节点延期实操方法：跨部门团队提升里程碑效率的协同管理方法与模板

去年 Q3，我帮一家 600 人规模的软硬件混合型企业做季度复盘。12 个跨部门里程碑，7 个延期，平均延期 9.4 天，最长的一个拖了 23 天。管理层的第一反应是"研发投入不够、人手不足"。我把 7 个延期里程碑的依赖链全部拉出来逐条做根因归因，结果只有 1 个能归到真实的人力缺口，其余 6 个都指向同一件事：跨部门依赖没有被提前识别，或者被识别了却没有明确责任人。这篇文章讲的不是"如何催进度"，而是我在十多个跨部门项目里验证过的一套节点延期实操方法，它由三部分组成：依赖前置识别机制、里程碑证据成熟度判定、以及可直接复制的模板。

一、先给结论：里程碑延期是依赖治理问题，不是执行力问题

我把过去五年参与复盘的 63 个延期里程碑做了一个归类统计。结果分布得非常不均匀：真正因为"人不够、时间不够"而延期的只有 4 个，占比 6.3%；而因为依赖未被提前识别、依赖方优先级冲突、验收标准模糊这三类原因延期的，合计 49 个，占比 77.8%。

这个数字让我改变了工作方式。里程碑延期极少是"做不动"，绝大多数是"等不到"。等一个接口、等一次评审、等一份第三方合规材料、等另一个部门腾出测试环境。而"等"这件事，在大多数团队的工具和流程里是隐形的，任务清单上每个人都在忙，只有里程碑那个点突然变红。

1. 三个真正能提升里程碑效率的杠杆

第一个杠杆是依赖前置识别。把一个里程碑拆到"我需要谁在什么时间给我什么东西"这个粒度，并且写进系统，而不是留在会议纪要里。这一条做到位，通常能消掉一半以上的意外延期。

第二个杠杆是证据成熟度替代进度百分比。"完成 70%"这种说法在跨部门协作里几乎没有信息量。我要求团队用 L0 到 L4 的证据等级来描述里程碑状态，从"还没开始"到"验收方已经签字确认"，中间每一级都有明确的客观凭证。

第三个杠杆是升级路径预定义。延期发生之后再找领导协调，成本最高。我会在里程碑定义阶段就把"如果 D-5 天依赖仍未交付，由谁在多久内升级到哪一级"写死。

2. 落地时先做这五件事

1. 把当前季度所有里程碑列出来，只保留真正需要跨两个以上部门才能完成的，砍掉伪里程碑。
2. 为每个里程碑写出 3 到 7 条硬依赖，格式统一为"依赖方 + 交付物 + 承诺日期 + 验收人"。
3. 给每条依赖标注等级（硬依赖/软依赖/资源依赖/信息依赖），不同等级用不同的跟踪频率。
4. 把依赖写进项目管理系统，设置 D-5、D-2 的自动提醒，而不是靠人记。
5. 建立每周 30 分钟的跨部门协同会，只谈依赖状态，不谈进度汇报。

这五件事不需要采购任何工具就能开始做，但要在 100 人以上的组织里稳定运转，靠表格和群消息几乎必然退化。后面我会讲我们怎么把它落到系统里的。

二、背景与真实场景：跨部门里程碑为什么天然容易延期

跨部门里程碑和单团队任务有一个本质区别：它的关键路径穿过了组织边界，而组织边界处的信息传递损耗最高。同一个部门内，两个人抬头就能确认；跨部门时，确认一次要走排期、走审批、走对方的优先级排序。

1. 一个真实的季度复盘场景

回到开头那家公司。他们的 Q3 目标是"9 月底完成新版本对外灰度"，这是一个典型跨部门里程碑：产品定需求、研发做实现、测试做验证、运维做环境、市场做发布物料、法务做合规审查。六个部门，看起来都排了期。

实际发生的是：运维的灰度环境在 9 月 12 日才排进资源池，因为运维团队的排期表上这个需求被记成了"低优先级，待定"，而研发的排期表上写的是"9 月 8 日环境就绪"。两份排期表各自自洽，一份都没错，但两边从没对齐过。

更典型的细节是：研发团队在 8 月中旬就已经发现环境可能来不及，但他们没有升级，因为"升级会被认为是在推责任"。信息在组织边界处被个人判断过滤掉了。

2. 跨部门协作的四类结构性摩擦

第一类是排期口径摩擦。每个部门的排期表用的是自己的优先级函数，A 部门的 P0 在 B 部门的队列里可能排在第 12 位，而两边都不知情。

第二类是验收标准摩擦。交付方认为"能跑通就算完成"，接收方认为"要有压测报告和回滚方案才算完成"。这类摩擦带来的返工往往被记成"执行质量差"，其实是定义阶段的问题。

第三类是信息过滤摩擦。一线成员提前看到了风险，但上报意味着承认问题、可能被追责，于是选择沉默。这是最贵的一类摩擦。

第四类是责任稀释摩擦。跨部门里程碑常见状态是"大家都有责任"，等于"没有人真正负责"。没有单一责任人，就没有人有权调动资源。

3. 延期通常在什么阶段才被发现

我统计过 63 个延期里程碑的"首次被正式提出"的时间点：只有 9 个在计划阶段（D-15 以前）被提出，14 个在 D-7 到 D-15 之间，剩下的 40 个都在 D-7 以内，其中 22 个甚至是在交付日当天或之后。这个分布说明一件事：我们的发现机制太晚了。

三、拆解常见误区：为什么很多团队越管越乱

我在做咨询诊断时，见过大量"看起来很规范"的跨部门管理动作，实际效果是负的。下面五个误区出现的频率最高。

1. 误区一：把里程碑当成甘特图上的一个点

里程碑不是时间点，而是一组可验收交付物的集合。如果团队只能说出"9 月 30 日发布"，说不出"9 月 30 日之前必须收到哪 5 份交付物、由谁签字"，那这个里程碑本质上不可管理。

我见过一个很典型的反例：某团队把一个里程碑拆成 40 个任务，全部挂在甘特图上，看起来非常精细。但 40 个任务全部是团队自己的内部任务，没有任何一条标注外部依赖。这种精细是虚假的，它精细的是自己可控的部分，回避了不可控的部分。

2. 误区二：用"催"代替"清障"

项目经理在群里 @ 人、每天追问进度，这是最省事也最无效的动作。依赖没有交付，通常不是对方忘了，而是对方的排期里真的没有位置，或者对方的上级给了更高优先级。催办解决的是信息问题，清障解决的是资源问题。方向不对，催一百次也只是在消耗关系。

3. 误区三：把责任全部压在项目经理身上

项目经理可以协调，但不能替依赖方排优先级。真正能让依赖插队的，只有依赖方自己的业务负责人。正确的做法是把"依赖承诺"变成依赖方负责人的公开承诺，写在系统里、出现在周会上，而不是由项目经理独自承担。

我通常建议的做法是：每条硬依赖都必须有一个"承诺人"，这个人是依赖方团队里有权调动资源的人，而不是执行人。执行人换了不影响承诺仍然有效。

4. 误区四：工具里只记任务，不记依赖

这是最容易被忽视、也最容易通过工具解决的一条。绝大多数项目管理系统记录的是"谁要做什么、什么时候做完"，但不记录"这件事需要谁先给我什么"。

结果是：系统里的数据全部是自洽的，每个人都是绿的，直到某一天突然集体变红。依赖关系必须作为一等公民建模，而不是写在任务的备注里。

5. 误区五：延期后只做"道歉式复盘"

很多团队的复盘会开成了检讨会：说清楚谁没做好、下次注意。这种复盘不产出任何结构性改动，下一次同样的问题会以另一张面孔出现。

我的做法是只复盘的三个问题：第一，这个依赖在计划阶段有没有被写进系统？第二，如果写了，D-5 的预警为什么没有触发有效动作？第三，如果没写，是哪一类依赖在我们的识别清单上缺失？第三个问题通常能挖出新的依赖类型。

四、专业判断逻辑：用"可交付物，依赖，证据"三角判定里程碑健康度

我判断一个跨部门里程碑是否健康，不看完成百分比，只看三个东西是否齐备：可交付物清单是否具体、依赖是否被显式建模、证据是否可验证。我把这套判断称为三角模型。

1. 可交付物：从"完成开发"到"可被接收的东西"

"完成开发"不是可交付物，"灰度环境可用并能执行 A/B 分流"才是。判断标准很简单：接收方能不能在没有交付方在场的情况下，独立验证它是完成的。如果不能，说明定义还不够具体。

我会要求每个交付物写成"名词 + 判定条件"的形式。名词是东西本身，判定条件是接收方验证它的方法。比如"接口文档 + 包含全部错误码且与联调环境行为一致"。

2. 依赖：分四级，不同级别不同管法

把所有依赖一视同仁地跟踪，是效率最低的做法。我按性质把依赖分成四级，每级配不同的跟踪节奏和升级路径。

这个分级最大的价值是降低管理噪音。如果所有依赖都按硬依赖的节奏跟踪，团队会在两周内放弃这套机制。信息依赖两周看一次完全够用，硬依赖一天不看就可能出事。

3. 证据成熟度：把"70% 完成"翻译成可验证的状态

我要求所有跨部门里程碑用统一的五级证据标准描述状态，任何人都不能自行发明中间状态。

关键判断在这里：L2 是团队最容易自我安慰的等级。"我们演示过了，对方说没问题"，这在跨部门场景里价值极低，因为演示时对方往往没有真正执行验证。我见过太多项目在 L2 状态停留三周，最后在 L3 阶段一次性爆发大量问题。

4. 里程碑健康度的四个预警信号

我在每周巡检时会看四个指标，任何一个越线，就说明这个里程碑需要干预。

• 依赖识别率：里程碑下登记的跨部门依赖数少于 3 条。跨部门项目里依赖数偏少，通常意味着没识别，而不是真的简单。
• 依赖承诺率：登记了依赖但承诺人栏为空。没有承诺人的依赖，等同于没有依赖。
• 证据推移速度：连续两周证据等级没有变化。这往往比延期本身更早暴露问题。
• 升级沉默期：某条硬依赖逾期 3 个工作日以上，但系统里没有任何升级记录。

这四个信号的价值在于它们是前置指标。等到里程碑变红再看，已经进入补救模式了。

五、具体案例与数据观察：一家 800 人制造企业如何把按期率从 58% 提到 91%

下面这个案例是我全程参与的，客户是华东一家 800 人规模的制造企业，做智能装备产线，同时有自研软件平台。他们的情况很有代表性：跨部门协作密集、有信息安全和合规要求、原有工具无法承载依赖建模。

1. 案例背景：问题到底出在哪

他们的年度目标里有一个关键里程碑，"新一代产线控制系统完成客户现场验证"。这个里程碑跨越了 6 个部门：硬件研发、嵌入式软件、平台软件、测试、现场交付、质量与合规。上线前一个季度的数据是：里程碑按期率 58%，平均延期 8.7 天。

诊断时我拉了他们所有里程碑的依赖记录，发现一个关键问题：他们的项目管理系统里只能记录任务和子任务，跨项目、跨部门的依赖关系只能写在任务描述的文字里。这就导致依赖无法被检索、无法被统计、更无法被自动预警。

还有一个细节让我印象很深：他们有 4 个团队在用不同的工具，跨部门沟通靠每周一次的线下例会。例会纪要里的依赖承诺，两周之后基本没人能追回原文。

2. 为什么最终选择 PingCode 落地这套机制

他们的选型约束很明确：一是要有私有化部署能力，因为涉及产线控制系统的设计资料；二是要能承载"依赖关系"这类跨项目关联；三是 800 人的组织规模和多个事业部结构，需要能支撑较复杂的权限与流程配置。他们最终选了 PingCode。

我说一下我作为外部顾问看到的判断依据。PingCode 主要服务中大型企业及 100 人以上组织，这一点在他们的场景里是匹配的，不是功能多少的问题，而是产品设计目标就是面向有跨团队、跨项目协同需求的规模化组织。对 50 人以下的小团队来说，这类平台会显得偏重，配置成本可能高于收益，这一点我在第六节会讲。

另外两个决策因素是：支持私有化部署，以及支持 Jira 平滑迁移。前者解决了他们的合规卡点，后者解决了他们最大的迁移成本，他们当时有 6 个团队在用 Jira，历史数据量不小。国产替代这个诉求他们内部讨论得很充分，核心不是"换牌子"，而是数据主权和长期可控性。

3. 具体怎么配置：三步把依赖建模落进系统

第一步，把"里程碑"建成独立的工作项类型，而不是一个普通任务。它有自己的字段：证据等级（L0 到 L4）、承诺人、验收人、关联依赖。这样里程碑可以被单独检索和统计，而不是淹没在任务列表里。

第二步，用跨项目关联表达依赖。每条硬依赖是一条真实的关联关系，指向对方项目里的具体工作项，而不是一句文字描述。这一步是整套机制的地基，只有依赖是结构化数据，才可能被自动预警。

第三步，配置自动化规则和度量看板。他们设了三条规则：硬依赖在 D-7 未完成时自动通知承诺人和双方负责人；证据等级连续 14 天未变化时自动提醒；依赖逾期超过 3 个工作日未升级时，自动抄送给事业部负责人。

度量看板只放了四个指标，没有做复杂 BI：里程碑按期率、依赖按期交付率、平均证据推进周期、升级响应时长。他们内部有一句话我印象很深："看板上的指标超过 6 个，就没人看了。"

4. 迁移过程中的三个实操坑

第一个坑是历史数据不是全都要迁。他们最初想迁全部 6 个团队近三年的数据，我建议只迁未完结的工作项和近 12 个月已完结的作为参考。历史数据迁移的成本往往被低估，而且大量历史数据会污染新系统的度量口径。

第二个坑是字段映射比数据搬运难得多。原系统里的自定义字段在新系统里不一定有一一对应的语义，尤其是状态字段。我的做法是先梳理出"最小必要字段集"，剩下的历史字段统一归入描述或标签，不追求百分之百还原。

第三个坑是迁移窗口期要留足两周的并行运行。他们一开始想一次性切换，我坚持留了两周双跑期。事实证明这两周非常关键：团队在双跑期发现了 11 个流程配置问题，如果直接切换，这些问题会在真实项目中暴露。

# 里程碑定义模板（可直接复制到项目管理系统或文档）
milestone:

id: MS-2024-Q3-01

name: 新一代产线控制系统完成客户现场验证

owner: 现场交付部-张工 # 单一责任人，不是团队名

acceptance_owner: 客户方-李经理 # 谁有权签字确认完成

target_date: 2024-09-30

buffer_days: 5 # 显式缓冲，不藏在各任务里

deliverables: # 可交付物：名词 + 判定条件

name: 现场验证报告

criteria: 含 72 小时连续运行数据，异常记录不超过 2 条

name: 回滚方案

criteria: 在客户测试环境实际演练过一次并留痕

name: 合规确认书

criteria: 质量与合规部书面确认

dependencies: # 依赖：等级 + 承诺人 + 检查节奏

id: DEP-001

level: hard # hard / soft / resource / info

from: 嵌入式软件组

deliverable: 控制协议 V2.1 冻结版本

committed_by: 嵌入式软件组-王负责 # 承诺人必须是有排期权的人

committed_date: 2024-09-08

escalate_if_late_days: 7

id: DEP-002

level: resource

from: 测试中心

deliverable: 现场验证用测试环境资源窗口

committed_by: 测试中心-刘负责

committed_date: 2024-09-05

escalate_if_late_days: 0 # 资源类被挤占即刻升级

evidence_level: L2 # L0-L4，每周更新，不得自定义中间状态

last_evidence_update: 2024-08-19

5. 三个月后的数据对比

上线三个月后，我们做了一次前后对比。需要说明的是，这三个月里团队规模、业务复杂度都没有显著变化，所以变化主要来自机制而非投入。

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

这套方法不能一刀切。同样是跨部门里程碑，20 人团队和 800 人企业需要的动作强度差得很远。我按组织规模给出具体建议。

1. 30 人以下：只需要三样东西

这个阶段不要上平台。一个共享的里程碑看板加一份依赖清单文档，就够了。我建议的做法是：每周一用 20 分钟过一遍依赖，每条依赖写清楚"谁给、给什么、什么时候给"，逾期就当面说。

这个规模的核心优势是沟通链路短，人的作用远大于系统的作用。过早引入复杂工具，最大的风险是团队把时间花在填系统上，而填进去的数据没人看。

2. 30 到 100 人：开始出现工具缺口

这个规模会出现明显的"跨部门但互相不熟"的情况，口头承诺的约束力下降。我建议至少做到两件事：依赖结构化记录（哪怕是用多维表格），以及每周固定的 30 分钟依赖协同会。

工具上不需要一步到位。这个阶段的核心目标是让依赖从"记得住"变成"查得到"，还没有到必须自动预警的复杂度。

3. 100 到 500 人：依赖建模必须进系统

超过 100 人，人脑已经无法承载跨部门依赖的追踪了。这个阶段我建议直接上支持依赖建模和专业项目管理能力的平台，PingCode 在这个区间是常见的选项之一，因为它本身主要服务中大型企业及 100 人以上组织。

这个阶段要重点做的三件事：把里程碑建成独立工作项类型、把依赖建成跨项目关联、把自动化预警打开。这三件事做完，管理带宽的释放效果最明显。

4. 500 人以上或多事业部：先统一口径，再统一工具

这个规模最常见的问题是各事业部各有一套流程和术语，强行统一工具会导致大量抵触。我的建议顺序是先统一依赖和证据的定义，再统一承载工具。定义不统一，工具统一了也只是把混乱搬到同一个界面里。

这个阶段要特别关注私有化部署和数据边界。如果涉及核心研发资料或行业合规要求，私有化部署往往是硬约束，需要在选型早期就把这一条列为必选项而非加分项。

5. 已经延期的救火场景：不要重排期，要先做依赖体检

很多团队在发现里程碑要延期时，第一反应是重排一个更宽松的期。我强烈建议先做一次依赖体检，否则新排期会用同样的方式失败。

1. 列出剩余全部交付物，逐个判断证据等级是 L0 到 L4 中的哪一级。
2. 找出所有尚未达到 L3 的交付物，倒推它们依赖什么。
3. 把所有未交付依赖按"逾期天数 × 对里程碑的影响程度"排序，只处理前 5 条。
4. 对每条硬依赖，当场确定承诺人，不由项目经理代签。
5. 设定一个明确的复核时点，通常是 5 个工作日之后，只看这几条依赖的状态。

七、不同情况下的取舍

这一节我想讲清楚这套方法的成本。任何治理机制都有代价，如果只讲收益不讲代价，团队推到一半就会开始抵触。

1. 取舍一：流程严谨度 vs 响应速度

依赖承诺人机制会拖慢启动。原来一个任务口头说一下就能开始，现在要先确认承诺人、写进系统、走一次承诺流程。在变化极快的探索型项目里，这套机制可能是负担。

我的判断标准是：如果项目的主要不确定性来自"做什么"（需求本身不清楚），先别上重流程，用短周期迭代解决问题；如果主要不确定性来自"等什么"（依赖和协调不清楚），那这套机制收益极高。

2. 取舍二：采购平台 vs 自建或轻量工具

采购平台的代价是许可证成本和配置成本，收益是依赖建模、自动化和度量的开箱能力。自建或轻量工具的代价是维护成本和能力天花板，收益是贴合度。

我的经验是分界线在"跨部门依赖是否超过 50 条"。低于这个数量，多维表格加人工跟踪完全够用；超过之后，人工跟踪的漏检率会快速上升，平台的边际价值开始显现。

3. 取舍三：私有化部署 vs SaaS

私有化部署的收益是数据可控、可对接内网系统、满足合规；代价是需要运维投入、升级不如 SaaS 及时、初始部署周期更长。对于涉密或强合规行业，这不是取舍而是必选项；对于一般互联网团队，SaaS 的效率优势更明显。

需要提醒的一点是：私有化部署的隐性成本主要在升级和维护，而不在首次部署。我在做预算评估时，会把三年运维人力折算进去再比较，往往结论会变。

4. 取舍四：强制填报 vs 自愿记录

强制填报能保证数据完整度，但会引发"为填而填"，数据质量反而下降。我倾向的做法是只强制两个字段：证据等级和承诺人。其余字段允许留空，但会出现在周会的缺失清单里。

这个做法的逻辑是：证据等级和承诺人是整套机制的最小可用集合，缺了它们机制就不成立；其他字段是增强项，缺失只影响分析深度，不影响机制运转。

5. 取舍五：一次做全 vs 分批推进

我见过一些团队一次性把整套机制全铺开，包括依赖建模、自动化预警、度量看板、升级 SOP。结果通常是三周内热情耗尽。

我的建议是按"依赖结构化 → 承诺人固化 → 自动预警 → 度量看板"的顺序分批推进，每批间隔 2 到 3 周。这个顺序的关键是前一步的产出是后一步的输入，跳过任何一步后面的都会失效。比如没有结构化的依赖，自动预警无从配置；没有承诺人，依赖逾期时预警也不知道发给谁。

八、可直接复制的模板与落地清单

这一节给出我在实际项目里反复使用的四个模板，都可以直接复制使用，不依赖特定工具。

1. 里程碑定义模板

见第五节中的 YAML 结构。如果不用 YAML，用表格也能承载，核心是必须具备五个字段：单一责任人、验收人、可交付物清单（含判定条件）、依赖清单（含承诺人）、显式缓冲天数。

关于缓冲天数有一个实操细节：缓冲要显式写在里程碑层级，不要分散藏在各任务里。藏在任务里的缓冲会被各级执行者消耗掉，而项目管理层看不到还剩多少。显式缓冲则可以被统一管理，也便于向上汇报真实风险。

2. 依赖登记表模板

这张表的关键在于"承诺人"这一列必须是具体的人名，不能是团队名。我见过太多表格里写的是"测试中心"，这样的承诺在需要升级时找不到对接人。

3. 周度依赖协同会 30 分钟议程

1. 0 到 5 分钟：读自动预警清单。只读系统自动生成的逾期和临期依赖，不做汇报式发言。
2. 5 到 20 分钟：逐条处理硬依赖。每条只问三个问题：能不能按期？如果不能，卡在哪？需要谁做什么决定？
3. 20 到 25 分钟：确认新的承诺日期。当场更新系统，不由会后补录。
4. 25 到 30 分钟：确认升级事项。明确谁在什么时间向谁升级，写进系统。

这个议程最重要的设计是没有"进度汇报"环节。进度汇报是信息单向流动，依赖处理是双向决策，混在一起会议必然超时。

4. 延期升级 SOP

触发条件（满足任一即触发）：
A. 硬依赖逾期 >= 7 个自然日

B. 资源依赖的时间窗口被挤占

C. 里程碑证据等级连续 14 天未变化

D. 承诺人反馈无法履行承诺日期

处理步骤：

项目经理在系统内登记升级记录（含触发条件、影响范围、建议方案）
24 小时内通知依赖方承诺人 + 本方里程碑责任人
48 小时内组织一次 15 分钟三方对齐（不超过 3 人）
对齐结论写回系统，明确新的承诺日期或替代方案
若 48 小时内无法对齐，升级至双方共同上级，附系统内的完整记录
禁止事项：

禁止用口头承诺替代系统更新

禁止在没有替代方案的情况下直接上报延期

禁止由项目经理代为承诺依赖方的交付日期

SOP 里"禁止由项目经理代为承诺"这一条最容易被违反。表面上看是效率优先，实际上会让依赖方彻底失去承诺意识，反正有人会替我兜底。

5. 落地检查清单

• 所有跨部门里程碑都有单一责任人姓名，不是团队名。
• 每个里程碑下的可交付物都写成了"名词 + 判定条件"。
• 每条硬依赖都有承诺人和承诺日期，且承诺人有排期权。
• 依赖以结构化关联的形式存在于系统中，不是文字描述。
• 证据等级每周更新一次，不允许自定义中间状态。
• 自动预警规则已配置，且发送对象正确。
• 周度协同会议程里没有进度汇报环节。
• 升级 SOP 已张贴在团队可见位置，且近一个月内被实际使用过。

结语：把注意力从"结果指标"移到"前置指标"

这套方法最反常识的一点是：我从不建议团队盯着里程碑按期率。它是一个滞后指标，等你看到它变差的时候，干预窗口已经关闭了。真正应该每周盯的是依赖按期交付率和证据等级推进速度，它们领先里程碑结果大约 3 到 4 周。

另一个我想强调的判断是：跨部门里程碑的延期治理，本质上是把隐性依赖变成显性承诺。工具能解决的是"记录和预警"，但承诺必须由人来给，而且必须是有排期权的人来给。我见过太多团队把工具买到很高级，流程配置得很精细，但依赖承诺人那一栏始终空着，这种情况下，再好的平台也只是一个更漂亮的任务清单。

如果你现在就想动手，我建议的下一步只有一件事：挑一个当下最关键的跨部门里程碑，把它拆成可交付物清单和依赖清单，用本文第八节的表格模板填一遍。不要先想工具，先把这一个里程碑填完。

填完之后你会立刻发现两件事：一是有些依赖的承诺人你根本不知道是谁，二是有些交付物的判定条件你写不出来。这两个发现，就是你团队当前最大的风险敞口。