实施计划最佳实践：跨部门团队项目规划协同管理，常见问题

我办公室里一直留着一份 2023 年的实施计划表：189 行任务、7 个部门、4 位部门负责人在启动会上当场签字确认，看上去无懈可击。项目最终延期 11 周才上线。复盘的时候我们逐行检查，发现没有任何一行任务排错了日期，真正卡住进度的是三处"没有名字的接口"，两份主数据由谁清洗、谁负责最终校验、出了问题找谁拍板，全程没人认领。

从那以后，我做跨部门实施计划的第一件事不再是打开排期表，而是先画一张协同断点图。这份材料就是把这套方法完整拆开：跨部门团队在项目规划协同管理里最常踩的坑在哪、怎么判断根因、不同规模和不同约束下该怎么选、哪些机制现在就得建、哪些可以往后放。

一、结论先行：跨部门实施计划真正失效的地方，不在甘特图

先给三个我反复验证过的结论，后面的内容都是为这三句话提供支撑和操作细节。

1. 跨部门实施计划的失败，绝大多数发生在"协同设计"层，而不是"排期精度"层。排期再细，只要目标、责任、依赖、变更、决策这五件事没对齐，计划表就会在第 4 到第 8 周开始系统性失真。
2. 协同问题不能用沟通技巧解决，只能用机制解决。"多沟通""加强协作""建立信任"这类建议之所以没用，是因为它没有回答"谁在什么时间、用什么格式、向谁交付什么"。
3. 治理机制必须先于工具采购。流程没统一之前上任何项目管理平台，结果只是把混乱电子化，还可能把混乱固化下来，后面更难改。

这三条结论听起来朴素，但我在实际项目里见过太多次反向操作：先花两个月选型、采购、配置权限，再回头讨论"变更到底谁批"，然后发现工具里根本没有对应的工作流，只能靠微信群补位。

1. 为什么"把计划做细"这条路走不通

很多项目经理的第一反应是：延期是因为计划颗粒度不够，那就拆到 4 小时一个任务。我试过。结果是计划行数从 189 涨到 600 多，维护成本翻了三倍，而按时达成率几乎没有改善。

原因很简单：任务的颗粒度解决的是"我该干什么"，解决不了"我和你之间怎么交接"。跨部门项目里，绝大多数的等待时间发生在部门与部门的边界上，而不是发生在任务内部。你把单个任务拆得再细，边界上的模糊一点没减少。

2. 一个可以直接用的判断标准

我现在的判断标准是：如果一份实施计划里，跨部门交付物的"接收人"和"验收标准"是空白的，那这份计划无论多长，都还处在草稿状态。

你可以立刻拿现有的计划表试一下：筛出所有涉及两个以上部门的任务，看每条任务是否写清了交付物名称、接收角色、验收口径、最晚交付时间。如果这四项有任意一项缺失，这条任务在跨部门场景下就是一颗定时炸弹。

二、真实场景：跨部门实施计划最常见的六类协同断点

我把跨部门实施计划的问题归纳成六类断点。每一类都给出症状、早期信号和常见归因错误，方便你对着自己的项目对号入座。

1. 目标断点：部门目标和项目目标不是一回事

症状：启动会上各部门都说"全力支持"，到了资源协调的时候全都排不出人。

早期信号：你问部门负责人"这个项目对你们部门今年的考核指标有什么影响"，对方回答"这是公司层面的项目，我们配合就好"。这句话出现，目标断点基本已经存在了。

常见归因错误：把这种情况归结为"部门本位主义"或者"执行力不行"。实际上这是激励机制问题，如果项目的成功标准没有和部门负责人的考核产生任何连接，那么"配合"就是他们在理性范围内的最优选择。

我的处理方式是在启动会之前，单独和每个部门负责人做 30 分钟的一对一，把三件事问清楚：这个项目上线后，你部门的哪个指标会变好？你需要我帮你解决什么？如果冲突了，你希望怎么排序？这三问的答案汇总起来，才是真正的项目目标，而不是立项文件里那段正确但无用的文字。

2. 范围与接口断点：做什么写清了，不做什么没写

症状：项目做了六个月，范围膨胀了将近一倍，没人说得清哪些是原本就在计划内的。

早期信号：范围说明书里只有"功能清单"，没有"明确排除项"。我后来强制所有项目必须写一节"本期不做"，而且要在启动会上逐条念出来。这一节的价值非常高，因为它把"我以为你会做"变成"我们确认了不做"。

接口边界比范围清单更隐蔽。两个系统之间的字段映射、主数据归属、异常处理责任，这些内容在计划表里经常被压缩成一行"系统对接"。我在一个制造业项目里见过整整两周的联调延期，起因只是"物料编码由谁生成"这一件事没有明确。

3. 责任断点：多头负责等于无人负责

症状：任务卡住了，追问下去有三个部门都说"这块我们在配合"。

早期信号：计划表里一条任务后面跟着两个以上部门名，但没有单独的责任人姓名。这是最典型的责任断点。

我个人的经验是：跨部门任务的"负责"必须是单一角色，可以有人"参与"，可以有人"知会"，但只能有一个角色对最终结果负责。这一条说起来简单，但在实际操作中，每次都要花不少时间才能让各方接受"某个人是唯一责任人"。

4. 依赖与资源断点：前置条件藏在别人脑子里

症状：联调当天才发现测试环境还没申请下来。

早期信号：项目会议上频繁出现"我以为那个已经好了"。依赖没有被显性化的时候，所有依赖都只存在于个别人的记忆里，而记忆是不可靠的。

依赖断点的解药是依赖登记册，而且必须包含四个字段：依赖内容、提供方、需要日期、当前状态。缺少"需要日期"的依赖登记册等于没有，因为它无法提前触发提醒。

5. 变更断点：需求随意插入，计划频繁失真

症状：计划表每周都在改，改到后来没人愿意再看。

早期信号：变更请求通过微信或者口头传达，没有人记录，也没有人评估对进度的影响。等到版本发布前一算，发现多了 30% 的工作量。

我见过最典型的做法是"先加进来，回头再评估"，结果是所有评估都发生在最后，那时候已经没有调整空间了。变更断点的关键是建立入口：没有入口的变更管理，等于没有变更管理。

6. 决策与升级断点：问题在部门之间循环

症状：一个问题在会上讨论了三次，每次都以"我们再研究一下"结束。

早期信号：会议纪要里出现"待定""继续跟进""双方再沟通"这类措辞，而且同一个议题反复出现。这说明决策权限没有落到具体的人身上。

跨部门项目里，项目经理通常没有对业务部门的直接管理权，这是客观现实。所以更需要的不是更强的推动力，而是预先设计好的升级路径：什么条件下升级、升级给谁、多久必须给出结论。

三、常见误区拆解：计划很全、执行很散的六个原因

下面这六个误区，我在至少十个项目里见过重复上演。它们的共同点是：看起来都在解决问题，实际上是在绕开真正的问题。

1. 误区一：计划越细越好

前面已经提到过。补充一个数据观察：我把自己经手的 6 个跨部门项目做了脱敏统计，把计划任务行数和里程碑按时达成率放在一起看，趋势非常清楚，当任务行数超过 300 之后，按时达成率不再改善，反而因为维护成本上升而下降。

2. 误区二：把"沟通不畅"当成根因

复盘会上最容易出现的结论就是"沟通不畅"。但"沟通不畅"是一个结果描述，不是一个原因。往下一层追问通常是：没有统一的信息源、没有明确的决策人、没有固定的同步节奏。这三件都是机制问题，不是沟通意愿问题。

如果你在复盘里写"加强沟通"，那这份复盘基本等于白做，因为下个季度同样的问题会再来一次。

3. 误区三：先买工具，再定流程

我在一个项目里见过这样的顺序：选型 6 周、采购 3 周、配置和权限梳理 5 周，前后 14 周。等工具上线，才发现变更审批流程根本没定义，只能先用工具里的默认工作流顶着，结果所有人都在抱怨"这个流程不符合我们的实际情况"。

正确的顺序是：先定义最小协同规则（谁提、谁评、谁批、怎么回写），再判断工具能不能承载这套规则，最后才配置工具。规则是 3 页纸的事，工具是 3 个月的事，顺序反了代价很大。

4. 误区四：贴一张责任矩阵就以为解决了扯皮

责任矩阵不是银弹。我见过贴了矩阵之后依然扯皮的项目，原因是矩阵只写到了部门级，"运营部 R、IT 部 C"，但具体是运营部的谁，没人知道。

责任矩阵要真正起作用，必须落到"角色 + 姓名"，而且最重要的那条规则要反复强调：每一项交付物只能有一个 A（最终负责），可以有多个 R（执行），但 A 不能有两个。

5. 误区五：变更管控等于拒绝变更

有些团队一听"变更管理"就紧张，以为是要卡住业务方。这会导致另一种极端：业务方绕过流程私下推进，变更管理名存实亡。

我的做法是把变更分成三档：小额变更（不影响到关键路径）由项目经理直接批；中额变更由项目发起人批；大额变更（影响里程碑或预算超过一定比例）上变更评审会。分级的意义是让 80% 的变更快速通过，而不是让 100% 的变更都排队。

6. 误区六：指望项目经理的个人推动力

这是我见过代价最高的一种依赖。一个经验丰富的项目经理确实能在没有机制的情况下把事情推下去，但一旦他休假、调岗或者项目进入高峰期，整个协同就会塌陷。

判断一个项目的协同是否健康，我常用的一个反直觉问题是：如果这个项目经理请两周假，项目会不会乱？如果答案是"会乱"，那说明项目靠的是人，不是机制。

四、专业判断逻辑：先定位断点，再设计机制，最后固化工具

我自己的操作顺序固定为三步，顺序不能换。跳过第一步直接谈机制，很容易做成"为了规范而规范"；跳过第二步直接上工具，就会把混乱固化下来。

1. 第一步：用清单定位断点，而不是靠感觉

我给团队用的是一份 12 问的断点自检清单，每个问题只能回答"是/否/部分"。回答"否"和"部分"的项目，就是你的断点所在。这里给出其中的核心 8 问：

1. 项目的成功标准是否用可量化指标写成了一句话？
2. 各部门负责人是否清楚本项目对他部门指标的影响？
3. 范围说明书里是否有明确的"本期不做"清单？
4. 跨部门交付物是否都注明了接收角色和验收口径？
5. 每条跨部门任务是否只有一个最终责任人？
6. 是否存在一份包含"需要日期"的依赖登记册？
7. 变更是否有唯一入口，并记录影响评估结果？
8. 是否存在书面的升级路径，包括升级条件和时限？

我用这份清单做过一次内部对照：在 9 个跨部门项目里，回答"否"超过 3 项的项目，全部出现了超过 4 周的延期；回答"否"少于 2 项的项目，只有 1 个出现延期。样本很小，不足以当成统计结论，但作为自查工具已经足够有效。

2. 第二步：设计五个"统一"，每个都对应一个可交付物

机制设计不需要复杂，我通常只做五件事，每件事必须产出一份可以存档的文件，否则不算完成。

这五份文件加起来通常不超过 15 页，但它们的价值远高于任何一份 600 行的计划表。因为它们回答的是"我们怎么协作"，而不是"我们做什么"。

3. 第三步：判断工具能不能承载你的机制

选工具的时候我会拿下面 6 个问题去对照，缺一不可：

• 是否支持单一信息源：计划、变更、风险、决策记录能不能放在同一个体系里，而不是分散在四个系统加三个群。
• 权限是否清晰：外部协作方、业务方、实施方能不能看到各自该看的内容，且不需要人工裁剪。
• 变更是否可追溯：每次变更谁提、谁批、影响哪些任务，能不能形成完整链路。
• 依赖关系是否可视：跨部门依赖能不能在视图里呈现，而不是躺在表格里。
• 状态是否可视化：管理层能不能在 30 秒内看到红黄绿和阻塞项，而不是听 40 分钟汇报。
• 跨部门是否可访问：业务部门同事愿不愿意用，这在很多企业里是决定性的。

4. 什么情况下 PingCode 这类平台是合适的

我参与过的项目里，有几家组织规模在 300 到 2000 人之间、跨部门依赖强、且对数据存放位置有明确要求的客户，最终选择了 PingCode。它的适用边界比较清晰：

• 适合中大型企业及 100 人以上组织。团队规模太小时，配置成本可能超过收益，用表格加一份依赖登记册往往更快。
• 适合需要私有化部署的场景。对数据不出内网、需要走内部安全审查的组织，私有化部署是硬性门槛。
• 适合从 Jira 迁移的团队。我见过几个团队从 Jira 迁移过来，主要是为了把需求、迭代、测试、缺陷放回同一个体系，减少跨系统对账。PingCode 支持 Jira 平滑迁移，这一点在国产替代的选型场景里是比较实际的考虑。

需要说明的是，工具本身不会自动带来协同改善。我在一次项目里见过这样的对照：同一套平台，A 团队先把责任矩阵和变更分级定好再配置，三个月后依赖解决周期从 11 天降到 3.6 天；B 团队直接上线，只把原来的表格搬进系统，三个月后依赖解决周期几乎没变。差别不在工具，在有没有先做机制设计。

5. 什么情况下先别上重型工具

反过来也有几种情况我建议先别急着上平台：团队少于 30 人且只有一个业务线；项目周期短于 3 个月；组织内还没有任何跨部门协作规范；或者当前最大的问题其实是目标没对齐，而不是信息不同步。

这几种情况下，一份共享的依赖登记册加每周一次的 30 分钟同步会，成本低得多，效果也更直接。工具应该用来固化已经跑通的流程，而不是用来创造还没想清楚的流程。

五、案例与数据观察：一家三百人制造企业的 18 周实施复盘

下面这个案例来自 2024 年我参与的一个项目，客户是一家约 300 人的制造企业，做 ERP 与生产执行系统的对接实施。信息做了脱敏处理，数据来自项目台账和周报记录。

1. 项目背景

项目涉及 7 个部门：IT、生产、计划、采购、质量、财务、销售。原计划 12 周上线，实际投入 18 周。前 6 周按常规方式推进，第 6 周做了中期复盘，发现三个里程碑全部延期，于是从第 7 周开始做机制改造。

2. 前 6 周：三个数字暴露了问题

第 6 周复盘时我们算了三个数字，这三个数字基本决定了我后面的所有判断。

• 平均依赖解决周期 11.4 天。一个跨部门依赖从提出到关闭，平均要 11 天以上，其中超过一半时间花在"找不到责任人"和"等回复"上。
• 平均变更决策周期 9.2 天。变更提出后平均要 9 天才有人给出结论，导致大量任务在等待期间无法排期。
• 高风险问题平均关闭周期 14.5 天。真正卡住进度的高风险问题，解决速度比普通问题慢得多，因为都在等决策。

这三个数字指向同一个根因：决策链条太长，而责任边界不清是决策链条变长的主要原因。

3. 第 7 到第 18 周：四项机制改造

我们没有换工具，只在现有条件上做了四件事。

第一，重建交付物责任表。把所有跨部门交付物列出来，每一条指定唯一责任人姓名和验收口径，一共 43 条，花了两天时间逐条对齐。

第二，建立依赖登记册。要求每条依赖必须写清提供方、需要日期、当前状态，状态每周更新。登记册用一个结构化文件维护，格式大致如下：

dependency_id: DEP-014
content: 供应商主数据清洗与校验

provider: 采购部 – 张工

consumer: IT 部 – 李工

needed_by: 2024-08-16

impact_if_delayed: 影响采购模块联调，波及里程碑 M3

status: in_progress

escalate_if_not_closed_by: 2024-08-12

escalate_to: 项目发起人

第三，变更分级。把变更分成三档：影响工时小于 3 人天的由项目经理直接批；3 到 10 人天的由项目发起人批；超过 10 人天或影响里程碑的上变更评审会，48 小时内必须给出结论。

第四，会议分层。原来的做法是所有人参加每周一次的两小时大例会。改造后拆成三个：15 分钟的每日阻塞同步（只谈卡点）、每周一小时的进度与风险会（只谈红黄绿和依赖）、按需召开的决策会（只做决策，不做汇报）。

4. 结果数据

到第 18 周上线时，我们回看了几个关键指标的变化。

5. 我的三点反思

第一，机制见效有滞后。第 7 周做完改造，第 9 周才开始看到明显改善。如果管理层在第 8 周因为没有立竿见影就叫停，整个改造就浪费了。所以我在任何项目里都会提前和管理层约定观察窗口至少 4 周。

第二，最有效的不是工具，是那两个字段。如果只让我保留一个改动，我会保留依赖登记册里的"需要日期"和"升级触发日期"。这两个字段把被动的等待变成了主动的提醒，效果立竿见影。

第三，变更分级比变更管控更有效。最初我们尝试所有变更都上会，结果两周后业务方开始绕过流程。改成三级审批之后，小额变更当天过，业务方反而愿意走流程了。

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

跨部门协同没有万能模板。下面按组织规模和约束条件分五类，给出我认为更贴合实际的起手式。

1. 100 人以下、单一业务线

这个规模下最大的风险是过度治理。我的建议是只做三件事：一页纸的目标与优先级共识、一份共享的依赖登记册、每周一次 30 分钟的阻塞同步会。

不需要正式的责任矩阵文件，但需要一条规则：每条跨部门任务在计划表里必须有唯一责任人姓名。不需要变更评审会，但需要一条约定：任何人改计划前必须在群里说一句改了什么、为什么改。

2. 100 到 500 人、多部门强依赖

这是最典型的场景，也是前面案例对应的区间。建议完整做五个"统一"，并明确引入升级路径。

工具层面，这个规模开始需要考虑单一信息源的问题。表格加群聊的组合在 100 人以下还能撑住，超过这个规模，信息会自然分裂成多个版本。这个阶段如果组织对私有化部署和数据管控有要求，PingCode 这类支持私有化部署、并且能承接从 Jira 平滑迁移的平台是比较现实的选择。但前提仍然是先把责任矩阵和变更分级定下来，再去做配置。

3. 500 人以上、集团型或强合规约束

这个规模下，跨部门协同会叠加多层级审批和合规要求。我的建议是：在五个"统一"之上，加两个东西，跨项目的依赖看板，以及项目组合层面的资源冲突仲裁机制。

另外要注意的是，这个规模下最容易被忽略的是"接口人"机制。每个部门指定一位固定的协同接口人，比每次临时找人效率高得多，因为接口人积累了上下文，能减少大量重复解释。

4. 已经在跑 Jira 或其他老旧系统的团队

这类团队的典型困境是：需求、迭代、测试、缺陷分布在多个系统，跨部门对账成本很高。我的建议分两步：先做数据梳理，明确哪些数据是权威源、哪些可以归档；再评估迁移路径。

迁移这件事我建议不要一次性全切。可以按项目或者按团队分批迁移，先让一个跨部门依赖最强的团队跑通，再推广。PingCode 支持 Jira 平滑迁移，在国产替代的选型讨论中这一点经常被提到，但真正决定迁移成败的不是工具能力，而是你对自己历史数据的梳理程度。

5. 业务侧主导、IT 只做支持的场景

这类项目里，IT 通常处于被评价的位置，话语权有限。我的建议是把协同机制的重点放在业务侧：谁提需求、谁验收、谁对业务结果负责。

同时一定要争取一个高层赞助人。没有汇报关系的情况下，项目经理能推动的范围是有限的，跨部门的资源冲突需要一个有权限的人来仲裁，这是机制设计的一部分，不是"政治手段"。

七、不同情况下的取舍：哪些现在必须做，哪些可以晚做

资源永远是有限的。我自己的取舍原则是：优先做那些"投入小、直接减少等待"的机制，推迟那些"投入大、主要提升可观测性"的机制。

1. 必须现在就做的三件事

1. 目标与优先级的对齐会。没有这一步，后面所有机制都会变成形式。投入通常只需要 2 到 3 人天。
2. 依赖登记册（含需要日期）。这是投入产出比最高的一项，通常 3 到 5 人天就能建立起初版。
3. 升级路径与时限。哪怕只是一页纸，也要写清什么条件下升级、升级给谁、多久必须回复。

2. 可以晚做但不要跳过的两件事

完整责任矩阵和变更分级标准，可以在项目启动两三周后再补齐。因为它们需要在实际协作中才能暴露出真正的边界问题，太早做容易做成纸面文章。

但不要跳过，尤其是变更分级。我见过最多的失控场景，就是项目跑到中途，变更已经积压了几十项，这时候再谈分级，成本会高很多。

3. 看起来重要其实可以砍掉的三件事

• 全量指标看板。一开始就做 20 个指标的看板，采集成本高、没人看。建议先只跟踪 3 到 5 个指标。
• 复杂的多级审批流。三级以上审批在跨部门项目里往往成为瓶颈，两级通常够用。
• 完美格式的周报模板。周报的价值在于暴露红黄绿和阻塞项，不在于排版。我见过团队花了三周设计模板，实际使用两个月后就废弃了。

4. 冲突时的优先级排序

如果只能做一件事，我会选依赖登记册。理由很直接：它同时缓解了责任、依赖和决策三类断点，因为它逼着团队把"谁提供、什么时候要、不交怎么办"写清楚。

如果能做两件事，加上目标对齐会。这两件事结合起来，基本能把 60% 以上的跨部门等待消除掉。

八、90 天起步路线与自检清单

最后给一条我自己用过的 90 天路线，适合从一个正在进行的项目切入，不需要停下来重构。

1. 第 0 到 30 天：建立最小规则集

这个阶段的唯一目标是让协作规则从"口头"变成"可见"。具体动作包括：开一次目标与优先级对齐会并形成纪要；建立依赖登记册并至少运行三轮更新；明确升级路径与 48 小时回复时限。

不要在这个阶段碰工具配置。规则本身还在调整，过早配置会带来大量返工。

2. 第 31 到 60 天：补齐责任与变更

这个阶段把跨部门交付物的责任表补全，明确每条交付物的唯一责任人和验收口径；同时上线变更分级标准，并在实际变更中试运行至少两周。

如果这两个动作能顺利跑起来，你会开始观察到依赖解决周期和变更决策周期的下降。这也是判断机制是否有效的第一个信号。

3. 第 61 到 90 天：固化到工具与指标

到了这个阶段，规则已经相对稳定，可以开始把它固化到工具里。配置的重点不是功能多少，而是能否承载你已经跑通的流程：责任矩阵、依赖登记、变更分级、决策记录。

同时确定 3 到 5 个持续跟踪的指标，不要贪多。我通常保留四个：里程碑按时达成率、平均依赖解决周期、平均变更决策周期、高风险问题关闭率。

4. 一页纸自检清单

把下面这份清单放在项目周报首页，每两周打一次分。任何一项从"是"变成"否"，就说明对应机制在退化。

九、常见追问 FAQ

1. 小团队真的需要做这么正式的机制吗？

不需要做全套。100 人以下、单业务线、项目周期短于 3 个月的团队，做两件事就够了：一份共享的依赖登记册，一条"改计划必须说明原因"的约定。机制的价值在于减少不确定性，不是为了流程好看。

2. 部门负责人不配合，项目经理能做什么？

我的经验是先分清是"不愿意"还是"排不出人"。前者通常是因为项目目标与他部门的指标没有连接，需要靠目标对齐解决；后者是资源冲突，需要靠升级路径解决。

这两种情况的处理方式完全不同。如果用了错误的方案，比如对着资源不足的部门反复强调"要加强协同"，只会让关系变差。

3. 变更分级的三档阈值怎么定？

没有通用答案，但有一个判断口径：让 80% 的变更能在一级快速通过。如果一级审批卡住了大部分变更，说明门槛设低了，要往上调；如果一级几乎不审批直接放行，说明门槛设高了。我通常从 3 人天和 10 人天这两个档位开始试，跑两周再调。

4. 一定要私有化部署吗？

取决于你的数据敏感度。制造、金融、政务以及有内部安全审查流程的组织，通常把私有化部署列为硬性要求；纯互联网团队、数据敏感度低的场景，公有云版本往往更省运维成本。这个问题应该先问内部安全团队，而不是问工具供应商。

5. 已有一套体系在跑，迁移成本会不会太高？

会，但通常低于预期。关键动作不是技术迁移，而是数据梳理：哪些是权威数据、哪些可以归档、哪些直接不再需要。我建议分批迁移，先让跨部门依赖最强的一个团队跑通，再逐步推广，而不是一次性全切。

6. 怎么判断协同机制真的起作用了？

看三个数：平均依赖解决周期有没有连续两周下降、变更平均决策周期有没有缩短、里程碑按时达成率有没有在 4 周后出现改善。如果三个都没动，通常是机制没有真正落地，而不是机制无效。

跨部门实施计划最难的部分从来不是把任务排清楚，而是把人和人之间的交接设计清楚。189 行任务救不了项目，两个字段，"需要日期"和"升级触发日期"，却经常能救。

如果你现在正准备启动一个跨部门项目，我的建议是：这周先做一件事，把项目的跨部门交付物列出来，给每一条写上唯一责任人和验收口径。这一步通常一个下午就能完成，而它带来的清晰度，往往超过花两周做的精细排期。

下周再补依赖登记册和升级路径。三个月后你会发现，真正让项目跑起来的，不是那份漂亮的甘特图，而是这几页看起来很朴素、但所有人都认账的协同规则。