意圖和目標
意圖是我們執行某件事的動機和背後的原因，你必須要馬上理解這個背後的邏輯才能事半功倍。
目標則是為了實現或解決這個問題，所設下一個或多個的明確定義的項目，這一切的項目意義都只有一個，達成或解決背後的意圖。
規劃，則是理解意圖後，設定目標的過程。
這個就是規劃事情的底層思路，並沒有什麼很複雜的學問。
關鍵問題
知道了意圖之後，那就要知道自己在這個故事中的那一個結點，這個事情可能牽涉很多人，你可能是其中一個節點中的某一環。
但眼前的問題是，你要知道自己的問題是什麼，才能對症下藥啊。
所以必須要稍微理解背後的故事之後，分析出自己在那一個步驟上。
假設整個故事的脈絡是這樣
那麼往往到你的手裡的時候（其實不管組織的什麼職位，都會是一個結點的問題），就是一個結點的問題。
你的關鍵問題，就是你的問題的原因，然後給出建議和組作法。
給出建議
當針對一個問題的時候，我們可以給出原因，同時給出建議，規劃，則是這些建議的具體執行方式罷了。
花了那麼大篇幅，其實就是為了介紹，規劃到底是在做什麼，所以如果當有人請你規劃一些事，不要再零零碎碎的給一些資訊就草草了事。
那我們真的下手要做規劃，就是要有了以上那個思路之後，開始下手設計。
有效的實驗方法
在報告前，先自己進行實驗，證明自己的想法是對的，如果時間關係無法證明，就給予規定的時間。
實驗可以是時間，可以是單位項目，可以是任何一個單位，例如：
1，我們用方法A執行10次。
2，我們用半年時間使用方法B。
3，我們有一個人做方法A，一個人做方法B，
這些都是為了更好提供一個參考單位讓評估你方案的人，如何配合你，或如何和其他人配合。
共存和退場
當然，在真實的場景中，我們都要處理新舊交替的局面，所以就必須會有一段時期，出現新舊共存的過渡期。
要具體提出如何執行和細節，兩個新舊系統如何可以替換工作，當然還要解釋當中的風險和解決辦法。
有效的掌控的流程是計畫中很重要的一環，如果計畫中完全體現不出掌控力度，那麼整個計畫可能會在哪裡出錯，就成為整件事的風險管理中明顯的漏洞，因為也沒有想要一直提心吊膽。
當然每個計畫都會經歷時間的洗禮，總會有一天他會滅燈，又或者過程中不如預期，是如何執行退版，又或者整個退場，維持舊有的系統。
邊際切割
假設是新設計的系統，這一步必須要做好；假設是舊有的系統，這一步更要做好，即便它很難做。
為什麼？因為多數系統再上線後，為了應付各種需求，就會開始模糊了邊界，為了達到效果，技術債不斷累積，那都是因為對於這種「邊界」毫無概念的後果。
以下是一個非常經典和簡單的新聞網站，按理說，我們會將APP設計成這樣。
但其實你可能會問，為什麼要那麼多餘，我們可以這樣，像下圖那樣，直接打API，直接顯示；或者我們可以在Server做一層，前端直接顯示HTML更快。
其實不管那一個方案，都對，但最後我們必須釐清這些方便的邊界在哪裡，在很多架構設計的書或者理論上，我們都會把一些「複雜且不穩定的」因素集中在一個地方管理，其他相對的模組都是穩定且單純的。
這都是為了更好釐清APP的整個資料流動和結構，另外要不要加一層cache並不是邊界要在乎的，對整個系統來說，cache也就是邊界其中一環，有沒有它，都不應該會影響整個系統運作，而不是把cache加進來，他才能運作。
前後分離很常被使用，是因為那是最簡單且好理解的分割點，我們可以獨立測試API； 但我相信，會去測試UI的人是佔少數，會去真的找出UI中的錯誤更是少數中的少數。
介面，是介於API和UI之間的一層轉換層，你可以很好的利用它來控制進入和出去的數據長相和錯誤處理。
以上只是一個舉例說明，真實情況遠比這個複雜的多，但這也是極大多數人在設計APP時最常忽略的事，拿到API就直接用了，API錯，你的APP也跟著錯，沒有例外。
風險控制
一個完成的計畫，會涵蓋很多重點，無法一一說明，但是有一個重點是必須要要有的，那就是有什麼風險？
可以思考看看：
1，執行這件事，困難的點（技術上需要克服）什麼？
2，有什麼事情你事做不到的，什麼事情是做得到的。
3，做這些事情需要花多久時間，投入多少人和成本。
4，如果這事情中途有什麼變卦，可以怎麼應對。
5，如果執行完畢上線，最佳的狀況是什麼，而最糟的狀況是什麼？如何避免發生最糟的狀況。
總結上述所說的，一個工程師的項目規劃，可以有以下內容
1，我們面對的問題和困難是什麼，如何解決，代辦項目是什麼。
2，每個代辦項目中，又有什麼困難和代辦項目。
3，整個計畫中，一個有幾個模組和區塊，如何劃分，如何分開測試。
4，有什麼風險，時程，成本投入，預期結果。
為了節省開會時間，請務必準備好「精簡」易懂的圖文並茂簡報，讓人能很短時間內知道你的想法。
先說結果和結論，再分析你的觀點和想法。
