计划基线实操方法：研发团队提升项目规划效率的入门指南方法与模板

去年秋天，我带的一个中台版本原定 9 月 12 日发布，实际拖到 9 月 15 日才上线。复盘会开了两个小时，团队在“到底是范围变了、估算错了，还是依赖方拖了”这个问题上争论了四十分钟，最后谁也没说服谁。原因很简单：从立项到发布，团队手里没有任何一版被正式确认过的计划可以拿来对齐，所有人凭的是各自记忆里那个“应该的时间”。这不是执行力问题，是参照系缺失。计划基线要解决的就是这件事，它不保证项目不延期，但它保证延期发生时，你能在十分钟内说清楚哪里变了、变了多少、是谁批的。

一、核心结论：基线不是锁死计划，而是给变更一个参照系

先把结论放在前面，后面所有内容都是围绕这三条展开的。如果你的团队时间极其紧张，只看这一段也能拿到七成的价值。

第一，研发团队缺的不是更细的甘特图，而是一份经过确认、可被对比的计划版本。很多团队排期表做得非常漂亮，任务拆到两天粒度，责任人、依赖关系、颜色标记一应俱全，但从来没有一次正式的“确认”动作。三个团队看的是三个版本的表，等到延期了才发现彼此理解根本不一致。详细不等于有效，被确认才等于有效。

第二，基线的最小价值单位是“能被对比”，不是“足够详细”。一页纸的里程碑基线，只要写清了验收标准、关键依赖和责任人，它的可用性远高于二十页拆到任务级的排期表，因为前者每天都被用，后者第二周就没人更新了。我在过去几年见过太多“做完就放进文件夹”的详细计划，它们对项目没有任何约束力。

第三，提升规划效率的杠杆在机制，不在工具。统一模板、固定评审节奏、明确的变更入口、可复盘的变更记录，这四件事决定了一个团队能不能把规划效率提上去。工具解决的是承载和追溯问题，它不能替代机制。反过来，机制跑通之后再选工具，工具的收益会放大好几倍。

我用一组内部数据来说明基线的实际效果。这是我在 2024 年下半年参与的三个研发团队（合计约 120 人）共 14 个版本周期的记录汇总，属于团队样本推演，不是行业统计，仅供参考。

二、背景与真实场景：研发排期失控的三种典型形态

我观察到的研发排期失控，几乎都能归类到下面三种形态里。它们看起来是三个问题，底层其实是同一个原因：没有一版被确认过的计划作为参照。

1. 需求临时插入，没有人评估影响

典型场景是：业务方在版本中期提了一个“必须做”的需求，产品经理口头答应了，研发负责人看了一眼睛说“挤一挤应该能上”。没有人算过这个需求会挤掉什么、会让哪个里程碑后移、会让谁的加班增加多少。

这种插入的可怕之处在于，它的成本被隐藏了。团队在版本末期才发现测试时间被压缩，被迫用质量换时间，延期反而没人提。半年之后你问这个团队为什么总是延期，答案是“需求太多”，但具体是多在哪个版本、哪一次插入造成的，谁也说不出来。

2. 跨团队依赖靠口头承诺

“接口下周三给你们”“环境下周就能申请下来”“数据字典我们这边周五发”，这些话在研发协作里每天出现几十次，但真正落到有责任人、有日期、有验收标准的条目上的，可能不到三成。

更麻烦的是依赖失效之后没人负责升级。依赖方晚了三天，等着的一方默默接受，然后在版本末尾加班补回来。依赖阻塞的时间没有被记录，所以也没人知道这类问题一年累积起来是多少人天。

3. 延期归因靠回忆，版本复盘变成追责会

版本上线之后复盘，每个人都根据自己的记忆还原过程。产品经理记得是研发估得太乐观，研发记得是需求改了三版，测试记得是提测晚了两天。三种记忆都部分正确，但拼不出一条完整的时间线，最后复盘会变成情绪会。

归因不清的直接后果是，同类问题会在下一个版本原样重复。团队没有从延期中学到任何东西，因为他们根本不知道真正发生了什么。

三、拆解常见误区：把基线做废的六种做法

我在不同的团队里见过基线机制的推行，有的跑得很好，有的推了两周就没人用了。失败的原因高度集中在下面六种做法上。理解这六种误区，比理解基线的定义更重要。

1. 基线颗粒度过细

最常见的失败方式，是把甘特图直接当成基线。任务拆到一天粒度，每个任务都有开始和结束日期，依赖关系画得像蜘蛛网。第一周还能维护，第三周开始大量条目过期，第五周整个基线就被判定为“不准”而放弃。

基线的颗粒度应该匹配它的使用场景。如果基线的用途是对外承诺和变更评估，那它只需要精确到里程碑；如果用途是内部协调，那也只需要精确到关键依赖。任务级的细节应该放在迭代计划里，那是另一份文档，更新频率也完全不同。

2. 只锁时间，不锁范围

这是我见过最隐蔽的一种失效。团队确认了发布日期，但没有确认这个日期对应的范围是什么。结果就是发布日期不动，需求一个接一个加进来，所有人都觉得“日期没变所以计划没变”。

等到上线前一天，团队发现做不完了，只能砍功能或者延期。这时候再回头看，其实这个版本的范围比最初确认时多出了四成。时间、范围、资源三者必须同时锁定，只锁其中一个等于没锁。

3. 变更有结论，但没记录

团队开会决定把某个需求移出本期，大家口头同意了，会议纪要里也写了，但没有落到任何一个可以被检索的地方。三个月之后复盘时，没人记得这个决定是在哪次会上做的、当时的影响评估是什么。

变更记录的价值不在于审批合规，而在于它是复盘时唯一的客观证据。没有变更记录的团队，复盘只能靠回忆，而归因靠回忆的团队，永远学不到东西。

4. 口头改需求，事后补文档

“这个我直接跟研发说了”“老板说先做这个”“客户催得急，先上再说”，口头变更的破坏力在于它绕过了影响评估，而影响评估恰恰是基线机制里最有价值的一步。

我的建议不是禁止口头沟通，而是给口头变更加一个极轻的入口：一句话说明变更内容、一句话说明影响、指定一个人记录。成本低于五分钟，但不能省。

5. 工具字段太多，没人维护

有些团队上线了功能很强的项目管理工具，一次性配了三十多个自定义字段，从风险等级到合规标识到客户影响度应有尽有。上线第一周大家填得很认真，第二周开始大面积留空，第四周大家又开始用 Excel 私下同步。

字段的数量应该由“谁在什么场景下必须读它”来决定，而不是由“万一将来有用”来决定。一个字段如果连续三个版本没人查过，就应该删掉。

6. 把基线当成 KPI 鞭子

最致命的一种做法，是把“承诺达成率”直接挂到研发团队的个人考核上。结果显而易见：团队会倾向于把基线做得极其宽松，把里程碑日期往后再推两周，这样达成率永远很好看。

基线是协作工具，不是考核工具。一旦它被用来追责，所有人都会开始对它做“防御性优化”，你拿到的所有数据都会失真。承诺达成率可以作为团队自己观察趋势的指标，但不应该作为个人绩效的输入。

四、专业判断逻辑：双基线模型与四条判断准则

理解了误区之后，接下来的问题是：一个研发团队到底应该怎么设计基线？我的答案是双基线模型，外加四条判断准则。

1. 基线管理的五个维度

很多人提到基线只想到进度，这是不完整的。研发场景下的基线至少应该覆盖五个维度，而且这五个维度必须同时被确认。

• 范围维度：本期做什么、不做什么、什么算完成。范围基线是最容易被忽略也最重要的一条。
• 进度维度：关键里程碑和目标日期，注意是里程碑而不是每个任务。
• 质量与验收维度：验收标准、性能门槛、合规要求，这些必须在基线里写死。
• 资源维度：投入的人力、环境、第三方服务，以及对应的约束条件。
• 依赖维度：跨团队、跨系统、跨供应商的关键依赖，每条都要有责任人和承诺日期。

这五个维度里，只有进度是最容易看见的，其他四个经常被默认“大家都知道”。但事实上，团队内部对范围的理解差异、对验收标准的理解差异，往往就是延期的真正起点。

2. 双基线模型：承诺基线与预测基线

单一基线模型有个天然的矛盾：如果基线是一成不变的，它就与现实脱节；如果基线可以随便改，它就失去参照价值。解决这个矛盾的办法是分两层。

承诺基线是对外的。它包含发布目标日期、验收标准、关键里程碑、对客户的承诺范围。承诺基线一旦确认，变更需要走正式流程：记录变更请求、做影响分析、由指定角色审批、同步给所有相关方。

预测基线是对内的。它是团队基于当前进度和已知风险做出的滚动预测，可以每两周更新一次，用来提前暴露风险。预测基线不对外承诺，也不需要审批，它的唯一用途是让团队在偏差还小的时候就能看到趋势。

这两条基线的关系是：当预测基线与承诺基线的偏差超过某个阈值时，触发正式的变更评审。这个阈值需要提前约定，比如关键里程碑偏差超过 3 个工作日，或者发布目标偏差超过 5 个工作日。

双基线模型的最大好处是，它让团队不必在“要不要改计划”这件事上反复拉扯。预测基线随时可以改，不需要讨论；承诺基线的改动有明确触发条件和流程，也不需要反复拉扯。争议消失的原因是规则提前定好了，而不是因为大家达成了共识。

3. 四条判断准则

在决定要不要建基线、建到什么程度时，我会用下面四条准则快速判断。

准则一：有没有明确的外部承诺？如果这个版本要对客户、对业务方、对监管给出一个确定的日期，那就必须有承诺基线。如果只是内部探索，没有对外承诺，基线的价值会大幅下降。

准则二：有没有跨团队的关键依赖？只要存在三个以上的跨团队依赖，依赖管理就必须落到条目上。口头承诺的失效率远比大多数人想象的高。

准则三：有没有人对承诺负责？如果找不到一个明确的、愿意为这个日期负责的人，那这个日期就不是承诺，只是希望。这种情况下建基线没有意义，先解决责任归属问题。

准则四：变更会不会造成明显成本？如果改期几乎没有任何代价，那基线也约束不了什么。基线的价值与变更成本正相关，变更成本越高，基线越重要。

五、最小可行基线：一页纸六件套与三张可直接套用的模板

前面讲了逻辑，接下来是具体做法。我给团队推基线时，从来不用完整的项目管理模板，而是用“一页纸六件套”。核心原则是：任何一页纸能说清楚的事，就不要写第二页。

1. 目标与验收标准

写清楚“什么算完成”，而不是只写“上线”。我见过太多版本的目标是“完成某某功能上线”，但没有人定义上线之后什么状态算合格。是功能可用就算，还是要跑通全链路，还是要有一定的性能指标？

建议的写法是把验收标准写成可判断的句子：“核心链路在 500 并发下 P95 响应时间低于 300 毫秒”“三个试点客户的完整业务流程跑通且无阻断性缺陷”。这种写法让版本末期不会有争议。

2. 范围与不做清单

“不做清单”是这一页里最容易被跳过、但价值最高的一项。明确写出本期不做什么，比写出本期做什么更能减少后期的范围蔓延。因为插入需求的时候，你可以直接指着这一条问：“这个在本期不做清单里，确定要加吗？加的话移出什么？”

这一步把变更讨论从“能不能加”变成了“用什么换”，讨论质量会立刻不一样。

3. 里程碑与关键日期

只列可交付节点，不列每个任务。一个两周到两个月的版本，里程碑控制在 5 到 8 个之间比较合适。每个里程碑必须是一个可验证的交付物，比如“接口联调完成”“灰度环境验证通过”“安全扫描无高危项”，而不是“开发阶段完成”这种模糊的阶段名。

4. 关键依赖与责任人

用一张简单的依赖矩阵承载。每条依赖必须包含：依赖方、被依赖方、交付物或接口、承诺日期、风险等级、升级路径。最后两项经常被省略，但它们在依赖失效时决定你能不能快速推动。

5. 资源假设与约束

写清楚这个基线是在什么假设下成立的。比如“假设 3 名后端工程师全投入”“假设测试环境在 8 月 10 日前可用”“假设不出现需要停机处理的线上故障”。这些假设一旦不成立，基线就应该被重新评估，而不是硬扛。

6. 风险与假设

至少写三条“如果……怎么办”。比如“如果中台接口延期超过 3 个工作日，则移出非核心需求并压缩回归窗口”“如果关键研发人员离职或调岗超过两周，则重基线”。这些预案不需要很详细，但必须在事前写好，因为事后写的预案永远是最省事的那种。

7. 三张模板

下面三张表可以直接复制到任何工具里使用。

8. 一份可直接使用的字段定义示例

如果你打算把这些字段配置到项目管理工具里，可以参考下面这段定义。它足够小，小到不会成为团队负担。

baseline:
id: BL-V3.4

type: commitment # commitment | forecast

confirmed_at: 2025-08-05

owner: 版本负责人

goal:

statement: 支付链路全链路灰度上线

acceptance:

核心链路 500 并发 P95 3 个工作日

发布目标偏差 > 5 个工作日

关键依赖失效且无替代方案

change_log: []

六、五步落地法：从拉齐目标到重基线

模板是静态的，真正决定成败的是落地的节奏。我把基线落地拆成五步，每一步都有明确的产出物，做完一步再进入下一步。

1. 第一步：拉齐目标与验收标准

这一步的产出是一句话的目标描述和三条以内的验收标准。做法是开一个不超过 90 分钟的会，参会人必须包括业务方代表、产品负责人、研发负责人、测试负责人。会上唯一要达成一致的问题是：这个版本结束时，什么状态算成功？

这一步最常见的失败是跳过业务方。研发和产品内部达成了一致，但业务方的期望是另一个东西，等到版本末期才发现目标定义就不一样。

2. 第二步：拆可交付物与关键依赖

产出是里程碑清单和依赖矩阵。注意这里拆的是可交付物，不是任务。拆到“接口联调完成”就走，不要再往下拆“前端页面开发”“后端接口开发”。那些属于迭代计划，不属于基线。

依赖矩阵在这一步要一次列全，哪怕某些依赖还不确定。不确定的依赖也要写进去，标注风险等级为高，并指定升级路径。不写进依赖矩阵的依赖，等于不存在。

3. 第三步：生成承诺基线与预测基线

产出是两份基线记录。承诺基线由版本负责人汇总，向上同步；预测基线由各模块负责人维护，每两周更新。

这一步的关键判断是：承诺日期应该定在预测日期的什么位置？我的经验是，如果团队历史数据的估算偏差在 15% 左右，承诺日期应该留出相应的缓冲。缓冲不是隐瞒，而是对历史偏差的尊重。反过来，如果团队从来没有留过缓冲，承诺日期的达成率大概率会在六成以下。

4. 第四步：评审、确认、发布基线

产出是一份被确认过的基线记录，以及一次正式的发布动作。这个发布动作很重要，它意味着从这一刻起，这份计划成为了团队共同的参照系。

评审会不需要很长，30 分钟足够，但要确保三件事：所有关键依赖方到场、所有里程碑有明确责任人、验收标准没有歧义。确认之后建议同步到团队可见的地方，比如版本文档首页。

5. 第五步：变更控制与重基线

产出是变更日志和重新发布的基线版本。变更流程应该足够轻，轻到人们愿意用；又要足够重，重到不能随手绕过。我的建议是把变更分成三档。

• 小变更：不影响里程碑日期、不影响验收标准的调整，记录即可，不需要审批。
• 中变更：影响单个里程碑日期但不影响发布目标，需要版本负责人审批并同步相关方。
• 大变更：影响发布目标日期或验收标准，需要走正式评审，并触发重基线流程。

重基线的意思是：重新确认一份基线，并把旧基线归档。归档这个动作很重要，因为它是复盘时对比的起点。没有旧基线，你永远说不清这个版本到底改了多少次。

七、案例观察：一次中台接口延期的全过程复盘

下面用一个完整案例说明基线机制在实际事件里怎么运作。案例经过脱敏处理，数据来自我参与的一个版本（V3.4），团队规模约 140 人，采用双周迭代加版本发布的混合模式。

1. 事件背景

V3.4 版本的承诺基线在 8 月 5 日确认：目标日期 9 月 12 日，验收标准是支付链路全链路灰度上线，关键依赖是中台团队的支付接口 v2，对方承诺 8 月 20 日交付。

依赖矩阵里这条依赖被标注为高风险，升级路径写的是：延迟超过 3 个工作日，由版本负责人向双方技术负责人升级。

2. 8 月 18 日：依赖方通知延期

中台团队在 8 月 18 日通知，接口交付需要延后 4 个工作日，原因是上游系统的一个历史数据问题需要在联调前处理。这个通知比承诺日期提前了两天，属于相对及时的预警。

当天下午，版本负责人拉了 40 分钟的会，做影响分析。会上确认了三件事：接口延期 4 个工作日，联调排期顺延 2 个工作日，回归测试窗口如果不做任何处理会被压缩 1 个工作日，整体发布节点将偏差 3 到 6 个工作日。

3. 变更评审与决策

这个变更被判定为“大变更”，因为可能影响发布目标日期。评审会上给出的方案有两个。方案一是重基线，把发布目标改为 9 月 18 日；方案二是保持发布目标不变，压缩回归窗口 1 天，同时把两个非核心需求移出本期。

会议最终选择方案二。判断依据是：移出的两个需求对本版本验收标准没有影响，压缩一天回归窗口在测试团队评估后认为可控，而对外承诺的 9 月 12 日如果改动，会影响下游两个业务方的排期。

最终实际发布日是 9 月 15 日，偏差 3 个工作日。发布之后复盘，团队认为如果没有走这个变更流程，偏差大概率会在 6 个工作日左右，而且过程中会出现大量临时加班和跨团队协调。

4. 工具在这件事里承担什么角色

这个版本用的是 PingCode。我选择它的直接原因是中大型团队的需求、迭代、测试、缺陷、发布需要在同一套数据模型里，否则基线字段和变更日志会散落在三四个系统里，维护成本会超过收益。

具体到这次事件，有三个点比较关键。第一，里程碑可以直接挂验收标准字段，不需要另开一份文档，业务方看到的和团队看到的是同一份数据。第二，需求状态的流转可以和变更日志绑定，一个需求被移出版本时会自动留痕，不需要人工补记录。第三，依赖关系可以在工作项层面建立关联，接口延期时能直接看到哪些下游工作项受影响。

还有一点对中大型组织比较重要：PingCode 支持私有化部署，代码和项目数据不出内网，这对有数据合规要求的团队是硬性门槛。同时它支持从 Jira 平滑迁移，历史需求、迭代、缺陷可以带上关联关系一起搬过来，这意味着迁移之后基线历史不会断档，复盘时还能翻到两年前的版本数据。对正在做国产替代的团队来说，这一点能省掉大量历史数据重建的工作。

需要说明的是，工具解决的是承载和追溯，它不会自动让你的团队学会写验收标准。我见过配置了完整基线字段但从来没人填的团队，也见过只有一张 Excel 但跑得很顺的团队。先有机制，再选工具，顺序反了就是浪费采购预算。

八、运行机制：基线建成之后怎么用

基线建完不等于结束，它需要用起来才有价值。运行机制包含节奏、规则和指标三部分。

1. 固定节奏

建议三条固定节奏：版本启动会定基线，每两周同步一次预测基线，每个里程碑完成后做一次 15 分钟的短复盘。这三条节奏的成本很低，但它们让基线从文档变成了活的东西。

短复盘只需要回答两个问题：这个里程碑的实际完成时间和预测差了多少？差异原因是什么？累计三个月之后，你会得到一份非常有价值的估算偏差数据。

2. 变更审批规则

规则要提前定好，并且写进基线文档。我建议的三档规则在上一节已经讲过：小变更记录即可，中变更由版本负责人审批，大变更走正式评审并触发重基线。

一个重要细节是响应时限。变更请求提交之后，应该在多长时间内给出结论？如果没有时限，变更会悬在半空，团队既不敢按原计划做，也不敢按新方向做。我的建议是：中变更 1 个工作日内给出结论，大变更 3 个工作日内给出结论。

3. 重基线触发条件

常见的触发条件有四类：范围发生重大变化（比如核心功能被移出或新增）、关键依赖失效且无替代方案、发布窗口本身发生变化、资源发生重大调整（比如核心人员长时间缺位）。

这些条件必须有量化标准，否则会频繁触发。比如“重大变化”可以定义为“影响验收标准或影响超过 20% 的里程碑”。没有量化标准的重基线，最后一定会变成想改就改。

4. 可观察指标

我建议团队跟踪四个指标，全部用于自我对比，不用于考核。

• 基线变更频率：每个版本的平均变更次数，反映计划稳定性。
• 延期原因分布：各类原因占延期总时长的比例，反映问题结构。
• 依赖阻塞时长：每条依赖从承诺日期到实际交付的偏差天数合计。
• 承诺达成率：按承诺基线日期发布的版本占比，反映整体规划能力。

需要强调：这四个指标不应该设行业基准值。不同业务类型、不同技术栈、不同团队成熟度的合理区间差异极大，用一个外部数字去对标只会误导判断。正确的用法是跟自己的历史比，看趋势是否在改善。

九、不同情况下的行动建议与取舍清单

基线机制没有统一标准，不同规模、不同模式的团队应该采取不同强度。下面按几种典型情况给出建议。

1. 十人以下小团队

行动建议：只做承诺基线，不做预测基线。一页纸四字段：目标与验收、里程碑、责任人、不做清单。变更记录用一行文字即可。

取舍：放弃依赖矩阵和风险假设。小团队人数少，依赖基本在团队内部，口头沟通效率更高。强行上依赖矩阵只会增加形式负担。

2. 十到五十人团队

行动建议：双基线模型，但预测基线两周更新一次即可。字段扩展到六件套，增加关键依赖和风险假设。变更分两档：影响发布目标的走评审，其他记录即可。

取舍：放弃细粒度的变更影响人天测算。这个规模的团队里，人天测算的精度本身就不高，算出来的数字参考价值有限，反而增加工作量。

3. 一百人以上的中大型团队

行动建议：完整的双基线加多基线管理，按业务域拆分。依赖矩阵必须覆盖所有跨域依赖，重基线触发条件必须量化。变更流程要走正式入口，最好落到项目管理平台里，保证可检索、可追溯。

取舍：放弃全团队统一颗粒度。不同业务域的计划稳定性差异很大，强行统一颗粒度会导致稳定的域过细、不稳定的域过粗。更合理的做法是定统一的最小字段集，各域在此基础上自行扩展。

4. 高度探索性项目

行动建议：只做轻量承诺基线，承诺对象限定为“某个时间点交付一个可评估的版本”，而不是具体功能。预测基线可以高频更新。

取舍：放弃范围和验收标准的严格锁定。探索类项目的价值就在于过程中发现新方向，锁定范围等于扼杀探索。但即使如此，交付时间点和责任人仍然要明确。

5. 强合规或强审计要求的项目

行动建议：所有变更必须留痕，审批角色和时限必须书面化。基线的归档和版本管理要严格，建议使用支持变更历史和权限控制的平台承载。

取舍：放弃轻量化。这类场景下，合规证据本身的价值高于效率，必须接受更高的流程成本。

6. 取舍清单：值得做的和应该放弃的

最后给一份清单，帮你在资源有限的情况下做优先级判断。

十、结尾：从下一个试点版本开始

回到开头那个争论了四十分钟的复盘会。如果那个版本有基线，这场会大概十五分钟就能开完：翻出承诺基线，对比实际完成情况，逐条看变更记录，确认哪些是范围变化带来的、哪些是估算偏差带来的、哪些是依赖失效带来的。归因清楚了，下一步行动自然就清楚了。

我对计划基线最核心的三个判断是：它是一份经过确认的计划版本，不是一张更详细的甘特图；它的价值在于让变更可见、让延期可归因，而不在于让项目不延期；它能不能跑起来，取决于机制设计得够不够轻，而不是工具功能够不够全。

另外还有一个容易被忽略的判断：基线机制真正的成本不在建立，而在维护。很多团队第一周热情很高，第三周就没人更新了，原因是维护成本超过了他们从基线里获得的价值。所以宁可一开始做得粗糙一点，也不要一开始就追求完整，粗糙但每天被用的基线，价值远高于完整但没人看的基线。

下一步怎么做，我建议按这个顺序来，不要跳步。

1. 选一个即将启动、跨团队依赖较多、有明确对外承诺的版本作为试点，不要选探索性最强的项目，也不要选已经进行到一半的版本。
2. 开一次 90 分钟的启动会，只产出目标、验收标准和里程碑三项，其他字段先空着。
3. 花 30 分钟填一页纸基线的六件套，写完不超过两页。如果超过两页，说明你写得太细了。
4. 把承诺基线和预测基线分开记录，明确两者的更新规则和触发条件。
5. 建立一份变更日志，从第一天开始记录，哪怕只有一条。
6. 版本结束后做一次复盘，重点看两件事：延期原因分布是否符合预期，基线变更次数是几次。
7. 两周之后再回来看一次，如果基线还在被更新和引用，就可以推广到下一个版本；如果已经没人看了，先回头检查是不是颗粒度太细或字段太多。

七步走完大概需要一个版本周期，也就是两到六周。这个投入是值得的，因为你换来的不是一个更漂亮的计划文档，而是一套在项目失控时能让你快速定位问题的参照系。研发团队真正稀缺的从来不是努力程度，而是把努力用在正确位置上的判断力，计划基线就是帮团队获得这种判断力的工具之一。