一、背景
随着公司产品体系的复杂化和业务迭代速度的加快，确保技术架构的合理性、前瞻性与稳定性已成为支撑业务高质量发展的关键。在过去的项目实践中，我们观察到在需求转化为技术方案的过程中，存在一些普遍性问题，制约了研发效率与产品质量的进一步提升：
- 评审效率低下：产品需求文档（PRD）在未达到基本评审标准的情况下便进入架构评审会，导致会议大量时间被用于澄清基础需求、补充缺失信息，而非深入探讨技术架构。“评审会”变成了“需求讲解会”，资深技术资源被严重浪费。
- 职责边界模糊：产品、架构、开发团队对各自在评审前后的输入输出责任认识不清。容易出现产品认为“技术实现是开发的事”，开发认为“产品没想清楚就别来评审”的相互指责局面，协作链条存在断点。
- 架构决策失焦：评审会议缺乏明确的讨论边界，容易陷入两个极端：一是过度讨论业务规则的合理性，偏离技术主题；二是过早沉溺于代码实现细节，“只见树木，不见森林”，忽视了宏观的技术选型、系统拆分和数据流向等核心架构问题。
- 风险后置与项目失控：架构评审后即进入工时评估与项目排期，但需求在工时评估后仍然快速变化，技术路线与架构评审缺乏对改动部分评估，诸多技术风险或是项目风险在开发中甚至上线前才暴露，导致项目延期、紧急加班、临时重构，甚至引发线上故障，成本和风险极高。
二、目标与适用范围
- 目的
为规范需求在进入正式架构评审流程前的质量标准，确保所有影响系统整体架构的需求在立项/需求交底之前，经过充分的架构设计、风险评估和可实施性验证，避免设计返工、上线事故或跨团队协调失败。- 提升评审效率：避免因需求文档不成熟而导致的评审会议无效、反复。
- 明确责任边界：清晰定义产品经理、架构师、开发团队在评审前后的输入和输出责任。
- 保证技术可行性：确保产品需求在技术层面是可实现、可扩展、可维护的。
- 管控项目风险：提前识别和规避技术、资源、进度等方面的重大风险。
- 适用范围
本标准适用于公司所有软件产品/项目在需求交底会之前，对产品经理输出的产品需求文档 进行的架构评审 活动。
三、架构评审准入标准
- 准入标准是产品需求文档有资格提交给架构组进行正式评审的“门票”。若未满足，架构组有权拒绝或延期评审。
- 文档完整性
- 1.1 核心文档齐备：
- PRD主体：要求详见文档PRD要求
- 业务流程图：清晰描述核心业务场景下的用户操作路径和系统交互。
- 功能结构图/信息架构图：展示产品功能模块或信息页面的层级关系。
- 状态流图：超过3个以上状态流转，需要填写状态流图
- 关键功能的交互原型：高保真或低保真原型，需清晰展示页面布局、关键交互逻辑和状态变化（如成功、失败、加载中）。
- 1.2 需求清晰无歧义：
- 所有功能描述必须使用“用户+场景+目标”的格式，避免使用“可能”、“大概”、“等”模糊词汇。
- 尽可能少使用专业术语，如需使用，需要对专业术语、业务概念有明确的词汇表解释。
- 技术预沟通与准备
- 2.1 产品与核心开发/技术负责人已完成初步沟通：
- 产品经理已与架构师就需求的技术可行性和大致实现思路进行过非正式讨论。
- 已识别出初步的技术难点或不确定点，逐步升级并解决。
- 2.2 依赖关系初步识别：
- 明确列出本需求所依赖的内部系统/模块（如：依赖用户中心的权限需求）。
- 明确列出本需求所依赖的外部系统/第三方服务（如：依赖微信支付、e签宝）。
- 初步评估依赖项是否已就绪，或需要同步协调。
- 非功能性需求定义
- 3.1 性能指标：
- 通用性能/未特殊说明的需求按照通用性能指标实现。
- 定义特殊/需要特别处理的关键操作（如页面加载、数据提交、列表查询）的响应时间要求（如：95%的请求在2秒内完成）。
- 定义特殊/需要特别处理的用户量及QPS/TPS要求。
- 3.2 数据指标：
- 预估核心数据表的数据量级（如：日增数据量、总数据量）。
- 定义数据的存储周期和归档策略（如：交易记录保留2年）。
- 3.3 安全性要求：
- 明确涉及敏感信息（用户隐私、支付、权限）的功能，并提出基本的安全约束（如：密码加密存储、防SQL注入、接口防刷）。
- 3.4 可用性与可扩展性：
- 说明未来业务可能的扩展方向，以便架构设计预留扩展点（如：当前仅支持微信登录，未来需支持手机号登录）。
- 评审材料提交
- 4.1 提前分发材料：
- 产品经理需在评审会议至少前2个工作日，将完整的PRD及相关材料发送给所有参会人员（包括架构师、主程、测试负责人、运维负责人等）。
- 4.2 提前定会议：
- 产品经理需在评审会议至少前1个工作日，定会议时间会议室并邀约所有参会人员。
- 资源与人员承诺
- 5.1 指定评审关键参与人（至少：PM、产品负责人、架构师、开发负责人、测试负责人、安全负责人），并确认他们有时间参加评审会议或审阅材料。
- 5.2 若涉及第三方或上下游系统，需要提前进行沟通。
- 文档完整性
四、架构评审过程
- 评审会议组织
- 由产品经理主持评审会议。
- 由研发侧负责人决定评审结果。
- 评审颗粒度规范
- 核心要点
暂时无法在飞书文档外展示此内容 - 不应在架构评审中讨论的内容（排除清单）
暂时无法在飞书文档外展示此内容
- 核心要点
五、架构评审准出标准
- 总体要求
架构评审通过后，PRD应满足以下总体目标：- 业务逻辑与系统能力匹配；
- 无重大技术不可行点；
- 系统边界与依赖清晰；
- 非功能性诉求已被明确识别；
- 评审结论与问题闭环记录完整。
- 准出标准
暂时无法在飞书文档外展示此内容 - 评审结论分级
暂时无法在飞书文档外展示此内容
六、架构评审通过后续流程
-
产品侧
- 必需项：
- 通过评审当天需将prd上传至ones，并上传离线文档至附件。
- 上传完成后通知研发进行工时评审。
- 发送邮件同步。
- 可选项：
- 如有遗留问题或会上未达成一致，视问题多少与严重性，按需邮件同步或会议重新澄清。
- 仅允许对prd进行描述性细化，原则上不允许出现对功能/流程上进行改动。
- 如确实需对功能进行改动，功能类改动需要同步至项目经理，架构师，开发组长，测试组长。且在排期允许情况下，一致同意后进行修改。
- 如确实需对流程进行改动，需要重新进行架构评审。
- 必需项：
- 研发侧
- 必需项：
- prd上传至ones后，研发组长和测试组长进行工时评估，填写预计工时，反馈至项目经理。
- 项目经理进行工时排期。
- 必需项：
附件：快速检查清单
【准入检查清单 - 会前5分钟核对-产品经理自检】
目的：确认会议能开，避免浪费时间。
暂时无法在飞书文档外展示此内容
结论：若以上任何一项为“否”，会议应延期。
【准出检查清单 - 会后5分钟核对-技术负责人检查】
目的：确认会议有效，可以进入下一阶段。
暂时无法在飞书文档外展示此内容
结论：若以上五项全部为“是”，评审通过。若第1项为否，则不通过。若1为是，但2/3/4/5有缺失，则有条件通过或不通过，需跟踪待办。
发表回复