大綱

6/12/2016

靠感覺做專案管理 - 鐵定失敗



真實故事:


有近70個工程師參與的軟體專案的組長會議中,除了專案經理之外,另有8個負責領導開發不同模組的組長一同與會。

例行的報告進度後,專案經理看了一下大家,帶著遲疑的臉說:「在兩三個禮拜大家的模組就都完成了,如果沒有問題的話,應該整個系統同時也都弄好了吧?」

負責UI以及整合模組的組長,看著大家漠然不語,也只能硬著頭皮的說:「現在最大的風險在於:如果所有模組都在最後實現完成,那根本不會有人知道組合起來會發生什麼事,所以我只好老實的建議,要不就額外增加整合測試的時間,要不就要減少某些模組的功能讓他可以早點進入整合」。

但其實大家心裡有數,這麼多人在短時間開發出來的系統,不可能在短期間整合完畢。

未料,專案經理似乎沒有體會事實,他說:「接下來大家就要在努力一點,就快要搞定了」。

可能是心情不好,在加上長時間加班的火氣:某組長就說:「我們到目前為止的問題是在於我們不夠努力嗎?」。

專案經理當然說:「不是,我知道大家都很努力...」話未說完,該組長就說:「既然問題不在於我們不夠努力,為什麼叫我們更努力,就可以解決問題?」。

專案經理:「...」





許多失敗的專案管理者,在遇到困境時,只會用幾個永遠不會有好結果的方式,來試圖解決問題。常見的方式像是:無意義的加班,默許降低品質,虛報進度,哭訴人力不足要求增加人力。在緊要關頭,這些作法都不會有好效果。只會這幾種方式的專案經理,儘快離開管理位階,才會是組織最大的貢獻。

最有天賦以及領導力的管理者,通常擁有不可言喻的直覺,並能透過直覺透徹專案。很遺憾的是絕大部分的人不會有這樣的天賦,特別是作為軟體專案經理者。很難具備以敏銳直覺,完成複雜系統開發。

然而,專案管理其實不需要天賦,所有人都可以透過自我學習,了解專案管理的精隨,透過自身的努力作個稱職的專案經理。和所有重要的事情一樣,首先是要了解事實。在略具規模的專案,應該透過事實的呈現,來了解專案目前進度,可能的風險,遭遇的困難,以及解決方式。

而且,只有盡可能了解事實,面對事實,才能引發可行的創意行動。


事實的取得有三個面相:

恰當的衡量:


恰當衡量,是判斷專案經理的好與壞的關鍵之一。恰當:簡而言之,必須是可行,正確,有效,有意義,精簡的衡量。

近年來Scrum蔚為風潮,其中一個重要因素是對於進度的恰當衡量。通常專案進行了一段時間之後,burndown chart可以清楚的顯示,現在專案的進展,和是否可能在預定期限內完成。也因為burndown chart展示的是不可否認的事實,讓Scrum的團隊在取得洽當的衡量之後,做正確的因應。

不恰當的衡量,出現在幾乎所有失敗的專案場景裡。

有些專案經理會依賴WBS的圖表,來看進度是否得當,但WBS是固定的無法調整,即便調整,也很難追溯過去調整的細節。WBS在軟體專案中,很難達到可行,正確,精簡。

有些專案經理,會依賴團隊成員報口述「完成」來斷定進度,在沒有看到「實品」(例如程式碼,每天自動編譯測試的build等等),口述完成不是「有效」衡量。

最慘的專案經理,會透過大型,繁複,耗時的會議,逐一確定已經完成的項目,花在「了解事實」上的時間,遠超過「做事情」的時間。這種本末倒置的既不可行,也不精簡。它唯一的好處只是在於讓原本不懂的人 - 也就是專案經理,花上不可置信的時間了解事情而已。一個不超過10人的團隊,要是每個禮拜耗費總時超過4小時在這類型的會議上,就表示專案經理沒有對技術有透悉能力,儘快換掉專案經理會是對團隊最有利的作法。



承認不確定性:


沒有人可以預知未來,必須承認不確定性,並且把可能的不確定性當做事實加以處理。當打算推測不可知的未來時,用過去之已知事實,並加上不確定性。

例如:未來3個月團隊的總人時?假設團隊成員共10人,每個月22個工作天。則總人時推測為220人日時,等於表示沒有推測。這220人日,根本沒有把「過去已知事實」考慮進去。比較好的推測應該是,220人日,減到(1) 過去3個月,這10人的總休假生病天數。再減掉(2)可能的季節性假日,例如颱風。再減掉(3) 組織已知的活動,例如員工旅遊,大型會議等等。當然,這些以過去的數字推測未來不一定準確。但是,以過去的事實推測未來的不確定性,總比當做沒看到的好得多。

一般專案管理中,不確定性會用風險管理來衡量並且控制。正是「真正」的風險,就是坦然面對事實。

失敗的專案經理在每週的報告中,會把「人力不足」當做風險,試圖避免未來失敗的責任歸屬 - 畢竟已經先在每週報告中說了,目前人力不足是風險,但是就是沒給足夠的人力。這其實單純是專案經理試圖逃避未來責任的作法。

人力不足壓根就不是真正的風險!如果人力不足是真的,那麼專案時程規劃不正確,對技術掌握不足,專案經理沒有創意來解決問題...這些才是真正的風險!假如真有人力不足,它必定不是突然出現的可能機率,它是「已經存在的必然」,風險必須是某種可能會出現的事件,萬一出現,會對專案造成及大的影響。例如,在建築專案中,大地震就是風險,必須要規範出現的機率,但它很有可能不會出現。

把不正確的風險當風險,以及不把真正的風險當風險,都是不願意面對事實的畏縮專案管理者會做的事情。



理解認知偏誤:


在專案管理中,人類認知偏誤(Human Bias) 不可能全部去除,但可以盡量避免。根據事實原則,專案經理應該承認:認知偏誤的存在,盡可能減少影響,但也要理解,不可能全然去除認知偏誤,畢竟人非聖賢,也非機器。自認為已經去除所有認知偏誤,等於是一種認知偏誤。

去除是不可能,理解並且降低偏誤,是取得真正事實的最重要的方向。

例如:在code view的精簡會議中,常出現偏誤在於,極為資深的員工的程式碼,通常比較不會被挑出問題。但根據研究,只要運用程式語言超過2年以上,資深與資淺員工,在程式碼撰寫品質並沒有太大的不同(參見約耳談軟體一書)。要去除這類型偏誤,最簡單的方式是透過系統送出匿名程式碼(在尚未commit之前),要求成員利用email寫出自己的意見,而意見也可以是匿名。

高階主管為另一個例子:高層主管對團隊的了解,大部分來自第一線主管或二級主管。高級主管必須要認知,取的團隊資訊,必然經過過濾和扭曲。這幾乎是不可避免的事情,畢竟第一線主管或二級主管也是「人」。例如,如果發現有某團隊老是有問題,進度不佳,人力似乎永遠不足,高級主管如果找第一線主管了解原因,不會有第一線主管直接了當的說「是我的問題」。但是,一個團隊有問題,75%的原因是出現在領導者身上。去除認知偏誤的方式,除了越級訪談之外,高級主管不應該詢問一級主管的「看法」,而是直接詢問可以獲得的事實。例如:目前的問題,一級主管採用哪些「有價值的作法」來解決。

偶爾進行的團隊訓練活動,也可以將人類偏誤以討論的方式作為主題。讓團隊成員知道有偏誤的存在,自然就有可能減少偏誤的發生。



只要能根據「事實」,降低並去除認知偏誤,比較有機會在困難的專案狀況下,發揮團隊潛能,並且找到有創意的解決方案!畢竟,根據「事實」,一個營利組織必然希望團隊能帶給組織真正的價值,而非僅只是達成表面目的。





沒有留言:

張貼留言