如何做好团队的技术方案评审？

关注私信：资料 
免费赠送

“ 团队技术方案评审的效果总是差强人意，低质量的方案评审导致人力成本的浪费以及后期落地成本的增加，本篇文章探讨一下 “如何做好团队技术方案评审？” ”

01

—

引言

技术方案评审是研发生命周期中最为常见的活动，技术方案评审会是最常见的活动形式。一般由研发人员基于产品需求完成技术方案设计之后，在干系人间发起技术方案的评审。作为架构师几乎每周都会参加1-2次团队的技术方案评审会，每个业务线团队的评审会质量层次不齐。在如此多的干系人参会情况下，如果评审会不能够有效的达成一致性认知，那么其造成的人员成本浪费可想而知。

技术方案评审会大家多多少少都会参加过，有时候是评审的主导发起者，有时候是参与者，不论以什么样的角色或身份出席，我相信大家都会有一些共鸣：有些评审会信息传递清晰、高效，过程非常愉悦，大家也能参入其中并理解和汲取所需。有些评审会冗长、混乱，那些应该覆盖的信息大量缺失，评审会完成依然“不知其所云”。

02

—

方案评审的本质

技术方案的本质是从技术视角出发提供的问题域的解决方案，技术方案评审的本质是一个协作决策过程，通过干系人共同参与，从多维度评估待评审的技术方案是否对问题域提供了合理、可行且最优的解决方案

通过干系人共同参与，基于待评审的技术方案，干系人：

评估技术方案的正确性、完整性、合理性

技术方案本身必须是正确的、合理的，且能够覆盖当前需求。“完整”要求方案不能对要解决的问题有所遗漏，不完整意味着不能满足“需求”。“正确”表明技术方案能够对问题域提供解决方案，“合理”则要求不仅仅关乎“正确”和“完整”，其要求在特定的上下文中多个因素间的平衡，比如，时间成本、资源投入成本、技术实现成本等多因素平衡。

干系人共识

评审不是为了给干系人集中展示“冷冰冰的文档”，而是文档所承载的设计信息，且保证这些信息在干系人间传递并达成共识。

识别潜在风险项，并有对应的应对策略

评审结果要体现对潜在风险的分析以及应对策略的制定。因为，设计本质上是一种基于特定上下文的权衡和折衷。每个架构决策的选择都可能伴有潜在的技术债或风险，因此，评审的重要目标之一是识别这些风险并制定对策。

02

—

技术方案评审的常见问题

技术方案评审过程中常见的问题如下：

缺少角色认知，干系人参与度不够，不能有效汲取必要的信息并提供角色视角的建议

评审过程中，部分干系人对自身角色认知不清晰，未能充分理解自己在评审中的职责和价值，导致参与度不足。例如，业务方可能只关注功能需求，而忽视技术可行性；技术团队可能过于关注技术细节，而忽略业务目标和用户需求。极容易容易导致评审流于表面，无法深入挖掘问题。“技术不了解业务，业务不了解技术”的现象时常发生。

部分干系人未能充分理解技术方案的背景、目标和约束条件，导致提供的建议缺乏针对性和实用性。例如，开发人员可能未充分了解业务需求，提出的技术方案与业务目标脱节；管理层可能未掌握技术细节，无法从战略层面提出优化建议。信息不对称或传递不完整，导致评审结果偏离实际需求。

技术方案的文档化表述欠佳

技术方案文档本身存在问题，不能提供有效的、相对全面的解决思路，参考《聊聊技术方案设计的普遍问题与参考实践》

主讲人的信息传递效果差

技术人员一般不太擅长演讲，在评审方案时可能会缺乏一些演讲技巧，导致设计信息不能高效的传递到干系人，对技术方案评审的效率大打折扣。

缺少风险项识别及应对

方案本身没有囊括对潜在风险的识别，评审过程也只关注方案域本身，也缺失对潜在风险的讨论

03

—

各司其职，深度参与

不同角色的干系人应该明确自己的职责，共同推进技术方案评审会的预期效果达成。典型的互联网组织架构中，业务线团队会涉及业务人员、产品经理、前端研发、后端研发、测试人员、架构师以及TL。

架构师/TL

•整体技术方案的架构合理性和一致性

•横向架构属性满足度：可扩展性、可维护性、性能、安全、合规性等

•对现有系统架构的影响评估

•工期与技术成本的合理性

•技术栈选型与团队能力的匹配度

产品品经理

* 功能性需求的实现是否覆盖

* 用户敏感的非功能性需求的实现是否覆盖

* 业务概念的一致性

* 产品视角的安全：敏感信息明文/密文存储与反显；敏感数据泄漏；资损等等

* 系统状态机是否满足业务状态机要求

测试工程师

* 方案的可测试性

* 是否需要压测

* 变更影响需要回归的范围

方案设计/主讲人

* 清晰、明确的撰写技术方案文档

* 基于评审的目的，有的放矢的、有侧重点的讲解方案

* 对参会干系人的问题答疑，以及现场的开放探讨

03

—

一些实践

意识先行

难，但必要！提升大家对技术方案评审的认识，不同角色的干系人明确各自在评审过程中的诉求和职责，并能自驱的、积极主动的参与其中。培养和提升团队成员在某个事物的意识是一件困难且难以度量的事情，特别是垮团队场景中更甚。不论是统一的宣贯，还是通过不断实践-复盘的方式，都不能一蹴而就。但这中意识的建立是非常有价值的工作，需要团队持续的实践和推进。

实践传播

建议一：统一技术方案模板

团队可以考虑采用统一的、标准或规范化的技术方案设计模板，允许设计人员按照具体情况进行裁剪，在最大程度上保留技术方案设计以及文档化表述的好的实践，有助于提高评审效率；

建议二：主讲过程要有必要的背景或上下文同步

主讲人有必要在评审过程中把相关的业务背景、产品背景、技术背景、当前需求背景等信息进行同步，当然，没有必要事无巨细的讲解，关注核心部分，关注与本次技术方案内容有密切关系的部分，目的是确保参会干系人对背景有所认识，以便能够在评审过程中代入。

流程固化

建议一：预评审机制

在扩大干系人范围发起技术方案评审之前，好的做法是在技术侧内部预先进行一轮内部评审，要求参会人员包括相关的开发实现成员、架构师或TL，这种方式能够在很大程度上确保方案的质量，极大避免正式评审的现场风暴和返工。

建议二：方案提前阅读

发起评审会至少半天提供定版技术方案文档（可能不是最终版，但至少是内部评审通过。互联网行业一般迭代节奏较快，方案评设计评审的周期相对于传统行业会更短一些），以确保干系人可以提前阅读。当然，让产品/业务等非直接干系人提前阅读是一个挑战，实践过程中不太可控。基于此，团队可以强制在评审会的前10分钟或15分钟时间设置为统一阅读期，通过流程方式进行强控也能收获一些效果。

建议三：待办项要有跟进机制

评审结果可能不是0或1，作为方案评审结果的一部分产出待办项。建议通过团队规范或机制的方式确保有负责人跟进，并在启动开发之前进行明确确认答复，并同步至干系人。

04

—

结语

虽然无法通过完全定量的指标评估技术方案评审效果，但通过持续的实践、流程、机制的保障提升评审质量依然有价值。