作者 | 馮英睿

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

也可以理解為這類似于五看三定中的五看一定：看趨勢、看客戶市場、看競爭、看自己、看機會再加上定目標(biāo)?？偟膩碚f，這些分析都是為了推導(dǎo)出一個合理的，但可落地的目標(biāo)。

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

另外，很多解決方案架構(gòu)師會忽略啟動解決方案設(shè)計的背景。例如：本來是為了解決規(guī)?；膯栴}，但是因為解決方案設(shè)計師對工程效率并不了解，本來應(yīng)該用價值鏈分析找到改進(jìn)點，卻把重點放到了技術(shù)趨勢分析上，追求創(chuàng)新而忽視了效率。

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

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

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

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

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

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

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

二、問題分析

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

1. 問題分類

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

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

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

2. 解構(gòu)問題

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

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

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

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

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

3. 問題與方案

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

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

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

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

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

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

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

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

三、整體方案  

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

1. 用戶旅程

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

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

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

2. 功能分析  

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

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

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

用戶故事地圖舉例

3. 跨功能需求

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

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

4. 功能架構(gòu)

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

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

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

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

四、技術(shù)方案

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

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

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

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

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

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

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

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

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

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

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

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

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

五、實施計劃

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

1. 風(fēng)險/假設(shè)/問題/依賴

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

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

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

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

2. 路線圖

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

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

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

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

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

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

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

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

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

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