风险预警阈值可以按“可能性×影响”两个维度打分，再映射为黄、橙、红三级预警。本文给出一份已填好的演示表：一个为期六个月、十人左右的交付项目，列出风险条目、分值区间、触发条件、响应时限和责任人，并逐项解释取值理由，最后说明换项目时该改哪些参数、哪些情形不宜直接套用。表中数值为演示情景下的初始假设，不构成行业标准。
要点总览（TL;DR）
- 阈值表用“可能性×影响”两个维度各分五档打分，乘积映射为黄、橙、红三级预警，并配触发条件、响应时限、风险 owner 与升级对象。
- 黄橙红分界取1–6、8–12、15–25，空档按“就高”归级；影响为5且可能性不低于2的风险直接按红色处理，避免高后果风险被分值稀释。
- 响应时限随级别收紧：红色24小时、橙色3个工作日、黄色按周跟踪，起算点统一为风险被识别并登记的时间。
- 换项目时保留表结构，按项目周期改响应时限、按业务影响面改写档位描述、按团队规模调整升级层级，并用历史风险回测校准分界值。
- 已发生的阻塞问题转入项目问题管理，跨项目组合风险平衡另行处理；示例数值为演示假设，不构成行业标准。
这份阈值示例要解决什么问题
这份示例要回答一个具体问题：当团队在例会上讨论“这个风险要不要升级”时，依据什么条件判定它属于哪一级预警，以及判定之后谁在多长时间内做什么。没有统一口径时，同一个风险在不同人眼里可能是“先记一下”也可能是“马上处理”，预警就失去了提前量。
示例设定为一个演示情景：某软件交付项目，周期六个月，团队约十人，处于开发与联调阶段，客户验收节点固定。项目已建立风险登记表，每周更新一次风险状态。这个规模意味着风险信息可以靠项目例会集中处理，升级链条不宜过长；六个月周期意味着响应时限以“天”为单位比以“周”为单位更合适。
示例覆盖的风险类型包括进度延期、关键人员流失、需求变更、外部依赖交付延迟和质量的集中爆发。判定链条固定为三步：先给可能性和影响各打一个分，再算综合分值并对照区间得到预警级别，最后按级别执行对应的响应时限和上报路径。低概率但高影响的风险允许跨级触发，这条规则在表中单独体现。
完整示例：一张填好的风险预警阈值表
先确定两个维度的打分口径，两者都分五档，分值越高代表越需要关注。
| 档位 | 可能性描述 | 影响描述 |
|---|---|---|
| 1 | 几乎不会发生，无近期迹象 | 对交付节点和成本基本无影响 |
| 2 | 较少发生，有间接迹象 | 局部返工，可由团队内部消化 |
| 3 | 有可能发生，已有早期信号 | 影响一个里程碑，需要调整局部计划 |
| 4 | 较可能发生，条件正在形成 | 影响关键路径或客户验收节点 |
| 5 | 很可能发生，已出现明确征兆 | 导致交付延期、合同违约或重大质量事故 |
综合分值为可能性与影响的乘积，范围1至25，映射为三级预警：1至6分为黄色，8至12分为橙色，15至25分为红色。乘积为7、13、14等不落在区间内的组合，按“就高”原则归入相邻的较高级别，避免出现无级别可归的空档。此外设置一条跨级规则：影响为5且可能性不低于2的风险，直接按红色处理。
| 风险编号 | 风险描述 | 可能性 | 影响 | 综合分值 | 预警级别 | 触发条件 | 响应时限 | 风险 owner | 升级对象 |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | 核心模块联调进度落后于基线计划 | 4 | 4 | 16 | 红色 | 联调完成率连续两周低于计划的80%，或关键里程碑偏差超过5个工作日 | 24小时内召集专项会议并给出纠偏方案 | 开发负责人 | 项目经理，必要时上报项目发起人 |
| R-02 | 第三方接口供应商交付延迟 | 3 | 4 | 12 | 橙色 | 供应商承诺交付日推迟超过3个工作日，或接口文档未按期提供 | 3个工作日内确认替代方案与新的对接时间 | 集成负责人 | 项目经理与采购接口人 |
| R-03 | 需求变更导致部分已开发功能返工 | 3 | 3 | 9 | 橙色 | 单次变更涉及已进入测试阶段的功能，或累计变更工作量超过10人天 | 3个工作日内完成影响评估并更新计划 | 需求负责人 | 项目经理与产品负责人 |
| R-04 | 测试阶段缺陷密度高于预期 | 2 | 3 | 6 | 黄色 | 单个迭代内严重缺陷数超过3个，或缺陷修复周期超过5个工作日 | 每周例会跟踪，5个工作日内给出改进措施 | 测试负责人 | 项目经理 |
| R-05 | 关键岗位人员可能离职 | 2 | 5 | 10，按跨级规则升为红色 | 红色 | 出现明确离职意向，或该岗位知识未完成交接 | 24小时内启动交接安排与备份人员指定 | 项目经理 | 部门负责人与人力资源接口人 |
表中R-05是跨级规则的应用示例：乘积为10本应落在橙色区间，但影响为5且可能性为2，满足“影响5、可能性不低于2”的条件，直接按红色处理。这样处理的原因是关键岗位空缺对交付的冲击具有不可逆性，等待分值自然升高会错过干预窗口。
逐项解释：阈值为什么这样定
可能性与影响各分五档，是在可区分性和填写成本之间取的平衡。三档太粗，无法区分“已有早期信号”和“已出现明确征兆”；七档以上又会让评估者在相邻档位之间反复犹豫，降低打分一致性。五档配合具体的行为描述，能让不同角色对同一风险给出接近的判断。
黄橙红的分界值按乘积分布确定。1至6分对应低至中等组合，风险处于可观察范围，用例会节奏跟踪即可；8至12分对应至少一个维度达到3以上，意味着风险已具备影响里程碑的条件，需要指定动作和时间点；15分以上代表两个维度都偏高，属于必须立即投入资源的级别。分界值取整并留出空档，是为了让区间边界清晰、便于记忆，空档用“就高”原则处理。
响应时限与级别挂钩，遵循级别越高、时限越短的原则。红色24小时、橙色3个工作日、黄色5个工作日或按周跟踪，这个梯度与六个月的项期匹配：红色风险若拖过一周，纠偏窗口可能已经关闭；橙色风险需要跨角色协调，3个工作日足够完成一次评估和一次决策；黄色风险允许在例会节奏内处理。时限的起点统一为“风险被识别并登记”的时间，避免因起算点不同产生争议。
责任人区分风险 owner 与升级对象，是为了把日常跟踪和资源决策分开。风险 owner 是离风险最近、掌握第一手信息的人，负责更新状态、执行响应动作；升级对象掌握资源或决策权，在风险超出 owner 的处理能力时介入。两者分开可以避免所有风险都涌向项目经理，也能让升级动作有明确对象，而不是停留在“已上报”的状态。
可迁移规律：换一个项目怎么改这张表
迁移时保持表结构不变，只调整参数。字段、打分维度、三级预警的框架可以沿用，需要改的是档位描述、分界值和响应时限，因为这些参数与项目周期、影响面和团队规模直接相关。
- 按项目周期调整响应时限。周期三个月以内的项目，红色时限可压缩到12小时或当日，橙色压缩到1至2个工作日；周期一年以上的项目，橙色可放宽到5个工作日，但红色仍应保持在24至48小时内，避免长周期项目对紧急风险反应迟钝。
- 按业务影响面改写影响档位描述。面向外部客户、涉及资金或合规的项目，影响5的描述应具体到合同条款、监管要求和客户损失；内部工具类项目可以把影响5限定为“影响多个团队的核心工作流”，避免把内部不便误判为最高影响。
- 按团队规模调整升级层级。十人左右的项目，升级对象设到项目经理和部门负责人两级即可；五十人以上或跨部门项目，需要在橙色级别就引入跨部门协调人，红色级别设置固定的决策会，升级路径写入表中而不是临时约定。
- 按历史数据校准分界值。有历史风险记录的项目，可以统计过去风险的实际发生率和影响，把分界值设在“过去半年内需要干预的风险”所对应的分值附近；没有历史数据时，先按本文区间试运行一个季度，再根据误报和漏报情况调整。
- 保留跨级规则。无论参数怎么改，建议保留一条“高影响低概率可跨级”的规则，具体阈值可按项目风险偏好设定，但规则本身不宜删除，否则极端后果类风险容易被综合分值稀释。
调整完成后，用三到五条历史风险回测一遍：把当时的可能性和影响重新打分，看映射出的级别是否与当时的实际处理方式一致。偏差较大的条目，说明档位描述或分界值需要修正，这比直接上线一套未经验证的阈值更稳妥。
阈值表要真正发挥作用，需要和风险登记、状态更新、预警跟踪放在同一个协作流程里。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，用于提早识别风险和问题；项目列表可以查看项目状态、资源投入和当前进展，为可能性和影响的打分提供依据。风险登记后的跟踪动作，可以围绕关键阶段和交付目标开展协同管理，让 owner 更新状态、升级对象接收上报，形成从识别到响应的闭环。具体字段和通知方式以团队实际开通的模块为准。
适用边界：示例不能直接照搬的情形
这张表适用于尚未发生、需要提前判断和干预的风险。已经发生的阻塞问题，例如线上故障、已确认的交付违约，应转入项目问题管理流程，按问题处置的时限和责任分工处理，用风险阈值去衡量已发生事件会延误处置。
跨项目组合层面的风险平衡不在本文范围。多个项目争夺同一批资源、组合层面的风险敞口如何分配，需要组合管理的视角和独立的评估口径，单项目阈值表无法承担这个任务。
缺乏历史数据时，表中的分界值和响应时限只能作为初始假设。试运行期间应记录每次预警是否触发、触发后是否真的需要干预，用这些记录校准参数。把初始假设当成固定标准，容易出现黄色预警频繁误报或红色预警长期空转的情况。
示例中的数值是演示情景下自拟的，不构成行业标准、认证结论或对特定项目的效果承诺。不同行业、不同合同类型对风险影响的定义差异很大，直接照搬分值区间可能与本项目的实际风险感受不符。建议把本文表格作为起点，结合本项目的历史记录和干系人共识完成本地化调整后再投入使用。
常见问题
团队没有历史风险数据，第一次设阈值该从哪里起步？
可以先按本文区间试运行一个季度，把分界值和响应时限当作初始假设而不是定论。试运行期间记录两类情况：触发预警但实际无需干预的误报，以及事后发现应预警却未触发的漏报。季度末根据这两类记录调整分界值，误报集中就上调对应级别的下限，漏报集中就下调。同时用三到五条已发生的风险回测，把当时的可能性和影响重新打分，看映射级别与实际处理方式是否一致。
同一个风险，不同角色打出的可能性分数不一致怎么办？
分歧通常来自档位描述太抽象。处理方式是把五档描述改写成可观察的信号，例如“已有早期信号”具体到“连续两周进度偏差超过计划的一定比例”。打分时由风险 owner 先给出初评，例会上对跨档分歧做一次简短对齐，记录最终取值和理由。积累若干条记录后，档位描述会逐步贴合团队的实际判断习惯，分歧随之减少。
风险已经升级为红色，但响应后没有缓解，下一步怎么处理？
红色风险的24小时时限约束的是首次响应，不是风险关闭。首次响应后如果没有缓解，应在升级对象层面重新评估：是触发条件判断有误、纠偏方案不可行，还是风险本身已经转化为问题。若已出现实际阻塞，按项目问题管理流程处置；若仍属未发生的不确定性，则调整应对策略并重新设定下一次检查时间点，必要时上报更高层级。阈值表可以增加“红色风险连续两次检查未缓解即上报”的规则。
阈值表应该多久复核一次？
建议在项目阶段转换时复核一次，例如从开发进入联调、从联调进入验收，因为影响档位的含义会随阶段变化。此外出现以下情况时也应临时复核：项目范围或交付节点发生重大变更、团队规模明显增减、连续出现误报或漏报。复核内容主要是档位描述、分界值和响应时限三项参数，表结构保持不变，避免每次复核都重新设计表格。
在 ONES 里落地这套阈值，需要提前准备什么？
先建立项目计划和里程碑基线，ONES 支持实时对比计划与执行的偏差，用于提早识别风险和问题；项目列表可查看项目状态、资源投入和当前进展，为可能性和影响的打分提供依据。风险登记后的跟踪动作，可围绕关键阶段和交付目标开展协同管理，让风险 owner 更新状态、升级对象接收上报。具体字段和通知方式以团队实际开通的模块为准。
