圖片來源：http://images.takungpao.com/
之前寫過一篇［PL的Project Management］三軍未發，糧草先行，最近一個project的案例就是沒做好糧草的準備，過程中到處失火，搞得人仰馬翻。
在project進行二個多月後，有些feature都已經開發完成了，這時卻有人反應F模塊沒有owner負責，原因是debug時需要找該模塊的人一起看，卻發現找不到人。結果PL召集會議討論該如何處理，才知道原來大家對分工的認知有很大的落差。因為這是大project，所以跨了幾個sites的RD team一起合作，Z1 team的 PL認為F模塊有問題應該由上層使用的人自己去改，因為Z1 team過去的project也是依這種模式處理。但是H team卻認為F模塊的範圍很大，而且相關的domain know-how很深，不是隨便人輕易可以改的，應該是有一個專門的team負責處理。H team之前跟Z2 team合作的project就是有專門team在負責F模塊，他們只負責上層應用的部份。
大家對F模塊該由誰負責吵了一陣，但現實是H team沒有能力cover跟他們對應的F模塊部份，缺口的確存在，而且是一個很大的缺口。這麼大的問題並沒有在project初期做對project各模塊指定負責人，確定跨sites的分工合作模式時發現，卻延後到二個多月後才引爆，這是第一顆地雷。
當下為了填補這個缺口，會議中組織了Z1 team和Z3 team共同負責F模塊，儘管這些人都沒有相關經驗，也沒有相關domain know-how，而他們原本負責的工作則交接給其他各team並同分擔。這時埋下第二顆地雷，因為：
1. 為了填補缺口，只管找人頭，不管專業行不行。
2. 工作內容大風吹，Z1和Z3 team接了新的F模塊，其他各team分擔了Z1和Z3原本的工作，然後大家都不是很了解新的工作領域，project都進行到中期階段了卻仍在做job rotate。為了解決一個問題，卻引起了更多的問題。
第二顆地雷，其實不只爆了一次，而是連環爆：
1. 開始有RD不滿工作內容換來換去，而且project schedule並沒有因為RD不懂新的領域而給 RD study的時間。一個月後終於有RD不滿離職。
2. 因人員能力和人力的問題，使的project delay，project壓力大而且RD loading也相對增加，又因工作專業能力不足，在問題處理上不時碰壁，討論問題有時會有雞同鴨講的現象。RD面對問題經常第一個反應是＜這不是我的問題＞，即使他只看了bug的標題，連log都還沒打開就做出這樣的結論。大家開始推bug，工作的氣氛和情緒不好，工作效率差，project陷入惡性循環狀態。
3. 最後逼得大老闆自己下來review bug，調整其他projects的priority來協調RD resource，下令要求大家加班，花了很大力氣勉強救回schedule。
這個project的執行過程負面教材不斷，身為PL該負最大的責任。不只大老闆對他失去信心，各個team也怨聲連連。原因到底出在哪？值得探討：
1. PL不是沒有經驗，而是把自己當老闆而不是PL了。心態不對，事就做不對。
2. F模塊的缺口說明PL和PM組織規劃和溝通協調的能力有問題，整個project的分工不確實。
3. 沒有善用老闆的支持先去找對的人來彌補F模塊的缺口，卻以為從project team找人就可以填補，結果當然是挖東牆補西牆，弄得project team內部殘破不堪。人力資源沒有良好的規劃，病急亂投醫，把工作內容複雜化。
4. 工作內容玩了幾次大風吹，各team都是在百般無奈和不願意之下進行，事前的溝通沒做好，事後的協助也沒到位，所謂team work和人和都被這樣粗糙的決策引起的負面情緒給沖散了。
PL要經常自我檢討，project delay到底出錯在哪？做錯一件事通常還可以彌補，但是一連串的錯誤，不只害了project和project team，也害了自己。
而且別抱怨大家不配合，因為地雷其實都是你自己埋的！
沒有留言:
張貼留言