需求延期预警的价值，在于把“到期才发现延期”变成“过程中提前看到风险”。它需要先定义可判定的信号，再安排采集、判定、上报和处置的责任人，最后用复盘数据校准阈值。本文给出信号阈值表、四步流程、角色分工、完整示例和上线检查清单；预警记录与处置跟踪可以放在ONES中承载，具体配置按团队现有流程核验。
要点总览（TL;DR）
- 需求延期预警的关键是把延期识别前移：用时间、进度、阻塞、变更四类信号，把“感觉要延期”变成可判定、可记录的条件。
- 预警流程分采集、判定、上报、处置四步，每步都要有输入、动作、输出和完成标志，分级标准与处置权限一一对应。
- 需求负责人盯信号、开发负责人评估工作量、项目经理判定级别并组织处置、业务方确认范围与日期调整，预警记录和处置结论随需求留存。
- 机制上线后用预警命中率、误报率、平均提前天数校准阈值，按周或按迭代复盘，一次只调整一类信号。
- 常见失效是只报不处置、阈值过松或过紧、数据来源不可靠，应先修采集和处置责任，再调阈值。
预警先定信号：哪些情况算需求延期风险
预警机制的第一步，是把“感觉这个需求要延期”翻译成可判定、可记录的条件。建议从时间、进度、阻塞、变更四类信号入手，每类信号都写明判定条件、数据来源和判定人。信号只针对单个需求在实现过程中的风险，迭代整体排期是否合理、需求最终是否通过验收，属于另外的管理环节，不混入预警判定。
阈值不必一开始就追求精确。可以先设一个偏保守的初始值，运行两三个迭代后根据误报情况调整。关键是每个阈值都能从已有记录中取到数据，并且判定口径在团队内一致。
| 信号类别 | 判定条件示例 | 数据来源 | 判定人 |
|---|---|---|---|
| 时间类 | 距承诺交付日期剩余5个工作日，需求仍未进入开发或测试阶段；或计划里程碑已过而未达成 | 需求承诺日期、阶段状态、里程碑记录 | 需求负责人初判，项目经理确认 |
| 进度类 | 剩余工作量折算所需天数超过剩余可用天数；或连续两个检查点完成量低于计划 | 任务拆解与估点、每日或每周完成记录 | 开发负责人 |
| 阻塞类 | 等待外部输入、上游依赖未交付、测试环境或关键资源不可用，持续超过2个工作日未解除 | 阻塞标记、依赖关系、环境与资源记录 | 需求负责人 |
| 变更类 | 实现期内范围或验收标准被修改，且新增工作量超过原估算的20% | 需求变更记录、验收标准版本 | 需求负责人与业务方共同确认 |
四类信号可以单独触发，也可以组合升级。例如时间类信号出现时，若同时存在阻塞项，应直接进入较高预警级别。判定口径要写清楚“从哪天开始算”“按工作日还是自然日算”，避免同一条件在不同人手里得出不同结论。
预警怎么跑起来：采集、判定、上报、处置四步
信号定义之后，需要一条固定的执行链路，让风险从数据变成动作。四步流程的重点是每步都有明确输入、动作、输出和完成标志，避免预警发出后停在聊天记录里。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 采集 | 需求承诺日期、任务完成记录、阻塞标记、变更记录 | 每日站会前由需求负责人核对信号；每周固定时间由项目经理汇总跨需求情况 | 信号清单，标注命中的信号类别与数据依据 | 信号清单更新到当日或当周 | 需求负责人、项目经理 |
| 判定 | 信号清单 | 按分级标准把信号升级为正式预警：提示、预警、严重 | 带级别的预警条目 | 预警条目有级别、有判定人签字或确认记录 | 项目经理或交付负责人 |
| 上报 | 预警条目 | 填写预警信息并通知相关角色 | 预警通知，包含需求名称、承诺日期、信号依据、影响范围、建议处置方向、要求回复时间 | 相关角色确认收到并给出初步意见 | 需求负责人发起，项目经理跟踪 |
| 处置 | 预警通知与初步意见 | 选择重排期、拆范围、补资源或升级决策，并按权限审批 | 处置方案与新的承诺日期或范围 | 处置方案获批并落到需求记录中 | 项目经理牵头，业务方与开发负责人参与 |
分级标准建议与处置权限挂钩。提示级由需求负责人自行跟进并在站会说明；预警级需要项目经理组织处置并通知业务方；严重级涉及承诺日期无法守住或跨团队依赖，应升级到交付负责人和业务方共同决策。分级不是为了增加层级，而是让不同影响面的风险匹配相应决策人。
处置选项要提前约定适用条件。重排期适用于范围明确、资源稳定但时间不足的情况；拆范围适用于承诺日期不可动、可以分期交付的情况；补资源适用于瓶颈在人力或环境且可以短期调配的情况；升级决策适用于上述选项都需要更高层协调的情况。每种处置都应有审批记录，避免口头调整后无人知晓。
角色与交付物：谁盯信号、谁做决定
预警机制失效的常见原因，是信号有人看到但没人有权处置。角色分工要同时写清“盯什么”和“能定什么”，并把交付物归属固定下来。
| 角色 | 预警中的职责 | 决策权限 | 主要交付物 |
|---|---|---|---|
| 需求负责人 | 维护需求承诺日期与验收标准，日常核对时间类、阻塞类、变更类信号，发起预警 | 提示级预警的跟进与关闭建议 | 信号核对记录、预警发起记录 |
| 开发负责人 | 核对进度类信号，评估剩余工作量与技术阻塞，提出处置建议 | 技术方案与工作量重估 | 进度评估意见、阻塞解除记录 |
| 项目经理/交付负责人 | 汇总信号，判定预警级别，组织处置，跟踪关闭 | 预警级处置方案审批；严重级升级发起 | 预警台账、处置结论、升级纪要 |
| 业务方 | 确认变更类信号，参与范围取舍与日期调整决策 | 范围变更与承诺日期调整的确认 | 变更确认记录、范围取舍意见 |
交付物建议集中留存：预警记录随需求走，处置结论写入需求记录或预警台账，升级纪要单独归档。留存方式可以是一张共享台账，也可以是工作项中的状态与评论记录。关键是事后能回答三个问题：当时命中了什么信号、谁做的判定、处置后承诺日期或范围变成了什么。
在ONES中，需求可以放在统一的需求池里管理，复杂需求用子工作项拆解并关联研发和测试任务，预警记录与处置结论可以跟随需求记录留存；业务团队也能跟踪需求和缺陷的处理进度。看板和燃尽图适合在站会中对齐进度与风险。至于按承诺日期或剩余工作量自动触发提醒、以及预警分级的具体配置方式，需要结合团队实际使用的版本核验后再确定。
一个完整示例：某需求从信号出现到预警关闭
以下为演示情景，用于说明字段填写与判断过程，不代表真实客户案例。
某内部系统需求“报表导出支持按部门筛选”，承诺交付日期为某月20日，估算工作量8人天，需求负责人为产品经理A，开发负责人为B，项目经理为C，业务方为运营D。
第一次信号出现在当月8日。该需求仍处于开发中，剩余工作量约5人天，而剩余可用时间只有4个工作日，命中进度类信号。开发负责人B在站会上说明完成量低于计划，需求负责人A将信号记入清单。项目经理C判定为“预警”级，因为承诺日期存在实质风险但尚有调整空间。
上报内容包含：需求名称、承诺日期、信号依据（剩余5人天对4个工作日）、影响范围（依赖该报表的月度统计）、建议处置方向（拆范围或补资源）、要求回复时间（次日中午）。业务方D确认月度统计不能推迟，但首期可以只做部门筛选、暂不做多选。
处置选择拆范围：首期交付部门单选筛选，多选放入后续需求，承诺日期保持不变。该调整经业务方D确认、项目经理C审批后写入需求记录。当月15日，剩余工作完成并通过测试，预警关闭。关闭记录写明：信号已解除，范围调整已生效，后续需求另行排期。
这个示例体现的规律是：预警要尽早触发，处置要落到范围、日期或资源的具体变化上，关闭要有可核验的条件。若当时只记录“已知悉”而没有调整动作，预警就失去了意义。
让预警不失灵：校准与完成检查
机制上线后，需要用数据检验它是否真的提前发现了风险。建议按迭代或按周统计三类指标：预警命中率，即发出预警的需求中最终确实发生延期的比例；误报率，即预警后按期完成且无需调整的比例；平均提前天数，即从预警发出到原承诺日期的间隔。命中率过低说明阈值过松或信号采集不及时，误报率过高说明阈值过紧，平均提前天数太短说明预警发出时已来不及处置。
校准放在周度或迭代级复盘中进行。复盘时逐条查看已关闭和误报的预警，判断是信号定义问题、数据来源问题还是处置不及时。调整阈值要小步进行，一次只改一类信号，并观察下一个周期的指标变化。
上线前可用以下清单做完成检查：
- 每类信号都有可量化的判定条件和明确的判定人；
- 采集时点和数据来源已固定，不依赖临时询问；
- 预警分级与处置权限一一对应，严重级有明确的升级对象；
- 处置选项的适用条件和审批人已约定；
- 预警记录、处置结论和关闭条件可追溯；
- 校准指标有统计口径和复盘节奏。
常见失效情形包括：只报不处置，预警变成通知；阈值过松导致风险发现太晚，或过紧导致团队对预警麻木；数据来源不可靠，剩余工作量长期不更新，信号失真。出现这些情况时，先修数据采集和处置责任，再调阈值。ONES自动记录的工作项滞留时间等过程数据可以作为校准参考，预警专项指标的统计口径仍需团队自行约定。
常见问题
团队刚开始做需求延期预警，阈值应该设多严？
建议先设偏保守的初始值，运行两三个迭代后再调整。判断标准看两个方向：如果预警发出后多数需求仍按期完成且无需调整，说明阈值过紧；如果延期往往在承诺日期临近才被发现，说明阈值过松。调整时一次只改一类信号，观察下一个周期的命中率和误报率变化，避免同时改动多个条件后无法判断是哪一项起了作用。
预警发出后业务方不回复，处置卡住怎么办？
在上报环节就约定回复时限，例如要求次日中午前给出初步意见，超时视为默认接受项目经理提出的建议处置方向，并在预警记录中注明。涉及承诺日期调整或范围取舍的，仍需业务方书面确认。若业务方持续不响应且影响交付，应升级到交付负责人协调，把升级过程记入纪要，避免预警长期悬空。
剩余工作量估算不准，进度类信号还可信吗？
进度类信号依赖估算质量，估算偏差大时信号会失真。可以先要求开发负责人在每个检查点更新剩余工作量，用连续两个检查点的完成量对比计划，而不是只看单次估算。若估算长期不准，把校准重点放在估算习惯上，例如统一拆解粒度、参考历史同类需求的实际耗时，再逐步收紧阈值。
预警记录应该放在哪里，需要单独建台账吗？
两种方式都可行。规模较小的团队可以把预警信息写在需求记录的状态或评论中，随需求走；跨团队、预警量大的团队建议单独维护一张预警台账，便于统计命中率和误报率。无论哪种方式，都要能事后回答三个问题：命中了什么信号、谁做的判定、处置后承诺日期或范围变成了什么。在ONES中，预警记录与处置结论可以跟随需求记录留存，具体承载方式按团队现有流程确定。
预警机制运行一段时间后，怎么判断它值得继续投入？
看三个指标的趋势：预警命中率是否稳定在合理区间、平均提前天数是否足够支撑处置、因预警而调整范围或日期的需求占比是否在可接受范围。如果预警发出后处置动作很少、延期仍集中发生在交付日附近，说明机制没有真正起作用，应回到信号定义和处置权限上检查，而不是继续增加预警条目。
