在工作中，很多時候，我們都需要就一個問題提出一個解決方案，這時候，我們很可能需要產出一個文件來供大家討論，並指導下一步工作計劃。

問題可大可小，形式上是否叫它為一個專案並不重要，重要的是為了解決這個問題，專案規劃和方案設計的流程是一致的。就大資料平臺構建的語言環境來說，它可以是整個平臺體系的搭建方案，也可以是具體某個元件如排程系統的建設，還可以是某個具體的功能點或問題改進比如使用者任務指令碼的依賴關係分析，系統穩定性的提升等等。

一篇專案規劃和設計文件的好壞，往往決定了一個專案整體的調性和可預期的產出結果。但是，這麼重要的文件，真正能寫好的同學卻並不多，很多同學甚至可能都沒有意識到它的重要性，而僅僅是把它當作領導要求的一個軟體流程的規範來簡單應付，怎麼快怎麼來。

事實上，撰寫專案規劃和設計文件，最重要的不是文件的模版和格式，而是裡面的具體內容，它往往需要結合實際客觀環境因素來綜合考慮，平衡取捨，是一個需要充分腦力活動的工作。儘管如此，在大多數情況下，還是有一些相對通用的指導原則可以幫助我們更好的完成這項工作。

本文側重於方案的需求分析到概要設計部分，因為這部分內容通常是最容易被大家忽視，也最需要方法論和“端正的思想”來指導的 ；）而詳細設計相關內容，考驗更多的是技術的深度，以及如何做到全面周到，我計劃在後續文章中另行闡述。

總體原則和目標：

首先，需要有明確專案背景，目標，以及核心需求分析

方案規劃設計文件的好壞，幾乎完全取決於這一部分內容。但多數同學在這一部分內容身上，往往花費的時間卻是最少的，常見的方式，就是“直奔主題”，上來就寫具體要做的事

專案背景和目標

專案背景不是讓你寫一堆無關痛癢的鋪墊材料。實際上，專案背景的作用是：

Why？為什麼要在這個時候做這個專案？

換句話說，就是這個專案從產品或業務的角度，最核心的推動力是什麼？再換句話說，痛點是什麼？

有痛點自然就有目標，你希望專案最終以什麼方式解決問題，能達成什麼目標。

背景和目標的闡述，必須要能夠自然合理的推匯出下一部分內容：專案的核心需求/功能是什麼。

如果專案背景，目標的描述不能起到這個作用，那這一節內容就沒寫好，因為專案方案文件就缺乏了根本的出發點，後續的內容都沒有了好壞對錯判斷的基本依據。

專案核心需求

專案核心需求和專案目標有什麼區別？實際上沒有嚴格的區別，只是對需要解決的問題的概括抽象程度的不同，或者描述角度的不同。

目標可以理解為希望達到的一個狀態，是抽象的，和技術方案無關的偏結果角度的表述方式。

而專案核心需求，可以理解為了解決背景描述的問題，為了實現那幾個目標，進一步推匯出來的，在當前系統環境或方案框架體系中：必須要提供的產品功能形態，或者是必須滿足的關鍵特性，又或著是不能違背的約束條件。你也可以理解為用更技術的語言進行細化描述的專案目標。因為目標和背景的不同，可能同一件事推匯出來的核心需求也不同。

這麼說比較抽象。舉個例子，如果我想構建一個數據交換服務或ETL系統，那麼上述各環節的內容可能是（簡化的寫）：

• 背景 ： 當前資料ETL鏈路極端難用，效率低下，穩定性差，維護代價高，使用者抱怨多等等。
• 目標 ： 使用者全自助，簡單易用；可維護性好；效能高；可靠性好。
• 核心需求 ：比如針對“使用者全自助，簡單易用”這點（其它目標可以類似分析推理），可能是：
  • 提供統一的，標準化的配置後臺：用配置的形式表達ETL業務語意，遮蔽下層實現細節。
  • 提供完善的錯誤反饋資訊/機制：讓使用者能自助解決使用中遇到的問題。
  • ETL業務流程標準化：將最佳實踐沉澱下來，通過配置的方式讓使用者選擇，減少重複工作，降低使用者開發的難度，規避使用姿勢錯誤可能造成的問題。

講完區別，繼續回來講，這部分內容的要求。很多同學在寫這部分方案的時候，很容易把需求和實現手段混為一談。所以：

核心需求的重點是：本質上需要提供什麼能力，而不是具體實現上要做什麼

換個角度說，核心需求的描述方式是：要做成什麼樣，是功能目標而不是實現手段。

在完整的專案文件中，顯然目標和手段都需要，但是

目標必須先於手段，而非相反

原因也很簡單，脫離了目標談手段是沒有意義的，很容易導致方向做偏，使得最終的結果產出背離了專案最初真正的需求出發點。

實踐中，做成什麼樣和怎麼做有時候很難絕對分開。一句話的描述方式可能既包含了目標需求也包含了實現手段。那麼，怎麼判斷這部分內容寫得是否滿足要求呢。

• 如果你描述的側重點只是需求的一種實現方式，而這個需求可能還有更多的其它實現方式，或者即使真的只有一種實現方式，你所描述的內容的也只是因果關係中，間接的因而非直接的果，那麼很可能你描述的就只是手段而非目標。
• 如果看文件的同學看完只知道你要做什麼，而不知道做這些是為了什麼？是否做這些就足夠了，還應該做點別的？是否有別的解決方案，又或者做完了到底有什麼用。那麼也很可能是因為你把需求和實現手段混為一談了。
• 核心需求必須是本質的，一定要實現的功能，它是一個原則，不是工作列表。不要事無鉅細，凡是想做的都列在上面，那樣反而淡化了專案最根本的訴求。但它也必須足夠全面，要能確實解決專案目標中所提出的要求，應該用適當抽象的語言概括一個完整的事項。

總結一下，核心需求的根本目標是，讓參與專案的同學有方向感，能夠知道這個專案最終想要通過提供哪些能力，滿足哪些約束條件來解決問題，至於怎麼實現，具體要做哪些事，那是下一步才需要回答的問題，簡單來說：先選擇做正確的事，再考慮怎麼把事做正確。

其次，需要對現狀和問題進行充分的收集和分析

這一部分內容，從實際操作的先後順序來說，未必是第二步，很可能在我們總結前面的背景，目標，核心區需求的時候，就需要加以收集和分析。

不過，從方案文件的角度來說，放在這裡，是為了進一步細化問題，分析目標，核心需求與當前現狀的差距在哪裡，具體有哪些實際問題需要解決。為後續具體的實現方案，準備必要的輸入資訊，確定工作的優先順序，重要性，專案迭代的步驟等等。

需要強調的是，現狀和問題分析，要圍繞前面的核心需求的條目展開，兩者是強關聯的，不要相互脫節，各講各的

這塊內容本身沒有太特別的地方，就是現在實際情況如何，有什麼問題，關鍵是如何把問題收集完整。

所以這部分內容，難的是如何發現問題，很多做技術的同學往往容易陷入只關心技術難點，只能看到技術問題的局面中，而實際上，更多的問題往往是整體流程如何設計更加合理的問題，而不是技術方案絕對對錯的問題。

儘管行文上不難，但它的重要性，也往往容易被忽略，很多情況下被簡單對待。實際的情況是，很多專案的方案計劃往往是在對現狀問題相關資訊沒有充分收集和分析的基礎上就做出來的。導致專案方案後期不斷調整，或者一期一期的總是在小步迭代，甚至不斷推翻重來。而最終使用方真正關心的問題卻一直沒有得到重視和解決。

最後，是輸出解決方案

定完需求目標，分析完問題和現狀，接下來才是規劃具體做什麼，怎麼做，什麼時候做。

這部分內容，強依託前面的核心需求和問題分析工作，沒有做好前面的準備工作，千萬不要著急開始動手“規劃”方案！！！

那麼具體寫的時候有哪些注意事項呢？

做什麼：

• 做什麼和前面專案目標的要求剛好皆然相反，需要輸出明確的可執行的事項，而不是模糊的不可執行的要求。
• 具體做的每一件事情，都要和前面的核心需求和現狀問題對應上。如果你發現有些工作，和前面的目標沒有任何關聯性，那麼考慮一下目標是否需要再評估調整，或者這件事情根本就是不重要的。
• 要做的事項列表，是一個經過歸納思考以後的總結，而不只是一個個零散的事情的隨機列表。需要有重點和優先順序。如果有必要，以歸類，分組等形式結構化的組織相關聯的事項。
• 完整的事項列表，應該是一個和最終目標對應的完整解決方案，而不僅僅只是完成目標工作中的某一個環節。
  • 比如面向使用者的終端產品專案，需要包括整個產品的互動邏輯，業務流程的規範設計等等，而不僅僅是對底層系統實現和後臺功能點的設計。
  • 這點很多同學也很容易忽略，總覺得功能和架構的實現才是有挑戰，需要規劃的內容，而產品的形態並沒有花心思去琢磨，事後開發前端時才來考慮。實際上後者可能才是真正影響專案成功的關鍵，也很可能會影響到底層架構的設計和取捨。類比一下，好比一個使用者產品都開發完了，才來考慮埋點，資料採集和資料分析的工作，這時候就很被動了。

怎麼做：

• 前期方案文件，沒有必要列出詳細的技術方案細節，只需要一個整體的技術方向選型和初步的架構設想。但是，如果是涉及到核心需求能否有效滿足的關鍵的技術點，有可能影響整體的架構或產品實現的，那就有必要就可能的方案的進行詳細的評估並得出初步的結論。
• 無關架構或進度安排的方案細節，沒有必要寫太多，可以後續再補充。
• 方案中有不明確的地方，即使沒有時間調研，也不要簡單的略過不寫，要在文件中明確的把問題寫出來，給出下一步調研的方向計劃等。歸根到底，方案文件中，對每一個已知重要的問題，都需要一個明確的結論或者可以後續跟進的計劃，以免事後遺漏。

再強調一下，做什麼和怎麼做就是手段，既然是手段，就要寫得足夠具體，具體到有明確的可落地實施的事情，有明確可以衡量的標準，或者針對當前存在的一個具體問題，不要在這個地方又寫得像目標，沒有明確的可執行的點。

繼續舉上文資料交換服務的例子，針對其中的一個核心需求：

• ETL業務流程標準化：將最佳實踐沉澱下來，通過配置的方式讓使用者選擇，減少重複工作，降低使用者開發的難度，規避使用姿勢錯誤可能造成的問題。

這個內容要寫具體的要做的事項。以下方式來寫可能就是不合格的，因為不夠具體，還沒有足夠思考：

• 總結最佳實踐
• 生成標準的流程
• 總結常見的錯誤

以下內容可能就更加明確，更加可落地一些：

• 統一當前增量資料匯入的儲存，合併，歸檔方案
• 將常見合併，去重邏輯標準化，通過配置自動生成任務指令碼
• 制定ODS快照表生命週期管理方案，規範儲存路徑和命名方式，定期清理過期資料。

什麼時候做，誰來做：

• 這是做什麼和怎麼做的進一步延伸，需要強調的是整個專案如何實施的整體步驟計劃，而不僅僅是簡單的列一下每項工作的人員和排期，
• 需要分析系統可能的迭代步驟（包括可能的短期應急和長期解決方案），上下游依賴梳理，需要協同進行的工作，最終專案上線時可能的業務遷移，資料遷移，系統整合等等外圍工作的安排。

如果不是工期嚴格要求，deadline為導向的專案，整體的依賴和步驟往往才是在專案規劃階段需要重點闡述的內容，也是有可能對整體產品的進度，風險產生影響的事項

而具體工作工期的安排，說實話，多數情況下，反到沒有那麼重要。如果整體工作和步調沒考慮周全，工期排得再科學，再精細，也毫無意義。

總結一下，什麼時候做什麼事，最重要的目的，不在於工期的計算，甚至也不是人力資源的安排，而是為了理順事情依賴關係，控制可能的意外風險，提升專案開發進度的可控性。

小結

方案規劃設計文件，絕對不是為了滿足流程需要湊數的文件，也不是頭腦風暴式的簡單記錄。它的根本目標，抽象來說是：明確問題，圈定範圍，確定重點，闡明路徑。本質是為了統一認識，控制風險。它應該是一個問題經過思考以後的輸出的答案，而不是問題的調查報告，筆記或備忘錄。

它很像一個議論文體裁，事實，分析，結論缺一不可。所以，無論你的方案文件寫的多麼翔實，如果只是相關內容細節的羅列，只議不論，缺乏抽象總結，還需要閱讀文件的同學再去揣摩專案意圖，或者看完以後對專案所要做的工作為什麼要做，重不重要，要做成什麼樣都不明確的話。那它就只是一個不合格的半成品，不能對後續的專案開發工作發揮實質的指導和規劃作用。

結論列表

上面花了大量篇幅展開討論，目的是說服你接受我的看法。

如果你只需要明確的結論，那麼再總結一下：

總體原則：

• 專案方案規劃文件的根本目標是統一認識：明確問題，確定重點，闡明路徑，控制風險。
• 文件的撰寫方式，是目標和需求先行，圍繞出發點，逐步遞進展開。
• 文件的基本要素：背景，目標，核心需求，現狀問題分析，關鍵方案難點解析，總體實施路徑，工作事項列表，進度計劃安排。

再細化到一些注意事項：

• 核心需求，必須是核心的,一定要實現的內容！不能缺，也不能濫。
• 問題現狀，工作事項，必須呼應核心需求，要有明確的相關性，不要無的放矢。
• 圍繞最終目標，輸出完整的端到端的解決方案，而不是區域性環節的方案。需要從最終產品/功能形態的角度考慮要做的事，而不是僅僅考慮底層技術實現。
• 事專案標列表，不要僅僅羅列要做什麼事，更重要的是說明想要得到的結果，而不僅僅是描述實現手段。
• 所有工作事項，需要明確思考過實施步驟，重要性和優先順序，結合目標和需求，進行抽象歸納，而非簡單隨機羅列。
• 要有明確的計劃排期，但更重要的是，要完整的分析思考可能的上下游和周邊工作依賴。排期只是結果，完整的梳理才是關鍵。

兩條輔助判斷依據：

• 如果開發同學看完文件，無法根據後續開發過程中遇到的實際情況，調整工作事項和優先順序，完善和改進這個文件，那麼大概率這個專案方案文件是沒有寫好的。因為這個文件可能只起到了事項羅列和工作安排的作用，卻沒有起到指導思考，授人予漁的作用
• 如果看完文件，這個專案的最終產出你無法預見，你對專案的目標最終能否實現無從判斷，那麼這個專案方案文件大概率也是沒有寫好的。因為這個文件自身的歸納總結可能還沒做到位，風險和問題可能還沒有評估清楚，還需要走一步看一步。

提示

寫專案方案文件，不是八股文，所以本文的內容並非絕對的教條，你當然可以根據專案的實際情況和複雜程度自行調整，但前提是你真的知道你為什麼要這麼做，而不僅僅是為了偷懶

本文多數內容是各種觀點，注意事項，結論和目標，具體如何做到這些，每個同學都可以自行思考。當然除了思想和目標端正，每個環節，其實也有一些具體Tips和checklist可供參考。下一次再說，下一次再說吧。。。

軟廣

本文寫的各項原則，在我們之前的專案實踐上實際都有體現，有興趣結合例項比對參考的同學，我再厚臉皮再推一下這本書 《大資料平臺基礎架構指南》

常按掃描下面的二維碼，關注“大資料務虛雜談”，務虛，我是認真的 ；）