做開發，寫技術方案肯定不會少，但是通常一個公司一份模板，有點頭疼，而且，部門模板對於一些必要點的梳理也並非十分清晰，因此寫一份技術方案模板，用以方案前期評審時討論及擴展，可以做參考哈，但是具體的還是以自身實際需求為准。
XXX技術方案
時間：xxxx-xx-xx 編寫人：fn-f
- 需求背景
PRD： 產品需求鏈接
簡述PRD產生的背景，1. 產品業務需求、2. 技術優化擴展、3. 痛點，缺陷，不足等問題點
- 需求目標
分產品線、業務線、擴展性等方面，分析本次需求發布之后的涉及影響點
- 需求F&Q
需求中疑問點記錄及對原有邏輯的沖突問題、時間安排問題等等
- 需求細分
圖示本需求涉及的功能點，將其拆解細化至團隊或個人
- 技術方案
1. 方案一(主)
方案撰寫：思路、流程圖(時序圖，標明涉及系統以及系統調用鏈、上下游依賴接口等梳理)、模型設計(表之間關聯圖)、架構設計(需求涉及的整個系統架構影響點)、涉及技術棧(技術關鍵點check)、接口冪等並發等處理、接口涉及大數據量預估處理、兼容處理(現有功能兼容及影響業務范圍)、優缺點對比、接口文檔(http、rpc) 等等... ...
2. 方案二(備) (小的改動點可省略備份方案)
參考方案一，最后特別指出兩者之間的優缺點、對比、擴展、兼容等方面
- 關鍵測試點
針對需求，產品、測試、開發共同關注的測試點，包含以往邏輯交互的兼容、本期新增功能的測試關鍵點
- 人員估期
需求的產品、PM、前端、客戶端、服務端、測試等相關人員
可以甘特圖標識人員開發及介入時間安排，標明 deadLine
- 發布計划
整理正式發布的checkList，多系統間發布順序、配置變更、數據庫變更、數據初始化、技術點增加、發布時間點等等... ...
注：能使用圖示的盡量以圖展現，能更加清楚明確，而且邏輯性對於涉及開發的人員更加清晰，改定點也可以cover住，可以實時針對其進行討論
-------------------------------------------- 迷人的分割線 ----------------------------------------
商品審核及交易賬務對接技術方案
時間：xxxx-xx-xx 編寫人：fn-f
- 需求背景
PRD： 產品需求鏈接
簡述PRD產生的背景，1. 產品業務需求、2. 技術優化擴展、3. 痛點，缺陷，不足等問題點
- 需求目標
分產品線、業務線、擴展性等方面，分析本次需求發布之后的涉及影響點
商品：1. 完成商品審核對接流程【業務】
2. 商品對外提供類抽離【技術】
財務：1. XXXXXXXXXXXXXXX【業務】
- 需求F&Q
需求中疑問點記錄及對原有邏輯的沖突問題、時間安排問題等等
1. 本次涉及交易人員需求沖突，需產品與PM確認該功能點是否本期處理？
-- 產品：與下期迭代一同上線
2. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX？
- 需求細分
圖示本需求涉及的功能點，將其拆解細化至團隊或個人【下圖是xmind畫的】
- 技術方案
1. 方案一(主)
方案撰寫：思路、流程圖(時序圖，標明涉及系統以及系統調用鏈、上下游依賴接口等梳理)、模型設計(表之間關聯圖)、架構設計(需求涉及的整個系統架構影響點)、涉及技術棧(技術關鍵點check)、接口冪等並發等處理、接口涉及大數據量預估處理、兼容處理(現有功能兼容及影響業務范圍)、優缺點對比、接口文檔(http、rpc) 等等... ...
時序圖：
表結構設計：
架構設計：
涉及技術棧：
原有邏輯兼容：
暫無
接口文檔：
1. api：/trade/third/xxx/xxx/xx【交易三方xxxx接口】
param: userId number 用戶ID
itemId number 商品ID
result： {"tag":"trade_success","msg":"成功","data":{"id":109723,"xx":"xxxxxxxxx","xxxxx":"xxxxxxxxxxxx"}}
2. dubbo： com.xxxxx.xxxx.........XxxxClient # queryTradeXxxxxxInfo
依賴包：<dependency>
<artifactId>hutool-all</artifactId>
<groupId>cn.hutool</groupId>
<version>5.3.2</version>
</dependency>
param: userId number 用戶ID
itemId number 商品ID
result： {"tag":"trade_success","msg":"成功","data":{"id":109723,"xx":"xxxxxxxxx","xxxxx":"xxxxxxxxxxxx"}}
3. .......other.........
2. 方案二(備) (小的改動點可省略備份方案)
參考方案一，最后特別指出兩者之間的優缺點、對比、擴展、兼容等方面
- 關鍵測試點
針對需求，產品、測試、開發共同關注的測試點，包含以往邏輯交互的兼容、本期新增功能的測試關鍵點
- 人員估期
需求的產品、PM、前端、客戶端、服務端、測試等相關人員
可以甘特圖標識人員開發及介入時間安排，標明 deadLine
- 發布計划
整理正式發布的checkList，多系統間發布順序、配置變更、數據庫變更、數據初始化、技術點增加、發布時間點等等... ...
配置項：
表涉及：
新增技術點：
------------------：