1. 首頁 > 生活百科 > >

規劃文本的定義( 二 )

生活百科項目


核心需求必須是本質的，一定要實現的功能，它是一個原則，不是工作列表 。不要事無巨細，凡是想做的都列在上面，那樣反而淡化了項目最根本的訴求 。但它也必須足夠全面，要能確實解決項目目標中所提出的要求，應該用適當抽象的語言概括一個完整的事項 。
總結一下，核心需求的根本目標是，讓參與項目的同學有方向感，能夠知道這個項目最終想要通過提供哪些能力，滿足哪些約束條件來解決問題，至于怎么實現，具體要做哪些事，那是下一步才需要回答的問題，簡單來說：先選擇做正確的事，再考慮怎么把事做正確 。
其次，需要對現狀和問題進行充分的收集和分析
這一部分內容，從實際操作的先后順序來說，未必是第二步，很可能在我們總結前面的背景，目標，核心區需求的時候，就需要加以收集和分析 。
不過，從方案文檔的角度來說，放在這里，是為了進一步細化問題，分析目標，核心需求與當前現狀的差距在哪里，具體有哪些實際問題需要解決 。為后續具體的實現方案，準備必要的輸入信息，確定工作的優先級，重要性，項目迭代的步驟等等 。
需要強調的是，現狀和問題分析，要圍繞前面的核心需求的條目展開，兩者是強關聯的，不要相互脫節，各講各的
這塊內容本身沒有太特別的地方，就是現在實際情況如何，有什么問題，關鍵是如何把問題收集完整 。
所以這部分內容，難的是如何發現問題，很多做技術的同學往往容易陷入只關心技術難點，只能看到技術問題的局面中，而實際上，更多的問題往往是整體流程如何設計更加合理的問題，而不是技術方案絕對對錯的問題 。
盡管行文上不難，但它的重要性，也往往容易被忽略，很多情況下被簡單對待 。實際的情況是，很多項目的方案計劃往往是在對現狀問題相關信息沒有充分收集和分析的基礎上就做出來的 。導致項目方案后期不斷調整，或者一期一期的總是在小步迭代，甚至不斷推翻重來 。而最終使用方真正關心的問題卻一直沒有得到重視和解決 。
最后，是輸出解決方案
定完需求目標，分析完問題和現狀，接下來才是規劃具體做什么，怎么做，什么時候做 。
這部分內容，強依托前面的核心需求和問題分析工作，沒有做好前面的準備工作，千萬不要著急開始動手“規劃”方案?。?！
那么具體寫的時候有哪些注意事項呢？
做什么：
做什么和前面項目目標的要求剛好皆然相反，需要輸出明確的可執行的事項，而不是模糊的不可執行的要求 。
具體做的每一件事情，都要和前面的核心需求和現狀問題對應上 。如果你發現有些工作，和前面的目標沒有任何關聯性，那么考慮一下目標是否需要再評估調整，或者這件事情根本就是不重要的 。
要做的事項列表，是一個經過歸納思考以后的總結，而不只是一個個零散的事情的隨機列表 。需要有重點和優先級 。如果有必要，以歸類，分組等形式結構化的組織相關聯的事項 。
完整的事項列表，應該是一個和最終目標對應的完整解決方案，而不僅僅只是完成目標工作中的某一個環節 。
比如面向用戶的終端產品項目，需要包括整個產品的交互邏輯，業務流程的規范設計等等，而不僅僅是對底層系統實現和后臺功能點的設計 。
這點很多同學也很容易忽略，總覺得功能和架構的實現才是有挑戰，需要規劃的內容，而產品的形態并沒有花心思去琢磨，事后開發前端時才來考慮 。實際上后者可能才是真正影響項目成功的關鍵，也很可能會影響到底層架構的設計和取舍 。類比一下，好比一個用戶產品都開發完了，才來考慮埋點，數據采集和數據分析的工作，這時候就很被動了 。
怎么做：
前期方案文檔，沒有必要列出詳細的技術方案細節，只需要一個整體的技術方向選型和初步的架構設想 。但是，如果是涉及到核心需求能否有效滿足的關鍵的技術點，有可能影響整體的架構或產品實現的，那就有必要就可能的方案的進行詳細的評估并得出初步的結論 。
無關架構或進度安排的方案細節，沒有必要寫太多，可以后續再補充 。
方案中有不明確的地方，即使沒有時間調研，也不要簡單的略過不寫，要在文檔中明確的把問題寫出來，給出下一步調研的方向計劃等 。歸根到底，方案文檔中，對每一個已知重要的問題，都需要一個明確的結論或者可以后續跟進的計劃，以免事后遺漏 。

推薦閱讀