作者 | 馮英睿

很多解決方案架構(gòu)師的職業(yè)生涯起點(diǎn)都是從技術(shù)人員開(kāi)始的，在剛剛從事解決方案設(shè)計(jì)時(shí)，都只是負(fù)責(zé)軟件架構(gòu)設(shè)計(jì)的部分。我自己在剛開(kāi)始參與解決方案設(shè)計(jì)的時(shí)候，就有很多問(wèn)題，可能大家也都有類(lèi)似疑惑：

• 什么是愿景？愿景和目標(biāo)有什么不同？
• 明明技術(shù)深度都有，為什么得到一個(gè)很虛的評(píng)價(jià)？
• 解決方案不是顯而易見(jiàn)的嗎？怎么就有那么多人挑戰(zhàn)？
• 解決方案就是把已經(jīng)做出來(lái)的成果包裝包裝，到底有什么意義？
• 完全沒(méi)有辦法確定交付時(shí)間，怎么寫(xiě)的出來(lái)演進(jìn)路線？
• …

可能還有很多問(wèn)題無(wú)法都列舉出來(lái)，但大家可能已經(jīng)產(chǎn)生一些共鳴了。希望能通過(guò)這些分享，幫助大家減少“匯報(bào)一遍改一遍材料，看不到達(dá)成一致的希望”的痛苦。

關(guān)于解決方案，我理解的是：解決“問(wèn)題”的方案，沒(méi)有問(wèn)題是不需要解決方案的。所以解決方案的關(guān)鍵是問(wèn)題和應(yīng)對(duì)措施，包括指導(dǎo)后續(xù)研發(fā)交付落地的計(jì)劃。

很多朋友都知道這個(gè)道理，但就是難以提筆。這時(shí)候解決方案的結(jié)構(gòu)就很重要，需要能夠體現(xiàn)問(wèn)題、措施、計(jì)劃這些關(guān)鍵內(nèi)容。做Web開(kāi)發(fā)的朋友們大概都知道三層架構(gòu)，今天分享一個(gè)常用的解決方案分層結(jié)構(gòu)：

• 目標(biāo)設(shè)定
• 問(wèn)題分析
• 整體方案
• 技術(shù)方案
• 實(shí)施計(jì)劃

大致來(lái)說(shuō)，上一層的產(chǎn)出就是下一層的輸入。真實(shí)情況也存在相互影響，但反向的影響較小，往往是對(duì)上一層輸入的一些調(diào)整。

思考：有些朋友可能會(huì)有點(diǎn)疑惑，為什么問(wèn)題分析不是在目標(biāo)設(shè)定之前？

一、目標(biāo)設(shè)定  

目標(biāo)設(shè)定是為了確定解決方案要達(dá)成的具體目標(biāo)。目標(biāo)應(yīng)具體、可衡量、可落地，也可能有時(shí)效限制（目標(biāo)的SMART原則）。

1. 愿景不是目標(biāo)  

看到這里是不是有朋友能回憶起很多解決方案把愿景當(dāng)目標(biāo)的場(chǎng)景了。這有可能是領(lǐng)導(dǎo)聽(tīng)到朋友分享了某個(gè)厲害的概念，也可能確實(shí)是業(yè)務(wù)的痛點(diǎn)。但我們一定要清醒的認(rèn)知到愿景和目標(biāo)是不同的。

愿景是對(duì)未來(lái)理想狀態(tài)的描述和期望，它描繪了長(zhǎng)期目標(biāo)的發(fā)展方向，具有前瞻性和指向性。但愿景之所以不是目標(biāo)，是因?yàn)樗砹死硐牒同F(xiàn)實(shí)的差距。

在目標(biāo)設(shè)定的時(shí)候需要分析愿景嗎？除了定方向的作用外，是否需要分析愿景還取決于：

• 如果理想觸手可及，愿景就是目標(biāo)。
• 如果理想離得不遠(yuǎn)，愿景就是用來(lái)爭(zhēng)取預(yù)研經(jīng)費(fèi)的理由。
• 如果理想遙不可及，愿景就是用來(lái)控制范圍的工具，是用來(lái)把大家拉回現(xiàn)實(shí)的方法，愿景分析之后可以結(jié)合技術(shù)趨勢(shì)和在行業(yè)的應(yīng)用趨勢(shì)，分析大致的可行性。

2. 目標(biāo)分析工具

可落地的目標(biāo)分析是這一部分的關(guān)鍵，可以從外因或內(nèi)因的不同視角來(lái)分析，方法也有很多種：

• [趨勢(shì)] 技術(shù)趨勢(shì)分析：分析技術(shù)成熟度與目標(biāo)可行性和投入產(chǎn)出，例如Gartner的炒作周期等。
• [競(jìng)爭(zhēng)] 競(jìng)爭(zhēng)性目標(biāo)設(shè)定：人有我無(wú)、同業(yè)對(duì)比，收集專(zhuān)業(yè)領(lǐng)域的各項(xiàng)指標(biāo)和參數(shù)。
• [客戶] 用戶需求和趨勢(shì)洞察：可以關(guān)注目標(biāo)方向和緊迫性，例如一些行業(yè)報(bào)告。
• [客戶] 用戶旅程或應(yīng)用場(chǎng)景分析：分析痛點(diǎn)、機(jī)會(huì)點(diǎn)、價(jià)值點(diǎn)。
• [自己] 價(jià)值鏈分析：分析效率、質(zhì)量、收益，設(shè)定優(yōu)化和改進(jìn)目標(biāo)。
• [自己] 根因分析：分析識(shí)別問(wèn)題的潛在原因。
• [機(jī)會(huì)] 戰(zhàn)略分析：如SWOT、波特五力、商業(yè)模式畫(huà)布等，通過(guò)組織戰(zhàn)略分析設(shè)定重點(diǎn)目標(biāo)。

也可以理解為這類(lèi)似于五看三定中的五看一定：看趨勢(shì)、看客戶市場(chǎng)、看競(jìng)爭(zhēng)、看自己、看機(jī)會(huì)再加上定目標(biāo)?？偟膩?lái)說(shuō)，這些分析都是為了推導(dǎo)出一個(gè)合理的，但可落地的目標(biāo)。

并不是所有人擅長(zhǎng)分析的人都擅長(zhǎng)以上這些分析，有些分析內(nèi)容需要專(zhuān)業(yè)性的輸入和判斷。例如：同業(yè)指標(biāo)、根因分析和技術(shù)趨勢(shì)就需要行業(yè)專(zhuān)家或技術(shù)專(zhuān)家的輸入。

另外，很多解決方案架構(gòu)師會(huì)忽略啟動(dòng)解決方案設(shè)計(jì)的背景。例如：本來(lái)是為了解決規(guī)模化的問(wèn)題，但是因?yàn)榻鉀Q方案設(shè)計(jì)師對(duì)工程效率并不了解，本來(lái)應(yīng)該用價(jià)值鏈分析找到改進(jìn)點(diǎn)，卻把重點(diǎn)放到了技術(shù)趨勢(shì)分析上，追求創(chuàng)新而忽視了效率。

3. 目標(biāo)總結(jié)  

目標(biāo)作為下一部分的輸入，如何能夠快速把目標(biāo)清晰的講出來(lái)其實(shí)非常關(guān)鍵?？赡芎芏嗤瑢W(xué)希望在將目標(biāo)的時(shí)候把很多觀點(diǎn)放到一起來(lái)介紹，但這反而增加了描述目標(biāo)的難度！目標(biāo)范圍可以很詳細(xì)，但目標(biāo)的介紹應(yīng)該是非常簡(jiǎn)潔的，至少包括價(jià)值點(diǎn)、差異點(diǎn)、行動(dòng)號(hào)召等就是好的目標(biāo)。

常用的工具有產(chǎn)品電梯演講，可以幫助我們?cè)?0秒內(nèi)介紹完產(chǎn)品或解決方案的目標(biāo)、價(jià)值和優(yōu)勢(shì)。

• 為了：目標(biāo)客戶或用戶；
• 他們想：他們的痛點(diǎn)或期望；
• 這個(gè)：產(chǎn)品或解決方案的名稱(chēng)；
• 是一個(gè)：什么類(lèi)型的產(chǎn)品或者定位；
• 它可以：提供什么樣的功能，也可以是提供或形成某種能力；
• 不同于：差異化優(yōu)勢(shì)或者單純它不是什么；
• 它的優(yōu)勢(shì)或價(jià)值：不同于同類(lèi)項(xiàng)目或競(jìng)爭(zhēng)對(duì)手的獨(dú)特價(jià)值。

以下是一個(gè)電梯演講的例子：

回到開(kāi)頭的問(wèn)題，雖然解決方案是解決問(wèn)題的方案，但要小心不要把問(wèn)題當(dāng)作目標(biāo)！一來(lái)解決方案的目標(biāo)設(shè)定并不完全是問(wèn)題驅(qū)動(dòng)的，再一個(gè)解決方案要解決可以解決的問(wèn)題，所以下一部分是把可落地的目標(biāo)轉(zhuǎn)化成可以解決的問(wèn)題。

注：分析無(wú)法解決的問(wèn)題是用來(lái)澄清愿景和目標(biāo)差距的，可用于設(shè)定范圍，對(duì)指導(dǎo)設(shè)計(jì)幫助有限。

二、問(wèn)題分析

把可落地的目標(biāo)轉(zhuǎn)化成可以被解決的問(wèn)題，是這部分的重點(diǎn)。問(wèn)題分析越徹底，解決方案的可行性、可信度就越高。這是因?yàn)閱?wèn)題分析有一個(gè)很關(guān)鍵的價(jià)值，那就是向不同的關(guān)鍵干系人傳遞信息：所有的問(wèn)題我都考慮到了，如果這些問(wèn)題都能被解決，那么我的解決方案就是合格的。如果問(wèn)題分析不透徹，那么解決方案看起來(lái)就會(huì)比較虛。讓人感覺(jué)你說(shuō)的都對(duì)，但解決什么問(wèn)題呢？

1. 問(wèn)題分類(lèi)

通常要解決的問(wèn)題可分為：

• 技術(shù)問(wèn)題：當(dāng)解決方案是以技術(shù)為核心的時(shí)候，需要重點(diǎn)打開(kāi)分析技術(shù)上存在的問(wèn)題，例如：智能問(wèn)答系統(tǒng)、改進(jìn)系統(tǒng)技術(shù)參數(shù)等。
• 優(yōu)化問(wèn)題：隨著業(yè)務(wù)開(kāi)展，存在很多場(chǎng)景需要考慮資源和任務(wù)如何計(jì)劃和分配的問(wèn)題。此時(shí)需要進(jìn)一步分析數(shù)據(jù)、算法存在的問(wèn)題。
• 流程問(wèn)題：當(dāng)要解決效率或體驗(yàn)的問(wèn)題，往往從當(dāng)前的流程或用戶旅程開(kāi)始分析，發(fā)現(xiàn)需要解決的問(wèn)題。
• 信息問(wèn)題：當(dāng)存在海量信息，但無(wú)法獲得關(guān)鍵信息以輔助決策的時(shí)候，需要解決如何精準(zhǔn)快捷的獲取信息和情報(bào)的問(wèn)題。

當(dāng)然還存在很多不同類(lèi)型的問(wèn)題，但先對(duì)問(wèn)題進(jìn)行分類(lèi)，有助于根據(jù)類(lèi)型去尋找案例，進(jìn)一步細(xì)化問(wèn)題。    

2. 解構(gòu)問(wèn)題

如果一個(gè)問(wèn)題是一個(gè)系統(tǒng)性的問(wèn)題，則問(wèn)題解構(gòu)的框架是非常重要的事情，同時(shí)也沒(méi)有固定的方法。常見(jiàn)的問(wèn)題解構(gòu)的方法有：

• 金字塔原理：逐層分析問(wèn)題。
• MECE：一種系統(tǒng)性的問(wèn)題分析和框架構(gòu)建方法。
• 用戶旅程：一種分析流程和體驗(yàn)問(wèn)題的有效。
• 其他問(wèn)題分析框架：行業(yè)中存在的各自問(wèn)題分解框架。

如果要解決的問(wèn)題是行業(yè)中廣泛存在的，一般存在問(wèn)題分解的框架。例如，數(shù)據(jù)平臺(tái)的設(shè)計(jì)可以用數(shù)據(jù)工廠的概念來(lái)列舉問(wèn)題并對(duì)問(wèn)題進(jìn)行分類(lèi)。

目標(biāo)：構(gòu)建一個(gè)數(shù)據(jù)平臺(tái)幫助企業(yè)快速的加工高價(jià)值數(shù)據(jù)，為實(shí)現(xiàn)自服務(wù)的數(shù)據(jù)加工提供服務(wù)

框架：一家工廠包括原材料倉(cāng)庫(kù)、流水線廠房、實(shí)驗(yàn)室研發(fā)、辦公室、營(yíng)銷(xiāo)、運(yùn)行監(jiān)控中心等部分，每個(gè)部分的人員和責(zé)任不同，可以對(duì)應(yīng)到數(shù)據(jù)集成、數(shù)據(jù)流水線、數(shù)據(jù)治理、數(shù)據(jù)消費(fèi)、系統(tǒng)監(jiān)控等部分。是一種設(shè)計(jì)分系統(tǒng)的框架。

3. 問(wèn)題與方案

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

問(wèn)題（領(lǐng)域）與方案的映射

DDD提出了“事件風(fēng)暴”作為領(lǐng)域聚合的方法，但并沒(méi)有明確說(shuō)如何分析問(wèn)題。如果按照事件風(fēng)暴的分析方法來(lái)找到領(lǐng)域，可能并不適合分析一些智能化解決方案。這時(shí)也可以通過(guò)“發(fā)散再收斂”的方式對(duì)問(wèn)題分組，主要目標(biāo)還是要明確問(wèn)題和方案之間的關(guān)系。

例如設(shè)計(jì)一個(gè)搜索引擎系統(tǒng)，這個(gè)系統(tǒng)的問(wèn)題空間可以初步總結(jié)如下：

• 數(shù)據(jù)的采集：如何及時(shí)獲取關(guān)注的數(shù)據(jù)？
• 數(shù)據(jù)的處理：如何靈活的處理數(shù)據(jù)？
• 數(shù)據(jù)的存儲(chǔ)：海量的數(shù)據(jù)如何被索引？
• 信息的檢索：如何準(zhǔn)確的檢索用戶想要的信息？用戶如何分析檢索結(jié)果？
• 情報(bào)的傳遞：用戶如何訂閱并及時(shí)的獲取情報(bào)？

這個(gè)系統(tǒng)的解決方案空間就會(huì)包含：網(wǎng)頁(yè)采集系統(tǒng)（采集）、實(shí)時(shí)數(shù)據(jù)處理流水線（處理）、批處理數(shù)據(jù)加工平臺(tái)（處理）、大數(shù)據(jù)平臺(tái)（存儲(chǔ)）、搜索引擎集群（存儲(chǔ)/檢索）、信息檢索服務(wù)（檢索）、內(nèi)容推薦引擎（傳遞）等多個(gè)解決方案，并和問(wèn)題空間形成映射。

總的來(lái)說(shuō)，能夠更系統(tǒng)地識(shí)別問(wèn)題，是判斷解決方案的合理性的有力依據(jù)。

注：有朋友曾與我討論這部分的問(wèn)題是否就是需求，某種意義來(lái)說(shuō)，分析出可實(shí)現(xiàn)的問(wèn)題就是“目標(biāo)”。但分析過(guò)程其實(shí)往往會(huì)經(jīng)過(guò)幾次迭代，期間有些問(wèn)題會(huì)影響目標(biāo)的設(shè)定，所以最后覺(jué)得還是問(wèn)題分析更合適一些。而且本階段注重分析過(guò)程和邏輯，需求其實(shí)是分析的結(jié)果，屬于下一階段的產(chǎn)出。

三、整體方案  

可能很多朋友會(huì)問(wèn)：為什么分為整體方案和技術(shù)方案？如果提到4+1視圖，熟悉軟件架構(gòu)設(shè)計(jì)的朋友可能很快能理解，整體方案就好比是用例架構(gòu)，描述用例和功能。沒(méi)有用例，則余下的邏輯架構(gòu)、運(yùn)行架構(gòu)、實(shí)現(xiàn)架構(gòu)和部署架構(gòu)是很可能存在偏差。

1. 用戶旅程

所以此部分的實(shí)質(zhì)是推導(dǎo)出誰(shuí)是用戶，他們的旅程和功能等要求是什么？產(chǎn)出給下游的內(nèi)容主要包括：

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

為什么需要梳理數(shù)據(jù)和模型，可能這就是智能解決方案的不同吧！但本質(zhì)上，都是在梳理用戶、旅程、功能而已，只是智能解決方案交付的軟件系統(tǒng)，是由軟件、數(shù)據(jù)、模型三類(lèi)交付件構(gòu)成的。

2. 功能分析  

通過(guò)旅程或流程，對(duì)系統(tǒng)的能力和功能提出了具體的需求。為了和更多的干系人對(duì)齊理解，并進(jìn)一步指導(dǎo)技術(shù)設(shè)計(jì)和交付計(jì)劃的制定，一定需要詳細(xì)的設(shè)計(jì)。在整體方案的詳細(xì)設(shè)計(jì)的產(chǎn)出一般指：      

• 交互體驗(yàn)設(shè)計(jì)：因?yàn)楹芏喔上等似鋵?shí)并不是軟件領(lǐng)域?qū)＜遥缬脩?，要理解最終交付的產(chǎn)物是什么，還是需要類(lèi)似建筑設(shè)計(jì)圖才能直觀的理解。而在企業(yè)內(nèi)，用戶往往就是出資方。
• 用戶故事地圖：有了交互體驗(yàn)設(shè)計(jì)，業(yè)務(wù)分析師就可以基于此分析出需要開(kāi)發(fā)的用戶故事，而后技術(shù)團(tuán)隊(duì)就可以基于此評(píng)估所需的資源和人力，幫助制定實(shí)施計(jì)劃。

交互體驗(yàn)設(shè)計(jì)就不舉例分析了，用戶故事地圖是比功能列表更細(xì)的分解，每一張故事卡更聚焦于用戶需求，可能是為實(shí)現(xiàn)某用戶需求而需要的一個(gè)按鈕。

用戶故事地圖舉例

3. 跨功能需求

當(dāng)然除了功能，還需要更多的信息才能更好的描述業(yè)務(wù)的要求。一些非功能性或跨功能性的要求，都可以在這一部分明確的提出來(lái)。比如在一個(gè)智能問(wèn)答系統(tǒng)中，用戶等待的時(shí)間不能超過(guò)15s，用戶等待第一個(gè)token的返回的時(shí)間不超過(guò)5s等要求。

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

4. 功能架構(gòu)

整體方案是通過(guò)分析用戶和旅程，推導(dǎo)出能力需求的過(guò)程，而交互設(shè)計(jì)和用戶故事地圖是對(duì)功能進(jìn)一步的明確。最終我們可以將功能繪制成一張功能架構(gòu)圖，來(lái)向更多人呈現(xiàn)我們解決方案提供的各子產(chǎn)品或模塊包含的功能。功能架構(gòu)可以是一張思維導(dǎo)圖，也可以是一張由不同模塊組成的架構(gòu)圖。

通過(guò)思維導(dǎo)圖描述的產(chǎn)品功能架構(gòu)

常見(jiàn)產(chǎn)品功能架構(gòu)示意圖

功能架構(gòu)是對(duì)這整個(gè)部分的總結(jié)，是否需要對(duì)功能架構(gòu)進(jìn)行梳理，主要取決于項(xiàng)目功能是否龐雜，它可以很好的幫助項(xiàng)目組成員快速認(rèn)識(shí)產(chǎn)品或解決方案。它的另一個(gè)作用還可用于驗(yàn)證技術(shù)方案的完整性。不同功能點(diǎn)所需的技術(shù)方案不同，如果技術(shù)方案和功能點(diǎn)都能夠映射起來(lái)，那么技術(shù)方案基本上也很全面了。

四、技術(shù)方案

整體方案梳理的用戶、旅程和功能，是技術(shù)設(shè)計(jì)工作的重要輸入。如果從4+1視圖來(lái)看，需要完成邏輯架構(gòu)、運(yùn)行架構(gòu)、實(shí)現(xiàn)架構(gòu)和部署架構(gòu)，但如果不是實(shí)施過(guò)很多遍的成熟方案，是很難在方案設(shè)計(jì)階段就產(chǎn)出翔實(shí)準(zhǔn)確的實(shí)現(xiàn)架構(gòu)和部署架構(gòu)的。

于是，仍然要思考為什么要做技術(shù)方案設(shè)計(jì)？主要有兩部分原因：          

• 對(duì)齊功能，進(jìn)一步說(shuō)明技術(shù)上的可行性；
• 作為交付團(tuán)隊(duì)進(jìn)行詳細(xì)設(shè)計(jì)的輸入，用于分析成本投入并制定實(shí)施計(jì)劃（可能會(huì)新增很多技術(shù)卡）。

1. 架構(gòu)設(shè)計(jì)的內(nèi)容

所以并不是要按照4+1視圖完成設(shè)計(jì)之后再進(jìn)入交付，可以根據(jù)目的靈活處置，指導(dǎo)實(shí)施的技術(shù)方案包括：

• 邏輯架構(gòu)：描述各架構(gòu)元素之間的邏輯關(guān)系。
• 數(shù)據(jù)架構(gòu)（可選）：描述數(shù)據(jù)模型設(shè)計(jì)，以及所需的技術(shù)。
• 集成方案（可選）：是指導(dǎo)部署架構(gòu)逐步完善的指導(dǎo)。
• 運(yùn)行架構(gòu)（可選）：說(shuō)明系統(tǒng)間集成或者內(nèi)部關(guān)鍵技術(shù)組件運(yùn)行過(guò)程等，作為技術(shù)方案可行性判斷的補(bǔ)充說(shuō)明。
• 技術(shù)架構(gòu)：推薦的技術(shù)棧選型，包括軟件、數(shù)據(jù)、AI的各類(lèi)技術(shù)棧。
• 部署架構(gòu)（可選）：說(shuō)明技術(shù)方案在成本、可用性、可擴(kuò)展性、網(wǎng)絡(luò)安全等方面的設(shè)計(jì)。
• 持續(xù)集成（可選）：構(gòu)建、測(cè)試、發(fā)布、運(yùn)維的過(guò)程設(shè)計(jì)和技術(shù)選型。

2. 架構(gòu)設(shè)計(jì)的思路

架構(gòu)和技術(shù)選型可以參考行業(yè)內(nèi)最佳實(shí)踐如：

• 單體架構(gòu)：如果系統(tǒng)的標(biāo)準(zhǔn)化程度很高，單體架構(gòu)其實(shí)也是合理的選擇。
• 面向服務(wù)的架構(gòu)：采用SOA或微服務(wù)架構(gòu)設(shè)計(jì)思路。
• 事件驅(qū)動(dòng)的架構(gòu)：以及基于Event Sourcing & CQRS設(shè)計(jì)的微服務(wù)架構(gòu)。
• Severless架構(gòu)：適合專(zhuān)注業(yè)務(wù)功能的快速迭代的輕量級(jí)應(yīng)用系統(tǒng)的架構(gòu)。
• 數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)：數(shù)倉(cāng)設(shè)計(jì)的貼源層、數(shù)倉(cāng)層、集市層。
• 數(shù)據(jù)中臺(tái)架構(gòu)：One Data、One Service、One ID。
• 其他數(shù)據(jù)架構(gòu)：Data Mesh、Data Fabric。
• AI模型或算法：可以根據(jù)實(shí)驗(yàn)結(jié)果或行業(yè)橫向測(cè)評(píng)結(jié)果進(jìn)行選型。

架構(gòu)設(shè)計(jì)思路可能僅供參考，而不是方案設(shè)計(jì)的主要內(nèi)容。但只有結(jié)果而沒(méi)有技術(shù)方案建模的 過(guò)程，不足以體現(xiàn)出設(shè)計(jì)的合理性，可參考常見(jiàn)的設(shè)計(jì)方法：

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

雖然有很多實(shí)踐和方法可以指導(dǎo)我們開(kāi)展技術(shù)設(shè)計(jì)，但需要經(jīng)常自省的是，技術(shù)部分的設(shè)計(jì)最終還是為了分析可行性、指導(dǎo)交付團(tuán)隊(duì)并制定實(shí)施計(jì)劃。完全可以迭代完善設(shè)計(jì)，靈活控制設(shè)計(jì)投入。

注：注意遵從企業(yè)和組織要求的IaaS、PaaS、SaaS等高階的分層設(shè)計(jì)原則和技術(shù)管理要求。過(guò)程中可能需要和團(tuán)隊(duì)或企業(yè)的總架構(gòu)師對(duì)齊整體規(guī)劃。

五、實(shí)施計(jì)劃

這一部分的目標(biāo)就是制定清晰的計(jì)劃。但有了功能和技術(shù)方案，就可以評(píng)估交付計(jì)劃了嗎？理想很美好，現(xiàn)實(shí)往往存在各種各樣的問(wèn)題，導(dǎo)致很難制定一個(gè)清晰的可執(zhí)行的計(jì)劃。即便已經(jīng)進(jìn)入實(shí)施階段，有些解決方案仍然是基于某些關(guān)鍵假設(shè)來(lái)設(shè)計(jì)的。

1. 風(fēng)險(xiǎn)/假設(shè)/問(wèn)題/依賴(lài)

在開(kāi)始做計(jì)劃之前，可以先了解一下這個(gè)項(xiàng)目管理工具，將已知的風(fēng)險(xiǎn)、假設(shè)、問(wèn)題和依賴(lài)都寫(xiě)下來(lái)。

• 風(fēng)險(xiǎn)：可能對(duì)達(dá)成目標(biāo)產(chǎn)生負(fù)面影響的事情。
• 假設(shè)：沒(méi)有確定，但假設(shè)為真的，對(duì)項(xiàng)目目標(biāo)會(huì)產(chǎn)生影響的條件或事情。
• 問(wèn)題：正在對(duì)達(dá)成目標(biāo)產(chǎn)生負(fù)面影響的事情。
• 依賴(lài)：達(dá)成目標(biāo)所依賴(lài)的外部因素或條件。

在完善方案輸出時(shí)，不同類(lèi)型的具體事項(xiàng)，可以采取不同的應(yīng)對(duì)措施，并不斷的更新?tīng)顟B(tài)。例如：

存在問(wèn)題其實(shí)不用擔(dān)心，問(wèn)題不透明才是最要命的，通過(guò)提高透明度，能更好的促進(jìn)協(xié)作，提高效率。

2. 路線圖

回到開(kāi)頭提出的問(wèn)題：“完全沒(méi)有辦法確定交付時(shí)間，怎么寫(xiě)的出來(lái)演進(jìn)路線？”

現(xiàn)實(shí)中是一定會(huì)存在風(fēng)險(xiǎn)和問(wèn)題的。在制定演進(jìn)路線時(shí)候，可以先劃定階段或關(guān)鍵里程碑，而不是直接設(shè)定時(shí)間。確定里程碑沒(méi)有固定的方法，這需要結(jié)合具體的情況分析。主要來(lái)說(shuō)還是對(duì)關(guān)鍵子任務(wù)的分解，以及子任務(wù)之間的依賴(lài)關(guān)系的梳理。

當(dāng)然并不是說(shuō)路線圖一定就沒(méi)有時(shí)間了，只能說(shuō)時(shí)間估算是一個(gè)逐步清晰的過(guò)程。需要足夠清晰的任務(wù)分解和依賴(lài)關(guān)系分析，以及對(duì)任務(wù)復(fù)雜度和工作量的評(píng)估，才能最終得到準(zhǔn)確的實(shí)施計(jì)劃。

如果馬上就要開(kāi)始交付了，那么就需要評(píng)估工作量。這時(shí)候，有很多團(tuán)隊(duì)通過(guò)故事卡估點(diǎn)的方式來(lái)評(píng)估所需的資源并制定發(fā)布計(jì)劃。

六、方案發(fā)展的階段  

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

如果是由技術(shù)驅(qū)動(dòng)的創(chuàng)新性項(xiàng)目，它的發(fā)展一般會(huì)經(jīng)歷幾個(gè)階段：

• 概念驗(yàn)證：在概念驗(yàn)證階段，方案主要關(guān)注可行性的驗(yàn)證，不需要過(guò)多的關(guān)注體驗(yàn)，功能點(diǎn)也非常的簡(jiǎn)單，因?yàn)榭赡芏紱](méi)有真實(shí)的用戶。運(yùn)維運(yùn)營(yíng)管理基本上很少考慮。因?yàn)榭尚行远歼€沒(méi)有被驗(yàn)證，過(guò)渡設(shè)計(jì)就是浪費(fèi)。
• 價(jià)值驗(yàn)證：為了驗(yàn)證解決方案的業(yè)務(wù)價(jià)值，需要真實(shí)的用戶參與。這時(shí)也需要考慮體驗(yàn)問(wèn)題和系統(tǒng)集成等問(wèn)題。解決方案內(nèi)容就必須要包含旅程（流程）、功能等，而且因?yàn)檎鎸?shí)用戶使用過(guò)程的行為數(shù)據(jù)也需要考慮收集，運(yùn)營(yíng)相關(guān)的功能也需考慮是否包含。
• 持續(xù)運(yùn)營(yíng)：當(dāng)價(jià)值被驗(yàn)證之后，為了推動(dòng)到更大的范圍，需要考慮支撐規(guī)?；璧哪芰?，再規(guī)劃相應(yīng)的工具或平臺(tái)的開(kāi)發(fā)計(jì)劃。這時(shí)需要分析提供某種服務(wù)的價(jià)值鏈，尋找優(yōu)化運(yùn)營(yíng)的機(jī)會(huì)點(diǎn)，強(qiáng)調(diào)怎么把服務(wù)做好，成本控制好。因此運(yùn)營(yíng)推廣和協(xié)作的功能就是這一階段設(shè)計(jì)的重點(diǎn)。

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

以上就是所有和方案內(nèi)容有關(guān)的分享了，希望能夠?qū)Υ蠹矣兴鶈l(fā)。