問題可大可小，形式上是否叫它為乙個專案並不重要，重要的是為了解決這個問題，專案規劃和方案設計的流程是一致的。就大資料平台構建的語言環境來說，它可以是整個平台體系的搭建方案，也可以是具體某個元件如排程系統的建設，還可以是某個具體的功能點或問題改進比如使用者任務指令碼的依賴關係分析，系統穩定性的提公升等等。
一篇專案規劃和設計文件的好壞，往往決定了乙個專案整體的調性和可預期的產出結果。但是，這麼重要的文件，真正能寫好的同學卻並不多，很多同學甚至可能都沒有意識到它的重要性，而僅僅是把它當作領導要求的乙個軟體流程的規範來簡單應付，怎麼快怎麼來。
事實上，撰寫專案規劃和設計文件，最重要的不是文件的模版和格式，而是裡面的具體內容，它往往需要結合實際客觀環境因素來綜合考慮，平衡取捨，是乙個需要充分腦力活動的工作。儘管如此，在大多數情況下，還是有一些相對通用的指導原則可以幫助我們更好的完成這項工作。
方案規劃設計文件的好壞，幾乎完全取決於這一部分內容。但多數同學在這一部分內容身上，往往花費的時間卻是最少的，常見的方式，就是「直奔主題」，上來就寫具體要做的事
專案背景不是讓你寫一堆無關痛癢的鋪墊材料。實際上，專案背景的作用是：
why？為什麼要在這個時候做這個專案？
換句話說，就是這個專案從產品或業務的角度，最核心的推動力是什麼？再換句話說，痛點是什麼？
有痛點自然就有目標，你希望專案最終以什麼方式解決問題，能達成什麼目標。
如果專案背景，目標的描述不能起到這個作用，那這一節內容就沒寫好，因為專案方案文件就缺乏了根本的出發點，後續的內容都沒有了好壞對錯判斷的基本依據。
專案核心需求和專案目標有什麼區別？實際上沒有嚴格的區別，只是對需要解決的問題的概括抽象程度的不同，或者描述角度的不同。
目標可以理解為希望達到的乙個狀態，是抽象的，和技術方案無關的偏結果角度的表述方式。
而專案核心需求，可以理解為了解決背景描述的問題，為了實現那幾個目標，進一步推導出來的，在當前系統環境或方案框架體系中：必須要提供的產品功能形態，或者是必須滿足的關鍵特性，又或著是不能違背的約束條件。你也可以理解為用更技術的語言進行細化描述的專案目標。因為目標和背景的不同，可能同一件事推導出來的核心需求也不同。
這麼說比較抽象。舉個例子，如果我想構建乙個資料交換服務或etl系統，那麼上述各環節的內容可能是（簡化的寫）：
講完區別，繼續回來講，這部分內容的要求。很多同學在寫這部分方案的時候，很容易把需求和實現手段混為一談。所以：
核心需求的重點是：本質上需要提供什麼能力，而不是具體實現上要做什麼
換個角度說，核心需求的描述方式是：要做成什麼樣，是功能目標而不是實現手段。
在完整的專案文件中，顯然目標和手段都需要，但是
目標必須先於手段，而非相反
原因也很簡單，脫離了目標談手段是沒有意義的，很容易導致方向做偏，使得最終的結果產出背離了專案最初真正的需求出發點。
實踐中，做成什麼樣和怎麼做有時候很難絕對分開。一句話的描述方式可能既包含了目標需求也包含了實現手段。那麼，怎麼判斷這部分內容寫得是否滿足要求呢。
總結一下，核心需求的根本目標是，讓參與專案的同學有方向感，能夠知道這個專案最終想要通過提供哪些能力，滿足哪些約束條件來解決問題，至於怎麼實現，具體要做哪些事，那是下一步才需要回答的問題，簡單來說：先選擇做正確的事，再考慮怎麼把事做正確。
這一部分內容，從實際操作的先後順序來說，未必是第二步，很可能在我們總結前面的背景，目標，核心區需求的時候，就需要加以收集和分析。
不過，從方案文件的角度來說，放在這裡，是為了進一步細化問題，分析目標，核心需求與當前現狀的差距在**，具體有哪些實際問題需要解決。為後續具體的實現方案，準備必要的輸入資訊，確定工作的優先順序，重要性，專案迭代的步驟等等。
需要強調的是，現狀和問題分析，要圍繞前面的核心需求的條目展開，兩者是強關聯的，不要相互脫節，各講各的
這塊內容本身沒有太特別的地方，就是現在實際情況如何，有什麼問題，關鍵是如何把問題收集完整。
所以這部分內容，難的是如何發現問題，很多做技術的同學往往容易陷入只關心技術難點，只能看到技術問題的局面中，而實際上，更多的問題往往是整體流程如何設計更加合理的問題，而不是技術方案絕對對錯的問題。
儘管行文上不難，但它的重要性，也往往容易被忽略，很多情況下被簡單對待。實際的情況是，很多專案的方案計畫往往是在對現狀問題相關資訊沒有充分收集和分析的基礎上就做出來的。導致專案方案後期不斷調整，或者一期一期的總是在小步迭代，甚至不斷推翻重來。而最終使用方真正關心的問題卻一直沒有得到重視和解決。
定完需求目標，分析完問題和現狀，接下來才是規劃具體做什麼，怎麼做，什麼時候做。
這部分內容，強依託前面的核心需求和問題分析工作，沒有做好前面的準備工作，千萬不要著急開始動手「規劃」方案！！！
那麼具體寫的時候有哪些注意事項呢？
再強調一下，做什麼和怎麼做就是手段，既然是手段，就要寫得足夠具體，具體到有明確的可落地實施的事情，有明確可以衡量的標準，或者針對當前存在的乙個具體問題，不要在這個地方又寫得像目標，沒有明確的可執行的點。
繼續舉上文資料交換服務的例子，針對其中的乙個核心需求：
這個內容要寫具體的要做的事項。以下方式來寫可能就是不合格的，因為不夠具體，還沒有足夠思考：
以下內容可能就更加明確，更加可落地一些：
如果不是工期嚴格要求，deadline為導向的專案，整體的依賴和步驟往往才是在專案規劃階段需要重點闡述的內容，也是有可能對整體產品的進度，風險產生影響的事項
而具體工作工期的安排，說實話，多數情況下，反到沒有那麼重要。如果整體工作和步調沒考慮周全，工期排得再科學，再精細，也毫無意義。
總結一下，什麼時候做什麼事，最重要的目的，不在於工期的計算，甚至也不是人力資源的安排，而是為了理順事情依賴關係，控制可能的意外風險，提公升專案開發進度的可控性。
方案規劃設計文件，絕對不是為了滿足流程需要湊數的文件，也不是頭腦風暴式的簡單記錄。它的根本目標，抽象來說是：明確問題，圈定範圍，確定重點，闡明路徑。本質是為了統一認識，控制風險。它應該是乙個問題經過思考以後的輸出的答案，而不是問題的調查報告，筆記或備忘錄。
上面花了大量篇幅展開討論，目的是說服你接受我的看法。
如果你只需要明確的結論，那麼再總結一下：
總體原則：
再細化到一些注意事項：
兩條輔助判斷依據：
寫專案方案文件，不是八股文，所以本文的內容並非絕對的教條，你當然可以根據專案的實際情況和複雜程度自行調整，但前提是你真的知道你為什麼要這麼做，而不僅僅是為了偷懶
京東，**，中亞有售，jd購買鏈結 ： ；）
如何寫專案設計方案
如何寫安防監控工程設計方案書 其他專案也適用 乙份成功安防監控工程設計方案是贏得單子的重要砝碼，如何寫乙份令客戶心動的安防監控工程設計方案則需要下苦功夫。監控系統是屬於弱電系統中的一種安防範系統，它集微機自動識別技術和現代安全管理措施為一體，是一種先進的 防範能力極強的綜合系統，它可以通過遙控攝像機...
如何寫好軟體專案的工作計畫（一）
寫專案計畫是乙個非常考驗專案經理工作能力的工作，既包括了專案的客觀規律，也是在拼專案經理的工作經驗。這個行業門檻低，大家都可以學習了pmp或者prince2以後，嘗試一把去管專案，但是管的好不好，成功不成功，這個真的就是仁者見仁智者見智的事情。寫專案計畫是個技術活，可能真的沒有你想的那麼容易。因為專...
如何寫專案方案 從資料準備到書寫技巧
在工作中，除了技術工作之外，我們也經常需要寫一些專案的方案，當然如果公司比較大，崗位分工比較細，可能不存在這個問題。如果公司規模不大，比如我們公司，人不多，就要把自己鍛鍊成全面手，寫方案是乙個不可或缺的工作內容。以下是我在公司裡面寫技術方案的一些體會，希望對大家有幫助。一般我們寫方案，比如專案申請方...