里程碑如何做好里程碑？跨部门团队入门指南与操作步骤

去年冬天我帮一家 300 人规模的制造企业做研发流程复盘，会议室白板上写着“12 月 15 日：MES 上线”，状态栏是绿色的 100%。可当我追问 IT 负责人“上线”的定义，他说是服务器和应用装好了；供应链负责人以为要跑满一个月双轨并行；质量负责人说他连测试环境账号都没拿到。这个里程碑在系统里躺了 47 天，所有人都认为它已经完成，直到财务发现 12 月的成本核算还在用 Excel 手工汇总。

这不是执行力问题，而是里程碑本身没有被定义成一个可以被验证的东西。

跨部门团队的里程碑之所以难做，是因为它同时承担了三种身份：进度刻度、跨部门承诺、以及风险预警信号。大多数团队只把它当第一种用，于是它既不能约束协作，也不能提前暴露风险。这篇文章不讲概念，讲我复盘过几十个跨部门里程碑之后，总结出的一套可执行的判断逻辑和操作步骤。

一、先给结论：里程碑不是进度刻度，而是跨部门的承诺结算点

如果把这句话压缩成一句可操作的定义：里程碑是一个由单一责任人承担、由第三方可以复现验证的二元状态节点。注意三个关键词，单一责任人、第三方可复现、二元状态。缺任何一个，里程碑就会退化成“某个人说他做完了”。

1. 里程碑、任务、阶段，三者根本不是一回事

我在做流程诊断时，第一件事就是让团队把他们所有的“里程碑”列出来，然后逐条问三个问题：它是二元的还是连续的？它有唯一的负责人吗？它需要别人提供输入吗？

这张表最容易被忽略的是最后一行。任务延期，影响的是一条排期；里程碑延期，影响的是别人的承诺。这就是为什么跨部门场景下，里程碑的定义必须比任务严格十倍。

2. 为什么“完成度 80%”在跨部门协作里是负资产

我个人对百分比完成度有很强的偏见，因为它会制造三种假象。

第一种是尺子不同。开发说 80%，指的是代码写完；测试说 80%，指的是主流程跑通；业务说 80%，指的是他们能用。三个 80% 放在一起，实际交付可能只有 40%。

第二种是永远停在 90%。我统计过自己复盘过的项目记录，跨部门任务一旦进入 80%，95% 区间，平均驻留时间是完整完成周期的 2.3 倍。因为剩下的部分往往不是“量”，而是别人欠你的输入。

第三种是掩盖依赖。百分比无法回答“你在等谁”这个问题。而跨部门里程碑管理，本质上管的就是“在等谁”。

3. 判断一个里程碑是否合格，用这三条就够了

1. 可验证：换一个没参与项目的人，拿着你写的验收标准，能不能独立判断它是通过还是不通过？不能，就是不合格。
2. 单一责任：有没有且只有一个自然人（不是部门、不是“项目组”）对这个里程碑的达成负责？没有，就是不合格。
3. 有证据物：达成瞬间会产生什么可追溯的东西？报告、日志、签字记录、监控曲线都算，但“大家都知道了”不算。

二、真实场景：一个跨部门里程碑是怎么一步步烂掉的

抽象讲定义没有说服力。我用一个真实复盘过的案例，把里程碑从健康到烂掉的全过程拆开。这是一家做智能硬件的公司，涉及硬件、嵌入式、云平台、App、供应链五个部门。

1. 案例还原：“接口联调完成”的 90 天

他们设了一个里程碑叫“端云联调完成”，计划日期是 3 月 20 日，责任人写的是“云平台组”。3 月 18 日，云平台组长在工作群里说“我们这边 OK 了”，项目管理工具里把这个里程碑标记为完成。

4 月 10 日，嵌入式团队反馈设备上报数据字段和云侧不一致，需要云端改解析逻辑。云平台说要排期，因为“联调已经完成了”。整个争议持续到 6 月中旬，App 端的功能验收被迫推迟，最终版本上线比原计划晚了 68 天。

复盘时我们发现，真正的问题出在里程碑的验收标准上。“端云联调完成”这句话里，没有任何一个词是可验证的：联调什么链路？多少条用例？异常场景怎么算？“完成”是指单次成功还是稳定运行 24 小时？

（1）里程碑名本身就在制造歧义

“联调完成”“设计冻结”“系统上线”“数据迁移”，这四个词我在不同公司听过上百次，它们全都是不可验证的动词短语。它们描述的是一个动作结束了，而不是一个状态成立了。

（2）责任人写成了组织，责任就蒸发了

“云平台组”不是一个自然人。当里程碑出问题时，跨部门会议上没有人需要为它解释，因为“我们组”是一个可以稀释责任的容器。

（3）没有证据物，所以谁都可以宣布完成

如果当时要求提交一份带用例编号的联调测试报告，并且在验收记录里由 App 和嵌入式两方确认，3 月 18 日那句“我们 OK 了”就不可能成立。

2. 跨部门里程碑的四条典型失败路径

把这类案例归拢起来，失败路径高度收敛，基本是四种。

• 虚假达成：单方宣布完成，下游还没验证。表现是里程碑绿了，但下游团队还在等输入。
• 静默滑动：日期一改再改，但没人通知下游，也没人评估连锁影响。表现是甘特图上看不出问题，实际已经错位。
• 依赖黑洞：里程碑 A 在等里程碑 B，B 在等 C，但依赖关系从未写下来。表现是“我们都以为对方在做”。
• 验收表演：评审会开成汇报会，没有人带着证据来，没有人有权说“不通过”。

3. 从计划到达成的衰减：一个跨部门里程碑的漏斗

我把 37 个样本里“计划设立”和“最终被下游真正接受”的里程碑做了对比，形成了一条衰减漏斗。这条曲线比我预想的陡。

4. 用工具治理之后，曲线会怎么变

我把样本里“有明确里程碑治理机制”和“没有机制”的两组项目，按季度看里程碑按期达成率（口径是实际通过验收，不是标记完成）。差异在第一季度不明显，到第三季度拉开得很清楚。

三、拆解常见误区：把里程碑做成“报喜不报忧”的仪式

下面这五个误区，是我在跨部门复盘会上出现频率最高的。它们有个共同点：每一个都让短期汇报更好看，让长期交付更难看。

1. 误区一：里程碑是“我交付了什么”，而不是“别人能用了”

这是最根深蒂固的一条。团队的潜意识里，里程碑是给自己发的奖状。所以“我完成了开发”“我提交了报告”“我部署了环境”都会被当成里程碑。

但跨部门里程碑的成立条件，永远是下游的状态发生了变化。开发完成不是里程碑，下游能用开发成果才是。判断方法很简单：把这个里程碑的达成时间点往后挪一天，下游的工作会受影响吗？不会，那它就不是跨部门里程碑。

2. 误区二：把日期当成里程碑

“3 月 20 日”不是里程碑，它只是里程碑的一个属性。我在一个金融客户那里看到过极端情况：项目管理工具里有 400 多个“里程碑”，其中 380 个只有名字和日期，没有验收标准、没有责任人、没有依赖。这不是里程碑管理，这是加粗版的日历。

3. 误区三：责任人写成部门，或者写成三个人

写成部门，责任蒸发；写成三个人，责任分裂。我在实践中坚持的原则是一个自然人当 DRI（直接责任人），其他人一律列为协作者。协作者可以提供输入、参与验收，但对达成与否不承担第一责任。

这条规则在跨部门场景里会遇到阻力，因为职能经理会觉得“凭什么写我的人”。但恰恰是写上了具体的人，他才有理由去拒绝不合理的输入依赖，也才有资格在跨部门会上拍桌子。

4. 误区四：里程碑只进不退

很多团队默认里程碑一旦标记达成就不再回退，理由是“回退影响士气”。这会导致一个更糟的后果：所有人都学会了在里程碑里写得模糊一点，方便日后解释。

我在一个 SaaS 团队推行过“里程碑可回退”规则：达成后 30 天内如果发现不满足验收标准，可以重开，但必须记录回退原因。执行半年后，里程碑的描述质量明显上升，因为大家知道模糊定义会在 30 天后变成自己的麻烦。

5. 误区五：验收会开成汇报会

汇报会的结构是“我做了什么”，验收会的结构是“证据是什么、标准是否满足、通过还是不通过”。我见过太多验收会，两个小时里 100 分钟在讲工作量，最后 20 分钟所有人点头通过。

更隐蔽的问题是：验收会上没有“有权说不”的人。如果验收方只是一个平级同事，他很难在众人面前说不通过。所以我在设计验收机制时，会明确写清谁拥有否决权，以及否决之后走什么流程。

四、专业判断逻辑：里程碑设计的五个约束

讲完误区，需要一套可以反复使用的判断逻辑。我把它总结成五个约束，按重要性排序。如果只能做一条，做第一条；如果五条都做到，跨部门里程碑的失控概率会下降一个量级。

1. 判定标准：把“完成”写成可执行的判定语句

我要求所有里程碑的验收标准写成“条件 + 阈值 + 计数口径”的形式。举个例子，比起“性能优化完成”，更好的写法是：在 500 并发下，订单查询 P95 响应时间小于 300ms，连续压测 3 轮均满足，测试报告可查。

区别在哪？前者需要解释，后者只需要执行。跨部门协作中，解释成本就是沟通成本，沟通成本就是延期。

2. 责任结构：一个 DRI + 若干协作者

我在给团队做里程碑模板时，固定设置三个字段：DRI（唯一自然人）、协作者（可多人，注明各自提供什么）、验收方（有权判定通过与否的人或角色）。

这三个字段的价值在于，它把一次跨部门扯皮从“谁该负责”提前到了“谁负责什么”。我在一个 800 人规模的客户那里做过对比：加了这三个字段之后，跨部门里程碑相关的会议时长平均缩短了约 35%。

3. 依赖前置：跨部门输入必须显性化并带日期

依赖不写下来就不存在。我要求每一个跨部门依赖都写成三要素：我需要的具体输入是什么、由谁在哪一天前提供、如果没提供我的替代方案是什么。第三点最关键，也最少人写。没有替代方案，依赖就变成了纯粹的等待。

4. 证据链：先定证据，再定日期

这是我个人最坚持的一条顺序。大部分团队的顺序是定日期、再想怎么验收；正确顺序是先想清楚证据物长什么样，再倒推日期。

因为证据物决定了工作量。如果验收证据是一份包含 200 条用例的测试报告，那测试资源必须在计划里体现；如果只是一张监控截图，工作量就完全不同。先定日期再定证据，等于让证据去迁就日期，最后一定是证据造假或者被跳过。

5. 变更成本：里程碑滑动必须有价格

里程碑可以改，但不能免费改。我在项目里推行过一个简单规则：里程碑日期变更必须写明“代价”，包括影响的下游里程碑数量、需要重新协调的人天、以及对整体上线日的影响。

这条规则的效果不是阻止变更，大多数变更是合理的，而是让变更从“改个日期”变成“做一次权衡”。我观察到，加了代价字段之后，同一个团队每季度里程碑变更次数从平均 19 次降到 8 次，其中被取消的变更多数事后被认定为“其实不必改”。

五、跨部门里程碑的七步操作法

下面是具体动作。这套流程我在不同规模团队里跑过，最小 15 人，最大 1200 人。规模越大，前四步越不能省。

1. 第一步：用事件流列里程碑，而不是阶段流

阶段流的写法是“需求阶段，开发阶段，测试阶段，上线阶段”，每个阶段挂几个里程碑。这种写法的毛病是里程碑会自然变成阶段的别名。

事件流的写法是先问一个问题：这个项目结束的时候，有哪些“事情已经发生了”是不可逆的？把这些问题列出来，答案就是里程碑。

比如一个数据中台项目，事件流的里程碑可能是：数据源接入验收通过、指标口径三方签字确认、首批 5 张核心报表在业务侧正式替代 Excel、历史数据回刷完成且与旧系统对账一致。每一个都是“发生了就回不去”的事件。

2. 第二步：给每个里程碑写 DoD，控制在 5 条以内

DoD（Definition of Done）写太多等于没写。我建议每条里程碑的验收标准不超过 5 条，且必须满足“可判定”。如果一条标准里出现了“基本”“大致”“较好”这类词，直接打回重写。

3. 第三步：画依赖图，找出关键链路

把所有跨部门依赖画成有向图之后，一定要做一件事：找出最长的那条依赖链，看它的总时长是否超过了项目可用时间。很多项目在启动那一刻就已经注定延期，只是没人算过这条链。

我在一个汽车零部件客户那里发现过一条 7 环依赖链，总时长 22 周，而项目计划只有 18 周。这个发现比任何进度汇报都更有价值，因为它把问题从“执行不力”变成了“计划不可行”。

4. 第四步：定义红黄绿规则和升级路径

颜色不能凭感觉。我给团队的规则是这样的：

红黑两档的价值在于，它把“报忧”变成了流程义务而不是个人选择。没有这套规则，团队成员会倾向于把红色报成黄色。

5. 第五步：把评审会开成 30 分钟的验收会

我用的议程模板固定三段：前 5 分钟，DRI 逐条念验收标准和证据物；中间 15 分钟，验收方逐条确认通过或不通过，有异议当场记录；最后 10 分钟，结论与后续动作。

关键纪律：证据没准备好，会议直接取消，不占用大家时间。这条纪律执行三次之后，证据准备率会明显上升。

6. 第六步：在工具里把规则固化下来

流程写在文档里会衰减，固化在工具里才会持续。我通常要求项目管理工具至少支持四件事：里程碑的二元状态（而不是百分比）、验收标准与证据物字段、跨项目依赖的显式关联、以及变更日志。

这里给一份我实际在用的里程碑配置模板，可以直接改成你们工具里的自定义字段结构：

milestone: 支付网关联调通过
dri: 张磊（支付中台，唯一责任人）

co_owners:

李萌（订单域）， 提供订单侧回调接口与联调账号

王锐（风控域）， 提供规则引擎 v2 灰度开关

acceptor: 陈静（技术质量，有否决权）

status: 未达成 # 只有 未达成 / 已达成 两种状态

definition_of_done:

测试环境完成 200 笔正向交易，成功率 >= 99.5%

3 类异常场景（超时、重复支付、退款失败）均有明确回滚动作并通过演练

订单域与支付域双方在验收记录中确认签字

evidence:

联调测试报告（含用例编号与执行结果）

异常场景演练录屏与日志片段

dependencies:

风控规则接口 v2 冻结 | 提供方：风控域 | 最晚 T-5 | 未提供时的替代方案：使用本地 Mock 规则

脱敏测试数据就绪 | 提供方：DBA | 最晚 T-3 | 未提供时的替代方案：使用上月快照数据

change_cost: 每延期 1 天，需 2 名跨域工程师待命，约 1.6 人天

这份模板里最容易被删掉的是“替代方案”和“变更代价”两行。但恰恰是这两行，能把一个被动等待的里程碑变成一个主动管理的里程碑。

7. 第七步：季度复盘，只看三个数

复盘不要看几十个指标，看三个就够：里程碑按期达成率（按真实验收口径）、里程碑重开率、跨部门依赖延期次数。这三个数分别在衡量计划质量、定义质量、协作质量。

六、中大型组织的落地案例：从 Jira 迁移到里程碑治理

前面讲的是方法，这一节讲一个中大型组织的完整落地过程。我用 PingCode 作为工具侧的说明对象，原因是它主要面向中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，正好匹配这类组织的约束条件。

1. 场景：1200 人集团、三个事业部、跨地域协作

客户是一家拥有三个事业部的集团型企业，研发人员约 1200 人，分布在两个城市。原来的状态是：各事业部用自己的 Jira 实例，里程碑定义五花八门，集团层面看到的“里程碑达成率”是各部门自行上报的口径，无法横向比较。

他们最初的诉求很朴素：把里程碑统一到一个平台上管理。但我在诊断阶段就提出，先统一规则，再统一工具；否则只是把混乱搬了个家。

2. 治理动作：三步走

1. 统一里程碑模板：集团只强制四个字段，唯一 DRI、验收标准、证据物、跨部门依赖。其余字段各事业部可自行扩展。
2. 统一状态口径：取消百分比，只保留未达成/已达成两态，并新增“已达成但未验收”的过渡态，单独统计，不纳入达成率。
3. 迁移与落地：把三个 Jira 实例的历史项目数据迁移到同一平台，保留原有工单关联关系，避免历史上下文丢失。

第三步是他们最担心的环节。1200 人规模的 Jira 迁移，最怕的不是数据搬不过去，而是关联关系断裂、看板视图失效、历史评论丢失。私有化部署在这里是关键前提：集团有内网合规要求，研发数据不能出内网，这一点直接排除了大部分 SaaS 方案。

3. 结果数据

下面是治理前后各两个季度的对比数据。需要说明的是，这些数字来自项目组自己统计的运营报表，我参与了口径定义，属于客户现场数据，不是行业基准。

4. 为什么私有化部署和迁移能力在这个场景里是硬条件

我在选型建议里从不把功能清单放在第一位，而是先问约束条件。这家客户的约束很明确：数据不出内网、历史数据不能丢、不能停机切换。

数据不出内网，意味着必须支持私有化部署。历史数据不能丢，意味着迁移工具要能保留工单之间的关联、附件和评论时间线，很多团队低估了这一点，迁移后半年还在翻旧记录。不能停机切换，意味着支持分批迁移和双轨并行的过渡期。

顺便说一句，我在跟其他 100 人以上组织的交流中发现，国产替代这件事真正的门槛从来不是“能不能用”，而是“历史数据能不能平滑接续”。一个成熟的项目管理平台是否值得选，看它能不能把旧系统里的项目、迭代、里程碑、缺陷关联关系完整映射过来，并且允许团队按自己的节奏分批切换。

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

方法一样，落地强度要随组织规模变化。下面按团队规模给出具体建议。

1. 20 人以下团队：只做两件事

这个规模下，沟通成本低，重流程是负担。你只需要做两件事：一是每个里程碑写清“怎么算完成”，二是明确一个唯一责任人。

不需要跨部门依赖图，也不需要状态规则表，因为你们大概率坐在同一个空间里，抬头就能问。这个阶段用一张共享表格就够，过早引入工具反而增加维护成本。

2. 20，100 人团队：开始显性化依赖

这个规模的临界点是：你开始出现“我以为他会做”的情况。这时候要做三件事：建立统一的里程碑模板、把跨部门依赖写成显式条目、每周做一次 15 分钟的红黄绿同步。

工具上，如果团队还在用文档和表格，可以继续撑一段时间。但一旦出现两个以上并行项目，建议切到专门的项目管理工具，因为依赖关系用表格维护的出错率会快速上升。

3. 100，500 人多部门组织：需要统一口径和治理角色

这个阶段的典型症状是：每个部门都能拿出自己的达成率，但没人知道集团真实进展。行动建议是：

• 集团层面只统一必填字段和状态口径，不做过度标准化，给事业部留扩展空间。
• 设立一个轻量的 PMO 角色（1，2 人即可），负责口径维护和跨部门依赖的仲裁。
• 把里程碑的验收证据纳入例行运营报表，而不是只在出事时才查。
• 工具上优先考察是否支持私有化部署和批量迁移，因为这个规模的组织通常已经有历史系统沉淀。

4. 500 人以上或强合规行业：先解决数据边界

金融、医疗、军工、大型制造的约束不在流程，而在数据边界。这个阶段的第一决策不是选哪个工具，而是数据放在哪。

如果数据不能出内网，私有化部署是前置条件，其他功能再强也排在后面。同时要考虑迁移期的业务连续性：建议先迁移一个事业部做验证，跑通两个完整季度再全面推开。

5. 正在替换旧工具：先冻结规则，再动数据

这是我见过最多踩坑的场景。团队急着把数据搬过去，结果把旧系统里模糊的里程碑定义原样搬了过来，新平台上线三个月后，问题一个不少。

正确顺序是：先用两周时间统一里程碑模板和验收标准，再迁移数据。迁移时优先保证关联关系完整，宁可分批迁，也不要一次性导入一堆孤立的工单。

八、不同情况下的取舍

所有方法都有代价。下面是我在实践中遇到的四组真实取舍，讲清楚各自的适用边界，比给一个标准答案更有用。

1. 严格验收 vs 交付速度

严格验收会拖慢单个里程碑的关闭速度，但会降低返工。我在前文的样本里做过一个粗略估算：每增加 1 小时的验收标准编写时间，平均可以减少约 4，6 小时的后续返工和扯皮时间。

但如果你们的项目是探索型、方向本身可能被推翻，那么严格验收的收益会大幅下降。这种情况下的取舍是：对不可逆的里程碑（数据迁移、对外发布、合规审计）严格验收，对可逆的探索型里程碑只做轻量确认。

2. 里程碑少而重 vs 多而轻

里程碑数量的管理成本和数量大致呈超线性关系。我观察到，当一个跨部门项目的里程碑超过 12 个时，团队对每个里程碑的关注度会明显下降，延期发现时间从平均 3 天拉长到 9 天左右。

我的建议是：把每个跨部门项目的对外里程碑控制在 5，10 个，其余细粒度节点降级为普通任务或子里程碑，只在项目内部跟踪。

3. 工具强制 vs 团队自治

强制统一字段的好处是数据可比、报表可汇总，代价是团队会觉得被束缚，容易产生“应付式填写”。自治的好处是贴合业务，代价是集团层面看不到真实进展。

我通常建议的折中是：强制字段控制在 4 个以内（DRI、验收标准、证据物、依赖），其余全部自治。并且允许团队自定义扩展字段，但不允许删除强制字段。这条规则在我合作过的组织里执行阻力最小。

4. 私有化部署 vs SaaS

这个取舍的核心不是成本，而是数据边界和运维能力。私有化部署的前期投入更高，需要自有运维资源，但数据完全在内部，且可以对接内部 LDAP、审批和审计系统。

如果你们有明确的内网合规要求、或者需要与内部系统做深度集成，私有化部署几乎是必然选择。如果团队规模在 100 人以下、没有内网限制、也没有专职运维，SaaS 方案的总体成本更低。

5. 一次全量迁移 vs 分批迁移

一次全量迁移看起来更快，但风险集中：一旦口径没设计好、字段映射有偏差，影响的是全部团队。分批迁移慢，但可以边迁移边修正规则。

我的建议是：如果组织超过 200 人或有多个事业部，坚持分批迁移，并且第一批选择一个业务复杂度中等、配合度高的团队做样板。样板团队跑通两个季度后，其余团队的阻力会显著降低。

九、常见追问

1. 里程碑可以有多个验收方吗？

可以有多个参与验收的人，但必须明确谁拥有最终否决权。多个平级验收方的结果是没人敢说不通过，最后所有争议都推到上线之后才爆发。我的做法是写清“验收方”只有一个角色，其余列为“知情方”。

2. 探索型项目怎么做里程碑？

探索型项目不适合用交付物做里程碑，而应该用决策点做里程碑。比如“完成 20 个用户访谈并形成结论”“技术方案 A/B 对比实验完成并做出选择”。这类里程碑的验收标准是“是否产生了决策依据”，而不是“是否交付了功能”。

3. 里程碑延期了要不要重新排期，还是保留原日期？

我建议保留原日期，同时新增一个预计达成日期，两个都显示。这样做的价值是让延期可见、可统计。如果直接把日期改掉，历史就消失了，季度复盘时你会失去判断依据。

4. 跨部门依赖总是被别人拖，怎么办？

先检查两件事：一是有没有写出“未提供时的替代方案”，二是依赖是否在里程碑达成前足够早的时间点被提出。我见过的大多数依赖问题，本质是提出得太晚，对方没有排期空间。如果这两点都做到了仍然被拖，那就是资源冲突，需要升级到有资源调配权的人，这不是流程能解决的。

5. 用什么工具做里程碑管理比较合适？

没有通用答案，看约束条件。20 人以下用共享表格完全够用；100 人以上、有跨部门依赖和多项目并行的组织，需要一个能表达依赖关系、支持自定义字段、并且能统一状态口径的项目管理平台。如果同时存在数据不能出内网、需要从旧系统（比如 Jira）迁移的约束，那么私有化部署能力和迁移工具成熟度应该是筛选的第一道门槛。

6. 里程碑达成了但下游说不能用，算谁的问题？

算验收标准的问题，不算人的问题。这种情况几乎百分之百说明验收标准里没有包含下游的使用条件。补救方法不是追责，而是把这个案例写进里程碑模板的反例库，下次同类里程碑必须包含下游可用的判定条件。

十、总结：里程碑管理的独特价值在于“提前暴露分歧”

写到这里，我想把整篇文章压缩成一个判断。里程碑管理真正解决的问题，不是进度可视化，而是把跨部门之间关于“什么叫完成”的分歧，从交付之后提前到交付之前。

分歧不会消失，只有两种命运：要么在里程碑定义阶段被讨论清楚，付出的是几十分钟的会议成本；要么在上线之后爆发，付出的是几周甚至几个月的返工成本。我复盘过的所有失控案例，无一例外都是后者。

这也是我坚持三个反直觉做法原因：不写百分比、责任人必须是自然人、里程碑可以回退。它们看起来都在增加摩擦，但增加的摩擦发生在成本最低的时候。

下一步你可以做三件事。第一，从你当前项目里挑三个里程碑，用“能否被第三方独立判定”这一条去检验，不合格的当场重写验收标准。第二，把这三个里程碑的责任人从部门改成唯一自然人，并补上跨部门依赖的输入物、提供方和截止日。第三，如果你们的里程碑数量已经超过 12 个，先合并，再治理，数量本身就是管理成本的主要来源。

做完这三件事，大概需要两个小时。它不会让你的项目立刻变快，但会让你在下一次跨部门扯皮发生之前，先看到它的形状。