第3章 评审Checklist的总体框架：维度划分、检查项分类、优先级标注

适用场景

本章适用于以下情况：

• 团队首次搭建需求原型评审规范，需要建立结构化的Checklist体系。
• 现有评审清单条目杂乱、缺乏层次，导致评审效率低、遗漏率高。
• 需在多项目、多团队间统一评审标准，确保评审质量可度量、可追溯。
• 评审资源有限，需要明确高优先级检查项以集中精力发现关键问题。

前置条件

• 已完成原型基础元素（页面、流程、交互）的评审需求收集。
• 已确定评审的目标角色（产品、设计、开发、测试）。
• 已有至少3个历史评审案例的缺陷记录作为分类依据。

操作步骤

1. 识别归类维度：将需求原型评审的检查要点归类到业务逻辑、交互体验、数据校验、非功能约束、技术可行性五个基础维度中。
2. 建立条目分类树：根据维度划分定义检查项的分类层级，确保每个检查项归属唯一维度和子类。
3. 执行优先级标注：使用P0/P1/P2三级制标注每条检查项的重要程度，P0为必须通过项，P1为重要项，P2为优化建议项。
4. 形成框架矩阵：将维度、分类、优先级三维信息整合为二维Checklist表格，便于快速索引与使用。

输入输出物

责任边界

• 产品经理：主导维度划分与优先级标注，确保框架反映业务核心诉求。
• 开发代表：审核技术可行性维度的检查项是否完整，补充性能、安全等要点。
• 测试代表：审核数据校验维度的检查项是否覆盖边界、异常场景。
• 设计师：审核交互体验维度的分类是否符合用户体验一致性规范。
• 评审主持人：协调各方就分类归属和优先级达成一致，记录争议与最终决策。

记录材料

• 维度划分定稿会议记录（含各方签收）。
• Checklist框架的版本号与变更日志。
• 优先级标注的决策依据说明（如用户影响、成本、风险）。
• 框架试用反馈记录（至少覆盖1个完整评审周期）。

异常处理

验收标准

• Checklist框架包含≥5个维度、≥3级检查项分类、P0/P1/P2三级优先级标注。
• 每一条检查项均能唯一匹配到一个子分类且优先级明确。
• 框架能在1小时内对典型原型（20页以内）完成一轮完整评审。
• 至少3个不同角色的使用人员认可框架结构，无归类歧义。
• 框架的版本管理、变更记录、使用说明文档齐备。