技术方案编写规范标准 第1篇
解决什么问题，用什么方案，方案优势，方案的收益
问题从哪里来 ，为什么现在做 ，痛点是什么 ，业务或者技术术语有哪些，案例有什么 ，问题从哪里来
目标方法 SMART ：方案无遗漏，平衡阶段性投入
范围 ：涉及什么业务，方案边界
行业差距 ：内外对比，了解方案的行业位置
北极星指标：牵引方案，校准进度，体现收益
指标体系设计
常见指标：复杂度、召回率、准确率、渗透率
清晰的架构大图：标准的工具、标准名称
数据基建：线上观测、收益统计
技术选型：社区成熟度、团队熟悉度、新技术比例
概要设计与详细设计：合理的抽象层级，逐级推进
评估投入：与人、时间、资源相关
稳定性：风险评估、方案准入，观测、灰度、回滚
合理的任务拆解要有架构思维
任务拆解：设计与实施，保障有序协作
关键里程碑：对齐方法，设计、开发、提测、灰度、推全
协作范围：外部团队，不同职能，关键接口人
资源统计：投入有预期，事后能总结
方案才开始，取得收益才是目标
一切围绕目标，从目标出发，围绕目标推进，对齐目标总结，要保证文档系统的及时性、沟通纪要、进度总结
技术方案编写规范标准 第2篇
思路不清晰的技术方案有一个常见的问题：在交代完需求背景之后，就直接开始介绍每个子需求的具体实现。这种技术方案各个部分比较分散细碎，没有统一成整体，阅读起来并不好把握，这些设计背后的思路是什么，为什么要这样设计。所以需要高屋建瓴，先概要地介绍系统的整体构成，以及每个部分的职责，后面章节再细节介绍每个部分的具体实现。
概要设计主要包括总体设计和模块设计两个部分。
说明系统总体上的架构设计，画系统架构图是介绍清楚系统架构的有效手段，架构图常见的归类有：
注意画之前要想清楚这张图要表达什么内容，再针对性来画，不同的类型的图不要合在一起。例如想说明系统的部署结构，用部署图，说明业务的主要流程，用流程图等。
简要说明每个模块的职责，或者说每个模块在本次需求中需要作出的修改。
技术方案编写规范标准 第3篇
良好的测试方案能有效提高开发质量，技术方案中不仅需要考虑开发自测，为了进一步提高研发质量，还需要考虑如何提高测试同学的测试质量和效率。测试方案需要考虑的点包括：影响点，自测用例，测试注意点。
影响点可以用清单的形式列出本次开发影响了哪块功能，哪些接口，接口url，改动的内容是什么。这样测试同学在设计测试用例时可以做对照参考，减少功能遗漏测试的情况。
自测用例是介绍说明需求自测的用例设计，一般包括涉及场景，测试步骤，测试输入，期望输出等信息。
有些隐藏的异常情况处理，边界条件，特殊处理逻辑，如果没有特别说明，测试同学测试的时候很容易遗漏这块，而线上bug往往出现在这一块。
技术方案编写规范标准 第4篇
事先规划好上线部署的详细步骤，等到正式上线时就可以对着步骤来一步地执行和检查，减少上线事项遗漏或者处理出错的情况。
上线部署部分包括环境准备，系统准备，发布顺序，线上验证
系统依赖环境的准备包括MySQL、Redis、MQ、ES和Nginx等服务搭建和初始化，机器资源等。
系统准备常见主要如下：
如果不同的服务之间有依赖关系，在技术方案中应当标明。发布上线的服务依赖其他服务的情况下，需要先发布被依赖的服务。
线上验证的部分，需要说明服务发布上线之后，怎么验证服务是否正常，需要做哪些检查验证项。例如