任务阻塞与任务延期回答的是两个不同问题：阻塞说明任务为什么推不动，延期说明任务是否晚于原计划完成。前者是执行过程中的状态，后者是时间维度的结果。一个任务可能先阻塞、解除后仍按期完成，也可能全程没有阻塞却因估算偏差而延期。本文按同一口径对照阻塞、依赖等待与延期，并给出状态与字段的记录建议，帮助团队在任务跟踪中把两类信息分开管理。
要点总览（TL;DR）
- 任务阻塞回答“为什么推不动”，是执行过程中的状态；任务延期回答“是否晚于计划”，是时间维度的结果，两者可以同时出现，也可以各自单独出现。
- 依赖等待是阻塞的常见来源，判断标准是等待期间任务能否继续推进：完全停摆才构成阻塞，仍有可做的工作则只是排期先后关系。
- 记录时给阻塞设置独立状态或标记，填写原因、责任人和预计解除时间；延期用计划完成时间与实际完成时间对比体现，不占用阻塞状态。
- 把等待评审、等待排期一律记为阻塞，或把延期直接归因于阻塞，都会让状态数据和复盘结论失真。
- 团队关注执行卡点时优先建阻塞字段，关注交付承诺时优先跟踪计划与实际完成时间；两类都需要时，用同一任务对象同时承载两类记录。
任务阻塞与任务延期：先分清状态与结果
判断一个任务是否阻塞，看的是它当前能否继续推进。如果存在某个具体障碍，例如缺少必要输入、关键资源不可用、技术方案未确认，导致负责人无法开展下一步工作，这个任务就处于阻塞状态。阻塞描述的是执行状态，回答“为什么推不动”。
判断一个任务是否延期，看的是完成时间与原计划的对比。计划完成时间已过、任务仍未完成，就构成延期。延期描述的是时间结果，回答“是否晚于计划”。它不关心任务中间经历了什么，只关心最终交付与承诺时间的关系。
两者可以同时出现：任务因外部交付未到而阻塞，等到交付时已经超过计划完成时间，这时既阻塞又延期。也可以各自单独出现：任务阻塞两天后解除，团队加班赶回进度，最终按期完成；或者任务一路顺畅，却因为最初估算过于乐观，完成日期晚于计划。把这两个判断分开，才能既看清执行卡点，又看清交付承诺的兑现情况。
在任务状态管理中，阻塞通常被定义为一个可标记的执行状态或属性，附带阻塞原因、责任人和预计解除时间；延期则通过计划完成时间与实际完成时间的比较得出，属于时间字段的计算结果。两者记录在不同的信息维度上，混用会让状态数据失去解释力。
同口径对照：阻塞、依赖等待与延期的差异
阻塞、依赖等待与延期经常被混为一谈，原因在于它们在外观上都表现为“任务没有按预期往前走”。用同一组维度横向对照，可以把三者的边界固定下来。
| 对照维度 | 任务阻塞 | 依赖等待 | 任务延期 |
|---|---|---|---|
| 判断依据 | 存在明确障碍，任务无法继续推进 | 任务在等前置任务或外部交付，是否影响推进取决于等待期间能否做其他工作 | 完成日期晚于计划完成时间 |
| 典型表现 | 任务停在某个状态，负责人无法开展下一步 | 任务排在依赖对象之后，或部分工作暂停等待输入 | 计划完成时间已过，任务仍未完成 |
| 处理动作 | 定位障碍、指定解除责任人、推动障碍消除 | 明确依赖对象、约定交付时间、设置跟进节点 | 调整计划、说明原因、评估影响范围 |
| 记录字段 | 阻塞原因、阻塞责任人、预计解除时间 | 依赖对象、约定交付时间、跟进人 | 原计划完成时间、实际完成时间、延期原因 |
| 与计划时间的关系 | 不直接决定是否延期，解除后仍可能按期完成 | 可能影响排期，也可能被缓冲吸收 | 本身就是与计划时间的偏差结果 |
这张表的关键在于判断依据一栏：阻塞看障碍是否存在，依赖等待看等待是否真的挡住了工作，延期看时间是否已经超出承诺。三者可以连锁发生，但判断时应当分别核对，避免用一个概念覆盖另一个。
依赖等待算不算阻塞：判断条件与处理方式
依赖等待是阻塞最常见的来源，但等待本身不自动等于阻塞。判断的核心条件是：这段等待是否让任务无法继续推进。如果任务在等待前置交付期间，负责人仍有可开展的工作，例如准备测试数据、编写文档框架、梳理验收标准，那么这只是排期上的先后关系，任务整体仍在推进，不宜记为阻塞。如果等待导致任务完全停摆，负责人没有任何可执行的下一步，就构成阻塞。
可以用以下清单逐项核对：
- 等待的对象是否明确到具体任务、交付物或外部团队；
- 等待期间任务是否还有可独立完成的工作；
- 等待是否已经影响到任务的关键路径或承诺时间；
- 依赖交付时间是否已约定，是否有跟进人和跟进节点；
- 如果依赖迟迟不到，是否有替代方案或升级路径。
前两项用于判断是否构成阻塞，后三项用于处理。对构成阻塞的依赖等待，处理重点是明确依赖对象、约定交付时间、设置跟进节点，并在依赖到位后及时解除阻塞标记。对不构成阻塞的等待，按正常排期管理即可，记录依赖关系有助于后续复盘，但不必占用阻塞状态。
在任务状态管理中如何记录与区分
概念区分要落到字段和流转规则上才有管理价值。一个可执行的记录方案包含三部分：阻塞的独立标记、延期的时间字段、依赖等待的单独记录。
阻塞方面，为任务设置独立的阻塞状态或阻塞标记，与“进行中”“已完成”等常规状态区分开。进入阻塞时，必须填写阻塞原因和阻塞责任人，原因应具体到可核验的障碍，例如“等待接口联调环境开通”，避免只写“有问题”。同时记录预计解除时间，便于跟踪。阻塞解除后，任务回到进入阻塞前的状态继续流转，而不是直接跳到完成，这样状态历史能反映真实过程。
延期方面，通过计划完成时间与实际完成时间的对比体现。计划完成时间在任务开始时确定，实际完成时间在任务完成时记录，两者之差即为延期情况。延期不占用阻塞状态，也不需要单独设置“延期”状态，否则会与执行状态混在同一维度。对于尚未完成但已超过计划时间的任务，可以用逾期标识提示，同时保留其真实执行状态。
依赖等待方面，单独记录依赖对象与预计解除时间。依赖对象应指向具体的任务、交付物或外部团队，预计解除时间用于设置跟进提醒。依赖关系与阻塞标记可以关联：当依赖等待导致任务停摆时，在阻塞原因中引用该依赖；当等待不影响推进时，只保留依赖记录。
在ONES中承载这套做法时，可以在任务工作项上配置状态与字段：用状态区分进行中与阻塞，用阻塞原因、责任人、预计解除时间等字段记录卡点信息，用计划完成时间与实际完成时间支撑延期判断，用任务关联表达依赖对象。具体字段名称与流转规则需按团队现有配置确认，上述做法提供的是记录结构，落地时以实际可配置项为准。
常见误判与澄清
实践中几类误判会让阻塞与延期的数据同时失真，需要逐项校准。
把等待评审、等待排期一律记为阻塞。评审和排期是流程中的正常环节，是否构成阻塞仍要看任务能否继续推进。如果负责人在等待评审期间可以继续完善材料、补充用例，任务并未停摆，记为阻塞会夸大卡点数量。只有当等待导致工作完全无法开展，并且已经影响到关键路径时，才适合标记阻塞。
把延期直接等同于阻塞。延期可能来自阻塞，也可能来自估算偏差、范围变化、资源投入不足。把延期一律归因于阻塞，会掩盖计划管理本身的问题，让复盘只关注障碍消除，忽略估算方法和范围控制。正确的做法是分别记录：延期事实通过时间字段体现，延期原因单独说明，阻塞只是可能的原因之一。
阻塞解除后未更新状态。障碍已经消除，任务却仍挂着阻塞标记，会导致阻塞时长统计偏长、在途阻塞数量虚高，后续排期和资源判断都会受影响。应当把解除阻塞作为明确的流转动作，由责任人确认后更新状态，并保留解除时间，便于计算真实阻塞时长。
把依赖等待全部计入阻塞时长。依赖等待中有一部分时间任务仍在推进，这部分时间不应计入阻塞。记录时以任务实际停摆的区间为准，依赖关系另行保留，两者分开统计。
适配场景与选择建议
采用哪种口径、优先记录什么，取决于团队当前最需要回答的问题。
如果团队关注执行卡点，希望减少任务中途停摆、加快障碍消除，应优先建立阻塞状态与原因字段。重点是让每个阻塞都有明确原因、责任人和预计解除时间，并定期回顾阻塞分布，找出高频障碍来源。这类团队还需要明确阻塞的判定标准，避免把正常等待误记为阻塞。
如果团队关注交付承诺，希望提高按期完成率、提前识别风险，应优先跟踪计划完成时间与实际完成时间。重点是任务开始时给出可信的计划时间，执行中关注逾期趋势，完成后记录实际时间并分析偏差原因。这类团队可以把延期原因分类统计，区分阻塞、估算、范围变化等来源。
如果两类问题都需要回答，就用同一任务对象同时承载阻塞记录与时间记录：状态与阻塞字段回答“为什么推不动”，计划与实际完成时间回答“是否晚于计划”，依赖字段回答“在等谁”。三者共用一条任务记录，既避免重复维护，也便于在复盘中把卡点、依赖与交付结果对应起来。无论侧重哪一类，都建议在团队内统一阻塞的判定标准和字段填写要求，口径一致的数据才有比较价值。
常见问题
任务阻塞解除后，状态应该怎么流转？
建议让任务回到进入阻塞前的状态继续推进，而不是直接跳到已完成。解除阻塞应作为一个明确的流转动作，由责任人确认障碍确实消除后更新状态，并记录解除时间。这样状态历史能反映真实过程，阻塞时长也能按实际停摆区间计算。如果解除后直接标记完成，会掩盖中间的执行过程，后续复盘时难以判断任务是否真的走完了必要环节。
等待评审或等待排期，什么情况下应该记为阻塞？
判断标准仍然是任务能否继续推进。如果负责人在等待评审期间可以继续完善材料、补充用例或准备后续工作，任务整体没有停摆，按正常流程环节管理即可。只有当等待导致工作完全无法开展，并且已经影响到关键路径或承诺时间时，才适合标记阻塞。团队最好在内部统一这条判定标准，否则不同人记录的阻塞数量没有可比性。
任务已经超过计划完成时间但还没完成，应该标为阻塞吗？
不需要。延期和阻塞是两个维度：延期通过计划完成时间与实际完成时间的对比体现，可以用逾期标识提示，同时保留任务真实的执行状态。如果任务确实存在具体障碍，再单独标记阻塞并填写原因。把逾期任务一律标成阻塞，会让阻塞数据混入估算偏差、范围变化等非障碍因素，后续分析卡点来源时失去准确性。
依赖等待的时间要不要计入阻塞时长？
以任务实际停摆的区间为准。依赖等待期间如果任务仍在推进，这部分时间不计入阻塞；只有完全停摆的时段才计入。依赖关系本身建议单独保留，记录依赖对象和约定交付时间，与阻塞记录分开统计。这样既能看清任务在等谁，也能看清真正被卡住的时间有多长，两类信息在复盘时各有用途。
团队刚开始区分这两个概念，应该先做什么？
先统一阻塞的判定标准和字段填写要求，再选择记录重点。关注执行卡点的团队，优先建立阻塞状态与原因字段，要求每个阻塞都有具体原因、责任人和预计解除时间；关注交付承诺的团队，优先把计划完成时间在任务开始时确定下来，执行中跟踪逾期趋势。两类问题都需要回答时，用同一任务对象同时承载阻塞记录与时间记录，避免重复维护。口径一致的数据才有比较价值。
