我认为写好一个技术方案，对于开发同学来说至关重要，不仅可以帮助我们做好需求，更能帮助我们锻炼自己的文字功底。


在接手需求时，我们很难做到每一次都对需求的影响面都十分清楚，更多的都是要借助团队的力量，拉齐产品的需求以及需求的影响面之间的信息，即做到正真的理解没有问题，做法没有问题。让相关业务同事放心，产品大大放心，让领导放心，甚至是让自己放心。我认为技术方案评审除了完成对本次需求影响面盘点的评审，还可以同步系统功能变化（需求调整了功能），如果涉及多方人员之间的配合，那么更需要协调人员之间的工作排期，继而保证整体项目的稳步推进。


开发中常见案例就是，开发任务进行到一半，发现之前技术方案中的做法有问题，于是推翻重来，这是我们都不愿意看到的。当然根据我在实际工作中的观察，如果需求影响面很大，基本都无法难盘点到每一个影响点，那问题就变成了如何尽可能多的盘点。


本文亦在分享一个基础版的技术方案模板，让大家在编写技术方案时，能够在一个相对完整的方案流程中，根据自身团队及业务需求的特性，快速上手，提高编写技术方案效率，最终形成自己编写技术方案的方法论。

一、需求背景

背景描述、业务约束，来源于PRD，可直接贴prd文档

无需求评审，可自己自由发挥

二、术语定义

可选，对项目中出现的一些专业词汇进行解释，拉齐信息差。

术语	说明

三、总体方案

附上架构方案文档地址或PPT。架构方案要阐述清楚系统视角的完整业务流程，全链路上将有哪些域需要参与进来，它们的协作与分工关系是什么，各域的关键改造点。包括方案设计对各域带来的影响，让大家对此次改造的整体影响面有一个基本的概念。

3.1 历史状况

在《金字塔原理》一书中提到，在解决问题前我们一定要界定清楚问题，界定清楚问题必然就离不开说清楚已有的（现状）和想要的（目标）之间的差距，所以说清楚历史状态是很有必要的。

3.2 完整流程

讲清楚现状，我们可以简单说说我们的目标，根据目标和现状之间的差距，我们开始规划出我们的解决路径，完整流程可以理解为就是对解决路径的一次综述

3.3 涉及应用

1、应用1（主要调整）

改造点

添加xxx业务需求

2、应用2（提供时区接口）

改造点

提供RPC服务，查询数据

四、系统分析

如果是进行业务重构，本节可以调整为侧重对问题的说明，即前文提到的，现状的问题点有哪些，我们的目标是什么，解决路径又是什么

将整体方案拆解为用例，逐个进行详细分析，阐述形式可以自由发挥，建议UML图（时序图，活动图、xmind等），在方案评审会议上，由于时间有限，在其他同事不是特别了解功能细节时，朗读过多的文字反而容易让人抓不住重点，更多的都是一个点一个点，无法形成面的感觉，此时只能靠同事自己在脑中自己去画自己的结构图。当然足够详细的文字描述也同样重要，会议之后就只能靠文档了。我对自己的要求就是，每一次出现成体系的内容描述时，都反问自己一句，如果这里有张图会不会更好？

4.1 用例1 XX支付

对方案实现细节做详细分析，以下内容作为参考

1）模型设计

新增表模型

2）业务校验

相关业务参数约束拦截，如平衡校验、参数格式校验等；

3）系统交互

详述系统交互接口入参、返回参数、调用方式、超时时间、峰值tps等内容；

4）切流分析

系统切流目标、维度条件、依赖关系、切流顺序等内容。

5）兼容分析

• 同系统

• 新数据在老代码上运行

• 老数据在新代码运行

• 跨系统

• 新代码请求下游老代码机器

• 老代码请求下游新代码机器

4.2 用例2 XX退款

同上

五、风险评估

将有可能涉及到资损风险或稳定性风险的改动内容, 在下面逐条说明，并明确应对措施:

1. XXX
2. XXX

六、稳定上线

6.1 可监控

针对上述风险，是否可以有效监控、核对发现可能出现的资金安全、稳定性风险。

6.2 可灰度

是否可以进行灰度对比，在灰度期间及时发现问题，尽可能小得影响到线上流量。

6.3 可回滚

发现问题后，配置、代码是否可以及时回滚止血。

七、测试建议

站在开发视角，对测试同学提供建议，如哪些场景需要重点关注。

1. casexxx 验证；
2. casexxx 回归。

八、参与人员

开发:XX

测试:XX

需求评估人:XX

九、发布计划

xx.xx开始开发

xx.xx提测

xx.xx预发

xx.xx灰度

xx.xx上线