里程碑预警检查模板：通知对象与升级路径设置

里程碑预警检查模板的关键，是把“谁来收通知、什么情况下升级给谁”写进一张可填写的规则表。本文提供一张空白预警规则表，逐字段说明填写口径，并给出一条完整示例，帮助项目负责人把通知对象、升级路径和响应关闭动作配置清楚。文中也会说明这些规则在ONES中可由里程碑、工作项状态和项目计划来承载。

要点总览（TL;DR）

• 模板以一张“预警规则表”为核心，每条规则写清里程碑、基线日期、触发条件、绿/黄/红阈值、通知对象、升级路径与时限、响应动作和关闭条件。
• 阈值按绿/黄/红三级设置：绿色正常不通知，黄色为临近或轻度偏差，红色为逾期或严重偏差；黄色和红色阈值需衔接且不重叠。
• 通知对象按“直接责任人—项目负责人—项目群或管理层”逐级配置，填写角色而非人名，人员变动时只需更新角色成员。
• 升级路径必须写明触发条件、接收角色和时限三要素；最低可用配置至少保留第一级升级路径和升级时限。
• 模板上线后按预警记录调整阈值，在阶段评审或月度例会复核升级路径，每次变更保留变更记录和批准人。

可复制空白模板：里程碑预警规则表

下表可直接复制到文档或表格工具中填写。每条规则对应一个里程碑的一种预警情形，同一里程碑可以有多条规则，分别对应黄色和红色阈值。填写时先确定里程碑和基线日期，再设置阈值分级，最后配置通知对象与升级路径。

字段	填写内容
规则编号
里程碑名称
基线日期
触发条件
阈值分级（绿/黄/红）
黄色阈值
红色阈值
通知对象（角色）
通知方式与频率
升级路径（第一级）
升级路径（第二级）
升级时限
响应动作
关闭条件
确认与关闭记录
规则责任人
生效日期

表格中的“通知对象”和“升级路径”两栏是配置重点。通知对象决定预警第一次发给谁，升级路径决定在无人响应或偏差扩大时，预警如何继续向上传递。两栏都按角色填写，不写具体人名，便于人员变动时维护。

字段说明：每个字段填什么、怎么判断

字段说明解决“知道要填什么、但不确定怎么判断”的问题。下表逐字段给出含义与填写口径，其中阈值分级、通知对象和升级时限三项需要结合项目实际约定，不宜照搬固定数值。

字段	含义	填写口径
规则编号	规则的唯一标识	建议采用“里程碑缩写-阈值级别”格式，便于检索和变更记录引用
里程碑名称	被监控的关键节点	填写可验收的节点名称，如“需求评审完成”“首批交付物验收”，避免写成日常任务
基线日期	预警比较的基准时间	填写经批准的计划日期；基线变更后同步更新此字段，并在变更记录中注明
触发条件	规则生效的判断依据	写明比较对象和比较方式，如“当前预计完成日期晚于基线日期”“交付物完成率低于约定值”
阈值分级	预警的严重程度	采用绿/黄/红三级：绿色为正常，不触发通知；黄色为临近或轻度偏差；红色为严重偏差或已逾期
黄色阈值	进入黄色预警的边界	用可计算的量表达，如“距基线日期剩余5个工作日且完成率低于80%”
红色阈值	进入红色预警的边界	如“已超过基线日期”或“偏差超过约定天数”，需与黄色阈值衔接、不重叠
通知对象（角色）	预警首次送达的角色	填写角色名称，如“里程碑直接责任人”“项目负责人”，不写人名
通知方式与频率	预警如何送达、多久一次	写明渠道和重复提醒节奏，如“系统通知加邮件，黄色每日一次，红色每半日一次”
升级路径（第一级）	首次升级的接收角色	写明触发升级的条件、接收角色和时限，如“黄色预警24小时未确认，升级至项目负责人”
升级路径（第二级）	再次升级的接收角色	如“红色预警或第一级升级后48小时未处理，升级至项目群负责人或管理层”
升级时限	每一级等待响应的最长时间	按工作日或小时填写，与升级路径中的条件对应，避免只写“尽快”
响应动作	接收方需要做的事	写具体动作，如“确认预警、更新预计完成日期、提交纠偏措施”
关闭条件	规则停止预警的依据	如“里程碑完成并通过验收”或“基线经批准调整且偏差回到绿色区间”
确认与关闭记录	响应过程的留痕	记录确认人、确认时间、处理动作和关闭时间，作为复盘依据
规则责任人	维护该条规则的角色	通常为项目负责人或项目管理办公室指定角色
生效日期	规则开始执行的日期	与项目计划启动或基线批准时间对齐

阈值分级建议采用绿/黄/红三级，原因是三级既能区分“正常、需关注、需干预”，又不至于让通知层级过多。黄色阈值通常设在临近基线且进度出现轻度偏差时，红色阈值设在已逾期或偏差影响后续交付时。具体天数应结合里程碑的重要程度和团队响应速度确定，重要节点可以缩短黄色预警的提前量。

通知对象按“直接责任人—项目负责人—项目群或管理层”逐级配置。第一级通知直接责任人，负责日常跟进；第二级通知项目负责人，负责协调资源；第三级通知项目群或管理层，负责跨项目决策。升级路径要写明触发条件、接收角色和时限三要素，缺少任一项，升级就容易停留在口头约定。

必填与选填：哪些字段不能空

最低可用配置只需要保证预警能触发、能送达、能关闭。下表区分必填与选填字段，项目规模较小时可先填必填项上线，再逐步补充选填项。

类别	字段	说明
必填	规则编号、里程碑名称、基线日期	缺少任一项，规则无法定位监控对象和比较基准
必填	触发条件、阈值分级、黄色阈值、红色阈值	缺少阈值，预警无法判断何时触发
必填	通知对象（角色）	缺少通知对象，预警发出后无人接收
必填	升级路径（至少第一级）、升级时限	缺少升级路径，预警在无人响应时会中断
必填	响应动作、关闭条件	缺少关闭条件，预警无法结束，会持续干扰接收方
选填	通知方式与频率	未填写时可按团队默认通知渠道执行
选填	升级路径（第二级）	小型项目可先设一级升级，跨项目或高风险节点建议补齐
选填	确认与关闭记录、规则责任人、生效日期	建议填写以支持复盘和审计，初期可先由项目负责人统一维护

必填字段缺失时，不建议直接上线规则。可先补齐里程碑名称、基线日期和通知对象三项，再补阈值和升级时限；如果基线日期尚未批准，可先以计划日期试运行，并在规则中注明“基线待批准”。项目规模较小时，可只配置黄色和红色两级阈值、一级升级路径，减少维护负担；涉及多个团队或对外交付的里程碑，建议补齐第二级升级路径和确认关闭记录。

填写示例：一条完整的里程碑预警规则

以下示例为演示情景，里程碑、天数和角色均为示意，不代表真实项目数据。示例展示各字段如何联动：阈值触发通知，通知未确认则按时限升级，响应后按关闭条件结束预警。

字段	示例内容
规则编号	REV-01
里程碑名称	需求评审完成
基线日期	2025年6月30日
触发条件	当前预计完成日期晚于基线日期，或评审通过率低于约定值
阈值分级	绿/黄/红三级
黄色阈值	距基线日期剩余5个工作日，且评审通过率低于80%
红色阈值	已超过基线日期，或预计完成日期晚于基线3个工作日以上
通知对象（角色）	需求评审直接责任人
通知方式与频率	系统通知加邮件；黄色每日一次，红色每半日一次
升级路径（第一级）	黄色预警24小时未确认，升级至项目负责人
升级路径（第二级）	红色预警或第一级升级后48小时未处理，升级至项目群负责人
升级时限	第一级24小时，第二级48小时，均按工作日计算
响应动作	确认预警、更新预计完成日期、提交评审纠偏措施
关闭条件	需求评审完成并通过，或基线经批准调整且偏差回到绿色区间
确认与关闭记录	记录确认人、确认时间、纠偏措施和关闭时间
规则责任人	项目负责人
生效日期	2025年6月1日

这条规则中，黄色预警先送达直接责任人，24小时未确认即升级至项目负责人；红色预警直接进入更高关注级别，48小时未处理升级至项目群负责人。关闭条件同时覆盖“完成验收”和“基线调整后回到绿色区间”两种情形，避免预警在计划变更后仍然持续。确认与关闭记录保留处理过程，便于在项目复盘中判断阈值是否合理。

在ONES中，里程碑可用于标记项目中的重要时间点、事件或决策点，项目计划和里程碑基线支持实时对比计划与执行的偏差，帮助提早识别风险。上述规则表可以作为配置依据：里程碑对应监控对象，工作项状态和预计完成日期对应触发条件的判断来源，通知与升级则依托团队在工具中约定的流转方式执行。具体通知对象和升级流转的配置方式，需结合所选产品的实际能力核验。

调整与维护：阈值分级和升级路径怎么改

模板上线后，阈值和升级路径需要随项目进展和人员变化调整。维护的重点是让规则始终对应真实的角色和可执行的时限，而不是一次配置后长期不动。

• 阈值分级的调整依据：当同一里程碑连续多次触发黄色预警但未出现实际延误，说明黄色阈值偏早，可适当缩短提前量；当红色预警频繁出现且升级后仍无法按期完成，说明阈值偏晚或基线本身需要复核。调整阈值应基于一段时间的预警记录，并在规则变更记录中写明调整原因和生效日期。
• 通知对象随人员变动的维护：规则中填写角色而非人名，人员变动时只需更新角色对应的成员，不改动规则本身。项目负责人变更、团队拆分或职责调整后，应核对每条规则的通知对象是否仍指向正确的角色。
• 升级路径的定期复核：建议在项目阶段评审或月度例会上复核升级路径，确认每一级的接收角色仍在岗、时限仍可执行。跨项目里程碑进入项目群管理后，第二级升级对象应同步调整。
• 规则变更记录方式：每次修改阈值、通知对象或升级路径，记录变更日期、变更字段、变更前后内容和批准人。规则编号保持不变，通过版本或变更记录区分历史配置，便于回溯某次预警为何按当时的路径升级。

维护责任建议落到规则责任人，通常为项目负责人；涉及多个项目的公共里程碑，可由项目管理办公室统一维护阈值口径和升级层级。调整完成后，用一条历史预警做一次核对，确认通知对象和升级时限按新配置生效，再结束变更流程。

常见问题

里程碑预警的黄色和红色阈值应该间隔多久才合理？

间隔没有统一标准，取决于里程碑的重要程度和团队的实际响应速度。一个可操作的判断方法是：黄色阈值留出的时间，应当足够直接责任人完成一次确认和一次纠偏动作；红色阈值则设在偏差已经影响后续交付或已经逾期时。重要节点可以缩短黄色预警的提前量，让团队更早介入；响应链条较长的跨团队里程碑，可以适当放宽黄色提前量，避免预警过早触发后被忽略。上线一段时间后，用预警记录核对：黄色频繁触发但未出现实际延误，说明提前量偏早；红色频繁出现且升级后仍无法按期完成，说明阈值偏晚或基线需要复核。

通知对象填角色还是填具体人名？人员变动时怎么处理？

建议填角色，例如“里程碑直接责任人”“项目负责人”“项目群负责人”，不填具体人名。角色相对稳定，人员变动时只需更新角色对应的成员，规则本身不用改动。如果某些特殊里程碑确实需要指定个人，可以在角色之外单独备注，但主字段仍保留角色，避免因个别人离岗导致预警无人接收。项目负责人变更、团队拆分或职责调整后，应逐条核对规则中的通知对象是否仍指向正确的角色。

小型项目可以只设一级升级路径吗？

可以。最低可用配置只需要保证预警能触发、能送达、能关闭，小型项目可先配置黄色和红色两级阈值、一级升级路径，减少维护负担。涉及多个团队、对外交付或高风险的里程碑，建议补齐第二级升级路径和确认关闭记录，让预警在项目负责人层面仍未处理时能继续向上传递。第二级升级对象可以是项目群负责人或管理层，具体按组织实际的管理层级确定。

预警发出后一直没人确认，规则应该怎么设计才能避免中断？

关键是给每一级升级设置明确的时限，并把“未确认”本身作为升级触发条件。例如黄色预警24小时未确认即升级至项目负责人，红色预警或第一级升级后48小时未处理再升级至项目群负责人。时限按工作日或小时填写，避免只写“尽快”。同时配置关闭条件，让预警在里程碑完成验收或基线经批准调整后能够结束，防止预警长期挂起、持续干扰接收方。确认与关闭记录保留确认人、确认时间和处理动作，便于复盘时判断时限是否合理。

模板里的规则需要多久复核一次？由谁负责？

建议在项目阶段评审或月度例会上复核升级路径，确认每一级的接收角色仍在岗、时限仍可执行。维护责任通常落到规则责任人，一般为项目负责人；涉及多个项目的公共里程碑，可由项目管理办公室统一维护阈值口径和升级层级。每次修改阈值、通知对象或升级路径，记录变更日期、变更字段、变更前后内容和批准人，规则编号保持不变，通过版本或变更记录区分历史配置。调整完成后，用一条历史预警核对新配置是否生效。