專案管理
專案要做的重要事項?
- 事先要做什麼
- 行動前先設想怎麼做、做什麼
- 怎麼把一個大的任務細化拆解小任務
- 每一件事情要有負責人
- 漸進明細，逐步前進
- 過程的管理不可缺
- 有開始有結束-結束也會有總結
事先做什麼?
最常見的就是一個專案或是系統需求項目丟下來，搞不清楚要做什麼，事先做什麼，需求分析做一做，開發做一做，沒有計畫或方向，是一個滿危險狀況，筆者認為，行軍打仗也是要進行，資源準備以及平常的軍
事演練。
有當過兵的人一定都知道，在和平時代狀況，也是要跑日常戰備任務，也就是說平常都是排定計畫，演練，但一旦遇到變化或是戰爭到來的時候，平常的演練就會派上用場。
也就是說在還沒打仗以前，最基本的會做會有，例如：日常操課、戰備操演、下基地、軍事演習、後勤作業、保養裝備…等!
這個如果在對照之前寫上一篇文章寫的專案項目，筆者會定義拆成四個階段：
- 需求分析梳理
- 功能開發
- 測試
- 上線作業
上述這些階段，也就是說你已經知道你一定會做這些事情，這些就可以列出來了。
行動前先設想怎麼做、做什麼
從上述這四個階段，列出來的時候，上級都會要你我要整個專案的時程…
長官：張三、可以把整個專案時程列給我嗎?
張三：….好….(OS:這怎麼抓阿，我不會抓阿…時程會估不準…為什麼要估阿???)
首先剖析這個情境來看，為什麼張三會如此抗拒呢?
首先我們要從角色立場去看：
主管會遇到的問題
- 本身管的專案這麼多
- 沒辦法一一每個專案都過濾
- 沒辦法每個專案細化，因為實作的人是最了解細化，也是最清楚實作，要花多少時間
主管的職責是在於所有專案的管理和掌控，無法每一個專案都能夠細化參與，必須透過底下的人回報和協助。
為什麼? 光開會雜事都忙不完了…
再來張三的角色是基層RD狀況
- 軟體開發是屬於動態
- 對專案認知是屬於瀑布模式，希望能夠需求固定
- 已知道做軟體專案是學習，無法準確估算時程
正因為如此，所以才要把項目要把任務部分，通通列出來，並開始排序和掌握，因為軟體專案是動態，更因為動態所以才要管理，同時一旦出現變化就要找對應並回報，還要能夠掌握風險。
至少在這邊你已經知道
- 需求分析部分：可能會做功能的需求梳理與規則
- 開發部分：會有一個功能會分別有UI與API串接、API開發、開發者測試
- 測試部分：使用者測試。
- 上線：上線部屬作業與結案。
在做專案的時候沒有一個計劃出來狀況下，發現做的狀況不對，沒有計畫狀況下，沒有把上述的東西列出來，代價就是會失控，同時張三跟長官都沒辦法掌握。
怎麼把一個大的任務細化拆解小任務
一個項目或是任務非常大的時候，通常都比較複雜無法量化出來，當無法量化的狀況下，就要由大拆小，小到能夠量化出來去推估與估算。
每一件事情要有負責人
任務一定要有一個負責人，任務有負責人，是為了讓人員能夠參與工作，筆者認為計畫一旦出來，有參與者，就應該要讓任務負責人能夠一起進行參與計畫。
漸進明細，逐步前進
整個專案任務一旦進行，啟動，就依照計畫去進行作戰，每週的討論或是開會來討論整個明細過程是否有按照計畫進行，如果計畫有問題，可以大家一起想辦法怎麼推進和解決問題，調整策略跟戰術，讓計畫能夠逐步推進，當然也會隨者任務了解，也會越來越清晰和想法誕生。
過程管理，不可缺
過程管理，不可缺意思是筆者先前進行專案的時候，筆者認為過程的管理不是只有PM有責任，底下的RD被指派到的任務也是有責任，也是自我管理，透過計畫訂出來之後，可以經過討論來調整，過程管理中來改善和調度，因為計畫明確出來之後，就可以按照計畫中執行，若遇到困難，也可以彼此討論，或是臨時調度或是投入，把任務完成，過程管理是屬於動態，而不是靜態。
最後不想被管理的人，永遠無法管理別人。 就算錯誤，也知道怎麼死。 從另一個角度看，不想被管理的人，永遠無法管理別人。 將來自己有可能成為管理者，自己也要慢慢建構能有自己管理的方式。 但是不去嘗試去做，怎麼教人家對吧?
有開始有結束-結束也會有總結
一個專案它是有開始，終究也會有結束的時刻，不可能沒結束，在結束的時候，可以透過在做專案項目能夠獲得到什麼，覺得下次再進行的時候，哪邊可以更好，在未來的任務進行可以持續改進。
老E隨手寫