專案管理
筆者隨者工作久之後，開始找尋簡單好用且免費的專案管理工具來控管，不是每一家公司都會購買比較複雜的專案管理軟體!
筆者工作一陣子之後採用GanntProject。
原因：免費好用、可以應付上面的人，給他們要的資訊。
去官方網站下載完之後，其實筆者還會再多設定一個預估時數。
筆者以一個訂單系統為Demo
拆解階段
筆者在拆解任務的時候會以這四個階段為主。
一個專案當中有這幾個週期運作，對筆者來說這個模式是為了能夠掌握資源、成本、控管、風險。
- 需求分析
- 程式開發
- 測試時間
- 上線
專案管理循環流程圖
在專案管理當中的循環會是流程關係會是如下：
上圖是為了制定計畫，在執行計畫，在過程中進行監控，如果遇到偏差的時候，就要思考，到底要調度人力支援還是要重新調配資源或尋求求助來呢?
因為這個最主要是能夠找到相對應的計畫來來回歸計畫軌道。
假設整個都已經偏差狀況下，那就說明這個計畫已經不適用真實現況，必須重新制定計畫和策略，重新設立基準定回歸實施軌道上。
筆者在實務上在制定專案，滿常看到開發人員遇到上層交辦任務的時候，可以把整個專案時程估算給我嗎?
開發人員就不知道如何著手了….
筆者認為一個專案它是屬於動態進行發展，所以制定計畫是為了能夠確保計畫，能夠監控與進行，來找出對應的變化來牽制。
以訂單系統Demo需求為例
需求部分，通常我們會進行這些功能上的梳理，跟USER或是客戶討論需求規格部分。
功能開發拆解
在功能開發部分：筆者會拆一個功能會拆兩個
- 畫面與API的串接
- 功能API
如圖
一個功能展開出來之後，就可以開始把時數慢慢估算上去。
常見狀況：在初期的部分，可以先把大項部分列上去，把功能部分，先列出來再說。
筆者會推估時數列上去!
需求部分
功能部分
最後筆者會把它匯出，重整。
在EXCEL當中會加入一個負責人，多人開發可能會用到，若是一個人自己進行就先保留空白。
最後再開始進行時數彙總，進行初步的回報，進行時數的加總總計之後，可以以哪一天開始，假設你的時數加總是158/8=19.75，筆者會進位為20工作天。
最後再把每個功能日期，起訖列上去，日期的起訖列上去，才會知道整個計畫的狀況，後續才會因應計畫上部分，來做調整與變動。
最後來盤算一下結束日期與預計完成日期，保守推估一下。
這個計畫一旦形成，就可以考慮跟成員把這項計畫，進行專案推行的討論。
為何要讓成員了解整個專案輪廓
- 整個專案每個人都是參與者，缺一不可。
- 可以培養成員，對整個專案的整體觀，定期的依據計畫，一起討論有參與感，一起專案推進。
- 同時可以傳承參與的人，慢慢培養出專案管理的能力。
計畫是活的，不是計畫訂出來就好…
最後老闆或上面，最愛看的就是時間、金錢，具多會是以產出績效為主，所以要怎麼思考從技術面來轉換成商業與績效為主部分，相當具有挑戰。
筆者覺得如何讓RD同仁，嘗試去估算整個專案時程，以及鼓勵他們嘗試估算來進行動態調整是具有挑戰性，因為筆者工作上RD其實很抗拒這種動態型的調整迭代。
元哥的筆記