聊聊技术方案设计的普遍问题与参考实践

关注公众号！留言：参考模板 ，
送《技术方案设计参考模板》

1 动机

其实很早写一篇关于技术方案设计的文章，种种原因并未能成行。10年的研发经历，经历了不同的公司、形形色色的项目和产品形态、大大小小的研发团队，写这篇文章的目的其实并不是指导研发同学如何做具体设计，由于不同产品/系统面临的问题域各不相同，既有产品形态的差异，亦有团队水平、设计偏好、基础设施环境的不同，因此，没有办法提供详细的指南。今天这篇文章想聊聊对技术方案，特别是技术方案文档存在的普遍问题，并从宏观的视角给出一些自己的思考。

2 “技术方案”普遍存在的问题

问题一：方案覆盖范围难对齐

技术方案文档所涵盖的内容范围参差不齐，有的技术方案过于简化，涵盖的内容较少，特别是在特定上下文下丢失了部分关键信息。

问题二：方案设计的粒度难平衡

有些技术方案设计的过于宏观：只提供方向性的、宏观的设计要素，从而缺乏必要的用于指导落地的技术细节。由此导致的问题是一些研发人员无法从方案中获取明确的、有效的信息，在实际开发过程中不得不“边开发边设计”。这不仅仅增加了一线开发人员的负担、打击情绪，更为重要的是后续的细节可能会导致整个设计的返工。

有些技术方案设计的过于详细，力求面面俱到、事无巨细：冗长的技术方案文档提供了支持实现的方方面面，但巨大的信息量如何在有限的评审时间内在干系人间迅速、有效的同步是一个挑战。多数情况下，参会的人无法全面的、有重点的获取设计信息

问题三：缺失必要的上下文

这是我个人所见的技术方案中最为普遍的问题之一，方案直入主题，通篇都是技术实现的“干货”，缺少对当前方案所对应的业务上下文，比如业务背景、业务价值等必要信息代入。参与评审的干系人不太可能对相关背景了如指掌，因此，这种上下文的缺失会降低方案评审的效果。

同样的，多数情况下我们建设的不是从0到1的系统，而是在已有系统上的迭代演进。技术方案中如果缺失系统整体的技术上下文信息，比如整体技术架构、技术栈等，导致参与评审干系人如同“管中窥豹”、缺失了对当前方案在整体系统中的关系的视角，这也会增加对方案的理解难度，降低信息共识的效率，增加后续实现的成本。

问题四：方案文档可视化表述效果差

几乎每个技术方案文档中都会有“图”，通过图形化表述设计信息是一个好的实践，相比于冗长的文章描述，图能够更有效的传递设计意图。但普遍存在的问题是用于表述技术方案设计意图的图是“五花八门”的。不同团队有不同的风格，同一个团队不同设计人员有不同画图风格、画图工具。这些可视化的差异同样对信息传递形成阻碍。

3 重新审视技术方案的本质

从上述的普遍问题看，最根本的问题是“信息传递的损失”：作为连接业务/产品-技术域的纽带，技术方案信息的传递有效性直接关系到团队研发的成本和效率。能够清晰表述设计意图、指导团队落地、易于在干系人间达成共识的技术方案对研发团队的成本降低和效率提升有正向作用。相反，设计信息传递损失越大，则有负向作用。

作为协作型团队，信息传递的效率和有效性是影响团队研发效率和成本的重要因素之一。典型的团队会包含多种岗位或角色的干系人，研发、测试、产品、业务等等，不同角色有自己特定的认知特点，如何能保证信息在不同的“认知墙”内有效传递是普遍面临的问题。当然，这个问题不仅仅体现的技术方案环节，其穿插于整体业务生命周期中。

从更通用的问题域-解决方案域模型看，技术方案本身是解决方案的子集，其本质是也是对某个问题域在某个上下文下求解。以典型研发过程为例，市场驱动着业务模式创新。业务需求则基于既定的商业目标进行拆解，产品需求则基于业务诉求提供产品层面的解决方案，同理，技术方案是对产品能力诉求在技术域的求解。

对于“问题域-方案域”是一个通用抽象，软件工程领域同样适用。不论各异的软件研发过程包含的研发阶段、角色、交付工件差异化有多大，本质上可以统一为这一模型（“问题域-方案域”）在不同层次上的投影。回顾到技术方案本身，其目的是对产品能力诉求（功能及非功能）提供技术域的解决方案

4 技术方案设计目标、原则、实践

4.1 目标与原则

目标：技术方案设计的目标是提供对问题域的可行的技术解决方案，并确保在干系人间达成共识，能够指导落地实施。

原则一：追求简单

原则二：最大化干系人间信息同步效率

原则三：范围适中，不应追求过度覆盖，或覆盖不足

原则四：粒度适中，不应过度设计，或过少设计

4.2 建议范围

技术方案所包含的内容范围没有统一标准，基于实际的工程经验建议基于以下维度进行裁剪。

业务上下文：业务背景与业务价值

同步业务相关信息，区分事情的重要和紧急程度；包括但不限于业务的整体背景、ROI、长期和短期目标、产品方案等

技术上下文

第一个维度，提供当前系统现状的技术背景说明，包括但不限于整体技术架构、系统部署架构

第二个维度，架构师基于对业务、产品、技术现状及诉求的理解，分析当前重点衍生的技术需求，作为产品需求在技术视角的补充，包括但不限于诸如技术安全、业务安全、性能要求、规模要求，目的是尽量避免技术需求的遗漏，以及为关键的部分预留可迭代的空间；

技术安全：功能安全、数据安全、存储加密、传输加密、签名验证、防伪造和篡改的问题，要防范安全漏洞。

业务安全：多个业务共享数据时需要重点考虑，事务安全、保证一致性、要预防黑产攻击。

概要设计

对系统的宏观问题提供解决方案，典型的元素包括：

1.整体方案选型：基础设施选型、技术栈选型、子系统拆分及交互的高层选型等等

2.应用架构及其变更

3.技术架构：系统稳定性、性能、安全性的方案选型

详细设计

这部分信息是领域实现的设计，关注领域内的元素和他们之间的关系。一般是根据领域进行分工，各领域可以独立完成设计；目的是把控质量、指导开发，降低后期的风险；典型的包含以下元素：

1.领域模型

2.交互流程

3.领域实体状态机

4.数据模型

5.关键协议

6.接口设计

7.监控/验证及灰度

影响分析

描述当前设计方案对系统、业务、团队所带来的影响

风险评估

目的是为了消除问题，避免小问题可能变成大问题，因为在实际情况下，很多出现的问题都是曾经考虑过但是又被忽略的问题；

决策过程

技术方案的设计过程是进行权衡分析的过程，方案中应该对过程所做决策进行留存记录。参考之前写的两篇文章：

轻量级的架构决策文档化机制

再聊对轻量级ADR的一些思考

4.3 可视化实践

参考之前写的公众号文章：

架构可视化及C4模型：架构设计不只是UML

系统架构设计-简单却功能强大的系统语境图

6 结语

技术方案的设计没有完全统一的标准，也不应该有强制标准。团队内可以根据自身情况制定可裁剪的技术方案设计模板，作为团队方案设计的参考。“好”的技术方案可能不是面面俱到、事无巨细的表述，应该结合迭代需求/产品建设的上下文灵活的决定技术方案要体现的内容、详细程度等。“好”的技术方案应该是有清晰的背景说明、关键的技术实现方案表述、能够在干系人间达成一致，并能指导团队实施落地。