圖片來源:http://www.foxgrp.com/
Schedule delay怎麼辦?
當老闆或客戶劈頭就問你這句話時,你該怎麼辦?
如果你平常就不是很用心的PL,你不會知道project真正的問題在哪裡,不知道問題在哪,你當然也就提不出好的方法。這時你就只能期待老闆不懂,含混過去,但可以想見project依舊改變不了delay的情勢。也許你就是project最大的問題也說不定。
即使你平常很用心,你也不一定會知道問題在哪裡。用心的PL不知道問題在哪裡而delay,就跟很認真做事的RD卻效率不好一樣,結果讓老闆生氣卻又不忍罵他。只能說能力、經驗、做事方法還不夠到位,要學習的東西還很多。不過好在有用心,project delay有機會成為最好的教訓,好好想想檢討一下,會找到一些答案的。提出好的改善方案或lesson learn,相信老闆會再給你支持和機會的。
如果你是用心的PL,也知道project問題在哪,卻還是delay。要嘛是想不出好的方法解決問題,不然就是想到的方法已經超出你的能力或權力範圍了。即使沒有解決的方案,面對老闆的提問,至少也應該把問題點說清楚,說不定老闆可以幫你找到解決的方法。若是方案超出你的能力,向老闆call help,有老闆的加持,或許就可行了。
Project delay了該怎麼救?
如果你是不用心的PL,老闆又怎會期待你來救呢?可能老闆救project的方式就是把你換掉!
如果你是用心的PL,至少你還保有自救的權力。
你可以檢視以下幾個問題,來找出project的問題和解決方法:
A、人的問題
1、RD(PM/PV)的人力或能力不足嗎?人有放對位置了嗎?
2、大家的工作態度對嗎?是太累了還是太散了?
3、Project team的氣氛和情緒是正面的還是負面的?抱怨、推責任的情況多嗎?
4、團隊之間的合作和互動有問題嗎?工作loading balance嗎?
5、各team的leader都配合嗎?你對各team的狀況了解夠嗎?
6、有project以外的人力可以支援或合作的可能嗎?
7、有之前的PL、你的老闆或其他可供你諮商的人嗎?
8、有任何激勵鼓勵project team的方法嗎?
B、時間的問題
1、原本的schedule合理嗎?有可能再調整嗎?
2、大家工作時間合理嗎?太長或太短?有可能加班嗎?
3、對Project、function team、RD平均一個bug要花多久時間?愈後期的bug會愈難解。
4、Project正處在life-cycle的什麼階段?後面還有哪些階段要走?
5、溝通和訊息傳遞快速嗎?Report line會不會太長太複雜?
6、所有人對project的下一個milestone時間是否夠清楚?
7、有簡化流程,縮短處理事情時間的可能嗎?
8、有共用資源(e.g. RD expert、工具設備、PV)使用時間衝突的問題嗎?如何協調?
C、事的問題
1、需求一直改來改去,沒完沒了嗎?
2、Project被中斷或跟別的project搶資源嗎?
3、做事、溝通有效率嗎?減少浪費了嗎?有重工的嗎?有可reuse的嗎?有整合了嗎?制度統一嗎?
4、Report真實反應狀況了嗎?對於你覺得怪怪的report,你查證過了嗎?
5、有數字統計分析讓你了解趨勢和分布嗎?尤其是RD和bug的關係。
6、Bug review、code review和會議,只是在擔誤大家的時間,還是真的對解決問題有幫助。
7、Priority、目標設定明確嗎?有確實傳達給每一個人嗎?
8、風險控管了嗎?有action可應對嗎?
9、後續的計劃是什麼?可行嗎?PM或team leader有參與討論嗎?老闆認可嗎?
10、會block的、有dependency的事或問題有好好處理嗎?有等待或浪費的情形嗎?
想想上面幾個問題,相信你會找出project的問題,也會找出適合你project問題的方法。
不過project delay大部份都是因為人的問題,而任何解決方法也還是要靠人來執行,所以想救回你的project,須先解決人的問題,再來解決事的問題。
當delay還在可控範圍,也許做些微調就可導回正軌。但若是嚴重delay,只做微調是改變不了什麼的,時間也不允許你慢慢追回來,必須下猛藥才能扭轉乾坤。除了你自己要做好心理準備外,也要讓整個project team和老闆理解並認同你非下猛藥不可的原因,不然再好的藥也是注定失敗,那就可惜了。
沒有留言:
張貼留言