作者 | 馮英睿

很多解決方案架構師的職業生涯起點都是從技術人員開始的，在剛剛從事解決方案設計時，都只是負責軟件架構設計的部分。我自己在剛開始參與解決方案設計的時候，就有很多問題，可能大家也都有類似疑惑：

• 什么是愿景？愿景和目標有什么不同？
• 明明技術深度都有，為什么得到一個很虛的評價？
• 解決方案不是顯而易見的嗎？怎么就有那么多人挑戰？
• 解決方案就是把已經做出來的成果包裝包裝，到底有什么意義？
• 完全沒有辦法確定交付時間，怎么寫的出來演進路線？
• …

可能還有很多問題無法都列舉出來，但大家可能已經產生一些共鳴了。希望能通過這些分享，幫助大家減少“匯報一遍改一遍材料，看不到達成一致的希望”的痛苦。

關于解決方案，我理解的是：解決“問題”的方案，沒有問題是不需要解決方案的。所以解決方案的關鍵是問題和應對措施，包括指導后續研發交付落地的計劃。

很多朋友都知道這個道理，但就是難以提筆。這時候解決方案的結構就很重要，需要能夠體現問題、措施、計劃這些關鍵內容。做Web開發的朋友們大概都知道三層架構，今天分享一個常用的解決方案分層結構：

• 目標設定
• 問題分析
• 整體方案
• 技術方案
• 實施計劃

大致來說，上一層的產出就是下一層的輸入。真實情況也存在相互影響，但反向的影響較小，往往是對上一層輸入的一些調整。

思考：有些朋友可能會有點疑惑，為什么問題分析不是在目標設定之前？

一、目標設定  

目標設定是為了確定解決方案要達成的具體目標。目標應具體、可衡量、可落地，也可能有時效限制（目標的SMART原則）。

1. 愿景不是目標  

看到這里是不是有朋友能回憶起很多解決方案把愿景當目標的場景了。這有可能是領導聽到朋友分享了某個厲害的概念，也可能確實是業務的痛點。但我們一定要清醒的認知到愿景和目標是不同的。

愿景是對未來理想狀態的描述和期望，它描繪了長期目標的發展方向，具有前瞻性和指向性。但愿景之所以不是目標，是因為它代表了理想和現實的差距。

在目標設定的時候需要分析愿景嗎？除了定方向的作用外，是否需要分析愿景還取決于：

• 如果理想觸手可及，愿景就是目標。
• 如果理想離得不遠，愿景就是用來爭取預研經費的理由。
• 如果理想遙不可及，愿景就是用來控制范圍的工具，是用來把大家拉回現實的方法，愿景分析之后可以結合技術趨勢和在行業的應用趨勢，分析大致的可行性。

2. 目標分析工具

可落地的目標分析是這一部分的關鍵，可以從外因或內因的不同視角來分析，方法也有很多種：

• [趨勢] 技術趨勢分析：分析技術成熟度與目標可行性和投入產出，例如Gartner的炒作周期等。
• [競爭] 競爭性目標設定：人有我無、同業對比，收集專業領域的各項指標和參數。
• [客戶] 用戶需求和趨勢洞察：可以關注目標方向和緊迫性，例如一些行業報告。
• [客戶] 用戶旅程或應用場景分析：分析痛點、機會點、價值點。
• [自己] 價值鏈分析：分析效率、質量、收益，設定優化和改進目標。
• [自己] 根因分析：分析識別問題的潛在原因。
• [機會] 戰略分析：如SWOT、波特五力、商業模式畫布等，通過組織戰略分析設定重點目標。

也可以理解為這類似于五看三定中的五看一定：看趨勢、看客戶市場、看競爭、看自己、看機會再加上定目標。總的來說，這些分析都是為了推導出一個合理的，但可落地的目標。

并不是所有人擅長分析的人都擅長以上這些分析，有些分析內容需要專業性的輸入和判斷。例如：同業指標、根因分析和技術趨勢就需要行業專家或技術專家的輸入。

另外，很多解決方案架構師會忽略啟動解決方案設計的背景。例如：本來是為了解決規模化的問題，但是因為解決方案設計師對工程效率并不了解，本來應該用價值鏈分析找到改進點，卻把重點放到了技術趨勢分析上，追求創新而忽視了效率。

3. 目標總結  

目標作為下一部分的輸入，如何能夠快速把目標清晰的講出來其實非常關鍵。可能很多同學希望在將目標的時候把很多觀點放到一起來介紹，但這反而增加了描述目標的難度！目標范圍可以很詳細，但目標的介紹應該是非常簡潔的，至少包括價值點、差異點、行動號召等就是好的目標。

常用的工具有產品電梯演講，可以幫助我們在30秒內介紹完產品或解決方案的目標、價值和優勢。

• 為了：目標客戶或用戶；
• 他們想：他們的痛點或期望；
• 這個：產品或解決方案的名稱；
• 是一個：什么類型的產品或者定位；
• 它可以：提供什么樣的功能，也可以是提供或形成某種能力；
• 不同于：差異化優勢或者單純它不是什么；
• 它的優勢或價值：不同于同類項目或競爭對手的獨特價值。

以下是一個電梯演講的例子：

回到開頭的問題，雖然解決方案是解決問題的方案，但要小心不要把問題當作目標！一來解決方案的目標設定并不完全是問題驅動的，再一個解決方案要解決可以解決的問題，所以下一部分是把可落地的目標轉化成可以解決的問題。

注：分析無法解決的問題是用來澄清愿景和目標差距的，可用于設定范圍，對指導設計幫助有限。

二、問題分析

把可落地的目標轉化成可以被解決的問題，是這部分的重點。問題分析越徹底，解決方案的可行性、可信度就越高。這是因為問題分析有一個很關鍵的價值，那就是向不同的關鍵干系人傳遞信息：所有的問題我都考慮到了，如果這些問題都能被解決，那么我的解決方案就是合格的。如果問題分析不透徹，那么解決方案看起來就會比較虛。讓人感覺你說的都對，但解決什么問題呢？

1. 問題分類

通常要解決的問題可分為：

• 技術問題：當解決方案是以技術為核心的時候，需要重點打開分析技術上存在的問題，例如：智能問答系統、改進系統技術參數等。
• 優化問題：隨著業務開展，存在很多場景需要考慮資源和任務如何計劃和分配的問題。此時需要進一步分析數據、算法存在的問題。
• 流程問題：當要解決效率或體驗的問題，往往從當前的流程或用戶旅程開始分析，發現需要解決的問題。
• 信息問題：當存在海量信息，但無法獲得關鍵信息以輔助決策的時候，需要解決如何精準快捷的獲取信息和情報的問題。

當然還存在很多不同類型的問題，但先對問題進行分類，有助于根據類型去尋找案例，進一步細化問題。    

2. 解構問題

如果一個問題是一個系統性的問題，則問題解構的框架是非常重要的事情，同時也沒有固定的方法。常見的問題解構的方法有：

• 金字塔原理：逐層分析問題。
• MECE：一種系統性的問題分析和框架構建方法。
• 用戶旅程：一種分析流程和體驗問題的有效。
• 其他問題分析框架：行業中存在的各自問題分解框架。

如果要解決的問題是行業中廣泛存在的，一般存在問題分解的框架。例如，數據平臺的設計可以用數據工廠的概念來列舉問題并對問題進行分類。

目標：構建一個數據平臺幫助企業快速的加工高價值數據，為實現自服務的數據加工提供服務

框架：一家工廠包括原材料倉庫、流水線廠房、實驗室研發、辦公室、營銷、運行監控中心等部分，每個部分的人員和責任不同，可以對應到數據集成、數據流水線、數據治理、數據消費、系統監控等部分。是一種設計分系統的框架。

3. 問題與方案

問題分析是方案設計的關鍵輸入，例如在DDD中有明確的提到的問題空間和解決方案空間這兩個核心概念。問題空間能幫助各干系人形成清晰的全局視角，同時也能幫助解決方案設計師認識到解決方案和問題之間的關系。

問題（領域）與方案的映射

DDD提出了“事件風暴”作為領域聚合的方法，但并沒有明確說如何分析問題。如果按照事件風暴的分析方法來找到領域，可能并不適合分析一些智能化解決方案。這時也可以通過“發散再收斂”的方式對問題分組，主要目標還是要明確問題和方案之間的關系。

例如設計一個搜索引擎系統，這個系統的問題空間可以初步總結如下：

• 數據的采集：如何及時獲取關注的數據？
• 數據的處理：如何靈活的處理數據？
• 數據的存儲：海量的數據如何被索引？
• 信息的檢索：如何準確的檢索用戶想要的信息？用戶如何分析檢索結果？
• 情報的傳遞：用戶如何訂閱并及時的獲取情報？

這個系統的解決方案空間就會包含：網頁采集系統（采集）、實時數據處理流水線（處理）、批處理數據加工平臺（處理）、大數據平臺（存儲）、搜索引擎集群（存儲/檢索）、信息檢索服務（檢索）、內容推薦引擎（傳遞）等多個解決方案，并和問題空間形成映射。

總的來說，能夠更系統地識別問題，是判斷解決方案的合理性的有力依據。

注：有朋友曾與我討論這部分的問題是否就是需求，某種意義來說，分析出可實現的問題就是“目標”。但分析過程其實往往會經過幾次迭代，期間有些問題會影響目標的設定，所以最后覺得還是問題分析更合適一些。而且本階段注重分析過程和邏輯，需求其實是分析的結果，屬于下一階段的產出。

三、整體方案  

可能很多朋友會問：為什么分為整體方案和技術方案？如果提到4+1視圖，熟悉軟件架構設計的朋友可能很快能理解，整體方案就好比是用例架構，描述用例和功能。沒有用例，則余下的邏輯架構、運行架構、實現架構和部署架構是很可能存在偏差。

1. 用戶旅程

所以此部分的實質是推導出誰是用戶，他們的旅程和功能等要求是什么？產出給下游的內容主要包括：

• 用戶角色與用戶旅程：是對未來用戶使用流程的描述，描述用戶為完成某項或多項任務的旅程。
• 功能架構（或用戶故事地圖）：是對功能的描述，同時功能或用戶故事需要能夠映射到用戶旅程，表明功能的必要性及完整性。
• 交互設計（可選）：功能是交互設計的輸入，而交互設計的目的是交付團隊和各干系人對齊理解的重要產出物，就好比建筑設計需要看得到，把設計理念呈現出來才能確認所有人的理解是一致的。
• 數據流（可選）：如果還依賴了外部數據，和用戶旅程類似，應該描述數據加工的流程。所以應提出需要什么數據，產生什么數據，數據的格式和質量要求等。
• 模型要求（可選）：如果需要AI能力，需要描述對AI能力的要求以及構建和改進AI能力的方法和流程，例如介紹相關的ML任務，通常AI能力的水平，需要做什么來持續改進等。
• 合規要求（可選）：涉及到內外部標準、規范等合規要求應及早梳理，如果技術分析的時候沒關注，可能會造成返工的后果。

為什么需要梳理數據和模型，可能這就是智能解決方案的不同吧！但本質上，都是在梳理用戶、旅程、功能而已，只是智能解決方案交付的軟件系統，是由軟件、數據、模型三類交付件構成的。

2. 功能分析  

通過旅程或流程，對系統的能力和功能提出了具體的需求。為了和更多的干系人對齊理解，并進一步指導技術設計和交付計劃的制定，一定需要詳細的設計。在整體方案的詳細設計的產出一般指：      

• 交互體驗設計：因為很多干系人其實并不是軟件領域專家，例如用戶，要理解最終交付的產物是什么，還是需要類似建筑設計圖才能直觀的理解。而在企業內，用戶往往就是出資方。
• 用戶故事地圖：有了交互體驗設計，業務分析師就可以基于此分析出需要開發的用戶故事，而后技術團隊就可以基于此評估所需的資源和人力，幫助制定實施計劃。

交互體驗設計就不舉例分析了，用戶故事地圖是比功能列表更細的分解，每一張故事卡更聚焦于用戶需求，可能是為實現某用戶需求而需要的一個按鈕。

用戶故事地圖舉例

3. 跨功能需求

當然除了功能，還需要更多的信息才能更好的描述業務的要求。一些非功能性或跨功能性的要求，都可以在這一部分明確的提出來。比如在一個智能問答系統中，用戶等待的時間不能超過15s，用戶等待第一個token的返回的時間不超過5s等要求。

注：如果是純技術解決方案，不涉及用戶、旅程、功能的變化，此部分可以介紹解決問題的原理方法。但其實很少有純技術解決方案，假設范圍僅是智能搜索或問答接口，仍然需要人員參與對基礎數據進行管理。

4. 功能架構

整體方案是通過分析用戶和旅程，推導出能力需求的過程，而交互設計和用戶故事地圖是對功能進一步的明確。最終我們可以將功能繪制成一張功能架構圖，來向更多人呈現我們解決方案提供的各子產品或模塊包含的功能。功能架構可以是一張思維導圖，也可以是一張由不同模塊組成的架構圖。

通過思維導圖描述的產品功能架構

常見產品功能架構示意圖

功能架構是對這整個部分的總結，是否需要對功能架構進行梳理，主要取決于項目功能是否龐雜，它可以很好的幫助項目組成員快速認識產品或解決方案。它的另一個作用還可用于驗證技術方案的完整性。不同功能點所需的技術方案不同，如果技術方案和功能點都能夠映射起來，那么技術方案基本上也很全面了。

四、技術方案

整體方案梳理的用戶、旅程和功能，是技術設計工作的重要輸入。如果從4+1視圖來看，需要完成邏輯架構、運行架構、實現架構和部署架構，但如果不是實施過很多遍的成熟方案，是很難在方案設計階段就產出翔實準確的實現架構和部署架構的。

于是，仍然要思考為什么要做技術方案設計？主要有兩部分原因：          

• 對齊功能，進一步說明技術上的可行性；
• 作為交付團隊進行詳細設計的輸入，用于分析成本投入并制定實施計劃（可能會新增很多技術卡）。

1. 架構設計的內容

所以并不是要按照4+1視圖完成設計之后再進入交付，可以根據目的靈活處置，指導實施的技術方案包括：

• 邏輯架構：描述各架構元素之間的邏輯關系。
• 數據架構（可選）：描述數據模型設計，以及所需的技術。
• 集成方案（可選）：是指導部署架構逐步完善的指導。
• 運行架構（可選）：說明系統間集成或者內部關鍵技術組件運行過程等，作為技術方案可行性判斷的補充說明。
• 技術架構：推薦的技術棧選型，包括軟件、數據、AI的各類技術棧。
• 部署架構（可選）：說明技術方案在成本、可用性、可擴展性、網絡安全等方面的設計。
• 持續集成（可選）：構建、測試、發布、運維的過程設計和技術選型。

2. 架構設計的思路

架構和技術選型可以參考行業內最佳實踐如：

• 單體架構：如果系統的標準化程度很高，單體架構其實也是合理的選擇。
• 面向服務的架構：采用SOA或微服務架構設計思路。
• 事件驅動的架構：以及基于Event Sourcing & CQRS設計的微服務架構。
• Severless架構：適合專注業務功能的快速迭代的輕量級應用系統的架構。
• 數據倉庫架構：數倉設計的貼源層、數倉層、集市層。
• 數據中臺架構：One Data、One Service、One ID。
• 其他數據架構：Data Mesh、Data Fabric。
• AI模型或算法：可以根據實驗結果或行業橫向測評結果進行選型。

架構設計思路可能僅供參考，而不是方案設計的主要內容。但只有結果而沒有技術方案建模的 過程，不足以體現出設計的合理性，可參考常見的設計方法：

• DDD：應用事件風暴、四色建模等工具完成領域建模，輸出更為合理的解決方案。
• 數據建模：可參考Inmon和Kimball的數據建模范式，Inmon還在大數據技術應用階段提出了Data Vault數據建模方法等。
• 安全設計分析：縱深防御、華為八維度設計方法、威脅建模等設計方法。
• 持續交付：可參考業界DevOps、DataOps、MLOps來指導設計。

雖然有很多實踐和方法可以指導我們開展技術設計，但需要經常自省的是，技術部分的設計最終還是為了分析可行性、指導交付團隊并制定實施計劃。完全可以迭代完善設計，靈活控制設計投入。

注：注意遵從企業和組織要求的IaaS、PaaS、SaaS等高階的分層設計原則和技術管理要求。過程中可能需要和團隊或企業的總架構師對齊整體規劃。

五、實施計劃

這一部分的目標就是制定清晰的計劃。但有了功能和技術方案，就可以評估交付計劃了嗎？理想很美好，現實往往存在各種各樣的問題，導致很難制定一個清晰的可執行的計劃。即便已經進入實施階段，有些解決方案仍然是基于某些關鍵假設來設計的。

1. 風險/假設/問題/依賴

在開始做計劃之前，可以先了解一下這個項目管理工具，將已知的風險、假設、問題和依賴都寫下來。

• 風險：可能對達成目標產生負面影響的事情。
• 假設：沒有確定，但假設為真的，對項目目標會產生影響的條件或事情。
• 問題：正在對達成目標產生負面影響的事情。
• 依賴：達成目標所依賴的外部因素或條件。

在完善方案輸出時，不同類型的具體事項，可以采取不同的應對措施，并不斷的更新狀態。例如：

存在問題其實不用擔心，問題不透明才是最要命的，通過提高透明度，能更好的促進協作，提高效率。

2. 路線圖

回到開頭提出的問題：“完全沒有辦法確定交付時間，怎么寫的出來演進路線？”

現實中是一定會存在風險和問題的。在制定演進路線時候，可以先劃定階段或關鍵里程碑，而不是直接設定時間。確定里程碑沒有固定的方法，這需要結合具體的情況分析。主要來說還是對關鍵子任務的分解，以及子任務之間的依賴關系的梳理。

當然并不是說路線圖一定就沒有時間了，只能說時間估算是一個逐步清晰的過程。需要足夠清晰的任務分解和依賴關系分析，以及對任務復雜度和工作量的評估，才能最終得到準確的實施計劃。

如果馬上就要開始交付了，那么就需要評估工作量。這時候，有很多團隊通過故事卡估點的方式來評估所需的資源并制定發布計劃。

六、方案發展的階段  

要達成的愿景可能真是“一張藍圖繪到底”，但不可能擼起袖子一直干一樣的事情！

如果是由技術驅動的創新性項目，它的發展一般會經歷幾個階段：

• 概念驗證：在概念驗證階段，方案主要關注可行性的驗證，不需要過多的關注體驗，功能點也非常的簡單，因為可能都沒有真實的用戶。運維運營管理基本上很少考慮。因為可行性都還沒有被驗證，過渡設計就是浪費。
• 價值驗證：為了驗證解決方案的業務價值，需要真實的用戶參與。這時也需要考慮體驗問題和系統集成等問題。解決方案內容就必須要包含旅程（流程）、功能等，而且因為真實用戶使用過程的行為數據也需要考慮收集，運營相關的功能也需考慮是否包含。
• 持續運營：當價值被驗證之后，為了推動到更大的范圍，需要考慮支撐規模化所需的能力，再規劃相應的工具或平臺的開發計劃。這時需要分析提供某種服務的價值鏈，尋找優化運營的機會點，強調怎么把服務做好，成本控制好。因此運營推廣和協作的功能就是這一階段設計的重點。

另外需要注意的是高階方案和詳細設計是不同的，并非所有以上討論的內容都需要在高階解決方案中完成，例如交互設計一般就不需要在高階解決方案中編寫。下表是一些內容的分類，可供參考：

以上就是所有和方案內容有關的分享了，希望能夠對大家有所啟發。