第1章 文档评审的适用场景
1.1 评审触发条件
文档评审并非随机发起，必须基于明确的触发条件。以下场景必须启动评审流程：
| 触发类型 | 具体条件 | 说明 |
|---|---|---|
| 里程碑节点 | 解决方案设计完成初稿、终稿、变更修订稿 | 项目阶段交付物默认触发评审 |
| 外部依赖变化 | 需求变更、技术选型调整、合规要求更新 | 非计划性触发，需快速响应 |
| 质量门禁 | 文档未通过自检清单、关键指标不达标 | 自动降级为评审保留状态 |
| 风险升级 | 设计存在架构风险、安全漏洞或成本超支 | 强制启动专项评审 |
关键阈值：文档版本号从 v0.1 提升至 v0.2 之前，必须完成至少一次正式评审；版本进入 v1.0 发布候选状态前，需通过全量评审。
1.2 评审类型
评审按关注维度分为三种类型，每类评审对应不同的评审组和检查要点：
| 评审类型 | 核心关注 | 典型参会角色 | 检查清单示例 |
|---|---|---|---|
| 技术评审 | 架构可行性、技术选型合理性、性能指标、集成方案 | 系统架构师、技术负责人、开发代表 | 模块分解是否清晰？依赖是否已声明？非功能需求是否可测量？ |
| 业务评审 | 需求覆盖度、业务价值匹配、用户场景闭环 | 业务分析师、产品经理、客户代表 | 核心流程是否完整？异常处理是否符合业务规则？验收标准是否被定义？ |
| 合规评审 | 安全规范、数据隐私、行业法规、组织政策 | 合规官、安全工程师、法务代表 | 数据存储是否满足 GDPR/等保？授权模型是否合理？审计日志是否包含？ |
实践建议：一次评审会议可以同时包含技术+业务两种类型，但合规评审建议单独召开，避免因合规结论影响技术/业务决策的独立判断。
1.3 评审频次要求
频次由项目节奏和文档变更幅度决定，遵循以下分级策略：
| 项目阶段 | 最低评审频次 | 说明 |
|---|---|---|
| 立项 / 概念阶段 | 1 次 / 里程碑 | 初步方案评审，确认方向 |
| 详细设计阶段 | 2 次 / 迭代 | 一次初稿评审（技术+业务），一次终稿全量评审 |
| 变更管理 | 按变更影响评估 | 影响范围≤20% 可走快速评审（仅邮件+审批）；＞20% 必须启动会议评审 |
| 发布前准备 | 1 次全面评审 | 涵盖技术、业务、合规三种类型，需三方签字 |
⚠ 常见偏差：团队容易在需求稳定期跳过评审，导致后期返工。建议在迭代计划中固定评审 slot，即使没有文档更新，也保持“零更新确认”机制。
1.4 场景关系图
1.5 前置条件 & 输入输出物
| 环节 | 前置条件 | 输入物 | 输出物 |
|---|---|---|---|
| 触发评审 | 满足1.1中任一条件 | 待评审文档草案、变更申请单 | 评审会议邀请、评审通知 |
| 执行评审 | 评审组长确认材料完备 | 评审材料包（文档、自检表、基线对比） | 评审意见汇总、问题跟踪表 |
| 关闭评审 | 所有问题已关闭或达成延期共识 | 修订后文档、问题处理记录 | 评审报告（含通过/带条件通过/不通过结论） |
1.6 责任边界 & 异常处理
- 评审组长：负责裁剪评审类型、控制时间、裁定争议。
- 文档作者：提供材料、解答疑问、执行修订。
- 评审员：独立检查，不参与本模块设计者优先。
异常处理规则：
• 评审中发现的重大架构缺陷，立即暂停评审，转向架构重构讨论。
• 合规评审不通过时，不允许进入下一阶段，需整改后重新评审。
• 若评审超时（预计2h实际超时30min以上），组长有权终止本次评审并要求补充材料后重新排期。
• 评审中发现的重大架构缺陷，立即暂停评审，转向架构重构讨论。
• 合规评审不通过时，不允许进入下一阶段，需整改后重新评审。
• 若评审超时（预计2h实际超时30min以上），组长有权终止本次评审并要求补充材料后重新排期。
1.7 验收标准
本章节相关流程满足以下条件视为通过：
- 所有触发条件均被文档化并纳入项目管理工具。
- 评审类型选择规则有明确书面定义，团队能一致回答“本次应做哪种评审”。
- 频次要求在项目计划中有对应里程碑或迭代条目。
- 评审前置条件、输入输出物在团队内部达成共识并签字确认。