我认为写好一个技术方案，对于开发同学来说至关重要，不仅可以帮助我们做好需求，更能帮助我们锻炼自己的文字功底。
在接手需求时，我们很难做到每一次都对需求的影响面都十分清楚，更多的都是要借助团队的力量，拉齐产品的需求以及需求的影响面之间的信息，即做到正真的理解没有问题，做法没有问题。让相关业务同事放心，产品大大放心，让领导放心，甚至是让自己放心。我认为技术方案评审除了完成对本次需求影响面盘点的评审，还可以同步系统功能变化（需求调整了功能），如果涉及多方人员之间的配合，那么更需要协调人员之间的工作排期，继而保证整体项目的稳步推进。
开发中常见案例就是，开发任务进行到一半，发现之前技术方案中的做法有问题，于是推翻重来，这是我们都不愿意看到的。当然根据我在实际工作中的观察，如果需求影响面很大，基本都无法难盘点到每一个影响点，那问题就变成了如何尽可能多的盘点。
本文亦在分享一个基础版的技术方案模板，让大家在编写技术方案时，能够在一个相对完整的方案流程中，根据自身团队及业务需求的特性，快速上手，提高编写技术方案效率，最终形成自己编写技术方案的方法论。
技术方案模板
- 一、需求背景
- 二、术语定义
- 三、总体方案
- 3.1 历史状况
- 3.2 完整流程
- 3.3 涉及应用
- 四、系统分析
- 4.1 用例1 XX支付
- 1）模型设计
- 2）业务校验
- 3）系统交互
- 4）切流分析
- 5）兼容分析
- 4.2 用例2 XX退款
- 五、风险评估
- 六、稳定上线
- 6.1 可监控
- 6.2 可灰度
- 6.3 可回滚
- 七、测试建议
- 八、参与人员
- 九、发布计划
一、需求背景
背景描述、业务约束，来源于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退款
同上
五、风险评估
将有可能涉及到资损风险或稳定性风险的改动内容, 在下面逐条说明，并明确应对措施:
- XXX
- XXX
六、稳定上线
6.1 可监控
针对上述风险，是否可以有效监控、核对发现可能出现的资金安全、稳定性风险。
6.2 可灰度
是否可以进行灰度对比，在灰度期间及时发现问题，尽可能小得影响到线上流量。
6.3 可回滚
发现问题后，配置、代码是否可以及时回滚止血。
七、测试建议
站在开发视角，对测试同学提供建议，如哪些场景需要重点关注。
- casexxx 验证；
- casexxx 回归。
八、参与人员
开发:XX
测试:XX
需求评估人:XX
九、发布计划
xx.xx开始开发
xx.xx提测
xx.xx预发
xx.xx灰度
xx.xx上线
