迭代管理如何做好迭代目标？项目负责人实操方法与操作步骤

迭代管理如何做好迭代目标？项目负责人实操方法与操作步骤

迭代计划会上，团队把需求排得满满当当，到了迭代结束却只交付了零散功能，核心用户问题依旧没解决，这通常不是团队不够努力，而是迭代目标被写成了任务清单。做好迭代目标，关键不是承诺“完成多少项”，而是说明“为谁解决什么问题、用什么结果证明、遇到什么情况及时调整”。

一、核心结论：目标要描述结果，任务才描述工作

1. 先把“做什么”改写成“要改变什么”

我判断一个迭代目标是否合格，通常先看它能不能回答三个问题：目标用户是谁？当前遇到什么困难？迭代结束后，哪个可观察的结果会发生变化？如果目标只能回答“做一个页面、加一个按钮、完成接口开发”，它描述的是工作，而不是价值。

例如，“完成批量导入功能”是交付项；“让运营人员能够在不逐条录入的情况下导入一批有效数据，并在错误记录中定位失败原因”才接近目标。后者仍需补充验收口径，但已经把团队注意力从实现清单转向用户结果。

一个好目标不是把需求标题换个说法，而是把这一轮迭代的价值边界说清楚。团队可以在目标下拆出多个需求、缺陷和技术任务，但不能反过来把一串任务拼在一起，就当作目标已经明确。

2. 目标、范围、验收口径要同时成立

目标说清楚价值，范围说明本轮做什么与不做什么，验收口径说明如何判断结果。三者缺一不可：只有价值没有范围，讨论容易发散；只有范围没有价值，团队会忙于交付却不知道为什么；没有验收口径，迭代结束后就容易陷入“做了很多，算不算完成”的争论。

3. 目标不是承诺所有需求都完成

迭代目标是团队在已知条件下作出的结果承诺，不是把所有干系人的愿望都装进一个周期。依赖未确认、方案未验证或人力被临时抽走时，目标需要重新评估。比起维持一个看似完整的计划，更重要的是尽早暴露承诺背后的风险。

我更愿意把迭代目标看作“优先级最高的一组结果”。团队可以完成目标之外的小项，但如果目标本身未达成，仅仅因为关闭了很多任务，也不能把这次迭代描述为成功。

二、背景和真实场景：为什么计划很满，目标仍然落空

1. 多团队协作让“等别人”变成隐形工作

在单一小团队里，目标含糊有时可以靠当面沟通补救。到了多个产品小组、研发团队和业务部门并行协作时，情况会变复杂：接口由另一组提供，数据口径由业务确认，权限由平台团队配置，测试环境还需要排期。任何一项依赖没有明确负责人和时间点，都可能把一个看似完整的目标拖到周期末。

因此，我在评审目标时不会只看需求本身，还会追问它的上游输入是否可用、跨团队交付是否有明确承诺、失败时有没有替代路径。计划里写着“联调”，并不等于依赖已经解决；真正有用的是知道谁在什么时间提供什么，以及延误会影响哪项结果。

2. 临时插单会改变目标，不只是增加几张卡片

插单常被描述为“只多一个小需求”，但它带来的成本通常不止开发工时。团队要重新理解背景、切换上下文、调整测试范围，有时还要改动已经评审过的方案。若负责人只把插单添加到看板，却不拿掉或推迟原有工作，团队就会在不知不觉中背上双重承诺。

所以，迭代中途接纳新工作时，我会要求同时回答两个问题：这项工作为何必须现在做？为它腾出容量后，原目标中的哪一部分要降级、延期或拆分？如果没有明确的交换条件，插单实际上是在扩大范围，而不是在管理优先级。

3. 交付完成不等于用户价值已经验证

产品团队往往容易统计“完成了多少需求”，却较少追踪功能上线后是否被目标用户使用、问题是否减少。迭代周期通常短于用户行为变化周期，不能要求每个结果都在两周内完全显现；但团队至少应该提前定义一个可以追踪的近期信号，例如试用完成率、错误反馈量或人工处理耗时。

对于效果需要更长时间观察的目标，可以把工作分成两个阶段：本轮完成可用能力并埋点，下轮结合真实使用数据判断是否达到预期。这样既不夸大短周期能证明的效果，也不至于把“功能上线”误当成“问题解决”。

4. 计划容量不应等于理论工时总和

一个人每天八小时，并不意味着每天有八小时可用于迭代任务。评审、沟通、线上问题、代码审查、跨团队等待和休假都会消耗可用时间。我的做法是先看团队近期实际完成的工作量，再结合当期人员和已知事件调整，而不是先把所有人的工作日相加，再把容量全部填满。

如果团队没有稳定的历史数据，可以先把容量估算当作假设，而不是事实。连续记录几个周期的计划量、完成量和未完成原因，比凭印象争论“大家是不是估得太保守”更有价值。

三、常见误区：看起来像目标，实际无法指导取舍

1. 用需求数量或任务数量充当成功标准

“本轮完成十个需求”方便统计，却无法说明这十个需求是否解决了最重要的问题。不同需求的工作量、风险和价值差异很大：一个依赖复杂的权限改造，可能比五个文案调整更影响业务。数量可以作为工作量观察指标，但不适合单独充当迭代目标。

如果团队长期用关闭数量评价表现，还可能诱发拆卡行为：把工作切成更多小任务，让数字变好看，却没有提升交付结果。更稳妥的做法是同时观察目标达成、交付节奏、未完成原因和质量信号，避免任何单一指标变成团队的“游戏规则”。

2. 把“按时上线”写成唯一目标

按时交付是重要约束，但它没有说明交付内容是否有用、是否安全、是否能被用户完成。只把日期写进目标，团队可能会通过压缩测试、降低验收标准或跳过依赖确认来守住时间，最后把风险转移到发布之后。

我会把日期作为承诺边界，把用户结果作为目标，把质量和合规要求作为不可轻易让步的约束。确实需要压缩范围时，可以减功能，不应默认牺牲关键安全检查、数据正确性或基本可用性。

3. 写“提升体验”“优化性能”等无法验收的词

这些词可以出现在愿景或问题描述里，却不能单独作为迭代验收条件。“提升体验”可能意味着少点几次，也可能意味着错误提示更清楚；“优化性能”可能关注页面首屏、接口响应或批处理吞吐。没有对象、场景和测量方法，团队成员会各自理解，到了验收时才发现说的不是一回事。

改写时不一定非要承诺一个看似精确的百分比。若现阶段没有可靠基线，可以先设定测量动作和改善方向，例如记录指定场景的响应时间分布，确认主要瓶颈后再确定下一阶段的目标值。没有基线时，先建立可信的测量，比编造一个精确数字更专业。

4. 把所有需求都列入目标，误以为这样更全面

目标写得过多，往往是负责人回避优先级选择的结果。十几条内容并列在同一个迭代目标下，团队就很难知道发生冲突时该保哪一项。更实际的做法是确定一个主结果，最多再列少数支撑结果，并把其他需求标为候选项或后续事项。

如果每个需求都被称为“最高优先级”，优先级就失去意义。负责人需要把不做什么也说清楚，包括延期影响、业务风险和重新评估条件，而不是只在计划中展示想做的部分。

5. 把目标当成计划会上的一次性文字

迭代开始后，目标仍要被用来做决策。需求变化、依赖延迟或测试暴露新问题时，负责人应回到目标判断是否需要调整范围。如果目标只在启动会上念过一次，之后没人用它判断插单、降级或发布，目标就成了文档装饰。

一个简单的检验方式是：本周发生争议时，团队能否用同一段目标文字说明为什么先做甲、暂缓乙？如果不能，问题可能不是执行不够积极，而是目标没有形成可用的决策规则。

四、专业判断逻辑：先判断价值，再判断可交付性

1. 判断目标是否值得做：看用户问题和业务后果

我通常从问题频率、影响范围和后果严重程度开始判断。问题发生得多、影响用户多、造成的后果重，通常更值得优先处理。但这不是机械打分：一个低频但涉及数据丢失或合规风险的问题，不能因为出现次数少就排在后面。

还要区分“有人提出需求”和“问题已经被证实”。访谈、客服记录、产品行为数据、销售反馈和现场观察都可以作为证据，但它们的偏差不同。客户提出的方案不一定等于根因，负责人应该追问用户在什么情境下遇到问题、现在如何绕过、绕行成本是多少。

2. 判断目标能否在本轮交付：看最短可验证路径

目标的颗粒度不应按需求条数决定，而应按团队能否在一个周期内完成一个有意义的验证闭环决定。若一项工作包括需求澄清、技术探索、开发、联调、发布和用户反馈，且依赖多、未知数多，就需要考虑拆成阶段性结果，而不是把整个愿景压进一个迭代。

拆分不是简单地把前端、后端、测试各写一张卡。更好的拆法是形成可验证切片：先让一小类用户在一个明确场景中完成核心动作，再逐步覆盖更多角色、数据规模或异常路径。这样每一段都能带来可观察的结果，而不是留下若干无法独立使用的半成品。

3. 判断承诺是否可信：看容量、依赖与不确定性

我把可交付性拆成三类检查。第一是容量：当前人员是否有足够时间，关键岗位是否被多个目标同时占用？第二是依赖：接口、数据、环境、审批和业务确认是否有负责人和时间点？第三是不确定性：需求是否经过验证，技术路线是否存在尚未解决的高风险问题？

其中任意一项明显不确定，都不该靠增加“努力程度”来弥补。可以缩小范围、先做技术验证、明确备选方案，或把目标改成先完成一个可测量的阶段性结果。把风险留在计划里，并不会让风险消失。

4. 让验收标准区分结果、质量与证据

验收标准不只是一句“功能可用”。我建议至少分辨三个层次：结果层说明用户能完成什么；质量层说明在重要边界条件下是否可靠；证据层说明用什么数据、测试或现场确认来判断。

并非每个迭代都能用商业指标证明价值。若观察周期尚未结束，就要把“功能已交付”和“效果已验证”分开记录，不要把前者直接包装成后者。

五、实操方法：从候选需求到迭代承诺的操作步骤

1. 会前先准备问题证据，不先排工时

迭代计划会不应成为第一次讨论需求背景的场合。负责人应提前收集需求来源、受影响角色、使用场景、已有数据、依赖团队、验收想法和风险。材料不必复杂，但必须让团队知道为什么现在讨论这件事，以及还有哪些事实未知。

如果证据不足，不要把缺口藏在“需求已明确”这样的结论里。可以把澄清、原型验证或技术调研作为本轮工作，但要说清它们要回答的问题以及何时做出后续决策。探索任务也需要结果定义，例如“验证方案甲在现有权限模型下是否可行”，而不是泛泛的“做一下调研”。

2. 把候选事项按问题归组，找出共同目标

将需求按同一用户问题、同一业务流程或同一风险归类。一个团队如果同时收到多个部门的请求，逐条评审往往会陷入局部最优：每一项看着都合理，却看不出它们是否指向同一个结果。

归组后，负责人可以问：哪些事项是解决核心问题的必要路径？哪些只是体验增强？哪些是某个部门的特殊要求？哪些可以用现有流程暂时绕过？这些问题帮助团队避免把“需求列表”误当成“迭代策略”。

3. 选择一个主目标，写出边界和验证方式

主目标建议用一句话表达，结构可以是：“面向某类用户，在某个场景中解决某个问题，使某项可观察结果发生变化。”随后补充本轮范围、明确不做事项、验收证据和依赖条件。写法可以调整，但关键要素不能丢。

例如，内部管理平台的目标可以写为：“让区域运营人员能够批量提交门店资料，并能快速定位格式错误，减少逐条录入和往返核对。”范围再明确支持哪些模板和字段，暂不支持哪些复杂导入场景，验收时检查错误提示、数据校验和操作记录。

4. 拆出可交付切片，不以技术分工代替价值拆分

将主目标拆成尽可能独立、可验收的用户路径。可以先支持一种标准文件和有限字段，再覆盖更复杂的异常；也可以先面向一个试点角色，再扩展到更多组织。拆分时要确保每个切片都能验证一部分目标，而不是只产生内部接口、空页面或不可运行的代码。

技术任务仍然需要拆，但它们应服务于价值切片。比如数据校验、错误反馈和权限处理可以是不同任务，最终验收仍回到用户能否正确完成批量提交这一结果。

5. 估算容量时显式记录预留和风险

使用团队近期实际交付记录作为起点，再扣除已知休假、发布支持、重要会议和其他承诺。若没有可用数据，可以先用较保守的容量假设，并在迭代结束后复盘偏差来自哪里。重点不是追求一个看似精确的小时数，而是避免计划把所有不确定性都算成零。

关键依赖应单独列出：负责人、预计完成时间、受影响目标、延误后的替代方案。若某个目标完全依赖尚未确认的外部输入，应明确标记为风险，不要用“预计没问题”取代验证。

6. 计划会上做取舍，不把讨论变成逐卡承诺

计划会先确认主目标和价值，再讨论是否有能力完成支持它的工作。遇到范围过大时，先问哪个用户路径最重要、哪些边界条件可以后续补齐、哪些质量要求不可妥协。工时估算是帮助发现差异的工具，不是让每个人在压力下报出一个保证数。

如果团队对一项工作估算差异很大，通常说明需求边界、技术未知或依赖条件还不清楚。此时应先澄清分歧，而不是简单取平均数。对于高风险事项，安排短周期验证往往比直接承诺完整交付更可靠。

7. 迭代中用目标管理变更和进度

每日同步不需要逐项汇报全部工作。更有用的问题是：主目标距离验收还差什么？哪些阻塞可能影响目标？是否出现了足以改变优先级的新信息？当工作偏离目标时，尽早调整比到了迭代末才发现来不及更有价值。

遇到插单时，负责人应同步说明影响。若新事项确实高于当前目标，明确它取代什么；若只是可延后的请求，就进入候选池。这样可以减少“所有事情都要做”的隐性压力，也让业务方看到取舍的真实成本。

8. 结束时分别复盘目标、交付与效果

迭代评审至少要分开回答三件事：承诺的结果是否完成？交付质量是否符合约束？上线后是否出现预期效果信号？如果目标完成但效果尚未显现，就记录待观察的数据和复查日期；如果功能完成但质量不达标，应明确不能把交付状态写成目标达成。

复盘则关注偏差原因，而不是寻找个人责任。目标过大、依赖迟到、估算不足、临时工作、验收不清和技术风险，分别需要不同改进措施。只说“下次加强沟通”没有可验证动作；更好的改进是指定负责人、检查时间和要验证的结果。

六、具体案例与数据观察：一次批量导入目标如何从“做功能”变成“解决问题”

1. 场景：运营人员反复手工录入，错误还难以定位

下面是一个匿名化的内部管理平台案例，用于说明目标设计方法，不代表某一企业的真实经营数据。运营人员每周需要录入一批门店资料，原流程是逐条填写；资料字段较多，格式不统一，出现错误后往往要重新检查整份表格。

最初的需求写法是“开发批量导入功能”。这句话没有说明支持哪些文件、错误如何反馈、谁负责确认数据口径，也没有说明为什么要在当前周期做。团队如果直接排开发任务，很可能在迭代末发现导入成功率低，或者错误提示无法帮助用户修正。

2. 先把目标改成用户结果，并划定试点范围

负责人先与运营代表确认真实流程：数据从哪里来、哪些字段最容易出错、每次录入后要经过什么审核。随后把本轮目标改成：“让一个试点运营小组能够用标准模板批量提交门店资料，并快速定位不合规记录，减少重复录入与错误核对。”

范围限定为一种标准模板、首批必要字段和明确的错误反馈方式。暂不支持多模板自动识别、跨文件合并和复杂批量修改。这样做不是降低要求，而是把未知范围压缩到一个可以验证的闭环：上传、校验、反馈、修正、再次提交。

3. 用过程数据判断改善，而不预先承诺漂亮结果

团队在试点前抽取了一个小样本，记录人工录入耗时、一次提交通过情况和错误修正所需时间。由于样本规模有限，负责人没有把抽样结果当作普遍结论，而是作为后续比较的基线。迭代验收侧重模板校验和错误定位是否符合约定，效果观察则在试点运行后继续收集。

这类场景最容易犯的错，是在没有可靠基线时承诺“效率提升一半”。如果最后变化没有达到目标，团队无法判断是方案无效、样本不同、操作培训不足，还是测量口径变了。先固定样本条件和统计方法，才能让效果判断有意义。

4. 试点结果应写成“观察到什么”，而不是“证明了什么”

假设试点中发现，标准模板下的错误记录更容易定位，但首次提交通过率变化不明显。合理的结论不是“批量导入没有价值”，也不是“效率已经大幅提升”，而是：错误反馈能力得到初步验证，源数据格式仍是主要阻碍，下一步应优先改进模板说明或数据校验规则。

这体现了迭代目标的另一层价值：让团队尽早获得可用于下一次决策的证据。即使商业效果尚未充分显现，只要本轮清楚验证了关键假设，也可能是一次有价值的迭代；相反，按计划交付了很多代码，却没有回答任何重要问题，就很难称为有效推进。

七、不同情况下的行动建议：按团队成熟度和业务风险调整

1. 新团队或数据不足：先建立基线，控制承诺精度

新团队通常缺少稳定的交付历史，不适合照搬成熟团队的容量比例或速度目标。我会先选择范围较小、风险可控的目标，记录计划与实际之间的差异，并注明偏差原因。经过几个周期后，再看哪些工作类型经常被低估、哪些依赖最常延迟。

在产品数据不足时，验收目标可以分为“交付验证”和“效果观察”。前者在迭代末确认功能和质量，后者约定上线后多久复查、由谁取数、怎样解释样本偏差。这样既不回避效果，也不会假装短周期可以回答所有问题。

2. 多团队并行：把依赖变成可跟踪的承诺

跨团队项目要把依赖写到目标旁边，而不是藏在会议纪要中。每项关键依赖至少标清交付物、负责人、期望日期、验收人和受影响的目标。依赖方无法承诺日期时，应讨论替代方案，例如先用模拟数据验证流程，或把主目标拆成不依赖该接口的阶段。

若目标横跨多个团队，指定一个统一的目标负责人有助于汇总风险和协调顺序，但不代表由一个人承担所有交付责任。每个团队仍需明确自己的交付边界和验收结果，避免“大家都参与，所以没人负责最终闭环”。

3. 合规、安全或数据敏感场景：先定不可妥协项

在涉及隐私、财务、生产控制或强监管要求的场景，功能范围可以分阶段，但权限校验、审计记录、数据保护和必要测试不能默认降级。负责人应把这些要求作为目标的硬约束，提前邀请安全、法务或治理角色参与，而不是等到发布前才集中检查。

这类目标的验收证据也要考虑留痕要求。团队不仅要确认“操作能成功”，还要确认授权边界、异常处理和审计信息满足组织规则。若合规条件尚未明确，先把规则澄清作为阶段性工作，通常比带着模糊理解直接开发更稳妥。

4. 临近发布或突发故障：判断是保目标还是保日期

突发事件发生后，负责人要区分“不可延迟的安全修复”和“可以排队的功能请求”。对必须立即处理的事项，先评估影响范围和失败后果，再明确从原目标中释放哪些工作。若目标结果仍有价值，可以缩小发布范围；若核心条件已失效，就应重新设定目标，而不是维持旧承诺做形式上的完成。

保日期可能有商业必要，但必须讲清代价和风险接受人。延后部分功能、调整试点人群和推迟非关键体验改进，通常比压缩关键验证更可控。任何涉及质量门槛的例外，都应明确审批责任和回退方案。

5. 目标频繁变化：先修正决策入口，再谈执行纪律

若每个周期都被大量临时事项打断，单纯要求团队“提高专注度”通常治标不治本。应检查需求入口是否缺少优先级规则、业务负责人是否能及时做取舍、线上事件是否有分类机制，以及管理层是否把所有工作都当作同等紧急。

可以设置一个轻量的变更决策门槛：说明紧急原因、影响对象、延迟代价、所需容量以及被替换的原工作。此机制不是为了拖慢响应，而是让组织看见插单的真实成本，减少未经评估的范围膨胀。

八、工具与流程的取舍：管理目标，不要把工具字段当成管理本身

1. 小团队先用轻量机制，规模增长后再统一追踪

十几人的团队如果目标少、依赖简单，使用共享文档、任务看板和固定评审节奏，通常足以管理迭代。关键是目标、范围、负责人、验收证据和风险能被团队持续看到。引入复杂系统却没有统一定义，往往只是把混乱从口头搬进字段。

当组织进入多个产品线、多个研发团队并行，或需要跨项目追踪依赖、版本、需求变更和交付状态时，统一平台的价值会变得更明显。负责人需要评估的不只是功能列表，还包括权限模型、数据治理、与现有研发流程的衔接、报表口径和迁移成本。

2. 选择平台时，先验证关键工作流是否跑得通

以 PingCode 为例，若组织是中大型企业或超过百人的研发团队，评估时可以重点检查它是否能覆盖从需求规划、迭代目标、任务协作到交付跟踪的关键链路，以及权限、审计、报表和团队协作方式是否满足实际要求。不要只凭产品演示判断，要用一条真实项目流程做小范围试用。

对有数据驻留或内部网络要求的企业，可进一步核对私有化部署的版本范围、运维责任、升级方式与支持边界。对于计划从 Jira 平滑迁移的团队，应把字段映射、历史数据、权限、附件、工作流和用户培训纳入迁移验证；迁移能力是否满足组织实际需求，需要通过具体数据和流程确认，不能只凭“支持迁移”四个字下结论。

国产替代也不应被简化为品牌替换。真正需要比较的是关键流程能否连续运行、数据能否完整迁移、权限和审计是否符合要求、团队是否愿意使用，以及长期维护成本是否可接受。工具选型的目标不是换一个界面，而是降低协作断点并提高管理信息的可信度。

3. 平台部署与迁移需要纳入迭代目标治理

如果平台本身正在迁移，项目负责人应避免把业务迭代与工具切换风险混为一谈。可以先确定迁移的试点范围、数据核对标准、双轨运行周期和回退方式，再决定哪些团队进入下一阶段。迁移项目也要有自己的目标，例如“试点团队能够在新流程中完成需求到交付追踪，并通过抽样核对确认关键历史记录完整”。

若只以“系统已上线”作为迁移成功标准，可能忽略用户仍在旧系统工作、报表口径不一致或权限未正确配置等问题。平台上线是里程碑，流程可用、数据可信、团队能独立完成工作，才是更有价值的阶段结果。

九、复盘与持续改进：让下一轮目标比上一轮更可信

1. 复盘目标偏差，不只复盘任务完成率

迭代结束时，先比较目标承诺和实际结果：哪些结果达成，哪些部分未达成，哪些是目标范围变化造成的。接着再看任务数据和质量信息，解释偏差来源。若只统计关闭任务的比例，可能看不到目标本身被改写、验收条件临时变化或关键依赖未兑现。

我建议将未完成事项分成几类：计划容量高估、需求理解偏差、技术未知、外部依赖、临时工作、质量返工和优先级调整。分类不是为了给团队贴标签，而是为了匹配改进动作。例如，依赖问题需要前置确认，技术未知需要探索任务，临时工作过多则需要调整入口机制。

2. 复盘测量口径，避免指标被误读

如果团队追踪了交付周期、完成比例或缺陷情况，应先确认口径一致。某些指标会被样本规模、工作类型、发布频率和团队协作方式影响，不能脱离上下文直接比较。一个周期的波动通常不足以证明流程变好或变差，尤其在团队成员、需求构成或统计方式刚发生改变时。

外部研究可以帮助建立问题意识，但不能替代企业自己的基线。若引用行业调查、标准或研究报告，应写明机构、发布日期、指标定义和适用范围；若没有可靠来源，就明确标注为团队观察或情景推演，不要把内部示例写成行业平均值。

3. 为下一轮留下一个具体改进实验

复盘最后不要列十条“以后注意”，而应选一个最有影响的改进点，设计一个可验证的小实验。例如：“下个周期对所有跨团队依赖提前确认负责人和交付日期，迭代中检查一次延期风险，比较依赖导致的等待时间是否下降。”

实验需要有负责人、执行时点和判断方式。如果一个改进项连续几轮都没有行动，说明它可能不是优先事项，或者责任和资源没有落实。持续改进不是把复盘纪要写得更长，而是让下一次计划少踩一个已经识别过的坑。

十、最后的行动建议：下一次计划会先做这三件事

1. 会前写出一条结果型目标

选择最重要的用户问题，补齐用户、场景、问题和预期变化。若暂时没有足够证据，就把本轮目标设为验证关键假设，并明确验证完成后如何决策。不要用一长串需求标题代替目标句。

2. 在计划会上明确范围、依赖与不做事项

把本轮覆盖内容、明确排除项、验收证据、依赖负责人和风险写在同一处。团队讨论容量时，留出实际协作与突发工作的空间；遇到估算分歧，先澄清未知，不要通过平均数掩盖问题。

3. 迭代中期回到目标做一次取舍检查

询问目标是否仍然成立，阻塞是否改变了承诺可信度，新增工作要替换什么。迭代结束后分开记录交付、质量和效果证据，并将复盘结论转成下一轮可执行的实验。

迭代管理做得好，不是每个周期都把计划塞满，而是团队始终知道这一轮最重要的结果是什么，哪些条件可能阻止它发生，以及改变计划时要付出什么代价。下一次迭代计划会，不妨先删掉任务列表，试着用一句话讲清楚用户结果，再决定哪些工作值得进入承诺。