提升技术方案编写效率：关键环节与模板分享-CSDN博客

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

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

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

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

一、需求背景

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

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

二、术语定义

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

术语	说明

三、总体方案

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

3.1 历史状况

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

3.2 完整流程

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

3.3 涉及应用

1、应用1（主要调整）

改造点

添加xxx业务需求

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

改造点

提供RPC服务，查询数据

四、系统分析

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

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