判断可用性问题是否阻断上线，可以先给每个问题定级，再把等级映射到上线门槛：阻断级问题清零才可上线，严重级问题需有修复计划与规避方案，一般级和轻微级问题可带入上线后迭代。定级依据应来自可复现的评审记录和任务测试数据，让不同评审人面对同一份问题清单能得出相近结论。本文给出四级定级表、数据口径、放行规则和一个完整算例，并说明结论的适用边界。
要点总览（TL;DR）
- 判断可用性问题是否阻断上线，先按影响范围、任务阻断程度、发生频率与触发条件、可恢复性、合规与安全风险五个维度定级，再把等级映射到上线门槛。
- 阻断级问题必须清零才可上线；严重级问题需具备修复计划、规避方案、责任人和完成时限，经审批后可带入；一般级与轻微级问题可排入上线后迭代。
- 定级依据来自可复现的问题记录和任务测试数据，影响范围的分母需事先约定为目标用户数或核心任务路径数，同一批问题只用一种口径。
- 定级表、记录字段和放行规则应在评审前固定，同一版本周期内不随意调整分档，结论才能前后可比、可复核。
- 定级结果只说明是否存在达到阻断条件的问题，样本偏差、小样本和分母为零都会影响结论，上线后仍需监控与回查修正。
上线前可用性评审要回答什么结论
可用性评审的产出是一份可判定、可追溯的上线结论，讨论过程本身不构成结论。结论针对问题清单逐条定级后汇总得出，整体印象只作为讨论背景。评审主持人在会前收齐问题记录，会上逐条确认等级，会后形成结论并留档。
结论有三种形态，适用条件如下：
- 可上线：阻断级问题为零，严重级问题已全部关闭或经批准带入，且每条带入问题都有责任人、时限和规避方案。
- 有条件上线：阻断级问题为零，但仍有未关闭的严重级问题。放行需附修复计划、用户侧规避方案、责任人和完成时限，并明确上线后的回查节点。
- 不可上线：存在任一未关闭的阻断级问题，或严重级问题缺少可执行的规避方案。此时应推迟上线或缩小发布范围。
结论要能追溯到依据：每条问题的等级对应哪几个维度的取值、数据来自哪次测试或哪份记录、谁确认的等级。缺少这层追溯，结论在复盘时就无法复核，也无法在争议时给出解释。
严重程度分级：用哪几个维度定级
定级用五个维度：影响范围、任务阻断程度、发生频率与触发条件、可恢复性、合规与安全风险。前四个维度决定基础等级，合规与安全风险作为独立加权项，可以把问题直接提升到更高等级。逐维度取值后对照分级表落级，避免凭单句描述直接给结论。
各维度的取值口径
- 影响范围：受影响用户占目标用户的比例，或受影响的核心任务路径占全部核心任务路径的比例。占比事先约定分档，例如超过50%、10%–50%、1%–10%、低于1%。
- 任务阻断程度：分为核心任务无法完成、核心任务可完成但需绕行、非核心任务受影响、仅体验瑕疵四档。存在替代路径时，要写明替代路径的操作成本。
- 发生频率与触发条件：在约定时间窗和样本内，问题被触发的次数占相关操作次数的比例。触发条件要写清是特定角色、特定数据状态还是特定设备环境。
- 可恢复性：分为造成数据丢失或不可逆状态、用户无法自行恢复需人工介入、用户可自行恢复但成本高、无残留影响四档。
- 合规与安全风险：涉及个人信息处理、权限越界、资金或合同数据错误时单独标注，按风险性质提升等级，不因影响范围小而降级。
四级定级表
| 等级 | 判定条件（满足其一即可） | 典型表现 |
|---|---|---|
| 阻断 | 核心任务无法完成且无替代路径；或影响范围超过50%；或造成数据丢失、权限越界等合规安全风险 | 关键流程走不通，用户被迫放弃任务 |
| 严重 | 核心任务可完成但需明显绕行；或影响范围10%–50%；或用户无法自行恢复 | 提交失败需重填，或部分角色看不到必要入口 |
| 一般 | 非核心任务受影响；或影响范围1%–10%；或用户可自行恢复但成本较高 | 提示信息不清导致反复尝试，筛选条件失效 |
| 轻微 | 仅体验瑕疵，影响范围低于1%，无恢复成本 | 文案措辞、对齐、非关键提示缺失 |
这张表是建议口径，团队应在上线前评审启动时确认一次并固定下来，同一版本周期内不随意调整分档，否则前后问题的等级不可比。合规与安全风险项一旦触发，直接按阻断处理，并同步给对应的合规或安全负责人确认。
数据口径：定级依据怎么取、怎么记
定级结论的可比性取决于记录字段是否统一。每条问题记录至少包含以下字段，缺字段的问题不进入定级环节：
- 问题描述与复现步骤，步骤要能让另一位评审人独立复现；
- 受影响的任务与任务路径，标明属于核心任务还是非核心任务；
- 触发条件，包括角色、数据状态、设备或浏览器环境；
- 影响范围估计值及其分母口径；
- 发生频率的统计时间窗、样本量与来源；
- 可恢复性判断与依据；
- 合规与安全风险标注；
- 证据附件，如录屏、操作路径记录、测试任务完成情况表。
影响范围的分母怎么定
影响范围占比 = 受影响用户数 ÷ 目标用户数，或受影响核心任务路径数 ÷ 核心任务路径总数。两个分母在评审启动时二选一并写进评审说明，同一批问题只用一种口径。目标用户数取本次上线覆盖的用户范围，不用全量注册用户数；核心任务路径数取本版本验收范围内的路径清单，路径清单本身要作为评审附件留档。
频率统计与缺失数据处理
频率统计要写明时间窗和样本来源，例如“上线前两周内12名测试用户、共86次提交操作中触发9次”。样本量过小时，频率只作为参考，等级主要由任务阻断程度和影响范围决定。某项数据缺失时，在记录中标注“缺失”并写明原因，由评审会现场确认取值，不允许用默认值填充后当作实测数据使用。
定性证据同样要留档：关键任务的录屏、用户操作路径记录、评审会上对争议问题的共识结论。共识结论要写明参与人和最终取值，便于后续复核。
问题记录、定级字段和放行结论如果分散在聊天记录和表格里，复核成本会很高。把每条可用性问题作为工作项登记，在同一个工作项上填写严重程度、影响范围、证据附件和责任人，评审结论与放行审批也挂在该工作项或关联的评审单上，等级变更和审批记录就自然形成可追溯的链路。ONES 的工作项与评审流程可以承载这类记录和流转，具体字段配置以团队实际搭建为准。
从定级到上线门槛：阻断判定规则
定级完成后，按下面的规则表把问题等级映射为上线决策。规则要在评审前公布，评审会只做逐条对照，不再临时讨论门槛。
| 问题等级 | 放行条件 | 需要留档的内容 |
|---|---|---|
| 阻断 | 数量必须为零；存在任一未关闭的阻断级问题即不可上线 | 关闭验证记录 |
| 严重 | 全部关闭，或经审批带入并具备修复计划、用户侧规避方案、责任人、完成时限 | 修复计划、规避方案、审批记录 |
| 一般 | 可带入上线后迭代，需排入迭代计划并指定责任人 | 迭代排期记录 |
| 轻微 | 可带入上线后迭代，可合并处理 | 问题清单条目 |
例外放行的处理
例外放行只适用于严重级问题，且必须同时具备四项内容：修复计划、规避方案、责任人、完成时限。审批由产品负责人与业务负责人共同确认，技术负责人对规避方案的可行性签字。审批记录写明放行理由、带入问题清单和回查日期，与上线结论一并归档。阻断级问题不设例外通道。
上线后回查
有条件上线的版本，在回查日期核对带入问题的修复状态和规避方案的实际效果。回查发现规避方案失效或问题影响扩大的，按新问题重新定级，必要时启动回滚或热修复。回查结果更新到原问题记录上，作为下一版本评审的输入。
算一遍：一次评审的定级与结论示例
以下为演示情景，数据为虚构，仅用于说明计算过程，不代表任何真实项目结论。假设本次上线覆盖目标用户2000人，验收范围内核心任务路径共8条，评审时间窗为上线前两周。
问题清单与维度取值
| 编号 | 问题 | 影响范围 | 任务阻断 | 频率 | 可恢复性 | 合规安全 |
|---|---|---|---|---|---|---|
| P1 | 批量导入订单时页面无响应 | 约600人，占30% | 核心任务无法完成，无替代路径 | 86次操作触发9次 | 需重新导入，无数据丢失 | 无 |
| P2 | 审批人看不到待办入口 | 约120人，占6% | 核心任务可完成，需从消息通知绕行 | 12名测试用户中4人遇到 | 可自行恢复，绕行成本高 | 无 |
| P3 | 筛选条件重置后不生效 | 约80人，占4% | 非核心任务受影响 | 样本内偶发 | 可自行恢复 | 无 |
| P4 | 帮助文案措辞不通顺 | 低于1% | 仅体验瑕疵 | — | 无残留影响 | 无 |
逐条定级
- P1：核心任务无法完成且无替代路径，直接满足阻断条件；影响范围30%也落在严重档，取高者定为阻断。
- P2：核心任务可完成但需绕行，影响范围6%落在一般档，可恢复性为“可自行恢复但成本高”落在一般档，任务阻断程度落在严重档，取高者定为严重。
- P3：非核心任务受影响，影响范围4%，可自行恢复，定为一般。
- P4：仅体验瑕疵，影响范围低于1%，定为轻微。
汇总与结论
汇总结果：阻断1条、严重1条、一般1条、轻微1条。阻断级问题数量不为零，按规则表本次结论为不可上线。处理路径是先修复P1并复测关闭，再重新汇总。
假设复测后P1关闭，P2仍未修复。此时阻断级为零，严重级1条，结论转为有条件上线：P2的修复计划排入下一迭代第一周，规避方案是在上线公告和站内消息中提示审批人从消息通知进入待办，责任人为主管审批模块的产品经理，完成时限为上线后第7个工作日，回查日期定在上线后第10个工作日。P3排入下一迭代，P4合并到文案优化批次处理。
结果怎么解读：常见误判与边界
定级结果回答的是“这批问题里有没有达到阻断条件的问题”，它不证明产品整体可用，也不证明业务目标能够达成。解读结论时注意以下边界：
- 样本偏差：评审用户与实际用户不一致时，影响范围和频率都会失真。测试用户集中在内部员工、缺少特定角色或特定数据状态时，结论只在该样本范围内成立，需要在记录中写明样本构成。
- 小样本与分母为零：样本量过小时频率不可比，分母为零（例如某任务路径本次无人使用）时占比无法计算，应标注为“未覆盖”，不能按零影响处理。
- 定级一致性：不同评审人对同一维度的取值可能不同。校准方法是评审前用3–5条历史问题做一次试定级，对齐分档理解；评审中对争议条目当场记录取值理由。
- 可用性通过不等于业务目标达成：阻断级清零只说明没有达到阻断条件的问题，转化率、留存等业务指标仍需上线后单独观测。
- 结论会被后续数据修正：上线后的监控数据、用户反馈和回查结果都可能改变原有判断。把回查发现的问题按同一套口径重新定级，更新问题记录，下一版本评审直接沿用，定级口径才能保持前后可比。
把定级表、记录字段和放行规则固定为评审模板，每次上线前按同一流程执行，结论就从个人判断变成可复核的团队决策依据。
常见问题
阻断级问题修复后复测通过，能否直接上线？
复测通过只说明该条问题已关闭，上线结论仍需重新汇总整份问题清单。按规则表核对：阻断级是否为零、严重级是否全部关闭或已具备修复计划与规避方案、一般级和轻微级是否已排入迭代。全部满足后由评审主持人更新结论并留档，再进入发布流程。
影响范围占比算不出来时，问题怎么定级？
分母为零或数据缺失时，在问题记录中标注“未覆盖”并写明原因，由评审会现场确认取值，不用默认值填充。此时等级主要由任务阻断程度和可恢复性决定，影响范围一栏保留缺失标注，便于后续补充数据后复核。
不同评审人对同一问题给出的等级不一致，怎么处理？
评审前用3–5条历史问题做一次试定级，对齐各维度的分档理解。评审中对争议条目当场记录取值理由和参与人，按分级表逐维度对照后取最高档。同一版本周期内不调整分档，避免前后问题等级不可比。
有条件上线后，回查发现规避方案失效怎么办？
按新问题重新定级，影响扩大的按阻断级处理，必要时启动回滚或热修复。回查结果更新到原问题记录上，作为下一版本评审的输入，定级口径保持不变以便前后对照。
合规与安全风险为什么单独加权？
涉及个人信息处理、权限越界、资金或合同数据错误的问题，即使影响范围小，后果也可能不可逆。这类问题单独标注并直接按阻断处理，同步给合规或安全负责人确认，不因影响范围占比低而降级。
