要寫好一份 B 端產品的技術方案，是非常有挑戰的事情，對最終項目價值達成起到決定性的作用，技術方案質量差可能直接毀滅一塊業務。下麵推薦一份 B 端產品的技術方案模板，供讀者參考。 ...
B端產品為企業提供協同辦公的工具，幫助企業解決某類經營管理問題，核心價值在於為企業增加收入、降本提效、管控風險，企業級SaaS產品也是B端產品中的一類。
B端產品有以下特點：
客戶是一個群體：B端產品為某個企業組織服務，一項工作通常需要由多名角色完成，例如，門店要貨流程，需要門店店員、總部運營、倉儲人員、配送人員共同完成，B端產品幫助他們完成分工協作。
功能繁雜：由於B端產品涉及企業經營的方方面面，關聯的用戶角色、業務流程非常繁多，反應到產品上，菜單、界面、配置項特別多，複雜度遠高於C端產品。為了實現一項功能需求，往往會影響其他許多功能，需要進行全面的梳理，考慮各種極端情況，才能保證整體功能正常。
定製化功能：B端產品必然會有很多定製化需求，如果一味抗拒，很容易丟掉一些優質客戶，但如果大包大攬地接受，系統複雜度會指數級上升，高昂的研發維護成本將很難承受，所以如何處理好定製化需求，是一項非常艱巨的任務。
見效慢、難量化：由於B端產品的客戶是一個群體，產品上線新功能，通常是管理層先評估，能否在企業中適用，如果合適，才會組織一線人員，進行操作培訓。這樣一來一回，可能要2個月後才有客戶正式使用新功能。
其次，業務見效的影響因素非常多，很多時候並非因為B端產品設計問題。例如，採購部門核心目標是找到更多優質、低價供應商，而這主要依賴採購員的專業能力，以及商家的管理能力，很難衡量產品功能對商家業務的實際貢獻。
正是由於B端產品這些複雜性，要寫好一份B端產品的技術方案，是非常有挑戰的事情，對最終項目價值達成起到決定性的作用，技術方案質量差可能直接毀滅一塊業務。下麵推薦一份B端產品的技術方案模板，供讀者參考。
一、概述【強制】
1.1 術語解釋
為什麼要這塊內容？
B端產品中的專業名稱非常多，對專業名詞進行彙總解釋，方便項目組理解上下文，統一認知。
1.2 項目背景與價值
為什麼要這塊內容？
介紹項目的背景，為什麼需要做這個項目，解決了用戶哪些痛點，為用戶創造什麼價值，或者是技術價值，例如，帶來多少活躍商家數？提升多少NPS？性能有多少提升？開發效率上有多少提升？
這部分內容極其重要，前文提到B端產品見效慢、難量化，但這並不代表只能自暴自棄，不去進行收益分析，相反，我們需要更加努力地對B端項目進行收益分析，即使最終也很難找到合適的度量方法，思考如何度量收益，這個過程本身就能幫助決策該不該做，如果一件事很難度量，同時放飛自我，不去謹慎思考，最終項目大概率失敗。
站在技術視角，系統複雜度無節制地增加，很重要的一個原因是由大量無價值的項目累積起來的，最終演變成一座“代碼屎山”，在項目初期，多追問項目的價值，項目上線後，也追著產品設計者回顧項目價值，能有效避免這種情況，讓技術人員的付出更容易獲得結果。
1.3 本期項目目標
介紹本期項目需要達成的目標
1.4 方案評審紀要
為什麼要這塊內容？
一個複雜項目，通常需要好幾次評審才能通過，記錄每次評審紀要，根據評審建議改進，是非常重要的。
二、業務分析【強制】
2.1 業務用例分析
為什麼要這塊內容？
業務用例，是指參與者為完成某個特定業務目標的一系列活動的集合，用例圖用於描述系統與用戶之間交互關係。用例圖關心的是系統為用戶提供什麼價值，而不是如何實現系統功能，它驅動了後續各階段的研發工作，如果用例分析出錯，很可能導致項目目標失敗。
業務用例希望我們跳出系統功能，以用戶視角來看待系統，思考什麼場景下為誰提供什麼服務？這樣才能以用戶為中心獲取需求，設計產品功能，同時這種視角也是用戶最容易理解的邏輯。
舉例說明
小項目如何設計？
在原有業務用例圖的基礎上，需要補充新用例或標識出待修改的用例，併在圖中用不同顏色標記出來，如上圖所示，紅色表示新增用例，黃色表示變更用例。
2.2業務流程分析
為什麼要這塊內容？
業務流程，是指為達成特定業務目標，由不同的角色分工完成的一系列活動。活動之間不僅有嚴格的先後順序限定，並且活動的內容、方式、責任等也都必須有明確的安排和界定，讓不同活動在不同崗位角色之間進行流轉與交接。
業務流程對於B端產品的意義不僅在於對B端客戶業務的一種描述，更在於產研團隊對B端業務運營的理解和剖析，這種理解是對企業資源的優化、對企業組織機構的優化以及對管理制度的一系列深入探究。只有真正理解業務流程，才能幫助B端客戶達成期望的目標：降低企業的運營成本，提高對市場需求的響應速度，爭取企業利潤的最大化。
對於研發人員，業務流程模型可以幫助研發人員更好地瞭解企業真實的運營場景，進而更好地實現客戶的需求。
舉例說明
小項目如何設計？
在原有業務流程圖的基礎上，需要用不同顏色標識出需要修改的部分。
2.3概念模型分析
為什麼要這塊內容？
概念模型，是指從業務視角出發，聚焦業務流程、業務活動中涉及的信息數據，抽象出關鍵業務對象，並描述這些對象間的關係。
概念模型實際上是現實世界到數字世界的第一層抽象。通過觀察業務中關於數據的採集、傳輸、處理、存儲、輸出等需求，經過分析、總結之後建立起來的一個邏輯模型，它主要是用於描述業務系統中數據的各種狀態。
概念模型不關心具體的實現方式（例如如何存儲）等技術細節，而是主要關心數據在業務流中各個處理階段的狀態。
想要全面地瞭解某個業務領域，首先要瞭解該業務是什麼，其次就要瞭解業務內部的核心運作原理，即從靜態到動態，從目標到過程，系統地理清業務的框架和脈絡。
業務的動態描述可以通過活動圖，流程圖，時序圖，泳道圖等模式描述，而業務的靜態描述首先要分析出概念模型。
舉例說明
三、方案選型分析【可選】
為什麼要這塊內容？
有些項目比較簡單，簡單到不需要花太多時間做方案決策。
但一些成本大、風險高的大型複雜項目，會讓人感覺到頭疼、焦慮，這些項目的技術方案的決策結果，很可能摧毀一個項目，甚至一塊業務。
為了避免做出錯誤決策，需要一系列的分析步驟，幫助我們做出正確的決定，保障項目目標順利達成：
1.詳細的現狀分析：很多項目失敗，原因是一開始就沒分析清楚問題。在這個環節，需要明確真正的問題是什麼，它與各個問題癥狀的因果關係是什麼。常用的分析工具有五個為什麼、根因分析法等。
2.核心成員同頻：一個複雜項目，通常需要很多人參與，有人是受益方，有人是受影響方，有人是決策者，需要讓核心成員儘早參與進來，並營造一個積極的討論氛圍，讓每個人充分貢獻自己的想法，這對做出正確的決定至關重要。
3.充分挖掘可行方案：挖掘出的可行方案越多，最終得出最優方案的概率就越大。
4.方案對比分析，選擇最優方案：通過一些分析維度，對比方案的優劣，最終選擇最優方案，分析維度可以通過團隊頭腦風暴篩選得出，或其他方法得出。這裡推薦幾種常用的分析維度：
-
交付效果：該方案是否對最終交付給存量或新客戶的價值有影響，例如，對存量客戶的操作體驗、效率有損，部分新功能無法實現等。
-
工作量：該方案需要多大的工作量？這是非常重要的一個決策因素，方案再好，無法真正落地也只能是空想。
-
影響面：該方案涉及多少關聯方改動？如果影響全公司所有部門，即使每個部門改動量不大，但要協調這麼多人，也是一項非常艱巨的任務。
-
穩定性：項目上線後是否有資料庫性能問題？伺服器資源不足？併發流量問題？能否平滑發佈？歷史介面或數據能否相容？
-
長期價值：該方案是不是長期方案？有時候對方案做長期投資也是很重要的一件事，短視的方案雖然工作量會減少一些，但會阻礙未來新項目迭代，欠的技術債可能要加倍還上。
5.向更多項目成員傳達方案，進一步優化：通過上述步驟，可為最終方案提供大量的信息，例如，根本問題、風險、收益、替代方案、決策方式和決策的原因等，這會讓更多人有理由支持該方案。在傳達的過程中，也可能有人指出方案的缺陷，這時可以進一步完善方案，這時對方案的改動，成本非常低，如果等到進入研發階段，昂貴的代價可能無法接受。
舉例說明
方案1：。。。（描述）
方案2：。。。（描述）
方案3：。。。（描述）
四、業務平臺化設計【可選】
為什麼要這塊內容？
業務平臺化是將多業務線可復用的能力抽取出來，並集中管理和演進的架構方案。
一方面，可讓企業避免重覆建設，浪費技術資源，另一方面基於平臺化的能力，讓新業務快速組裝上線，支撐業務創新。
4.1 業務能力建模
為什麼要這塊內容？
業務能力描述了應對當前和未來的挑戰，企業目前能做什麼或需要做什麼。業務能力建模的關鍵點在於它定義了企業做什麼，而不是如何做（由業務流程描述）。
以招聘業務為例，大部分公司都需要“招聘人才”這項業務能力，“招聘人才”告訴我們要做什麼，但並沒有展開說如何去做，可能是通過人力資源的招聘流程實現，例如，從招聘網站吸引候選人，再到招聘信息的管理，也可能外包給獵頭公司。
業務能力獨立於組織的結構、流程、人員、資產，準確地說，這些業務要素是支撐企業的業務能力而存在的。還是以“招聘人才”為例，“招聘人才”包括人力部門（人力資源團隊）、業務流程（例如吸引、篩選、面試、雇用）和IT系統（例如招聘系統、人事系統）。準確的業務能力是非常穩定的，在過去的幾十年中，招聘的流程、技術、模式發生了翻天覆地的變化，但“招聘人才”這項業務能力始終恆定存在。
正是因為業務能力的這些特征，業務能力視圖對構建IT架構提供了至關重要的幫助，圍繞業務能力構建的IT系統會具備更加穩定的結構，並易於擴展。
具體來說，業務能力視圖有以下2大應用場景：
1.產品定義與演進路線圖。如果需要推出的新產品或服務，可以使用業務能力地圖來描述產品規劃。尤其在基於敏捷、最小可行產品 (MVP)的文化中，業務能力地圖可以在定義產品的同時，保持最終產品方案的正確性，不至於在偽敏捷文化中迷失自我。
2.基於現有能力快速搭建新應用系統。通用能力很可能被多條業務線復用，當新業務需要搭建新應用系統時，合理地對現有能力進行組合是最高效的方案，此時業務能力圖可能是最重要的輸入。
舉例說明
4.2 系統工作流與擴展點設計
為什麼要這塊內容？
基礎能力是對領域對象的原子操作，是可復用的最小能力單元，擴展點是對基礎能力的可變性設計，而業務身份是業務能力在業務平臺上的唯一標識。
在技術視角下，基礎能力可對應於服務介面，將基礎能力的內部實現展開，即為一個系統工作流，而擴展點是指系統工作流的某一步驟級介面，這個步驟級介面的實現即為一個擴展點實現。基於業務身份，可實現工作流內部組件的路由、鏈路溯源、鏈路監控、業務隔離等。
有了擴展點機制，我們就可以基於現有基礎能力，快速實現定製需求。
舉例說明
五、概要設計【強制】
5.1 限界上下文劃分
為什麼要這塊內容？
在業務分析環節，我們需要分析業務流程、業務活動，根據業務目標的相關性、耦合關係，對業務活動進行歸類分組，劃分出一個個的邊界，這個邊界就是限界上下文。
限界上下文內包含一組能夠獨立提供服務的模塊或組件，這些模塊或組件服務共同的業務目標。
限界上下文的價值主要有：
1.基於業務目標的相關性，維護了一個分解後的邏輯邊界，將相關的模型封裝在內，對外提供抽象簡化後的服務介面，降低了系統整體複雜度。
2.以限界上下文定義的邏輯邊界為基礎，建立團隊間的協作邊界，團隊間同樣以服務介面進行交互，屏蔽內部的業務複雜度與技術複雜度。
舉例說明
5.2應用架構設計
為什麼要這塊內容？
應用架構描述出應用系統的層次結構，包括系統、應用、模塊、組件等構件的劃分規範，以及它們的定義、邊界、相互間的交互協議。
畫應用架構圖，推薦西蒙布朗提出的C4模型，它將應用架構分為4個抽象層次，分別為系統級、容器級、組件級、代碼級。
舉例說明
容器級應用架構：
組件級應用架構：
5.3 領域模型設計
為什麼要這塊內容？
領域模型是對業務知識的抽象與濃縮，它能夠有效幫助業務人員、技術人員快速理解現實業務，同時也是團隊統一語言的關鍵。
在DDD理論中，領域模型包含限界上下文、領域實體、聚合、值對象、領域事件、倉儲、應用服務、領域服務等，以及它們間的關係。
舉例說明
小項目如何設計？
在原有領域模型的基礎上，需要補充新的模型或新屬性，併在圖中用不同顏色標記出來。如果沒有模型變更，可以不需要這塊內容
5.4 容器級交互時序
為什麼要這塊內容？
容器級交互時序圖是一種流程建模，描述了應用容器之間的交互順序，將交互行為建模為消息傳遞，通過描述消息是如何在應用容器間發送和接收，來動態展示它們之間的交互。相對於其他UML圖，時序圖更強調交互的時間順序，可以直觀的描述交互的過程。
舉例說明
小項目如何設計？
在原有交互圖的基礎上，需要補充新的調用關係，併在圖中用不同顏色標記出來，例如，用紅色線條標識為本期項目新增。
六、詳細設計【強制】
6.1 組件/代碼級交互時序
為什麼要這塊內容？
相比於容器級交互圖，組件或代碼級的交互圖是更細粒度的交互流程，描述了應用容器內各個組件或代碼的交互順序。
舉例說明
小項目如何設計？
在原有組件間交互圖的基礎上，需要補充新的調用關係，併在圖中用不同顏色標記出來，例如，用紅色線條標識為本期項目新增。
6.2 領域模型詳細設計
6.2.1 領域實體&值對象定義
XX領域實體
XX值對象
6.2.2 領域服務定義
XXDomainService
6.2.3 應用服務定義
XXAppService
6.2.4 領域事件定義
XX領域事件
6.2.5 領域實體狀態機定義
舉例說明
要貨申請單的狀態機：
6.3 物理模型詳細設計
為什麼要這塊內容？
物理模型是指按照一定規則和方法，將領域模型中定義的實體、屬性、屬性類型、關係等要素轉換為資料庫設計所能夠識別的表關係圖，即我們常說的資料庫表結構設計。
舉例說明
XX表結構
6.4前端介面詳細設計
介面名稱：XX
入參設計：
返回值設計：
錯誤碼解釋：
七、非功能性需求設計【強制】
為什麼需要這塊內容？
非功能性需求是指軟體產品為滿足用戶業務需求，除功能需求以外必須具有的特性，包括系統的性能、可靠性、可維護性、擴展性、安全性等。
大多時候我們更關註功能需求，而容易忽視非功能性需求，但這些需求沒有做到位，也很容易讓用戶體驗受損，產品飽受詬病。我們在做技術方案時，需要有非功能性需求的checklist，避免遺漏關鍵的需求點。
7.1 性能分析
1.資料庫性能
評估新增的資料庫表的IO、事務數，是否有併發場景，是否有性能瓶頸，是否對現有業務或實時/離線數倉有影響。
若有高併發、熱點數據集中訪問等場景，需要有詳細的緩存設計方案。
2.JVM調優
JVM參數是否配置合理，是否有參考線上標準配置。
3.外部系統性能
當前業務流量，下游系統能否支撐，是否需要做限流處理。
4.伺服器性能
當前業務流量，對伺服器性能是否有挑戰，建議通過壓力測試，驗證伺服器性能狀況。
7.2 穩定性分析
1.降級、熔斷、限流
在大流量、高併發場景下，熔斷、降級、限流是保護系統的利器，評估該項目是否需要使用這些機制。
2.灰度發佈
評估該項目是否需要灰度發佈，雖然功能在測試環境測試過，但生產環境的場景異常複雜，對於複雜項目很難全面評估，通過灰度發佈，讓少部分用戶先使用新版本，提前發現bug，或者穩定性問題，提前做好修複，可以有效降低新版本帶來的影響。
3.監控報警
評估該項目是否需要新增或變更監控報警，監控報警能夠保障出現故障之後，第一時間知道，防止影響面擴大。
4.數據一致性對賬設計
分散式架構極容易出現數據不一致的問題，該項目是否需要設計數據對賬腳本，幫助及時發現不一致問題。
7.3 資損分析
1.評估資損點，例如服務介面中包含資損相關欄位（資金、積分、虛擬幣等）。
2.評估為了防止資損，是否需要進行冪等控制、併發控制、越權校驗、風控機制設計、止損機制設計、監控報警設計等。
7.4 相容性分析
1.歷史數據遷移
該項目對歷史數據是否有影響，若有，需要制定詳細的數據遷移計劃。
2.歷史版本相容
該項目對老系統、APP歷史版本、開放平臺介面是否有影響，是否需要開發相容邏輯。
7.5 安全分析
1.評估常用技術攻擊手段的防控，比如腳本（JS）註入、SQL註入、CSRF攻擊、越權問題、id遍歷、防重放攻擊。
2.數據是否需要脫敏，比如手機號等隱私、敏感數據。
八、附錄【強制】
8.1參考文檔
附上需求文檔、過往技術方案設計文檔、依賴的技術組件、技術服務的說明文檔等，給出文檔鏈接或附件。
參考資料
1.《ThoughtWorks現代企業架構框架白皮書》
2. https://c4model.com/
3.《實現領域驅動設計》作者：Vaughn Vernon
4.《領域驅動設計》作者：Eric Evans
5.《決勝B端：產品經理升級之路》作者：楊堃
本文來自博客園，作者：湯師爺說，轉載請註明原文鏈接：https://www.cnblogs.com/tangshiye/p/16197792.html
