(找了這張圖，來做為自已的示意圖)
接下來的五天連假，我可能有三天都要去加班，沒辦法，這個坑就是自已造出來的，還是要去填一填才行。
這已不是專案管理的議題、而是專案運作的災難
以目前的現狀，實在難以打分數，這樣的結果，自已實在是怎麼會搞成目前情況。
太久沒有寫日記，就以這一個主題，來做為省思的內容
來回想一下，到底是「那幾個環節」出了問題？？
每天一定要有個「主軸事」
常常就是一天就這樣過去了，然後感覺今天忙了不少事，但卻沒有個累積，就常常是來一件做一件，
而一定讓自已清楚知道，今天重點事務，到底是那一項目？至少要有3個小時以上的時間在這一件事務上。
「每日只要訂出要完成的3件事」，然後專注在這主軸上。
不然，沒有清楚的軸線，做再多，未來自已都會將之歸於「雜事」之上，而忘了自已做了些什麼。
「以終為始」的思維
你終點目的、目標是什麼？要能先捉得出來！
以這個為軸心，你就可以很清楚區分，那些是雜事，那些是正事！
「由上而下的計畫」
專案在前期的運作，自已一定要建構起這樣的輪廓！！
要能讓自已熟悉到，逢人就可以談論，可以清楚地傳達這樣的架構，自已要做的事務有那些！
因為這樣，你建立起的架構圖，你才可以知道你現做的是在那個環節？是在那個步驟之下？
敏捷的管理思維，不是在當下你遇到什麼問題就解決什麼問題，
是你的軸心計畫要先思考、寫下來
而非用「由下往上」的「歸納」，整理出你的計畫、要做的項目內容
怎麼建構你的專案管理？
不該去思考用什麼工具來幫你管理？或是怎麼做記錄去追蹤議題？
而是你的腦子裡，要先能架構出這樣的地圖，然後達到怎樣都不會忘的那種等級！
先「粗顆粒」的劃分你的專案範圍下要做的事務
然後檢查是否有遺漏的？
用「紙筆」分析出這樣的內容，一件件寫下來
站立會議不單單只是講講我做了什麼、今天預計做什麼、有什麼問題而已
這個會議，應該是讓身為管理者的，能知道運作的全貌
去思考他們在做的事，是在你腦子地圖裡的那一階段？
厲害一點的話，你還可以預知他要做的事
可以為他接下來要走的路、 可能遇到的問題，提前給予建議。
幫他劃清，他現在做事的主軸層面是什麼，
另外，對他提問也可以讓雙方都能更清楚專案的全貌
客戶訂的「時間」要當作是「時間」
訂下的這時間點，往前推，然後去弄清楚，要做到那些事情？
這些要在「前期」就要問清楚
讓自已手上有個依據，所要做的事務有那些？
而不是因為自已手上的時間很忙，
然後讓自已不太想去理解，要達到這時間點，重要的事務是什麼？
要能夠思考出「下一步」
就如同「下棋」一樣，你要能推測出別人的下一步是什麼？
或是基於「那個條件」下，它的下一步可能是什麼？
這也是讓你自已有「風險」意識
才可以警覺出，什麼事情，如果現在不做，會影響後面的事情
早點提醒對方要做、提醒對方要確認。
並可以告知原因、為什麼？
先花時間思考，會比直接下去做事來的好
如同上述「以終為始」，你現在要做的事，是基於要達到那個目的而做的？
沒有在這主軸架構下，所做的事，全是蝦忙，
因為沒有建立足夠深的連結，後續一定就會忘了自已做過了什麼。
「階段驗收」的動作一定要先做，不管自已當下有多忙
當夥伴說完成這個功能時，一定要「空下」及「排定」一個時間，為這一個功能做驗收。
不論自已手上的東西有多忙，一定要排出這個時間。
不然，後續收尾的動作，實在是花費太大了！
一是功能面的測試： 可以請他依據「那一份需求」做出的結果，由他操作過一次讓你知道整個邏輯及全貌
二是自我功能面的測試：在聽過他開發的邏輯，你要有辦法針對「需求」文件，驗証他實作功能的完成度，是否合規？
三是程式碼的CodeReview：
- 這個重點，不是在那種「命名規則」層級的Review， 可以說明團隊的開發規範，那幾個點是要有一致的風格的
- 重點在「商務邏輯」的思考，自已看程式碼，就要有辦法看出它邏輯的正確性才行。
- 補上邏輯的註解：若是有邏輯在的，一定要請對方為該區段做註解，請他假想別人來看時，要清楚的讓對方知道，為何會有這樣的邏輯處理
主要目的不是所謂的「不信任」，而是交岔驗証的模式。
不然，這個坑，自已實在是踩了不少。常常都在交接給你後，自已進去細看，才發現怎麼差這麼多？
