迭代规划怎么做？产品经理最佳实践：需求排期从0到1

迭代规划最容易出问题的时刻，往往不是团队没有需求，而是每个人都认为自己的需求“已经排好了”：产品经理按业务价值排序，研发按技术依赖估算，设计按交付日期承诺，最后却发现关键接口尚未确认、测试时间被挤掉，迭代中途又插入了紧急事项。我的判断是，需求排期从 0 到 1，不是把需求按优先级塞进日历，而是把目标、容量、依赖和风险放到同一张决策桌上。下面我会用一个明确标注为情景模拟的案例，拆解从需求池到迭代承诺的完整做法，并说明不同团队规模下该如何取舍。

一、先讲核心结论：迭代规划不是排满，而是做出可兑现的承诺

1. 先定义迭代规划的交付物

一场有效的迭代规划结束时，团队至少应该带走四样东西：一个清楚的迭代目标、一组经过澄清的候选需求、一份考虑容量和依赖的承诺范围，以及一份记录风险与取舍的决策。少了任何一项，排期都可能只是表格看起来完整，而不是团队真正对交付达成共识。

其中最重要的不是需求清单，而是迭代目标。需求清单回答“做什么”，目标回答“为什么这些事情值得一起做”。当范围发生变化时，目标是判断取舍的锚点；没有目标，团队只能按提出者声音大小或需求标题顺序争抢容量。

例如，“完成登录改版、导出优化、消息提醒”只是任务集合；“降低新用户首次操作的卡点，并让运营能独立完成基础数据复盘”才是目标。后者能帮助团队判断：如果导出优化与新用户激活无关，它是否应该占用本轮容量？如果消息提醒是新用户完成关键操作的必要条件，它是否比界面细节更优先？

2. 规划的基本顺序是先约束、再排序、后承诺

我建议将顺序固定为：明确业务结果，核验需求准备度，估算可用容量，识别依赖与风险，形成候选范围，最后由团队确认承诺。常见反模式恰好相反：先把需求排出优先级，再把估算结果塞进迭代，最后才发现目标、容量和依赖彼此冲突。

优先级不是承诺。一个需求价值很高，并不代表它已经可以进入本轮；它可能缺少规则说明、外部接口尚未确认，或关键设计仍在变化。“值得做”与“现在能做”是两个不同判断。规划时需要分别回答，而不是用一个优先级字段替代所有决策。

3. 规划质量要看兑现与结果，不看排了多少项

如果一轮迭代排了二十个需求，最后完成十八个，但最重要的业务目标没有变化，这不能算规划成功。反过来，团队在发现关键依赖不成立后，主动缩小范围，完成核心目标并明确延期事项，通常比“全部都先放进去”更健康。

因此，我会同时观察范围兑现、目标达成、变更来源和质量结果。完成率用于复盘预测能力，但不能单独当成团队绩效；否则团队可能通过少承诺、挑简单事项来美化数字，或者把未完成工作反复挪到下一轮。

二、背景和真实场景：为什么从 0 到 1 最容易把排期做成许愿清单

1. 新团队往往没有可用的历史预测基线

成熟团队可以参考过去几轮的完成量、缺陷返工、临时插单和人员缺勤情况；刚组建的团队通常没有可信基线。此时照搬别的团队的速度，或者把每个人的口头估时相加，容易制造虚假的精确感。数字写得越细，不代表判断越可靠。

从 0 到 1 的首轮规划，我会把重点放在建立共同语言，而不是追求一次预测准确。团队需要确认什么算“完成”、估算是否包含测试和联调、线上问题如何处理、需求变更如何记录，以及谁有权调整范围。这些约定比把工作量估算到小数点更有价值。

如果团队没有历史数据，可以先选一个范围有限、依赖较少的目标作为校准轮。规划时记录估算和实际投入，迭代结束后把偏差拆成需求理解偏差、技术不确定性、跨团队等待、返工、人员可用性等原因。两三轮后，团队才开始拥有自己的预测依据。

2. 需求来源不同，不能用同一把尺子直接比较

产品改进、客户承诺、故障治理、平台建设和合规事项的价值表达方式并不相同。客户承诺可能有明确窗口，故障治理要看影响范围和发生概率，平台建设的回报可能体现为后续交付成本下降。如果只按“商业价值 1 到 5 分”排序，无法解释这些需求为什么互相胜出或落败。

我会先把候选事项归入几类，再用适合该类的证据讨论优先级。比如，合规事项要标出截止日期和不做的后果；体验改进要说明受影响的人群、行为路径和预期变化；基础建设要展示当前重复成本或风险暴露。类别不是为了增加流程，而是避免把无法比较的价值伪装成统一分数。

3. 计划失败常常来自系统性等待，而非个人速度不足

看似研发估时不准的问题，可能实际上是需求规则反复变化；看似测试效率低的问题，可能是可测试版本太晚出现；看似跨团队配合差的问题，可能是接口负责人、交付时间和验收方式都没有明确。只看个人工作量，会把系统等待误诊成个人执行问题。

在规划会上，我会追问每个关键事项的“第一步何时能发生”和“最早何时能被验证”。如果工作从开发开始到可验收之间有一段无人负责的等待，计划中就应当显式呈现，而不是默认为它会自动消失。排期的目的之一，正是让隐性等待变成可讨论的约束。

三、常见误区：看似流程完整，实际把风险推迟到迭代中段

1. 误区一：把优先级高直接等同于本轮必做

高优先级意味着应该优先处理，并不自动证明它已经适合进入本轮。需求如果缺少验收条件，团队会在开发中不断确认“这是不是你想要的”；如果核心规则仍在讨论，估算就只是基于假设的数字。

我的做法是把优先级与准备度分开记录。优先级回答价值顺序，准备度回答进入执行的条件。一个高价值但未准备好的需求，可以被列为下一轮候选，并安排澄清动作；不要为了显得积极，把不确定性藏在迭代承诺里。

2. 误区二：把所有人的工作量相加，当成团队容量

团队容量不是每个人理想状态下能投入的小时数总和。会议、值班、支持、休假、代码评审、联调和测试都会占用时间，而且这些工作并非能被随意压缩。把八小时工作日直接乘以人数和迭代天数，通常会高估可用开发时间。

更重要的是，容量还受关键技能限制。总工作量看起来够，不代表某个需求所需的唯一后端、设计或测试资源有空。对关键角色来说，瓶颈可能比团队总人天更有解释力。容量评估要同时看总量和资源分布。

3. 误区三：把估算当作承诺，把不确定性藏在平均数里

估算是对工作量或复杂度的判断，承诺是团队依据目标、容量和风险作出的选择。两者混为一谈，会让估算变成谈判工具：需求方希望数字更小，交付方担心被追责，于是大家最终得到一个既不可信也不能用于决策的数字。

当团队对某项工作估算分歧很大时，不要急着取平均值。分歧往往说明大家对实现路径、边界条件或依赖理解不同。先让估算高低两端分别讲清假设，再决定补充探索、拆分需求，还是按较高风险预留缓冲。

4. 误区四：用缓冲百分比掩盖计划本身的问题

预留容量有必要，但“统一留 20%”不是适用于所有团队的科学结论。新团队、依赖多的项目、故障率高的系统和需求稳定的内部工具，风险结构不同，缓冲比例也不应机械一致。

更好的方式是说清楚预留用来承接什么：线上支持、未知技术风险、跨团队等待，还是临时业务事项。若预留容量连续几轮都被同一种问题消耗，就不应只增加缓冲，而应解决问题来源。缓冲是风险管理手段，不是无限扩张范围的许可证。

5. 误区五：迭代中途插单只改任务，不重算承诺

新增紧急需求会占用现有容量，若只把它加进任务板，却不明确移出什么，团队实际承诺就被悄悄扩大了。随后未完成项增加，复盘时又被解释成“执行不够努力”，这会让计划数据失去意义。

每次插单都应记录来源、原因、预估工作量、影响目标以及替换掉的事项。若确实没有可替换事项，团队也要明确接受目标或质量风险，而不是假设新增工作没有成本。

四、专业判断逻辑：从需求池到迭代承诺的七步法

1. 把迭代目标写成可验证的结果

目标最好包含对象、变化和验证方式。比如“让运营能独立完成月度渠道数据核对”，比“优化报表能力”更容易指导范围判断。目标不一定必须写成收入增长，也可以是降低错误率、缩短处理时间、减少人工步骤或满足明确的风险控制要求。

如果目标完全不能被验证，先别急着排需求。至少需要说明观察什么行为、在哪个范围观察、何时判断是否有效。对尚无可靠指标的探索型工作，可以把目标写成验证假设，例如“确认主要用户是否能在不依赖培训的情况下完成首次导入”，并明确验证样本与成功条件。

2. 做一次需求准备度检查

准备度不是要求所有需求都写成厚重文档，而是确认团队能够在不靠猜测的情况下开始工作。对于每个候选项，我会检查问题描述、目标用户、触发场景、验收条件、异常路径、依赖对象和设计状态。

检查时不必简单打勾。若缺少的信息会改变工作量或业务结果，就应当成为阻塞项；若只影响实现细节，且团队能在执行中安全决策，可以记录为开放问题。关键判断是：缺失信息是否会导致返工、越权决策或不可验证的交付。

3. 估算容量时从可用事实开始

对没有历史数据的团队，可以从成员实际可投入时间估算，再扣除已知休假、固定会议、值班和支持职责。这里的目标不是得到绝对精准的小时数，而是避免把不可用时间算进计划。若团队已有多轮数据，则优先参考过去相似长度迭代的实际完成量，并解释异常轮次。

我会把“容量”至少拆成两层：团队总容量与关键角色容量。比如总容量看似有 100 人时，但所有候选工作都依赖同一位工程师完成接口改造，那么该工程师的可用窗口才是实际约束。计划不应只看总量，也要看工作流是否能顺畅流动。

估算口径也要统一：故事点、理想人时、任务小时不能在同一张表里直接相加。不同方法都可以使用，关键是团队理解其含义并持续使用。对于刚起步的团队，先用相对复杂度做讨论，再记录实际耗时，往往比过早追求精细时长更稳妥。

4. 用价值、紧迫性和不确定性共同筛选候选项

排优先级时，我不会迷信单一公式。可以先用价值与紧迫性形成初步顺序，再单独标注不确定性和成本。价值高、窗口明确、准备度充分的事项通常适合优先；价值高但技术不确定的事项，可能应该先安排短时探索，而不是直接承诺完整交付。

一种实用的讨论方式是分别给业务价值、时间敏感度、风险降低或机会打开程度、实现成本做粗粒度评分。评分只是促成讨论，不是自动决策。若一个需求的高分来自一个未经验证的假设，就应降低置信度，或把验证工作拆出来单独评估。

对于紧急但价值有限的需求，要追问“不做的后果”和“最后决策时间”。如果只是提出者希望尽快看到结果，而没有窗口、风险或用户损失，可能并不是真正紧急。把紧急性说清楚，能减少“所有事情都是最高优先级”的噪声。

5. 识别依赖，先排出路径而非只排单项

某些需求单独看工作量不大，却依赖数据迁移、权限调整、外部接口或内容准备。把这些工作放在同一迭代里，未必就能降低风险；如果依赖方无法按时提供输入，后续事项依然会停滞。

我会标出每项关键需求的前置条件、责任人、最迟确认时间和失败时的替代方案。若依赖尚未解除，可以先安排不受影响的探索或可并行工作，但不能把“预计对方会完成”写成已确认事实。

6. 进行团队承诺，而不是由产品经理单方面塞单

产品经理负责解释目标、价值和需求边界；研发和测试负责判断实现路径、质量工作和依赖风险；设计、数据或运营等角色则在涉及各自职责时提供约束。最终承诺应由实际承担交付的团队共同确认，而不是由一个人依据估算表独自拍板。

讨论时可以从目标倒推范围：若本轮只能保住一个结果，什么是不可缺少的？哪些是体验增强，哪些可以后续补齐？哪些工作是完成目标所必需的质量保障？这一轮必须把“功能范围”与“质量门槛”一起承诺，不能用砍测试换取表面上的需求完成率。

7. 写清楚变更规则和退出条件

迭代开始前，应约定哪些情况可以触发范围调整，以及调整时由谁参与决策。安全、生产故障、法规变化等可能需要快速响应；普通优化则应进入候选池，不应因为临时提出就自动插入。

退出条件同样重要。如果关键依赖在某个时间点仍未解决，团队需要知道是换方案、缩小范围、移出迭代，还是接受延期。没有退出条件的风险项，会在每天的站会上反复出现，却没有人真正做决策。

五、案例与数据观察：用一个模拟迭代演示怎么从需求池收敛范围

1. 案例边界：以下是情景模拟，不是某公司的真实业绩

为了演示取舍，我设定一个 6 人跨职能团队，计划进行两周迭代。团队包括产品、设计、前端、后端和测试角色；其中有人需要承担线上支持，期间还有成员请假。以下工作量、容量和结果均为情景模拟数据，不代表行业均值，也不应直接作为其他团队的预测基准。

团队的业务目标是降低首次数据导入过程中的失败与人工求助。需求池里有五项候选工作：优化导入提示、增加失败原因明细、支持历史数据批量导出、补充操作权限说明、重构导入任务状态。团队先核实这五项与目标的关联，再看准备度、估算和依赖。

2. 先算可用容量，再看需求是否适配

模拟团队初步核算得到 160 人时的名义工作时间，扣除休假 16 人时、固定会议与协作 24 人时、线上支持预估 18 人时后，得到约 102 人时的计划容量。团队没有把 102 人时全部填满，而是为尚未确认的错误码映射和联调等待预留了 14 人时，因此本轮可承诺范围约为 88 人时。

这并不意味着每个团队都应预留 14 人时。这个案例的预留来自具体风险：错误码定义仍有少量待确认，且导入链路需要跨模块联调。如果后续数据证明这类等待稳定下降，团队可以调整预留；如果预留连续被故障支持消耗，应该改善支持机制，而不是长期把风险隐藏在容量折扣里。

接下来，团队没有按“估算从小到大”选需求，而是按目标贡献和风险来组合。优化导入提示和失败原因明细直接服务目标；权限说明只有在确认相关用户确实因权限失败时才进入；批量导出虽然准备度高，却与本轮目标联系较弱；状态重构则先做技术探索，避免在信息不足时承诺完整改造。

3. 取舍结果：承诺核心路径，探索高不确定性

本轮情景承诺包括优化导入提示、失败原因明细的最小可用版本，以及一项小范围的权限提示修正。失败原因明细先覆盖最常见的几类错误，不追求一次性解释所有边界情况。团队将剩余时间用于联调、验证和缺陷处理，并设置错误码确认的决策节点。

历史数据批量导出移至后续候选，不是因为它没有价值，而是因为它对当前目标的贡献较弱。状态重构拆出一个短时探索任务，先确认异常状态的发生频率、修复成本和影响模块，再决定是否需要完整重构。这样做把“可能很重要”变成下一轮可以验证的证据，而不是一次性背上 36 人时的模糊承诺。

迭代结束时，团队记录四类数据：承诺范围完成情况、目标指标变化、临时工作占用、需求返工来源。假设模拟结果为：核心功能按期上线，人工求助率从每百次导入 18 次降到 12 次，失败原因仍有 8% 无法归类。这个结果说明方向有改善，但并不证明所有变更都由本轮功能造成；还需要看样本规模、用户结构、同期活动和测量口径。

4. 观察结果时，避免把相关变化说成因果证明

如果人工求助率下降，产品团队很容易把变化全部归因于新提示。但同期也可能有用户培训、数据质量变化、流量结构变化或运营支持增加。复盘时至少要记录指标定义、观察周期、样本量和同期干预，避免用单一前后对比包装确定性。

对于样本较少的业务，可以补充定性证据：用户是否更快找到错误原因、客服工单中相关问题是否减少、用户是否仍需人工解释。量化数据告诉我们变化幅度，访谈和操作观察帮助解释变化机制；两者相互校验，比单独引用一个百分比更可靠。

六、不同情况下怎么行动：把方法调整到团队的真实约束

1. 新团队没有历史数据时

第一轮不要用外部团队的吞吐量给自己定目标。先选依赖少、范围可控的事项，统一完成定义，记录计划与实际差异。团队应重点观察估算偏差来自哪里，而不是急着给成员贴上“快”或“慢”的标签。

可以把首轮视为校准迭代，但不能因此放弃业务目标。选择一个小而可验证的结果，并明确哪些事项是试验、哪些是承诺。结束时把真实可用时间、返工、等待和支持工作记录下来，第二轮再基于本团队事实调整计划。

2. 需求高度不确定时

不确定性高不等于不能做，而是不能把完整方案假装成已知。先拆出验证假设所需的最小工作，例如技术原型、用户访谈、数据抽样或规则梳理，并规定探索结束后要产出什么决策。

探索工作也要有边界：时间上限、需要验证的问题、成功或失败的判断条件。否则“先研究一下”可能无限延长。若探索结果无法改变下一步决策，就不值得占用迭代容量；若它能避免大规模返工，就可能比立即开发更有价值。

3. 有明确外部截止日期时

截止日期真实且不可移动时，优先确认最小合规或可交付范围，并把审批、验收、发布和回滚时间倒推进去。不要只按研发完成日倒排，忽略业务验收和上线窗口。若外部依赖尚未确认，应尽早升级风险，而不是把希望当作计划。

此类事项的优先级还要结合不做的后果。若错过期限会导致合同损失、服务中断或合规风险，应该明确它对其他承诺的挤出影响；必要时减少并行需求，而不是要求团队在不变容量下完成更多工作。

4. 生产支持和临时工作较多时

如果线上支持反复打断迭代，先统计支持工作发生频率、响应时长和需要的技能，而不是每轮临时扣一个随意比例。团队可以轮值、设立响应窗口，或把常见问题自动化，减少所有成员同时被打断的成本。

对于真正无法预测的工作，可以采用明确的容量池或专门响应角色；但要持续检查它是否被稳定利用。若某类支持长期占据大量容量，它已经不是偶发噪声，而是产品或运维能力的结构性工作，应进入规划视野。

5. 跨团队依赖很多时

将依赖拆为可验证的交付物：谁提供什么、最晚何时可用、如何验收、延期时有什么替代方案。只写“依赖某团队支持”不够，因为它没有责任边界，也不能用于判断风险是否解除。

若关键依赖的时间无法控制，应考虑把本轮目标拆成可独立交付的部分，或者将依赖方确认作为进入承诺的门槛。并行开发只有在输入稳定且接口约定清楚时才真正并行；否则可能只是提前制造返工。

6. 管理层要求提高确定性时

确定性不等于承诺更多细节。对于范围、依赖和技术路径都未确定的工作，准确承诺发布日期很难成立。更可靠的沟通是提供区间、关键假设、最晚决策点以及改变预测的条件。

如果必须在特定日期给出承诺，就需要同步明确范围边界和质量底线。可通过减少非核心功能、增加必要资源、降低并行任务或调整验证方式来管理风险，但每一种办法都对应成本。没有成本的“提速”，通常只是把压力转化为返工或质量债务。

七、不同情况下如何取舍：目标、速度、质量与灵活性不能同时最大化

1. 取舍核心功能与完整体验时

若目标是验证用户是否愿意完成某个关键动作，可以先交付覆盖主路径的最小版本，但必须保留基本错误处理、数据安全和可理解性。不能把“最小可用”解释成“只要能演示”，更不能把明显会误导用户的状态留给后续修补。

如果功能一旦上线就会影响大量用户、形成数据不可逆操作，或者涉及权限与隐私，完整验证和防护应优先于缩短交付时间。版本大小可以缩小，质量底线不能被随意拿来换进度。

2. 取舍新增功能与技术债务时

技术债务不应仅凭“代码看起来不好”获得优先级，也不能因为用户看不见就无限延期。讨论时要把债务与可观察成本关联起来：每次改动多花多少时间、故障影响多少用户、发布频率受何限制、维护知识是否集中在少数人身上。

如果技术问题持续拖慢目标交付，可以把一部分迭代容量用于风险降低，并设置可验证结果，例如减少构建失败、缩短部署时间或降低重复故障。若债务只是局部代码风格问题，且对当前目标和风险影响很小，则可排在更紧迫事项之后。

3. 取舍临时插单与原有目标时

先判断临时事项是否满足明确的紧急标准：是否存在安全或生产风险、外部窗口是否即将关闭、用户损失是否正在扩大、是否有可行替代方案。仅仅因为需求方级别高或表达强烈，不足以证明插单合理。

若决定插入，应同步明确移出或延后的事项，更新目标风险，并通知相关决策者。若没有事项可以移出，团队就要明确承诺被扩大后的影响；不能在计划不变的情况下把增加的工作成本隐去。

4. 取舍准确预测与快速调整时

外部变化频繁的团队，过度追求一次性准确预测，可能花很多时间维护一份很快失效的计划。此时可以采用较短的规划周期、固定的决策检查点和清晰的范围调整规则，让预测随着新信息更新。

相反，对于审批复杂、发布窗口固定或上下游准备时间长的工作，较早做依赖和路径规划更重要。灵活不是随意变更，稳定也不是拒绝变化；两者的平衡点，取决于变化成本和错误承诺的代价。

八、复盘与持续改进：让下一轮比这一轮更会预测

1. 复盘先看偏差机制，不先追责个人

迭代结束后，先对照目标、承诺范围、实际交付和临时工作，再解释偏差。未完成事项可能来自估算偏差、需求变更、依赖等待、缺陷返工、容量变化或优先级调整。若不区分原因，只用“执行不力”概括，就无法知道下一轮应该改什么。

复盘最好保留少量稳定指标，例如承诺范围完成情况、目标指标变化、计划外工作占比、等待与返工时间、发布后缺陷情况。指标不必越多越好；每项指标都要有明确口径和使用目的，否则团队会花更多时间争论数字而非改进流程。

2. 把计划外工作记录成可分析的数据

临时工作不能只在复盘时凭记忆估计。可以在任务或事件记录中标明来源、类型、投入时间、影响范围和是否打断原计划。连续几轮后，团队能够判断支持工作究竟是少数突发事件，还是稳定存在的工作流。

若计划外工作占比持续升高，解决方案可能是改善故障治理、建立专门轮值、优化需求入口或减少无效会议，而不是在每轮计划中不断降低目标。数据的价值在于帮助团队找到结构性原因，而不是制造新的绩效排名。

3. 关注完成质量和目标结果的滞后效应

部分结果不会在迭代结束当天显现。用户行为、续用率、支持成本和业务转化可能需要更长时间观察。迭代复盘可以先确认功能是否按质量要求交付，之后再在约定时间回看业务指标，避免把短期波动误读成长期效果。

如果上线后指标没有变化，也不一定代表需求毫无价值。可能是触达不足、样本太小、测量链路有问题，或者用户问题并非产品团队最初假设。团队需要判断是继续观察、调整方案，还是停止投入，而不是为了证明原计划正确而不断增加功能。

4. 工具的作用是让决策可见，而不是替团队做判断

当需求、迭代、缺陷和发布信息分散在多个表格、聊天记录和文档中，团队很难还原某次取舍为什么发生。某项目管理平台或团队协作工具可以帮助团队集中维护需求状态、责任人、依赖、变更记录和目标关联，但工具字段本身不会让需求变得清楚。

我通常先定义团队的最小信息模型，再决定是否配置工具：需求要能关联目标，迭代要能显示承诺范围，变更要能留下原因，风险要有责任人与时间点，复盘要能回到实际结果。若工具流程要求成员重复录入同一信息，或字段过多却无人使用，应该先简化流程，而非继续增加表单。

九、下一步怎么做：用一周建立第一个可复盘的迭代计划

1. 第一天：确定目标和候选池边界

把需求集中到一个候选池，去重并标注来源。产品经理与业务方先确认本轮最重要的一个结果，以及哪些需求不属于这个目标。若确有多个目标，说明排序依据，不要把所有目标都写成“最高优先级”。

2. 第二天：集中澄清关键需求

对可能进入本轮的候选项补齐用户场景、验收条件、异常路径和依赖信息。无法当天澄清的项目，明确负责人和最晚决策时间；不满足开工条件的事项先留在候选池，不用模糊承诺填满计划。

3. 第三天：核对容量与关键角色窗口

统计团队实际可用时间，扣除已知休假、固定支持和协作工作。再检查关键角色是否形成瓶颈，以及跨团队依赖是否有明确交付时间。容量评估必须写明假设，避免数字脱离背景被当成硬指标。

4. 第四天：团队共同选范围并记录取舍

从目标倒推不可缺少的工作，再讨论增强项、探索项和延期项。每次纳入高风险需求时，都要说明它替代了什么、风险由谁跟进、什么情况下退出本轮。确认范围之后，再将目标、承诺、依赖和质量要求同步给相关人员。

5. 迭代过程中：按触发条件调整，而不是默默扩张

定期检查目标是否仍成立、阻塞是否解除、工作是否偏离原假设。遇到新事项时，先评估紧急程度与影响，再按预设规则决定接受、替换、拆分或延期。重要变化要留下决策记录，让所有人看到计划为什么改变。

6. 迭代结束后：用事实校准下一轮

记录承诺完成情况、实际目标表现、计划外工作、等待与返工原因。选择一到两个最能解释偏差的问题进入改进，不要一次性发起十几项流程整改。下一轮验证改进是否有效，再决定保留、调整或撤销。

我对迭代规划的最终判断是：它不是提高需求装载率的技巧，而是让团队在信息不完整时，仍能明确目标、暴露假设、控制风险并兑现承诺的决策机制。第一次规划不必完美，但必须留下可验证的目标、可解释的取舍和可复盘的数据。现在就可以从手头需求池中挑出一个目标，逐项检查准备度、容量和依赖；先做一轮小范围、真实可复盘的计划，再用团队自己的数据建立预测能力。

常见问题解答（FAQ）