里程碑预警规则表用来把“里程碑可能延期”从口头提醒变成可执行的判断：谁在什么偏差下收到通知、由谁接手、多久响应。本文交付一张可直接复制填写的空白表，并说明字段口径、必填项、四级阈值默认区间和一条完整填写示例，最后给出规则变更与复盘方法。
要点总览（TL;DR）
- 规则表以“一个里程碑一条规则”为单位，至少覆盖标识、日期、偏差、阈值级别、通知对象、升级路径、响应时限和状态记录。
- 阈值默认分四级：绿色为提前或按期，黄色为滞后1–3天，橙色为滞后4–7天，红色为滞后超过7天或已影响关键路径。
- 偏差天数用预测日期减基准日期计算，基准日期取经审批的里程碑基线，避免计划一改偏差归零。
- 必填字段缺失应在录入环节阻断；基准日期缺失时先补基线再启用预警判定。
- 规则变更需留痕，阈值与升级路径调整经项目负责人审批，并定期复盘阈值与实际风险的匹配度。
可复制空白模板：里程碑预警规则表
规则表以“一个里程碑一条规则”为基本单位。填写时先完成主表，再为每个里程碑配置阈值分级和升级路径。以下两张表可直接复制到电子表格或在线文档中使用。
规则主表
| 字段 | 填写内容 |
|---|---|
| 规则编号 | |
| 项目名称 | |
| 里程碑编号 | |
| 里程碑名称 | |
| 里程碑类型 | |
| 重要度 | |
| 责任人 | |
| 基准日期 | |
| 当前预测日期 | |
| 偏差天数 | |
| 当前预警级别 | |
| 是否影响关键路径 | |
| 通知对象 | |
| 升级路径 | |
| 响应时限 | |
| 状态 | |
| 最近更新日期 | |
| 备注 |
阈值分级与升级路径表
| 预警级别 | 触发条件（偏差天数） | 附加条件 | 通知对象 | 升级对象 | 响应时限 | 要求动作 |
|---|---|---|---|---|---|---|
| 绿色 | ||||||
| 黄色 | ||||||
| 橙色 | ||||||
| 红色 |
“附加条件”用于记录关键路径、外部依赖、合规节点等会改变判定结果的因素；“要求动作”写明该级别下责任人需要提交恢复计划、调整资源还是发起变更评审。
字段说明：每个字段填什么、怎么取数
字段口径不统一，规则表就会变成各人各填的登记簿。下表按标识与日期、偏差与阈值、通知升级与状态三组说明填写方式和取数来源。
| 字段 | 含义 | 填写口径 | 取数来源 |
|---|---|---|---|
| 规则编号 | 规则的唯一标识 | 建议采用“项目简称-ML-序号”，如“CRM-ML-03” | 规则表编制人分配 |
| 里程碑编号 | 与项目计划中里程碑的对应标识 | 沿用项目计划里的编号，不另行编码 | 项目计划或里程碑清单 |
| 里程碑名称 | 里程碑的业务含义 | 写可识别的交付节点，如“核心模块联调完成” | 项目计划 |
| 里程碑类型 | 区分内部节点与对外承诺节点 | 可填内部评审、客户交付、合规申报、上线发布等 | 项目计划与合同约定 |
| 重要度 | 决定阈值松紧的依据 | 分关键、重要、一般三档，判定标准在项目启动时约定 | 项目启动会确认 |
| 责任人 | 对该里程碑结果负责的人 | 填具体姓名与角色，不填部门 | 项目组织分工 |
| 基准日期 | 经审批的里程碑计划日期 | 取最近一次获批的基线日期，变更获批后同步更新并留痕 | 里程碑基线记录 |
| 当前预测日期 | 按当前进展推算的完成日期 | 由责任人定期更新，注明更新依据 | 进度评估、交付物完成情况 |
| 偏差天数 | 预测相对基准的滞后程度 | 预测日期减基准日期，提前为负值，按期为0 | 由前两个日期计算 |
| 当前预警级别 | 按阈值表判定的级别 | 取绿色、黄色、橙色、红色之一 | 按阈值分级表判定 |
| 是否影响关键路径 | 偏差是否传导到项目终点 | 填是或否，填是时需说明受影响的下游节点 | 项目计划中的依赖关系 |
| 通知对象 | 该级别下需要知会的人 | 写角色加姓名，避免只写“相关同事” | 阈值分级表对应行 |
| 升级路径 | 问题未解决时的上报链条 | 按级别逐级写明，红色直达项目发起人 | 项目治理约定 |
| 响应时限 | 收到预警后给出答复的时间 | 按级别设定，如黄色2个工作日内、红色当日 | 项目治理约定 |
| 状态 | 规则当前所处阶段 | 可填正常监控、预警中、已升级、已关闭 | 责任人更新 |
| 最近更新日期 | 本条规则最后一次修改时间 | 每次修改偏差、级别或状态时同步更新 | 规则表维护记录 |
| 备注 | 补充说明 | 记录外部依赖、豁免原因、临时措施等 | 责任人填写 |
偏差天数用基准日期而不是最新计划日期作对比，可以避免计划一改、偏差归零，把真实滞后掩盖掉。基准日期的每次调整都应经过审批，并在备注或变更记录中说明原因。
必填与选填：哪些字段不能空
规则表上线时，必填字段缺失会让预警无法触发或无法找到责任人，应在录入环节阻断；选填字段按项目复杂度补充，缺失不影响基本判定。
| 类别 | 字段 | 理由或适用场景 |
|---|---|---|
| 必填 | 规则编号、项目名称、里程碑编号、里程碑名称 | 保证规则可被唯一识别和检索 |
| 必填 | 重要度、责任人 | 决定阈值松紧，并保证有人对结果负责 |
| 必填 | 基准日期、当前预测日期、偏差天数 | 预警判定的计算基础 |
| 必填 | 当前预警级别、通知对象、升级路径、响应时限 | 保证预警触发后有明确的接收人和处理时限 |
| 必填 | 状态、最近更新日期 | 支撑规则表的日常维护和复盘 |
| 选填 | 里程碑类型 | 项目同时存在内部节点和对外承诺节点时建议填写 |
| 选填 | 是否影响关键路径 | 项目计划已建立依赖关系时填写，用于红色预警的附加判定 |
| 选填 | 备注 | 存在外部依赖、豁免或临时措施时填写 |
必填缺失时的处理分两步：录入阶段不允许保存，提示补齐；历史规则在复盘时发现缺项，由责任人限期补录，补录内容标注补录日期。基准日期缺失的规则应暂停预警判定，先补基线再启用，避免用未获批的日期作为对比基准。
阈值分级怎么定：四级划分与调整方法
默认按偏差天数划分四级，组织可在此基础上按里程碑重要度收紧或放宽。下表给出可直接采用的默认值。
| 预警级别 | 默认触发条件 | 典型通知对象 | 典型升级对象 | 响应时限参考 |
|---|---|---|---|---|
| 绿色 | 提前完成或按期，偏差≤0天 | 里程碑责任人 | 无需升级 | 按常规周报同步 |
| 黄色 | 滞后1–3天 | 责任人、项目负责人 | 项目负责人 | 2个工作日内给出恢复措施 |
| 橙色 | 滞后4–7天 | 项目负责人、相关职能负责人 | 项目管理办公室或项目指导层 | 1个工作日内提交调整方案 |
| 红色 | 滞后超过7天，或已影响关键路径 | 项目发起人、项目指导委员会 | 项目发起人决策 | 当日响应，约定决策时间 |
按重要度调整时，关键里程碑可整体收紧一档，例如把黄色起点从滞后1天提前到滞后1天即触发、橙色从4天提前到3天；一般里程碑可适度放宽，但红色阈值建议保持“超过7天或影响关键路径”不变，避免重大风险被稀释。调整结果写入阈值分级表的触发条件列，并在备注中说明调整依据。
多个条件同时触发时，按以下顺序判定：先看是否影响关键路径，影响则直接进入红色；再看是否属于对外承诺或合规节点，属于则在原级别上提升一级；最后按偏差天数落入对应区间。判定顺序应在项目启动时确认，避免同一里程碑在不同人手里得出不同级别。
填写示例：一条红色预警规则完整走一遍
以下为演示情景，用于说明字段之间如何配合，不代表任何真实项目数据。
| 字段 | 示例填写 | 说明 |
|---|---|---|
| 规则编号 | CRM-ML-03 | 项目简称加序号，便于检索 |
| 项目名称 | 客户管理系统升级 | 与项目立项名称一致 |
| 里程碑编号 | M3 | 沿用项目计划编号 |
| 里程碑名称 | 核心模块联调完成 | 可识别的交付节点 |
| 里程碑类型 | 内部评审 | 非对外承诺节点 |
| 重要度 | 关键 | 后续测试与上线均依赖此节点 |
| 责任人 | 张工（开发负责人） | 具体到人 |
| 基准日期 | 6月20日 | 取自获批基线 |
| 当前预测日期 | 6月30日 | 责任人按当前进展更新 |
| 偏差天数 | 10天 | 预测日期减基准日期 |
| 当前预警级别 | 红色 | 超过7天，且下游测试排期受影响 |
| 是否影响关键路径 | 是 | 测试启动依赖联调完成 |
| 通知对象 | 项目发起人、项目指导委员会、测试负责人 | 按红色级别配置 |
| 升级路径 | 责任人→项目负责人→项目发起人 | 红色直达发起人 |
| 响应时限 | 当日响应，2个工作日内给出决策 | 按红色级别约定 |
| 状态 | 已升级 | 已进入升级流程 |
| 最近更新日期 | 6月22日 | 与预测日期更新同步 |
| 备注 | 第三方接口联调排期延后，已申请资源支援 | 记录原因与临时措施 |
这条规则中，偏差10天先触发红色阈值，影响关键路径作为附加条件进一步确认级别，通知对象和升级路径直接取自阈值分级表红色行，响应时限与状态记录则支撑后续跟踪。字段之间形成闭环：日期算出偏差，偏差决定级别，级别决定通知谁、找谁决策、多久答复。
调整与维护：规则表的版本与复盘机制
规则表上线后需要随项目推进持续维护，重点在三件事：变更留痕、定期复盘、与里程碑清单保持同步。
规则变更包括阈值调整、通知对象更换、升级路径修改和里程碑增删。建议每次变更记录变更日期、变更字段、变更前后内容、申请人和审批人，形成变更记录表。阈值和升级路径属于治理约定，变更应经项目负责人审批；仅更新预测日期和状态属于日常维护，由责任人直接更新并保留最近更新日期。
| 变更记录字段 | 填写内容 |
|---|---|
| 变更日期 | |
| 规则编号 | |
| 变更字段 | |
| 变更前内容 | |
| 变更后内容 | |
| 变更原因 | |
| 申请人 | |
| 审批人 |
阈值复盘建议按固定周期进行，例如每个阶段结束时或每月一次；出现连续两次红色预警、同一里程碑反复调整基准日期、预警发出后无人响应等情况时，应触发临时复盘。复盘检查项包括：各级阈值是否与实际风险分布匹配，通知对象是否仍在岗并知情，响应时限是否被遵守，基准日期变更是否都有审批记录。
规则表与里程碑清单的同步维护可以设一条简单规则：里程碑清单新增或删除节点时，规则表在同一工作日内同步；里程碑名称或责任人变化时，规则编号保持不变，只更新对应字段。这样既保证一一对应，也保留历史记录的可追溯性。
当规则表需要在系统中承载时，可以把里程碑作为工作项、把基准日期和预测日期作为字段维护，用基线与实际进度的对比识别偏差。ONES 支持用里程碑标记项目中的重要时间点、事件或决策点，并可设置项目计划和里程碑基线，实时对比计划与执行的偏差，帮助团队提早识别风险；ONES Plan 也支持制定项目里程碑和甘特图，按多时间跨度查看进度。规则表中的阈值分级、通知对象和升级路径仍由团队按本文模板约定，系统承担的是里程碑状态、日期字段和偏差对比的记录与呈现。
常见问题
里程碑的基准日期被批准变更后，偏差天数要不要清零重算？
偏差天数始终按“当前预测日期减基准日期”计算，基准日期变更获批后，用新的基线日期重新计算，并在变更记录中写明原基准、新基准和变更原因。这样偏差反映的是相对当前获批基线的滞后程度，历史变更仍可追溯。若只是更新预测日期，基准日期保持不变。
同一个里程碑同时滞后5天又影响关键路径，应该判为橙色还是红色？
按判定顺序处理：先看是否影响关键路径，影响则直接进入红色；再看是否属于对外承诺或合规节点，属于则在偏差对应级别上提升一级；最后才按偏差天数落入区间。因此滞后5天且影响关键路径的里程碑应判为红色，通知对象和升级路径也按红色行执行。
一般重要度的里程碑，阈值可以放宽到什么程度？
可以适度放宽黄色和橙色的天数区间，例如把黄色起点从滞后1天调到滞后2天，但红色阈值建议保持“超过7天或影响关键路径”不变。放宽的依据要写入阈值分级表的触发条件列，并在备注中说明，避免不同里程碑之间口径混乱。关键里程碑则相反，可整体收紧一档。
规则表里的通知对象写角色还是写姓名？人员变动时怎么处理？
建议写“角色加姓名”，例如“项目负责人（李工）”，既明确到人又保留职责归属。人员变动时只更新姓名，角色和升级路径保持不变，规则编号不变，并在最近更新日期中记录。复盘检查项中应包含通知对象是否仍在岗并知情，避免预警发出后无人响应。
规则表需要在系统里承载时，哪些部分适合放进工具，哪些仍需团队约定？
里程碑本身、基准日期、预测日期和偏差对比适合在系统中维护。ONES 支持用里程碑标记项目中的重要时间点、事件或决策点，并可设置项目计划和里程碑基线，实时对比计划与执行的偏差，帮助团队提早识别风险；ONES Plan 也支持制定项目里程碑和甘特图，按多时间跨度查看进度。阈值分级、通知对象和升级路径属于团队治理约定，仍按本文模板确定，系统承担记录与呈现。
