里程碑预警规则表用来把“哪个里程碑、偏差到什么程度、通知谁、多久内升级”写成可执行的规则。本文提供三张可直接复制到Excel或文档的空白表，并逐字段说明取值与计算口径，标注必填项，附一条完整填写示例和后续维护方法。阈值按关注、预警、严重三级设置，每级对应不同通知范围与升级对象。
要点总览（TL;DR）
- 规则表以“规则行”为单位，每行对应一个里程碑的一条预警规则，核心字段包括规则编号、里程碑名称与类型、计划日期与基准日期、偏差计算口径、预警级别、阈值区间与单位、通知对象与方式、升级对象与时限、责任人、解除条件、规则状态与维护人。
- 阈值按关注（黄色）、预警（橙色）、严重（红色）三级设置，区间连续不重叠，严重级上限可留空表示“及以上”；关键路径受影响可作为附加触发条件直接判定为严重。
- 通知对象按级别分层写角色而非姓名，升级路径写明“触发级别—升级对象—升级时限—未响应处理”，通知时限与升级时限分开填写。
- 规则编号、里程碑名称、计划日期、基准日期、偏差计算口径、预警级别、阈值下限、阈值单位、通知对象、责任人、解除条件、规则状态为必填，缺失时规则置为草稿、不参与预警计算。
- 阈值需按历史偏差数据校准，规则按项目阶段或月度评审，调整阈值或升级路径即升版本，停用规则保留记录不删除。
可复制空白模板：里程碑预警规则表
模板由三张表组成：规则主表记录每条规则的完整信息，阈值分级子表定义各级别的数值边界，通知与升级路径表定义每个级别触达谁、多久升级。三张表通过“规则编号”和“预警级别”关联，复制时保持表头文字不变，后续字段说明与示例均使用同一套字段名。
表一：规则主表
| 规则编号 | 里程碑名称 | 里程碑类型 | 是否关键路径 | 计划日期 | 基准日期 | 偏差计算口径 | 当前预警级别 | 触发条件 | 责任人 | 解除条件 | 规则状态 | 维护人 | 版本号 | 生效日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表二：阈值分级子表
| 规则编号 | 预警级别 | 颜色标识 | 阈值下限 | 阈值上限 | 阈值单位 | 附加触发条件 | 判定说明 |
|---|---|---|---|---|---|---|---|
| 关注 | 黄色 | 天 / % | |||||
| 预警 | 橙色 | 天 / % | |||||
| 严重 | 红色 | 天 / % |
表三：通知与升级路径
| 规则编号 | 预警级别 | 通知对象 | 通知方式 | 通知时限 | 升级对象 | 升级时限 | 未响应处理 |
|---|---|---|---|---|---|---|---|
| 关注 | |||||||
| 预警 | |||||||
| 严重 |
字段说明：每个字段填什么、怎么算
字段按用途分为五组：标识与对象、日期与偏差计算、阈值与级别、通知升级与责任、状态与维护。填写时先确定偏差计算口径，再据此设置阈值，避免同一张表内混用天数差和百分比差。
标识与对象类字段
| 字段名 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 规则编号 | 唯一标识一条规则 | MS-001 | 建议“MS-序号”，全表不重复，子表引用同一编号 |
| 里程碑名称 | 被监控的关键节点 | 需求评审通过 | 与项目计划中的里程碑名称一致 |
| 里程碑类型 | 节点性质分类 | 评审 / 交付 / 决策 | 按团队既有分类填写，便于批量设置阈值 |
| 是否关键路径 | 是否位于关键路径 | 是 / 否 | 关键路径上的里程碑可设置更严格的阈值 |
日期与偏差计算口径字段
| 字段名 | 含义 | 取值示例 | 计算口径 |
|---|---|---|---|
| 计划日期 | 当前计划完成日期 | 2025-06-30 | 随计划变更更新，保留变更记录 |
| 基准日期 | 批准后的基线日期 | 2025-06-15 | 基线确定后不随意改动，作为偏差比较的锚点 |
| 偏差计算口径 | 偏差如何得出 | 预计完成日期减基准日期 | 天数口径写“预计完成日期−基准日期”；工作量口径写“计划完成占比−实际完成占比”的百分点差。同一规则只选一种 |
阈值与级别字段
| 字段名 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 预警级别 | 当前命中的级别 | 关注 / 预警 / 严重 | 由阈值子表判定，主表记录当前结果 |
| 阈值下限 / 上限 | 该级别的数值区间 | 3 / 7（天） | 区间连续不重叠，严重级上限可留空表示“及以上” |
| 阈值单位 | 阈值的计量单位 | 天 / % | 与偏差计算口径保持一致 |
| 附加触发条件 | 数值之外的条件 | 关键路径受影响 | 用于“偏差未达线但影响关键路径”时直接升级 |
通知、升级与责任字段
| 字段名 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 通知对象 | 该级别触达的人 | 里程碑负责人 | 按级别分层，写角色而非姓名，人员变动时只改角色映射 |
| 通知方式 | 触达渠道 | 站内消息 / 邮件 | 写明主渠道和备用渠道 |
| 通知时限 | 触发后多久发出 | 触发当日 | 与升级时限区分，前者是通知，后者是要求响应 |
| 升级对象 | 未响应时上报给谁 | 项目负责人 | 逐级上升，严重级可直达项目发起人 |
| 升级时限 | 多久未处理即升级 | 2个工作日 | 从通知发出时刻起算 |
| 责任人 | 负责跟进该里程碑的人 | 张工（角色：模块负责人） | 写角色加具体人，便于追责与交接 |
状态与维护字段
| 字段名 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 解除条件 | 预警何时关闭 | 实际完成且偏差回到关注线以内 | 写可核验的条件，如“完成评审并上传纪要” |
| 规则状态 | 规则当前是否生效 | 启用 / 停用 / 草稿 | 停用规则保留记录，不删除 |
| 维护人 | 负责该规则的人 | 项目管理办公室 | 与评审责任人一致 |
| 版本号 / 生效日期 | 规则版本与起算时间 | V1.2 / 2025-07-01 | 每次调整阈值或升级路径即升版本 |
必填与选填：哪些字段不能空
必填字段决定规则能否被判定和执行，缺失会导致预警无法触发或无人接收。条件必填字段在特定情形下必须填写，选填字段可按团队成熟度裁剪。
| 档位 | 字段 | 理由或缺失处理 |
|---|---|---|
| 必填 | 规则编号、里程碑名称、计划日期、基准日期、偏差计算口径、预警级别、阈值下限、阈值单位、通知对象、责任人、解除条件、规则状态 | 缺任一项，规则无法判定偏差或无法触达责任人；缺失时该规则不得启用 |
| 条件必填 | 是否关键路径、附加触发条件、升级对象、升级时限、通知时限 | 里程碑位于关键路径时必须填写关键路径标记与附加触发条件；设置了升级机制时必须填写升级对象与时限；未设升级的规则需在备注中说明 |
| 选填 | 里程碑类型、通知方式备用渠道、维护人、版本号、颜色标识、判定说明 | 可在规则表稳定运行后补充；颜色标识仅用于看板展示，不影响判定 |
缺失处理原则：必填字段为空时规则置为“草稿”，不参与预警计算；条件必填字段缺失时，在规则评审会上补齐后再启用。选填字段留空不影响执行，但建议在首次评审时统一补全，便于后续统计。
填写示例：一条完整规则从触发到升级
以下示例为演示情景，用于说明字段与阈值如何配合，数值按常见项目节奏设定，实际使用时按团队历史偏差数据调整。
示例规则完整填写
| 字段 | 填写内容 |
|---|---|
| 规则编号 | MS-003 |
| 里程碑名称 | 系统集成测试完成 |
| 里程碑类型 | 交付 |
| 是否关键路径 | 是 |
| 计划日期 | 2025-08-20 |
| 基准日期 | 2025-08-10 |
| 偏差计算口径 | 预计完成日期减基准日期（天） |
| 责任人 | 测试负责人 |
| 解除条件 | 集成测试报告通过评审，且预计完成日期回到基准日期后3天以内 |
| 规则状态 | 启用 |
| 维护人 | 项目管理办公室 |
| 版本号 / 生效日期 | V1.0 / 2025-07-01 |
三级阈值如何设置
| 预警级别 | 阈值区间 | 附加触发条件 | 判定说明 |
|---|---|---|---|
| 关注（黄色） | 偏差3至6天 | 无 | 预计完成日期晚于基准日期3天起进入关注 |
| 预警（橙色） | 偏差7至14天 | 无 | 偏差扩大，需项目负责人介入协调资源 |
| 严重（红色） | 偏差15天及以上 | 关键路径受影响即直接判定严重 | 即使天数未达15天，关键路径受阻也按严重处理 |
通知对象与升级路径填写
| 预警级别 | 通知对象 | 通知方式 | 通知时限 | 升级对象 | 升级时限 | 未响应处理 |
|---|---|---|---|---|---|---|
| 关注 | 测试负责人 | 站内消息 | 触发当日 | 项目负责人 | 3个工作日未处理 | 自动升级至预警级通知 |
| 预警 | 测试负责人、项目负责人 | 站内消息 + 邮件 | 触发当日 | 项目发起人 | 2个工作日未处理 | 升级至严重级并列入周会 |
| 严重 | 项目负责人、项目发起人、管理层 | 邮件 + 例会通报 | 触发后4小时内 | 项目发起人直接决策 | 1个工作日 | 启动专项协调会，记录决策结论 |
解除条件与关闭记录
该规则在集成测试报告通过评审、且预计完成日期回到基准日期后3天以内时解除。关闭时在规则主表记录解除日期、实际完成日期、最终偏差天数和关闭人，保留原预警记录，便于后续统计该里程碑的偏差分布，作为阈值调整依据。
在工具层面落地时，ONES 支持制定项目里程碑与甘特图，并通过项目计划和里程碑基线对比计划与执行的偏差。规则表中的通知对象、升级时限和解除条件，可以对应到工作项状态流转与消息通知的配置中，使预警从表格规则变成可跟踪的处理记录。
调整与维护：阈值怎么改、规则怎么退役
规则表不是一次填完就固定不变。阈值需要随项目实际偏差数据校准，规则需要定期评审、升版和停用，避免预警过多失去敏感度或过少漏掉风险。
阈值调整的触发情形
- 连续多个周期同一级别预警频繁触发，说明阈值偏严，可上调关注线或严重线。
- 出现预警未触发但实际已延误的情况，说明阈值偏松，需下调或补充附加触发条件。
- 项目阶段变化，如从开发转入交付，关键路径改变，需重新设置关键路径标记与对应阈值。
- 组织调整或责任人变更，通知对象与升级对象同步更新。
规则评审周期与责任人
建议按项目阶段节点评审，交付类项目可在每个里程碑完成后复核一次，长期项目按月评审。评审由维护人组织，责任人参加，输出结论为“维持、调整、停用”三种之一，并记录评审日期与参与人。
规则停用与版本记录
| 变更类型 | 记录内容 | 处理方式 |
|---|---|---|
| 阈值调整 | 旧阈值、新阈值、调整依据、生效日期 | 版本号加一，旧版本保留为停用状态 |
| 通知或升级路径变更 | 变更前后对象与时限 | 同步更新通知与升级路径表，通知相关角色 |
| 规则停用 | 停用原因、停用日期、替代规则编号 | 状态改为停用，不删除记录 |
与项目实际执行数据的对照校验
每月将规则表判定结果与实际完成情况对照：统计各级别触发次数、升级次数、平均响应时长和最终偏差天数。若某级别长期零触发，检查阈值是否形同虚设；若升级后仍延误，检查升级对象是否有足够决策权限。对照结果写入变更记录，作为下一版阈值的依据。ONES 提供多维度项目数据统计和分析能力，可用于核对里程碑偏差与预警响应的实际表现。
维护检查清单
- 每条启用规则的必填字段是否完整，条件必填字段是否按情形补齐。
- 阈值区间是否连续、无重叠，单位与偏差计算口径一致。
- 通知对象与升级对象是否仍为在职角色，升级时限是否可执行。
- 解除条件是否可核验，关闭记录是否包含实际完成日期与最终偏差。
- 版本号、生效日期、停用原因是否记录完整，旧版本是否可追溯。
- 本期实际偏差数据是否已对照，是否形成调整结论。
常见问题
里程碑预警规则表里的偏差计算口径，天数差和百分比差能混用吗？
同一张规则表内建议统一为一种口径。天数差适合完成日期可预估的节点，写法是“预计完成日期减基准日期”；百分比差适合工作量可量化的节点，写法是“计划完成占比与实际完成占比的百分点差”。两种口径混用会让阈值区间失去可比性，判定结果也难以横向统计。如果项目里两类节点都需要监控，可以按里程碑类型分组，每组内部保持口径一致，并在阈值单位字段中明确标注“天”或“%”。
关键路径上的里程碑偏差还没到严重线，需要提前升级吗？
可以在阈值分级子表中把“关键路径受影响”设为附加触发条件，命中后直接判定为严重级，不必等天数偏差达到严重线。这样设置的前提是规则主表中“是否关键路径”字段已如实填写，且关键路径标记随计划变更同步更新。若关键路径判断本身存在争议，建议先在规则评审会上确认判定依据，再启用该附加条件，避免同一里程碑在不同人手里得出不同级别。
通知对象写角色还是写具体人名？人员变动时怎么处理？
建议写角色，例如“测试负责人”“项目负责人”，并在责任人字段中补充角色加具体人，便于追责与交接。人员变动时只需更新角色映射，规则表本身不用逐条改。升级对象同样按角色填写，严重级可写到“项目发起人”或“管理层”这类稳定角色。若团队规模小、角色重叠，可以在备注中说明兼任情况，但通知与升级的层级关系仍需保留，避免升级路径退化为同一个人。
规则表填好后，多久评审一次比较合适？
可以按项目阶段节点评审：交付类项目在每个里程碑完成后复核一次，长期项目按月评审。评审由维护人组织，责任人参加，结论为“维持、调整、停用”三种之一，并记录评审日期与参与人。出现连续多个周期同一级别频繁触发、预警未触发但实际已延误、项目阶段变化或责任人变更时，应提前触发调整，不必等到固定评审日。评审结论写入变更记录，作为下一版阈值的依据。
规则停用后，原来的预警记录还要保留吗？
要保留。规则状态改为“停用”即可，记录不删除，同时在停用记录中写明停用原因、停用日期和替代规则编号。历史预警记录是后续统计偏差分布、校准阈值的基础数据，删除后无法回溯某条规则当时的判定是否合理。版本号与生效日期字段配合使用，每次调整阈值或升级路径即升版本，旧版本保留为停用状态，保证规则表可追溯。
