项目阻塞是已经发生、使某项工作无法按计划继续推进的具体障碍，需要有人解除后才能恢复流转。判断一个推进障碍是否纳入阻塞管理，可以看三点：它是否已经发生、是否卡住了具体工作项或交付节点、解除它是否需要项目内的角色决策或资源协调。本文按这三条标准梳理应纳入的障碍类型，并说明阻塞与风险、缺陷、服务事件之间的归类边界。
要点总览（TL;DR）
- 项目阻塞是已经发生、使具体工作项或交付节点无法继续推进的障碍，判断时依次核对三条标准：已经发生、卡住具体工作项、解除需要项目内决策或资源协调。
- 应纳入阻塞管理的典型障碍包括需求未确认、验收标准缺失、关键人员缺位、外部交付延迟、环境权限未就绪、审批未通过、接口人未定、供应商交付与法务安全审查未完成。
- 阻塞与风险的分界在于是否已经发生；产品缺陷归缺陷管理，服务中断归服务事件与问题管理，同一事实造成推进受阻时可登记阻塞并关联原记录。
- 归类之后要固定受阻工作项、阻塞原因、影响范围、解除责任人和期望解除时间，按待解除、解除中、已解除流转，解除后回到原工作项继续推进。
项目阻塞的准确定义与判断标准
项目阻塞指某项工作在当前状态下无法继续推进，且原因具体、可指向某个工作项或交付节点。它描述的是“事情已经卡住”这一现实状态，而不是对未来的担忧。一条合格的阻塞记录，应当能让团队回答三个问题：哪项工作停了、因为什么停了、谁需要做什么才能让它重新流动。
判断一个障碍是否纳入阻塞管理，可以依次核对三条标准：
- 已经发生。障碍是当下存在的事实，例如接口文档确实尚未提供、账号确实尚未开通。只是“可能来不及”“担心资源不够”的情况，属于风险范畴。
- 卡住具体工作项或交付节点。受阻对象能够被明确指认，例如某个联调任务、某次测试执行、某个评审环节。如果影响面模糊、无法对应到具体工作，先作为风险或待观察事项记录更合适。
- 解除需要项目内决策或资源协调。障碍无法由受阻人自行消除，需要负责人拍板、跨团队协调、外部方配合或资源调配。若只是当事人尚未动手，属于普通待办。
阻塞与普通待办、提醒的区别在于是否阻断流转。待办是计划内要完成的工作，提醒是时间或条件上的提示，二者都不改变“工作可以继续”的状态；阻塞则意味着在解除之前，后续动作无法开展。实践中可以把阻塞理解为一种带有“阻断”属性的特殊事项：它有明确的受阻对象、明确的解除条件，并且需要被跟踪到恢复为止。
哪些推进障碍应纳入阻塞管理
按障碍来源分类，以下几类情形通常符合前述三条标准，应纳入阻塞管理。分类的目的是帮助登记时找准原因归属和解除责任人，而不是要求所有障碍都套进固定模板。
| 障碍类别 | 典型情形 | 纳入理由 |
|---|---|---|
| 需求与范围类 | 需求未确认、验收标准缺失、范围变更未决 | 开发或测试缺少可执行的输入，工作项无法进入下一状态，需要产品或业务方决策 |
| 资源与依赖类 | 关键人员缺位、外部团队交付延迟、环境或权限未就绪 | 工作项已具备启动条件但缺少必要资源，解除依赖人员安排或外部配合 |
| 决策与协作类 | 审批未通过、跨团队接口人未定、方案评审未闭环 | 推进需要项目内角色作出决定或明确对接关系，悬置期间后续工作无法开展 |
| 外部与合规类 | 供应商交付延迟、法务或安全审查未完成 | 交付节点受外部方或审查流程制约，需要专人跟进并设定期望解除时间 |
需求与范围类障碍的纳入理由最直接：没有确认的需求和验收标准，开发和测试就缺少判断完成的依据。这类阻塞的解除责任人通常是产品负责人或业务方，登记时应写明待确认的具体问题和期望回复时间。
资源与依赖类障碍常见于跨团队协作场景。关键人员缺位、外部团队交付延迟、环境或权限未就绪，都会让已经排期的工作项停在原地。这类阻塞需要区分“等待中”和“已阻塞”：前者有明确的时间承诺，后者没有，登记时把期望解除时间写清楚，才能判断是否需要升级协调。
决策与协作类障碍容易被忽略，因为审批和评审看起来是流程动作。但当审批未通过导致工作项无法进入开发、接口人未定导致联调无法安排时，它已经构成现实阻断，应当登记并指定推动人。外部与合规类障碍同理，供应商交付和法务、安全审查的进度不受项目组直接控制，更需要以阻塞记录的方式明确跟进责任和影响范围。
阻塞、风险、缺陷、服务事件的边界
四类对象最容易混淆，用同一组维度对照可以把边界说清楚：是否已经发生、影响对象是什么、由谁负责处理、记录的目的是什么。
| 对象 | 是否已发生 | 影响对象 | 记录目的 |
|---|---|---|---|
| 项目阻塞 | 已发生 | 具体工作项或交付节点的推进 | 跟踪解除，恢复工作流转 |
| 项目风险 | 尚未发生，存在发生可能 | 项目目标、进度、成本的潜在影响 | 提前识别并制定应对措施 |
| 产品缺陷 | 已发生 | 产品功能或质量本身 | 修复问题，验证质量 |
| 服务事件与问题 | 已发生 | 线上服务的可用性与稳定性 | 恢复服务，分析根因，防止复发 |
风险与阻塞的分界在于是否已经发生。风险是对未来的判断，记录它是为了提前准备应对方案；阻塞是当下的现实，记录它是因为工作已经停住，必须有人解除。把潜在影响写成阻塞，会让阻塞列表失去“当前卡点”的意义；把已经卡住的工作挂在风险列表里长期观察，则容易延误解除时机。
产品缺陷归缺陷管理，原因是缺陷记录的核心是问题本身：什么功能、什么表现、如何复现、修复后如何验证。阻塞关注的是推进受阻，同一个缺陷可能同时造成阻塞，例如严重缺陷导致版本无法提测，此时缺陷记录负责修复跟踪，阻塞记录负责说明哪个交付节点被卡住、由谁推动解除，两者关联而不重复。
线上服务中断归服务事件与问题管理，处理重点是恢复服务和根因分析。项目阻塞关注的是交付节奏，如果服务中断导致某个项目任务无法继续，可以在项目侧登记阻塞并关联对应的事件记录，但事件本身的响应流程仍按服务管理的方式执行。
同一事实在不同阶段可能改变归属。一个尚未发生的依赖延迟先是风险，等到交付日确实未交付、下游任务无法开始时，就转为阻塞；一个缺陷在修复前可能阻塞提测，修复验证通过后阻塞随之解除，缺陷记录仍保留用于质量统计。归类应按当前影响判断，并在状态变化时及时调整记录。
具体例子：同一件事该记在哪里
以下示例用于演示归类结果，均为说明性情景。
示例一：第三方接口文档迟迟未提供，导致联调无法开始。联调任务已经排期，但因缺少接口文档无法启动，符合“已发生、卡住具体工作项、需要外部方配合”三条标准，应登记为阻塞。记录中写明受阻的联调任务、对接的外部团队、期望提供文档的时间，并由接口对接人负责跟进。
示例二：测试环境账号未开通，测试任务停滞。测试执行已经到期但无法开展，原因是账号权限未就绪，属于资源与依赖类阻塞。解除责任人是环境或权限管理员，登记时注明所需账号范围和影响到的测试任务，开通后由测试负责人确认恢复。
示例三：线上功能报错，属于缺陷还是阻塞。报错本身首先是一条缺陷，进入缺陷管理跟踪修复。如果该报错导致某个版本无法按计划发布或某批测试无法继续，则同时构成阻塞，应登记阻塞并关联该缺陷，说明受阻的交付节点。判断依据是它是否卡住了具体工作，而不是报错本身严重与否。
示例四：担心下季度人力不足，属于风险而非阻塞。人力不足目前只是对未来的判断，尚未有具体工作项因此停住，应作为风险记录，制定人力调配或排期调整的应对方案。等到某个迭代确实因人员缺位而无法启动时，再按阻塞登记。
常见误解有两个。一是把所有延期原因都记成阻塞，导致阻塞列表混入大量待办和一般性延迟，团队无法聚焦真正需要协调的卡点。二是把阻塞当成风险长期挂起，只观察不推动，工作项一直停在原地。阻塞记录应当有明确的解除责任人和期望解除时间，到期未解除就升级协调，而不是无限期保留。
纳入阻塞管理后的记录与解除流程
归类只是第一步，阻塞要真正被解除，需要在记录中固定关键字段，并明确谁提出、谁解除、谁确认恢复。
登记字段建议包含：受阻工作项（关联到具体任务或交付节点）、阻塞原因（按前述类别填写具体事实）、影响范围（哪些后续工作无法开展、影响哪个里程碑）、解除责任人（谁负责推动解决）、期望解除时间（何时需要恢复）。字段的作用是让阻塞可被检索、可被跟踪，避免只写一句“被卡住了”。
角色分工上，提出人是发现受阻并登记的人，通常是受阻工作项的负责人；解除责任人负责协调资源、推动决策或对接外部方；确认恢复的人在工作项重新流转前核对解除条件是否满足，一般由提出人或工作项负责人担任。三个角色可以由同一人兼任，但职责要写清楚。
状态流转可以按“待解除—解除中—已解除”推进。待解除表示阻塞已登记但尚未有人开始处理；解除中表示责任人已介入协调；已解除表示解除条件满足，受阻工作项回到原流程继续推进。解除后应回到原工作项更新状态，而不是让阻塞记录独立存在。
与风险、缺陷记录的关联方式，是在阻塞记录中引用对应的风险条目或缺陷编号，说明它们之间的关系，避免同一事实在多处重复登记、状态各自更新。风险转为现实阻塞时，保留原风险记录并标注转化；缺陷造成阻塞时，缺陷记录负责修复，阻塞记录负责推进节奏，两者通过关联字段互相指向。
在工具层面，这类流程可以依托工作项的状态与关联能力承载。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，提供看板、燃尽图等工具实时掌控当前进度，也支持任务筛选器按多重条件快速定位所需工作项；团队可以用工作项状态标记受阻与恢复，并通过关联字段把阻塞记录与对应任务、缺陷记录连接起来。缺陷跟踪方面，ONES Project 支持一键提交 Bug 至对应项目或迭代并记录修复情况，ONES TestCase 中未通过的用例也可快速创建缺陷任务，便于在测试与研发之间流转。具体采用哪种状态配置和关联方式，需要结合团队已有的工作项类型和流程约定来设计。
常见问题
一个障碍同时是缺陷又卡住了提测，应该记两次吗？
可以两条记录并存，但职责要分开。缺陷记录负责修复跟踪：什么功能、什么表现、如何复现、修复后如何验证；阻塞记录负责推进节奏：哪个交付节点被卡住、由谁推动解除、期望何时恢复。两条记录通过关联字段互相指向，修复验证通过后解除阻塞，缺陷记录保留用于质量统计。关键是避免同一事实在两处各自更新状态而互不知情。
外部团队口头承诺下周交付，现在算阻塞还是等待中？
如果该交付已经导致下游工作项无法启动，它已经构成现实阻断，应当登记为阻塞。区别“等待中”和“已阻塞”的意义在于跟进方式：等待中有明确的时间承诺，可以按承诺日期复查；已阻塞没有可靠的时间预期，需要指定推动人并准备升级协调。登记时把口头承诺的日期写进期望解除时间，到期未兑现就按阻塞升级处理，而不是继续挂在等待状态。
阻塞解除后，原记录应该删除还是保留？
建议保留并标记为已解除，同时回到原工作项更新状态，让工作重新进入流转。保留记录的价值在于复盘：哪类阻塞出现频率高、平均解除耗时多长、哪些外部方反复延迟交付，这些信息可以支撑流程改进。删除记录会让阻塞历史无法统计，也容易让同类问题重复发生时缺少参照。
小团队人手少，还需要单独维护阻塞记录吗？
可以简化形式，但判断标准仍然适用。人手少的团队往往靠口头同步，风险是卡点只存在于个别人的记忆里，负责人不知道哪项工作已经停住。做法上可以只保留最少字段：受阻工作项、卡住的原因、谁来解除，直接写在原工作项的备注或状态说明中，不必另建独立台账。团队规模扩大或跨团队协作增多时，再考虑把阻塞拆成独立记录并设置状态流转。
担心某个依赖方下个月可能延期，现在要登记阻塞吗？
尚未发生的潜在影响先按风险记录，制定应对方案，例如准备备选方案或提前沟通交付节奏。等到交付日确实未交付、下游任务无法开始时，再把该风险转为阻塞登记，并在原风险记录上标注转化关系。这样既不会让阻塞列表混入对未来的担忧，也不会让真正卡住的工作长期停留在观察状态。
