其實寫這篇是有感於過往的工作經驗的感想啦 , 每個專案總是在有一個好的發想之後 , 但在執行面上一定會遇到阻礙而讓專案的執行過程不順利 , 進而導致專案進度Delay 或與預期的結果有差異 , 更差的是會導致責任的歸咎而讓許多人死在結果論之下 , 但有果必有因 , 找出這個因我認為更重要 , 如果沒有找出真正的問題點去加以改善 , 那麼會不會扼殺好人 , 甚至劣幣驅逐良幣 ?

過去我只有待過一家公司有做好 P.D.C.A 這種簡單概念的管理方式 , 這種方式是一種不斷的循環檢討方式 , 直到問題解決 , 當初年紀小 , 不懂得這個 P.D.C.A 的精隨 , 現在回想起來 , 這種簡單概念如果認真的落實去做 , 其實可以讓個人到部門到企業都可以慢慢的健全起來

 

但 P.D.C.A 的概念如果是應用在個人自己的生涯規劃上 , 則手工作很簡單 , 因為自己可以對自己誠實 , 但應用到企業上就不一定了 , 因為若一個案子很大 , 簡單的 P.D.C.A 很難作交叉追蹤 , 這個很難詳細說清楚 , 但我思考過後 , 若是以電腦化可以解決這問題 , 則我會想要開發或尋找一套具備 P.D.C.A 的專案管理軟體會具備下列的特性

1. 任務細分

2. 任務指派

3. 時程控管

4. 每個任務的 P.D.C.A 紀錄

5. 版本控制

接著一個個來說明

為何要做任務細分化 ?

我想很多人可能會聽到老闆問一句 , 何時能做好 ?

我想很多人可能會先回答一個大概的數字 , 30. 50 . 100 天... 如果這些數字是沒有經過精確計算隨口說出的 , 那麼老闆若相信就是傻子(很多)

為何我會說老闆是傻子呢 ? 因為老闆不夠 Sense , 不知道何謂量化

我們假設一個狀況 , 今天若老闆問我某某網站那樣的留言板若是交給你作要多久 , 我就會先去評估留言版的項目 , 例如留言板的功能有留言列表 , 發言 , 翻頁 , 刪除 , 這就是細分化 , 細分化之後 , 我可以根據這些細分後的功能評估出製作工時 , 例如列表 4 小時 , 發言 2 小時 , 翻頁 2 小時 , 刪除 1 小時 , 加加起來 9 小時的工時 , 加上 Debug 可能會花上 5 小時 , 各位可能會以為 , 那這樣做好之後不就要 14 小時 , 是的 , 就是這麼精確 , 這比起順口說 2 天 , 3 天 , 7 天來講有根據多了 , 但任務細分化後還有一個好處 , 就是可以做任務指派 , 將某個大功能切成小功能之後 , 可以分給其他人作 , 那麼不僅可以縮減總體完成工時 , 所預估的完成日期也一樣是有依據的 , 當然 , 每個細分化的任務工時 , 可以是自己估 , 也可以給被分配的人估 , 每個任務需不需要細分也可以由指派者或被指派者自己去細分 , 這要視專案類型 , 例如軟體類我就建議給被分配的人去估 , 因為寫程式要花多少時間別人實在是估不準 , 若讓一個沒 sense 的人估 , 肯定誤了大事 , 而且讓真正在寫的人去估 , 責任就在寫的人了 , 也是自我負責的一種方式

另外細分化之後更可以對於檢視專案完成的進度更有感覺 , 如果老闆繼續問我. 留言板完成進度多少 , 我說 50% . 老闆會信就是傻子了 , 如果我根據任務細分化的結果說 , 目前已經完成留言列表與發言功能 , 那麼老闆心裡就會有個底 , 就是還剩刪除留言 , 翻頁及 debug 還沒做 , 這樣是不是更接近量化而非唬爛呢

 

任務指派

我理想中的任務指派 , 是大到總經理到最下面的員工都可以完整分配任務 , 例如公司想要今年要達成營收目標 100 億 , 不是說了就算了 , 肯定是有經過產業的分析及未來趨勢 , 然後會想出一堆策略要來達成 , 這些策略可能是開發新產品 , 如何行銷新產品 , 如何爭取客戶 , 財務的支出預估等等 , 因此各部門就會出現很多任務需要去執行了 , 也許 RD 部門要開發一個新產品 , 這個新產品又需要團隊去做 , 但要開發新產品也必須有行銷部門及業務部門去合作才可能賣得好吧 , 所以所有員工都是這個 100 億目標的成員 , 因此從上到下都可以是任務指派的對象 , 但這任務指派並不是由總經理去指派給所有員工 , 而是總經理去指派各部門一個任務 , 每個部門的主管再把任務細分化之後再指派給部門的成員 , 最上層的總經理若真的想要看最下面的員工被指派甚麼任務也可以 , 總是要知道那些主管或員工打混吧 .. 不對.. 應該是說可以觀察到資源是否分配得當

任務指派則必須至少要具備人事時的特性 , 就甚麼人做甚麼事,何時作, 何時完成 , 這樣才能去做好下面要講的時程控管

 

時程控管

時間這東西 , 可能職位較低的員工比較不會 care , 因為職位低的員工通常負擔的責任較小 , 但職位越高就越有壓力 , 一個大專案既然細分成很多小任務 , 如果有某個小任務發生問題 , 那麼可能會因為這個小任務而讓其他任務無法進行 , 甚至進行中的行銷活動會因為這樣而無法進下去或停止而浪費極大的成本 , 甚至和其他廠商發生不愉快那就虧很大了 , 但時程控管是個學問 , 專案管理者必須確認有那些事情一定要完成 , 其他事情才可以繼續進行 , 因此我理想中的專案管理模式是一定要把任務細分化並且指派之後 , 才會出現時程預估表 , 這樣才能做時程控管 , 因此在這個系統中 , 時程控管的機制其實很簡單 , 只要確定都指派完畢後 , 就可以讓時程預估表產生 , 而專案管理者可以定某個任務為檢查點 , 如果這個任務無法在限定時間內完成 , 那麼就會提出警告 , 讓專案管理者去想辦法修正專案以讓專案順利執行

時程控管也必須去記錄原始預估時間及實際完成時間 , 如此才能估算當初預估與實際的誤差 , 也可以幫助人員慢慢累積同類型的專案預估經驗 , 這樣時程的準確性會越來越高

 

任務的 P.D.C.A 紀錄

上述三點 , 其實已經有很多軟體具備了 , 但光具備上述三點 , 其實管理者看到的是個結果論 , 也就是只看到事情有沒有完成 , 我相信很多人都開過會 , 但應該有很多人開完會後甚麼都忘了(沒有會議記錄) , 這是很要不得的 , 也常常是很多事情交辦下去後卻發現事情沒辦好或根本主管都忘了去追蹤 , 反正一堆問題啦 .... 但每個人做紀錄的方式不太一樣 , 我是推崇 P.D.C.A 啦 , 因為 P.D.C.A 的方式可以完整的紀錄執行的動作 , 執行中發現的問題 , 及提出解決問題的對策 , 每個對策也可以衍生出新任務 , 這是一種循環改善直到任務完成的方式 , 由於 P.D.C.A 完整的記錄 , 因此若專案執行的不順利 , 要找出真正的原因就比較客觀 , 想推卸責任也推不了 , 但我認為 P.D.C.A  的用意不是為了追究責任啦 , 而是要找出問題的所在並且解決問題才是 P.D.C.A 的精意

 

版本控管

作專案 , 一定會遇到執行面上遇到的問題而調整專案的任務 , 如果是以手工方式來紀錄專案過程 , 那麼可能會因為調整過程中刪除了某個任務 , 那麼大家就遺忘過曾經有這個任務了 , 也許這個任務只做到一半 .... 但這作到一半的任務也是這個專案的過程之一 , 在刪除過後也應該保留住 , 但刪除的任務未必大家都想要透過列表看到 , 因此我們看到的任務列表 , 是最新的版本 , 但也可以回去看上一版的 , 看看為何刪了這個任務 , 也許刪了這個任務也是造成專案執行發生問題的主因 , 因此我認為版本控管應該也要做好以輔助問題的檢視

 

講了一大堆 ... 不知道有沒有人看過有這樣的軟體 , 還是說有更好的模式可以指教我 ... 不然我真的很想自己開發一套咧