如何寫好項目規劃和方案設計文檔 (轉)

在工做中，不少時候，咱們都須要就一個問題提出一個解決方案，這時候，咱們極可能須要產出一個文檔來供你們討論，並指導下一步工做計劃。

問題可大可小，形式上是否叫它爲一個項目並不重要，重要的是爲了解決這個問題，項目規劃和方案設計的流程是一致的。就大數據平臺構建的語言環境來講，它能夠是整個平臺體系的搭建方案，也能夠是具體某個組件如調度系統的建設，還能夠是某個具體的功能點或問題改進好比用戶任務腳本的依賴關係分析，系統穩定性的提高等等。

一篇項目規劃和設計文檔的好壞，每每決定了一個項目總體的調性和可預期的產出結果。可是，這麼重要的文檔，真正能寫好的同窗卻並很少，不少同窗甚至可能都沒有意識到它的重要性，而僅僅是把它看成領導要求的一個軟件流程的規範來簡單應付，怎麼快怎麼來。

事實上，撰寫項目規劃和設計文檔，最重要的不是文檔的模版和格式，而是裏面的具體內容，它每每須要結合實際客觀環境因素來綜合考慮，平衡取捨，是一個須要充分腦力活動的工做。儘管如此，在大多數狀況下，仍是有一些相對通用的指導原則能夠幫助咱們更好的完成這項工做。

本文側重於方案的需求分析到概要設計部分，由於這部份內容一般是最容易被你們忽視，也最須要方法論和「端正的思想」來指導的 ；）而詳細設計相關內容，考驗更多的是技術的深度，以及如何作到全面周到，我計劃在後續文章中另行闡述。

整體原則和目標：

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

方案規劃設計文檔的好壞，幾乎徹底取決於這一部份內容。但多數同窗在這一部份內容身上，每每花費的時間倒是最少的，常見的方式，就是「直奔主題」，上來就寫具體要作的事

項目背景和目標

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

Why？爲何要在這個時候作這個項目？

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

有痛點天然就有目標，你但願項目最終以什麼方式解決問題，能達成什麼目標。

背景和目標的闡述，必需要可以天然合理的推導出下一部份內容：項目的核心需求/功能是什麼。

若是項目背景，目標的描述不能起到這個做用，那這一節內容就沒寫好，由於項目方案文檔就缺少了根本的出發點，後續的內容都沒有了好壞對錯判斷的基本依據。

項目核心需求

項目核心需求和項目目標有什麼區別？實際上沒有嚴格的區別，只是對須要解決的問題的歸納抽象程度的不一樣，或者描述角度的不一樣。

目標能夠理解爲但願達到的一個狀態，是抽象的，和技術方案無關的偏結果角度的表述方式。

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

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

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

講完區別，繼續回來說，這部份內容的要求。不少同窗在寫這部分方案的時候，很容易把需求和實現手段混爲一談。因此：

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

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

在完整的項目文檔中，顯然目標和手段都須要，可是

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

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

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

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

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

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

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

不過，從方案文檔的角度來講，放在這裏，是爲了進一步細化問題，分析目標，核心需求與當前現狀的差距在哪裏，具體有哪些實際問題須要解決。爲後續具體的實現方案，準備必要的輸入信息，肯定工做的優先級，重要性，項目迭代的步驟等等。

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

這塊內容自己沒有太特別的地方，就是如今實際狀況如何，有什麼問題，關鍵是如何把問題收集完整。

因此這部份內容，難的是如何發現問題，不少作技術的同窗每每容易陷入只關心技術難點，只能看到技術問題的局面中，而實際上，更多的問題每每是總體流程如何設計更加合理的問題，而不是技術方案絕對對錯的問題。

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

最後，是輸出解決方案

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

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

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

作什麼：

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

怎麼作：

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

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

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

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

這個內容要寫具體的要作的事項。如下方式來寫可能就是不合格的，由於不夠具體，尚未足夠思考：

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

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

• 統一當前增量數據導入的存儲，合併，歸檔方案
• 將常見合併，去重邏輯標準化，經過配置自動生成任務腳本
• 制定ODS快照表生命週期管理方案，規範存儲路徑和命名方式，按期清理過時數據。

何時作，誰來作：

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

若是不是工期嚴格要求，deadline爲導向的項目，總體的依賴和步驟每每纔是在項目規劃階段須要重點闡述的內容，也是有可能對總體產品的進度，風險產生影響的事項

而具體工做工期的安排，說實話，多數狀況下，反到沒有那麼重要。若是總體工做和步調沒考慮周全，工期排得再科學，再精細，也毫無心義。

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

小結

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

它很像一個議論文體裁，事實，分析，結論缺一不可。因此，不管你的方案文檔寫的多麼翔實，若是隻是相關內容細節的羅列，只議不論，缺少抽象總結，還須要閱讀文檔的同窗再去揣摩項目意圖，或者看完之後對項目所要作的工做爲何要作，重不重要，要作成什麼樣都不明確的話。那它就只是一個不合格的半成品，不能對後續的項目開發工做發揮實質的指導和規劃做用。

結論列表

上面花了大量篇幅展開討論，目的是說服你接受個人見解。

若是你只須要明確的結論，那麼再總結一下：

整體原則：

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

再細化到一些注意事項：

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

兩條輔助判斷依據：

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

提示

寫項目方案文檔，不是八股文，因此本文的內容並不是絕對的教條，你固然能夠根據項目的實際狀況和複雜程度自行調整，但前提是你真的知道你爲何要這麼作，而不只僅是爲了偷懶

本文多數內容是各類觀點，注意事項，結論和目標，具體如何作到這些，每一個同窗均可以自行思考。固然除了思想和目標端正，每一個環節，其實也有一些具體Tips和checklist可供參考。