我的生态
🧭
Java 面试指南覆盖面试高频考点，助你从容应对技术面试

    决策评审流程

    好的技术决策来自好的评审过程。但很多团队的评审流于形式：评审会上大家客客气气，提案人说什么就是什么，会后没有人记得评审了什么结论。

    一个有效的评审流程，需要解决几个核心问题：什么规模的决策需要评审？谁来参与评审？评审过程中如何避免「一言堂」？评审结果如何记录？

    评审时机

    不是所有决策都需要正式评审。引入评审流程本身也有成本——组织会议、准备材料、等待评审结果，都会拖慢决策速度。

    决策规模分为三个层级：

    层级决策类型评审要求示例
    L1局部决策不需要正式评审，团队内讨论即可选择哪个缓存库、接口命名规范
    L2模块级决策需要技术负责人评审，邮件或文档评审服务拆分方案、数据库选型、API 设计规范
    L3系统级决策需要正式评审会，多方参与架构选型、技术栈迁移、引入新基础设施

    判断一个决策属于哪个层级，有两个标准：

    1. 影响范围：决策的影响范围有多大？是否跨多个团队？
    2. 回退成本：决策实施后，如果发现有问题，回退的成本有多高？

    如果影响范围跨团队，且回退成本高，就是 L3 级别决策，需要正式评审。

    以下是 L3 级别决策的判断标准：

    • 影响多个服务或多个团队的架构设计
    • 引入新的基础设施或外部依赖
    • 需要跨团队的标准和规范
    • 决策后难以回退，或回退成本极高

    如果团队规模小于 5 人，可以适当放宽评审标准，小团队的决策效率更重要。

    评审参与方

    评审的参与方不是越多越好。参与方太少，可能遗漏重要视角；参与方太多，效率低下，讨论难以收敛。

    L3 级别决策的评审，建议邀请以下角色：

    技术负责人

    技术负责人是决策的最终决策者。在评审过程中，技术负责人不一定是提出方案的人，但必须对决策负责。如果评审意见分歧较大，技术负责人需要拍板。

    相关模块负责人

    如果决策涉及其他团队的模块，需要邀请该模块的负责人参与评审。他们的视角是「这个决策对我的模块有什么影响」。

    测试负责人

    测试负责人关注决策对测试工作的影响。例如，新架构是否增加了测试复杂度？是否需要新的测试工具或测试方法？

    业务代表

    对于影响业务功能的决策，建议邀请业务代表参与。他们的视角是「这个决策对业务有什么影响，优先级是否合理」。

    可选：运维负责人

    如果决策涉及运维相关的内容，例如引入新的基础设施、修改部署架构，建议邀请运维负责人参与。

    评审流程

    L3 级别决策的评审分为四个阶段：提案、预审、正式评审、决策记录。

    第一阶段：提案

    提案人负责撰写 RFC（Request for Comments，请求评论文档）。RFC 是评审的输入材料，需要包含：

    • 背景：问题的场景和严重性
    • 目标：希望通过这个决策解决什么问题
    • 方案：具体的解决方案，包括可选方案
    • 权衡：每个方案的优缺点对比
    • 建议：提案人的推荐方案和理由

    RFC 应该提前至少 3 天发给评审参与方，让他们有时间阅读和准备意见。RFC 通过邮件、技术方案讨论群或内部 Wiki 发送。

    第二阶段：预审

    预审是非正式的讨论，目的是让评审参与方提前了解RFC的内容，提出初步意见，避免正式评审时出现「第一次看到」的尴尬。

    预审可以在线上完成：

    • 评审参与方在 RFC 文档下评论，提出问题和建议
    • 提案人根据反馈更新 RFC，补充遗漏的信息
    • 如果有重大分歧，预审阶段可以提前讨论清楚

    预审时间建议 2-3 天。如果预审阶段发现 RFC 需要重大修改，可能需要重新进入预审阶段。

    第三阶段：正式评审

    正式评审在会议中完成。会议时间建议控制在 1 小时内，超时说明准备不足或分歧过大。

    评审会议流程：

    1. 开场（5 分钟）：主持人介绍 RFC 背景和评审目的
    2. 提案人陈述（10-15 分钟）：提案人简要介绍 RFC 内容，重点说明争议点和权衡点
    3. 提问和讨论（20-30 分钟）：评审参与方提问和讨论，提案人回应
    4. 总结（5 分钟）：主持人总结讨论结果，形成明确的评审结论

    评审结论有三种：

    • 通过：方案可以直接实施
    • 有条件通过：方案可以实施，但需要满足某些条件
    • 不通过：方案需要重新设计，下次评审

    评审结论需要明确记录，不能模糊。例如，「方案基本可行，但建议再评估一下成本」不是明确的结论；「方案通过，3个月后复盘」才是明确的结论。

    第四阶段：决策记录

    评审通过后，提案人负责将 RFC 转化为 ADR，并更新 ADR 状态为 Accepted。

    ADR 的编号应该与 RFC 对应。例如 RFC-001 对应 ADR-0001。

    如果评审未通过，需要更新 RFC 状态为 Rejected，并说明原因。后续可以重新提交 RFC。

    评审会议的技巧

    评审会议最容易变成「一言堂」——技术负责人或提案人强势，其他人不说话。要避免这种情况，需要一些技巧。

    1. 会前收集意见

    在会议开始前，通过邮件或文档收集评审参与方的意见，让他们提前想好要说什么。

    可以在 RFC 文档中增加「评审检查清单」：

    ## 评审检查清单

请评审参与方在会议前回答以下问题：

1. 这个方案解决了什么问题？这个问题有多严重？
2. 这个方案的代价是什么？我们愿意承担吗？
3. 是否有我了解但 RFC 中未提及的风险？
4. 如果我来实施这个方案，会遇到什么困难？

    2. 主持人控制节奏

    主持人（通常是技术负责人或指定的协调人）负责控制会议节奏：

    • 确保每个人都有发言机会
    • 控制提案人的陈述时间，避免过度展开
    • 引导讨论聚焦，避免偏离主题
    • 总结分歧点，推进讨论收敛

    3. 明确分歧和共识

    评审过程中，主持人要明确区分「共识」和「分歧」：

    • 「这个方案解决了性能问题」，这是共识，不需要再讨论
    • 「运维复杂度是否可以接受」，这是分歧，需要讨论

    对于分歧，可以采取以下策略：

    • 时间限制：给分歧讨论设置时间限制，到点投票
    • 分层处理：把大分歧拆分为小问题，逐个解决
    • 搁置：如果短期内无法达成共识，可以搁置，后续再讨论

    4. 记录分歧

    评审会议纪要中，要明确记录分歧点和各方的观点。即使最终达成共识，也要记录「最初的分歧是什么，最终为什么达成共识」。

    这样做的好处是：

    • 后续如果决策出现问题，可以追溯「当初为什么这样决定」
    • 团队成员可以看到不同的观点，学习权衡过程
    ## 评审纪要

### 时间
2024-03-15 14:00-15:00

### 参与方
- 张三（技术负责人）
- 李四（订单服务负责人）
- 王五（测试负责人）

### 评审结论
通过，有条件

### 分歧与讨论

**分歧 1：运维复杂度是否可接受**

- 张三观点：RabbitMQ 单机部署足够，不需要额外的运维投入
- 李四观点：即使单机部署，也需要建立监控和告警体系，需要投入 1 周时间
- 最终结论：实施计划中增加 1 周时间用于运维体系建设，3 个月后复盘

**分歧 2：是否需要消息追踪**

- 张三观点：当前业务场景不需要消息追踪，先不实现
- 王五观点：没有追踪能力，出问题很难排查，建议先实现基础追踪
- 最终结论：采用轻量级方案，使用消息头携带追踪 ID，暂不引入完整的消息追踪系统

    评审纪要模板

    评审纪要应该包含以下内容：

    ## 评审纪要模板

### 基本信息
- **RFC 编号**：RFC-XXX
- **评审日期**：YYYY-MM-DD HH:MM
- **评审时长**：XX 分钟
- **主持人**：[姓名]
- **评审参与方**：[姓名列表]

### 评审结论
[通过 | 有条件通过 | 不通过]

如果是有条件通过，列出通过的条件；如果不通过，说明原因。

### 讨论摘要

**问题 1：[问题描述]**
- [观点 A]
- [观点 B]
- **结论**：[结论]

**问题 2：[问题描述]**
- [观点 A]
- [观点 B]
- **结论**：[结论]

### 后续行动

| 行动 | 负责人 | 完成时间 |
| --- | --- | --- |
| 更新 RFC 文档 | 提案人 | YYYY-MM-DD |
| 转化为 ADR | 提案人 | YYYY-MM-DD |
| 实施 ABC | [负责人] | YYYY-MM-DD |

    ADR 的有效期

    ADR 不是写完就永远有效的。当上下文发生变化时，ADR 需要重新评审。

    以下情况需要重新评审 ADR：

    触发条件评审内容
    业务场景变化原来的决策背景是否还适用？
    技术环境变化依赖的技术版本是否已更新？替代技术是否更成熟？
    性能指标变化当初的性能预期是否与实际相符？
    团队规模变化当初的复杂度评估是否还适用？
    ADR 年龄超过 2 年即使没有明显变化，也应该复盘是否仍然适用

    ADR 的复盘不需要完整的评审流程，可以更轻量。复盘可以由技术负责人发起，通过文档讨论或简短会议完成。

    复盘结论有三种：

    • 继续有效：ADR 仍然适用，不需要修改
    • 需要更新：ADR 需要更新部分内容，记录新的上下文
    • 废弃/替代：ADR 已不适用，标记为 Deprecated 或 Superseded

    建议每半年对所有 ADR 进行一次批量复盘，确保 ADR 库的质量。

    常见问题

    Q：评审会上达不成共识怎么办？

    A：如果评审会上分歧过大，无法在会议时间内达成共识，可以采取以下策略：

    1. 分段决策：把大决策拆分为多个小决策，先对分歧较小的部分达成共识
    2. 搁置争议：把争议点暂时搁置，先在其他问题上推进，争议点后续再讨论
    3. 委托决策：如果争议是技术细节层面的，可以委托更专业的团队或个人决定
    4. 时间限制投票：给讨论设置时间限制，时间到了进行投票，少数服从多数

    Q：提案人和评审人是上下级关系，如何避免「一言堂」？

    A：上下级关系确实会影响评审质量。可以尝试：

    1. 会前收集匿名意见，减少当面表达的压力
    2. 邀请更多独立的评审参与方，分散权力
    3. 主持人明确要求「反对意见」，给反对者更多表达空间

    Q：如果提案人不同意评审结论怎么办？

    A：如果提案人强烈反对评审结论，可以：

    1. 重新组织评审，扩大参与方范围
    2. 技术负责人行使决策权，结论强制执行
    3. 提案人可以选择保留个人意见，但决策以评审结论为准

    ADR 的价值不是「每个人都同意」，而是「决策过程透明、结论明确」。不同意见可以记录在 ADR 中，不影响决策的执行。

    总结

    决策评审流程的目标是��重要决策经过充分讨论，让不同视角得到表达，让决策结果有据可查。

    评审流程的核心原则：

    • 适度评审：不是什么决策都需要评审，L1 决策应该快速通过
    • 充分准备：RFC 要提前发给评审参与方，让他们有时间准备
    • 明确结论：评审结论必须明确，不能模糊
    • 记录分歧：分歧是学习的素材，要如实记录

    好的评审流程不是增加负担，而是提高决策质量。一次糟糕的评审可能导致后续几个月都在为错误决策买单。

    下一节我们将介绍经典架构决策案例，从真实案例中学习决策逻辑。