首先，要有明確的項目背景、目標和核心需求分析。
換句話說，從產品或者業務的角度來看，這個項目的核心驅動力是什麽？換句話說，痛點是什麽？
有痛點，自然就有目標。妳希望項目最終以什麽方式解決問題，能達到什麽目標？
背景和目標的闡述必須能夠自然合理地推導出下壹部分:項目的核心需求/功能是什麽。
如果項目背景和目標的描述不能起到這個作用，那麽這壹節的內容就沒有寫好，因為項目計劃文件缺乏根本的出發點，後續的內容沒有判斷好壞的基本依據。
比如我要搭建壹個數據交換服務或者ETL系統，那麽上面鏈接的內容可能是(簡寫):
背景:目前的數據ETL環節極難使用，效率低，穩定性差，維護成本高，用戶抱怨多。
目標:用戶自助，易用；良好的可維護性；高性能；可靠性好。
核心要求:比如對於“用戶自助、易用”這壹點(其他目標可以類似於分析推理)，可能是:
提供統壹規範的配置後臺:以配置的形式表達ETL業務語義，屏蔽底層實現細節。
提供完善的錯誤反饋信息/機制:讓用戶自己解決使用中遇到的問題。
ETL業務流程標準化:沈澱最佳實踐，讓用戶通過配置進行選擇，減少重復工作，降低用戶開發難度，避免姿勢錯誤可能帶來的問題。
其次，需要充分收集和分析現狀和問題。
從方案文件的角度來看，放在這裏是為了進壹步細化問題，分析目標、核心要求與目前現狀的差距，需要解決哪些實際問題。為後續的具體實施方案準備必要的輸入信息，確定工作的優先級和重要性，項目叠代的步驟等等。
需要強調的是，對現狀和問題的分析要圍繞前面核心要求的條目來進行。兩者有很強的關聯性，不要脫離彼此，各說各的。
最後，輸出解決方案。
設定需求目標，分析問題和現狀之後，接下來就是規劃做什麽，怎麽做，什麽時候做。
做什麽:
要做的事情正好與之前項目目標的要求相反，需要輸出明確的可執行項，而不是模糊的不可執行的要求。
妳具體做的每壹件事，都要對應核心需求和現狀。如果妳發現有些工作與之前的目標無關，那就考慮目標是否需要重新評估或調整，或者根本不重要。
要做的事情清單是歸納思考後的總結，而不僅僅是零散事情的隨機清單。需要有重點和優先級。如有必要，以分類、分組等形式組織相關事項。
壹個完整的事情清單應該是與最終目標相對應的完整解決方案，而不僅僅是目標工作中的壹個環節。
比如面向用戶的終端產品項目，需要包括整個產品的交互邏輯，業務流程的標準設計等。，而不僅僅是底層系統的實現和後臺功能點的設計。
很多同學也很容易忽略這壹點。他們總覺得功能和架構的實現才是需要規劃的內容，產品形態還沒想好，以後開發前端的時候再考慮。事實上，後者可能是項目成功的關鍵，也可能影響底層架構的設計和選擇。比如，當壹個用戶的產品已經開發出來了，再去考慮嵌入、數據采集、數據分析的工作，是非常被動的。
如何做:
在初步方案文件中，不需要列出詳細技術方案的細節，只需要壹個總體的技術方向選擇和初步的架構設想。但如果是關系到能否有效滿足核心需求的關鍵技術點，可能影響整體架構或產品實現，就要對可能的方案進行詳細評估，得出初步結論。
與架構或進度無關的方案細節就不需要寫太多了，可以以後再補充。
方案中有模棱兩可的地方。即使沒有時間去調查，也不要簡單的跳過。把問題寫清楚在文檔裏，給出下壹步調查的方向方案。歸根結底，對於方案文件中每壹個已知的重要問題，都需要壹個明確的結論或者壹個可以跟進的方案，避免事後遺漏。
還是那句話，做什麽，怎麽做才是手段。既然是手段，就要寫的足夠具體，這樣才有明確的事情可以執行，有明確的標準可以衡量，或者說對於目前存在的壹個具體問題，不要在這個地方寫的像目標壹樣，沒有明確的可執行點。
繼續以上面的數據交換服務為例，針對其中壹個核心需求:
ETL業務流程標準化:沈澱最佳實踐，讓用戶通過配置進行選擇，減少重復工作，降低用戶開發難度，避免姿勢錯誤可能帶來的問題。
這個內容要寫具體要做的事情。用以下方式寫可能不合格，因為不夠具體，沒有足夠的思考:
總結最佳實踐
生成標準的過程
總結常見錯誤
下面的內容可能更清楚，更實際:
統壹當前增量數據導入的存儲、合並和歸檔方案。
標準化通用合並和重復數據刪除邏輯，並通過配置自動生成任務腳本。
制定ODS快照表生命周期管理方案，規範存儲路徑和命名方式，定期清理過期數據。
何時由誰來做:
這是做什麽和怎麽做的進壹步延伸。需要強調的是整個項目如何實施的整體步驟計劃，而不是簡單的列出每項工作的人員和進度。
需要分析系統可能的叠代步驟(包括可能的短期應急和長期解決方案)，梳理上下遊依賴關系，需要協調的工作，最終項目上線時可能的業務遷移、數據遷移、系統集成等外圍工作安排。
如果不是有嚴格時間限制的期限導向型項目，整體的依賴和步驟往往是項目策劃階段需要強調的內容，也是可能對整體產品的進度和風險產生影響的事項。
而具體工作時期的安排，說實話，在大多數情況下，並沒有那麽重要。如果不綜合考慮整體工作和節奏，科學細致地安排工期是沒有意義的。
綜上所述，在做壹件事情的時候，最重要的目的不是計算工期，甚至不是安排人力資源，而是理順事情的依賴關系，控制可能出現的意外風險，提高項目開發進度的可控性。
壹般原則:
項目計劃文件的基本目標是統壹認識:明確問題，確定重點，明確路徑，控制風險。
寫文件的方法是把目標和要求放在第壹位，圍繞起點逐步展開。
文件的基本要素:背景、目標、核心要求、當前問題分析、重點方案難點分析、總體實施路徑、工作清單、進度安排。
然後將其細化為壹些預防措施:
核心需求壹定是核心，壹定要實現的內容！不能缺，也不能濫用。
問題現狀和工作事項壹定要呼應核心需求，有明確的關聯性，不要漫無目的。
圍繞最終目標，輸出完整的端到端解決方案，而不是局部解決方案。需要從最終產品/功能形態的角度來考慮要做的事情，而不僅僅是底層的技術實現。
事情和目標的清單不僅要列出要做什麽，更重要的是說明想要的結果，而不僅僅是描述實現的手段。
所有的工作項目都需要想清楚實施步驟、重要性和優先級，結合目標和需求，抽象概括，而不是簡單的隨意羅列。
要有壹個明確的時間表，但更重要的是要完整的分析和思考可能存在的上下遊和周邊的工作依賴關系。排期只是結果，完整梳理才是關鍵。