需求延期预警要解决的是“等到交付日才发现来不及”的问题。做法是把延期从口头判断变成可计算的规则：先确定承诺日期和预计完成日期的偏差口径，再把需求拆成带日期的关键节点，设定触发阈值和提前量，明确谁在什么时点向谁发出包含哪些字段的预警，最后用固定的同步节奏和复盘让预警产生处置结果。本文按这条主线给出可直接套用的规则表、节点模板、流转路径和检查清单，范围聚焦单个需求从排期到交付的过程，不展开迭代整体容量规划与验收闭环。
要点总览（TL;DR）
- 延期预警的第一步是定口径：以承诺交付日期与当前预计完成日期的偏差为基准，按需求类型和优先级设定触发阈值与提前量，并区分进度偏差预警和已确定延期通知。
- 预警的数据来自节点：把需求拆成方案确认、开发完成、提测、联调、上线等带计划日期和责任人的关键节点，约定最小状态更新频率，偏差才有比较对象。
- 预警信息必须包含原定日期、当前预计、偏差天数、原因、影响范围和处置计划，按级别从需求负责人升级到研发负责人、交付负责人，并同步产品、测试和业务方。
- 预警发出后要落到处置动作和新的承诺日期，仅有“已知悉”回复不算闭环；用提前量、字段完整性、处置动作、同步覆盖和复盘五项检查机制是否真正运转。
先定预警口径：什么算延期、提前多久报
第一步是写清楚“延期”的计算方式，否则每个人对同一个需求的判断都不同。建议以两个日期为基准：需求进入排期时对外承诺的交付日期，以及当前责任人给出的预计完成日期。两者之差为正数即存在进度偏差，偏差天数就是预警的核心数值。承诺日期一旦变更，必须留下变更记录和新旧日期对照，避免用“最新预计”悄悄替换原承诺。
仅有偏差还不够，还要规定提前多久报。提前量按需求类型和优先级分档设置，让高影响需求更早暴露风险。下表是一份可直接修改使用的判定与触发规则示例，数值仅作参考，团队应结合自身交付节奏调整。
| 需求类型/优先级 | 判定基准 | 触发条件（示例） | 预警级别 | 提前量（示例） |
|---|---|---|---|---|
| 高优先级、对外承诺需求 | 承诺交付日期与当前预计完成日期偏差 | 偏差≥2天，或任一关键节点逾期1天 | 红色 | 距承诺日期不少于5个工作日 |
| 常规迭代需求 | 同上 | 偏差≥3天，或提测节点逾期 | 黄色 | 距承诺日期不少于3个工作日 |
| 低优先级、可顺延需求 | 同上 | 偏差≥5天 | 蓝色 | 距承诺日期不少于2个工作日 |
同时要区分两类信息：进度偏差预警表示“按当前趋势可能延期”，目的是争取资源或调整范围；已确定延期通知表示“新日期已经确认”，目的是让相关方调整预期和下游安排。前者由需求负责人发出，后者需经项目或交付负责人确认后发出，两者使用不同模板，避免把风险提示当成最终结论传播。
把需求拆成带日期的关键节点
预警需要数据来源，数据来自节点。把每个需求从排期到交付拆成若干可观测节点，每个节点都写明计划日期和责任人，偏差才有比较对象。常见节点包括：方案与范围确认、开发开始、开发完成、提测、测试通过、联调完成、上线。需求规模不同，节点可以合并或细化，原则是每个节点都有明确的完成标志，例如“提测”以测试环境可访问且提测说明齐全为完成，而不是以“开发说差不多了”为完成。
节点粒度与需求规模匹配：小型需求保留方案确认、开发完成、提测、上线四个节点即可；跨团队或涉及外部依赖的需求，应增加联调和依赖方交付节点，并把外部依赖单独标注责任人和约定日期。节点过多会增加维护成本，节点过少则无法提前发现偏差，通常以每个节点间隔不超过三到五个工作日为宜。
状态更新要有最小约定：责任人至少在每个节点计划日期当天更新一次状态，状态取值为未开始、进行中、已完成、受阻；预计完成日期发生变化时必须当天更新并注明原因。更新动作落在需求工作项上，而不是只在聊天群里说一声，这样预警时可以直接引用字段而非回忆。ONES 的子工作项可将复杂需求拆解并关联研发、测试任务，看板状态与需求池信息保持同步，适合作为节点状态的承载位置；具体日期字段与提醒规则的配置方式，建议在选型或实施时结合实际版本确认。
预警的触发、流转与同步动作
触发方式有三种，可按团队成熟度选择：人工巡检适合机制起步阶段，由需求负责人每周固定两次核对偏差；看板规则适合状态已经数字化的团队，按偏差天数或节点逾期自动标色；系统提醒适合希望减少人工遗漏的团队，在阈值命中时推送消息。三种方式可以并存，关键是触发时点写进团队约定，而不是靠临时想起来。
一条可用的预警信息必须包含以下字段，缺一项都会导致接收方无法决策：
- 需求名称与编号
- 原定交付日期
- 当前预计完成日期
- 偏差天数及触发规则
- 偏差原因（技术、依赖、需求变更、资源等）
- 影响范围（涉及的下游需求、业务方、上线窗口）
- 处置计划（拟采取的动作、需要谁支持、新的承诺日期）
- 预警级别与发出人、发出时间
流转路径按级别递进：需求负责人发现偏差后先在自己的需求上更新预计日期并发出预警；黄色及以上级别同步给研发负责人确认技术可行性与新日期；红色级别或涉及对外承诺的，升级到项目或交付负责人，由其裁决优先级、协调资源并对外同步。同步对象覆盖产品、研发、测试和业务方，节奏上建议日常偏差走需求评论与看板，周度汇总在交付例会上过一遍红色与黄色项，已确定延期则单独通知业务方并确认接受方式。
角色分工与各自交付物
预警机制跑不起来，多数时候不是规则缺失，而是角色边界模糊。下表把每个角色在预警过程中的动作和产出固定下来，便于在团队内达成一致。
| 角色 | 主要动作 | 交付物 | 完成标志 |
|---|---|---|---|
| 需求负责人 | 维护节点状态与预计日期，发现偏差后发起预警 | 更新后的需求工作项、预警信息、处置计划 | 预警在约定提前量内发出，字段完整 |
| 研发负责人 | 评估技术可行性，确认新预计日期与所需资源 | 技术评估结论、调整后的节点日期 | 新日期有依据并在需求上更新 |
| 项目/交付负责人 | 裁决优先级，协调跨团队资源，对外同步 | 优先级裁决记录、对外沟通结论 | 相关方确认收到并知晓影响 |
| 业务或需求提出方 | 确认业务影响，反馈接受延期或调整范围 | 影响确认意见、范围调整说明 | 书面反馈接受或调整方案 |
角色可以兼任，但同一需求上“发起预警”和“确认新承诺日期”不宜由同一人独自完成，否则预警容易变成单方面通知。ONES 通过统一的需求池、工单与任务看板同步状态与信息，业务团队可跟踪需求处理进度，产品与研发在同一工作项上协作，便于把上述动作和字段沉淀在需求记录中，减少口头传递造成的信息丢失。
一个完整示例：从偏差发现到恢复交付
以下为演示情景，不对应真实项目数据。某对外承诺需求“订单导出功能”原定3月28日上线，节点计划为：3月10日方案确认、3月14日开发开始、3月21日提测、3月25日测试通过、3月27日联调完成、3月28日上线。
3月19日，需求负责人核对节点时发现开发完成时间从3月20日推迟到3月24日，原因是导出模板依赖的第三方接口文档延迟提供。按规则，该需求为高优先级对外承诺需求，偏差预计达到4天且提测节点将逾期，触发红色预警，距承诺日期9天，满足不少于5个工作日的提前量要求。
需求负责人当天在需求上更新预计完成日期为4月1日，并发出预警，字段填写为：原定3月28日，当前预计4月1日，偏差4天；原因第三方接口文档延迟；影响范围为对外的月度报表导出和两个下游报表需求；处置计划为研发负责人3月20日前确认是否可用临时数据源替代，若不可行则申请顺延上线并提前通知业务方。预警同步给研发负责人、测试负责人和业务方，并升级至交付负责人。
3月20日研发负责人确认临时数据源可行，提测日期调整为3月25日，测试周期压缩一天，新承诺日期回到3月30日。交付负责人确认后由业务方书面接受。后续跟踪中，该需求在3月25日按时提测，3月30日上线。复盘记录了两条改进项：外部依赖在方案确认阶段就登记责任人和交付日期；接口类依赖设置单独的检查节点。整个过程的关键不是预警本身，而是预警触发了替代方案评估和新的承诺日期。
完成检查：机制是否真的跑起来
机制是否有效，不看有没有写过规则，而看几次真实偏差中动作是否按约定发生。可以用下面这份清单逐项核对，每项都给出可验证的判断依据：
- 预警是否在约定提前量内发出：抽查最近若干条发生偏差的需求，比较预警发出时间与承诺日期，确认满足对应级别的提前量要求。
- 预警字段是否完整可决策：检查每条预警是否包含原定日期、当前预计、偏差天数、原因、影响范围和处置计划，缺少任一项即视为不合格。
- 预警后是否产生处置动作与新承诺日期：确认每条预警都对应至少一个具体动作和更新后的日期，仅有“已知悉”回复不算闭环。
- 同步是否覆盖必要相关方：核对产品、研发、测试、业务方是否在预警记录中留有确认痕迹，红色级别是否完成升级。
- 复盘是否沉淀原因与改进项：按原因分类统计一段时间内的偏差，确认改进项有责任人和完成时间，并在下一周期检查是否复发。
如果抽查中发现预警集中在交付前两三天才发出，说明节点设置过粗或状态更新不及时，应回到节点模板调整；如果预警字段经常缺失处置计划，说明角色分工需要重新确认。把这份清单纳入月度交付回顾，机制才能持续运转，而不是停留在文档里。
常见问题
需求延期预警应该由谁发起，需求负责人和项目经理如何分工？
日常的进度偏差预警由需求负责人发起，因为他最清楚节点状态和预计日期变化。项目经理或交付负责人负责红色级别预警的裁决和对外同步，包括确认新承诺日期、协调跨团队资源、通知业务方。两者可以兼任，但“发起预警”和“确认新承诺日期”建议由不同人完成，避免预警变成单方面通知。
团队刚开始做延期预警，阈值和提前量怎么定才不至于天天报警？
建议先用较宽松的阈值跑两到四周，例如常规需求偏差达到3天才触发，再根据实际报警数量和误报情况收紧。判断标准是：预警发出后是否还有时间采取动作。如果多数预警发出时已经来不及调整，说明提前量偏小；如果大量预警最终没有延期，说明阈值偏敏感。阈值是团队约定，不需要一次定到最优。
需求范围中途变更导致的延期，预警口径怎么处理？
范围变更应先走变更确认，再判断是否延期。确认变更后，原承诺日期和变更后的日期都要保留记录，预警中注明“因范围变更导致”，避免把变更成本混入执行偏差。如果变更由业务方提出，影响范围一栏要写清新增内容对下游需求和上线窗口的影响，由业务方书面确认接受新日期或调整范围。
外部依赖方延迟交付时，预警应该发给谁、怎么跟踪？
外部依赖应在方案确认阶段就登记责任人和约定交付日期，作为独立节点跟踪。依赖方延迟时，需求负责人当天更新预计日期并发出预警，同步给研发负责人评估替代方案，同时升级到交付负责人协调依赖方。跟踪上要为依赖项设置单独的检查节点，在约定日期前主动确认进展，而不是等到节点逾期才发现。
预警机制运行一段时间后，怎么判断它是否真的有效？
抽查最近发生偏差的需求，看三件事：预警是否在约定提前量内发出、字段是否完整到可以据此决策、每条预警是否对应具体处置动作和更新后的承诺日期。再看复盘记录中原因分类和改进项是否有责任人与完成时间。如果预警集中在交付前两三天才出现，或者处置计划一栏经常为空，说明节点设置或角色分工需要调整。
