开发前的应用蓝图评审
本章目标：在正式开发前，用业务场景逐项检查需求、数据、表单、规则、流程、权限和查询是否形成一致闭环。
1. 为什么要在开发前评审
蓝图评审的成本远低于上线后修改。
它不是让所有人评论颜色和字段位置，而是确认：
- 业务问题是否被正确理解；
- 第一版范围是否明确；
- 正常和异常场景是否都有设计；
- 各部分是否互相矛盾；
- 设计是否在当前条件下可实现；
- 业务负责人是否愿意按这套规则运行。
2. 评审参与者
至少包括：
- 业务负责人：确认目标、制度和优先级；
- 一线用户代表：检查实际操作是否合理；
- 处理/审批角色代表：确认信息和责任；
- 应用开发者：解释整体设计和影响；
- 必要时实例管理者：确认人员、组织和平台前提。
避免只有开发者内部评审，也避免人数过多而没有明确决定人。
3. 评审材料
准备一份简洁但完整的评审包：
- 业务目标卡；
- 第一版范围和暂不做清单；
- 相关人员与职责图；
- 核心业务场景；
- 业务词汇表；
- 业务对象和数据字典；
- 状态与动作表；
- 业务规则和决策表；
- 目标流程图；
- 表单草图；
- 角色权限矩阵；
- 视图、指标、通知和输出清单；
- 需求追踪表；
- 未决问题、依赖和风险。
材料的作用是帮助作决定，不要用大量格式掩盖仍不清楚的内容。
4. 用一笔真实业务走完整蓝图
选择一笔典型采购：
申请人购买 10 盒纸，每盒 35 元；2 个键盘，每个 180 元。总额 710 元。
从头演练：
- 谁发起；
- 用户看到什么；
- 哪些信息自动得到；
- 哪些规则被检查；
- 进入哪条审批路线；
- 审批人看到什么；
- 批准后谁接手；
- 行政怎样登记；
- 申请人在哪里看到结果；
- 管理者的统计如何变化。
然后再走异常：
- 数量为零；
- 金额恰好 5000；
- 金额 5000.01；
- 主管不存在；
- 退回后金额改变；
- 批准后缺货；
- 申请人尝试查看他人申请。
如果演练中频繁出现“到时候再说”，蓝图还未准备好。
5. 七个完整性检查
5.1 目标完整
- 每项功能都能解释服务哪个业务目标；
- 第一版成功标准可观察；
- 没有为了展示功能而增加无关复杂度。
5.2 场景完整
- 正常路径完整；
- 主要异常有去向；
- 角色、前提和结果明确；
- 边界值已决定。
5.3 数据完整
- 所有规则和查询所需信息都被记录；
- 字段来源和责任清楚；
- 主信息和明细合理；
- 关键业务日期完整；
- 历史事实不会被无意覆盖。
5.4 规则与流程完整
- 计算、校验、分支和权限不互相冲突；
- 每个状态有允许动作；
- 流程每个节点有处理人；
- 退回、拒绝、撤回和作废不同；
- 流程结束后有人接手后续业务。
5.5 权限完整
- 每个角色能完成职责；
- 不应允许的访问被明确拒绝；
- 数据范围和流程任务区分；
- 管理权限不替代业务责任；
- 导出和附件已考虑。
5.6 使用体验完整
- 新建、修改、查看和处理场景都可理解；
- 表单顺序符合实际工作；
- 自动和手工信息容易区分；
- 错误提示可操作；
- 用户知道每一步之后发生什么。
5.7 管理闭环完整
- 责任人能看到待处理事项；
- 负责人能发现积压和异常；
- 指标口径明确；
- 记录可追踪；
- 上线后有人维护。
6. 一致性检查
跨材料核对：
- 词汇表中的状态与流程、视图是否同名同义；
- 数据字典中的字段是否支持规则表；
- 流程分支使用的金额是否与表单计算相同；
- 权限矩阵是否允许流程参与者打开记录；
- 视图是否遵守数据范围；
- 通知内容是否与实际状态一致；
- 打印和导出是否使用正确金额与日期；
- 测试场景是否覆盖所有必须需求。
许多严重问题不是某一部分单独错误，而是两部分之间不一致。
7. 可实现性检查
对关键设计逐项标记：
| 状态 | 含义 |
|---|---|
| 可直接实现 | 当前功能和条件清楚 |
| 需要准备 | 先配置组织、角色、服务或基础资料 |
| 需要验证 | 功能存在，但必须做一个小样确认行为 |
| 存在差距 | 当前不能按要求完整实现 |
| 暂不进入第一版 | 价值不足或依赖未满足 |
存在差距时提出业务选择：
- 调整需求；
- 采用可接受的人工步骤；
- 延后；
- 推动能力补齐。
任何替代都应说明影响并重新确认验收标准。
8. 风险检查
至少评估：
- 删除或修改数据结构的风险；
- 过度开放权限；
- 找不到处理人导致业务停滞；
- 自动动作重复执行；
- 指标口径不一致；
- 外部数据冲突；
- 历史记录和在途流程受新版本影响；
- 第一版范围过大；
- 没有真实用户参与验证。
对高风险项指定负责人、预防措施和验证方法。
9. 评审会议的推荐顺序
- 重述业务目标和第一版范围；
- 用正常场景走一遍；
- 用关键异常和边界再走；
- 检查角色责任和权限；
- 展示查询、统计和输出；
- 确认能力差距和替代方案；
- 逐项决定未决问题；
- 确认进入开发的条件。
不要逐字段朗读数据字典。只有在场景需要或有争议时深入字段。
10. 记录决定
每个关键决定记录：
| 编号 | 问题 | 决定 | 决定人 | 日期 | 影响 |
|---|---|---|---|---|---|
| D-01 | 高金额边界 | 大于 5000 元 | 行政负责人 | 7-27 | 流程、测试 |
| D-02 | 退回后路线 | 修改后从头审批 | 业务负责人 | 7-27 | 流程、状态 |
| D-03 | 历史数据 | 第一版不导入 | 业务负责人 | 7-27 | 上线范围 |
口头“大家都同意”很快会被不同记忆替代。
11. 进入开发的门槛
只有以下条件满足，才建议正式开发：
- [ ] 业务目标和范围已确认；
- [ ] 核心正常场景可以从头走到尾；
- [ ] 关键异常和边界已有处理方式；
- [ ] 业务对象、状态和规则稳定；
- [ ] 数据字典支持表单、流程和查询；
- [ ] 权限矩阵覆盖全部主要角色；
- [ ] 必须需求都有设计落点和验收方式；
- [ ] 能力差距和替代方案已确认；
- [ ] 关键未决项已经关闭，或有明确负责人和期限；
- [ ] 第一阶段开发范围足够小，可以尽快形成闭环。
12. 常见错误
- 评审变成界面颜色讨论；
- 只展示正常场景；
- 只有负责人参加，没有一线用户；
- 能力不足时默认用低质量替代；
- 未决问题没有决定人和截止时间；
- 评审通过但没有记录关键决定；
- 为了赶进度，在业务规则仍冲突时开工。
下一步
蓝图评审通过后进入开发。下一章学习如何从最小闭环开始增量开发，尽早获得真实反馈并控制返工。