第3章 优先级等级定义标准
3.1 适用场景
优先级等级定义标准适用于所有需要进行紧急程度与业务影响排序的评审活动，包括但不限于：缺陷修复排期、需求开发顺序、技术债务清理、安全漏洞响应、运营故障处理。本标准采用 P0–P4 五级体系，确保跨团队、跨角色在沟通优先级时使用统一语言，避免因理解偏差导致资源错配。
3.2 前置条件
- 组织已建立 优先级评审机制，明确评审周期与参与角色；
- 团队已完成 P0–P4 等级标准宣贯，产品、研发、测试、运维各方对定义达成初步共识；
- 存在 待评审事项清单（如缺陷列表、需求池、技术债条目），且每条事项已具备基本描述与影响分析；
- 评审主持人已准备 等级判定参考卡（即本章定义的 P0–P4 标准表）。
3.3 操作步骤
按照以下 五步判定流程 为每一待评事项赋予 P0–P4 等级：
- 识别场景类型 —— 判断当前事项属于 生产故障、功能缺陷、体验优化 还是 未来规划，初步锚定等级区间。
- 对照等级定义表 —— 将事项的 业务影响范围、用户受损程度、是否有变通方案 与 P0–P4 标准逐项比对。
- 判定初始等级 —— 由事项提出人或负责人依据对照结果给出建议等级，并附 判定依据摘要（不超过 50 字）。
- 团队评审校准 —— 在评审会议上集体过审，重点检查跨事项的 相对排序一致性，避免同类事项被赋予不同等级。
- 记录与发布 —— 将最终等级写入 优先级评审记录表，标注判定依据、评审人、评审日期，并同步至相关协作系统。
💡 校准技巧： 若两个事项同时被建议为 P1，但资源仅够处理一个，则触发“同级竞争”讨论，可通过 ROI（影响价值/修复成本） 辅助排序。
3.4 输入输出物
| 类型 | 名称 | 内容说明 | 责任人 |
|---|---|---|---|
| 输入 | 待评审事项清单 | 包含事项编号、标题、描述、提出人、提出日期、初始建议等级 | 事项提出人 / 产品经理 |
| 输出 | 优先级等级定义表（已定稿） | 包含最终 P0–P4 等级、判定依据、评审人、评审日期 | 评审主持人 |
3.5 责任边界
- 事项提出人： 负责提供准确的事项描述与影响评估，给出初始建议等级。
- 评审主持人： 负责召集评审会议，把控判定标准一致性，裁决等级争议。
- 产品经理 / 业务方： 负责从业务价值与用户影响角度提供输入，参与等级校准。
- 研发 / 运维代表： 负责从技术实现、修复成本、紧急程度角度提供输入。
- 记录员： 负责将评审结果、判定依据、决议日期完整录入记录表。
3.6 记录材料
每次优先级评审必须生成 《优先级评审记录表》，该表包含以下核心字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 事项编号 | 唯一标识 | BUG-2025-0381 |
| 事项标题 | 简短描述 | 支付网关超时导致订单丢失 |
| 建议等级 | 提出人初始建议 | P0 |
| 最终等级 | 评审后确定的等级 | P0 |
| 判定依据 | 影响范围 + 触发条件摘要 | 核心交易链路完全中断，无变通方案 |
| 评审人 | 参与评审的人员名单 | 张三 / 李四 / 王五 |
| 评审日期 | 评审会议日期 | 2025-03-21 |
⚠️ 归档要求： 记录表须在评审结束后 24 小时内 完成归档，并同步至项目管理工具（如 Jira、ClickUp），确保可追溯、可审计。
3.7 异常处理
| 异常场景 | 处理措施 | escalation 路径 |
|---|---|---|
| 等级争议（P0 vs P1） | 由评审主持人发起 二次表决，若仍无法达成一致，升级至技术委员会或产品委员会终裁。 | 主持人 → 委员会 |
| 跨团队优先级冲突 | 由双方架构师或产品负责人进行 联合影响评估，按“用户影响 > 商业价值 > 技术成本”排序。 | 团队负责人 → 联合评估会 |
| P0 事项漏评或误判 | 触发 紧急补评流程，由运维或值班架构师直接定级并通知相关方执行应急响应。 | 值班架构师 → 应急响应组 |
| 评审超时（单事项 > 15 分钟） | 暂停该事项讨论，标记为“待线下对齐”，由主持人安排会后再评审。 | 主持人 → 线下对齐 |
3.8 验收标准
- 所有待评事项均已标注 明确的 P0–P4 等级，无未评级项；
- 每个等级的判定依据 可追溯、可复现，第三方角色可依据标准表验证其合理性；
- 团队内部对等级定义的理解 偏差率 < 10%（可通过随机抽样 10 项进行一致性检验）；
- 评审记录表已归档，且 字段完整性 100%（无必填字段缺失）。