敏捷雖如專案管理巧婦,無米無灶也難為炊

敏捷雖如專案管理巧婦,無米無灶也難為炊

日前為一家規模龐大的組織進行敏捷式專案管理課程,課前一天傍晚,副執行長熱情晚宴款待,席間提及,某個老舊資訊系統更新專案,執行兩年以來延誤不斷,掌握不了可靠的結案日期,令他相當頭疼,不過在他的話語之間,我倒是感受不到絲毫的怪罪之意!

副執行長雖然熟稔傳統式專案管理手法,但卻謙沖承認自己是敏捷方法門外漢,在我向他簡略介紹完敏捷方法之後,副執行長略顯無奈地提出了這樣的疑惑,「聽說敏捷方法可以把專案做得又快又好(客戶/用戶滿意),可是我們IT團隊已經用敏捷方法做專案好幾年了,這個專案還是延誤成這樣,不僅開發人力資源卡死在那兒,使用單位也抱怨連連,到底問題會是出在哪裡呢?」

我知道副執行長並無惡意,也非在挑戰我或敏捷方法,更非要我當下就給出靈丹妙藥,否則也不用大費周章,喬出相關單位人馬來上我這堂敏捷式專案管理課程了。如果真對敏捷方法失去了信心和信念,倒不如直接下令 IT 團隊改回傳統式專案管理方法,這樣要省事許多。

課程當天中午用餐時,IT 部門既專案管理主管談及該延誤專案,我便順勢探索了一下該專案的來龍去脈,真相終於大白,還了敏捷方法清白。其實,正是巧婦(敏捷方法)難為無米(適切角色與流程)之炊的寫照。


無米一:專案管理專家角色闕如或失能

一般來說,歷史愈悠久的資訊系統(以下簡稱系統),其功能與架構愈是錯綜複雜,背後累積愈多怪異的商業邏輯(Business logic)和臨時性補丁(Workarounds)。經過歲月的洗禮,龐大的系統健在依舊,可是人事卻往往早已全非,過去曾經參與打造或修補這系統的人們,來來去去,早已無法有人能清楚掌握整個系統的來龍去脈。

您也許會問,不是應該有文件,記錄著大大小小的變動歷史嗎?不幸的是,實務上,原本好好的理想系統架構,經常會被一些臨時又緊急的修補動作所破壞,且這些修補又常被遺忘而長期留置在系統當中,相關文件當然也沒被正確更新。

當系統如此演化,肥大到難以維護或技術老舊到跟不上時代之時,就有人會開始想全面重新打造這個系統。人是喜新厭舊的動物,這一點也不奇怪,不過也正因為如此,人類才能不斷地創新進步。

自己投身資訊電子產業二十餘年,我能充分體會了解,軟體開發人員對於新技術的躍躍欲試渴望之情,若有機會能不受限制地發揮創意,打造全新的東西,絕對會感到興奮無比。

不過,貿然全面拋棄舊系統,從頭打造新系統,卻是風險極高的行為,尤其是,當組織仍需仰賴舊系統進行大量業務活動之時。即便各行各業早有許多打掉重練的慘劇示警,可是大家似乎還是很難學乖,仍不斷上演著類似的劇情。

經驗老到的專案管理專家,絕不會同意「全面拋棄舊系統,從頭打造新系統」的決策。可是,在舊系統已不堪負荷,難以使用,業務又不可能為此停擺數個月的兩難之下,到底又該怎麼辦才好呢?


無米二:產品負責人與敏捷大師角色闕如或失能

要在翻新舊系統的同時,維持組織業務的順暢進行,的確不是件容易的事,就好像得邊開車邊換四個輪子趕路一樣。你絕對無法、也不該,在行進中同時更換四個輪子。

為了安全起見,我們頂多只能一次換一個輪子,而且還得先確認,司機有能力只用任何其他三個輪子,就維持住車子的平衡,持續前進。而有資格做這個決策的人,就是坐在這胎紋嚴重耗損的車上(老舊系統),還需趕時間去遠方(業務進行)的車主(產品負責人),他不但是車的 Owner,也是對業務負全責的人,既要安全,也要業務,缺一不可。

此嚴重延誤的老舊資訊系統更新專案,使用單位用戶眾多又強勢,意見廣泛卻常相互牴觸,但卻不見產品負責人(Product Owner)出來仲裁與決策,以致 IT 團隊只能先服務那些大聲又強硬的用戶,可是事後卻又常遭到其他用戶的抱怨和抵制,系統需求因此反覆難定,IT 團隊經常陷入「順了姑意,逆了嫂意」的窘境。

此例中,產品負責人嚴重失能,並非敏捷方法之罪。此外,頻繁出現這樣的狀況,亦不見敏捷大師(Scrum Master)出來協調,為 IT 這個開發團隊(Development Team)的效能把關、排除障礙,任由團隊資源被恣意濫用浪費,敏捷大師也嚴重失能,此亦非敏捷方法之罪。


無米三:關鍵開發團隊專家角色闕如或失能

換輪子的技師和司機就如同敏捷開發團隊成員,司機需要隨時關注車內技師的行動和車外的動態,以機動調整方向盤、油門和煞車,維持車輛平穩和速度;而技師們也需要聽司機的指示,什麼時候該暫停,什麼時候可以繼續。這就是團隊成員間的協同作業,整個團隊是集體行動的、有紀律的、榮辱與共的生命共同體。

然而,在此之前,還有一件更重要的事,那就是,得請原始車輛設計者告訴大家,四個輪胎的更換順序和時機,以及當下的適當安全車速,司機和技師們才能照表安全操完課。

這位原始車輛設計者,就像一個資訊系統的架構分析師(Architect),沒有他/她的妥善設計規劃,團隊很容易就會陷入沒有章法、各自為政的亂象,系統結構也很容易就被輕易破壞。此嚴重延誤專案,正好就缺乏這樣的關鍵開發團隊專家角色,此亦非敏捷方法之罪。

於此同時,敏捷大師事實上還必需隨時密切觀察、監控、協助團隊的協作(例如,防止有技師偷偷同時更換兩個輪子來炫技,影響全員安全抵達目的地),而此嚴重延誤專案的敏捷大師卻身兼開發團隊成員的角色,其花在開發工作的心力遠多過執行敏捷大師職責所花的心力,此為敏捷大師的失能,亦非敏捷方法之罪。


敏捷方法是巧婦,仍需好米與好灶

敏捷方法的確是巧婦,但你也得先給她米和灶才行,不論是白米、糙米,還是紫米,只要不是壞掉發霉的米,巧婦總是能炊出軟硬適中的香Q米飯。

話說回來,其實無論是傳統式還是敏捷式方法,都需要組織各級主管的全力支持,讓涉入流程方法的各種角色都能到位,都能發揮其應有的職能,否則,不論導入什麼方法,可能都難以讓專案做得又快又好,您說是嗎?

 

本文轉貼自:威廉網紙原文連結

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
盧鄭麟 William Lu

盧老師曾任HTC軟體專案經理團隊主管,掌管上百個智慧型手機軟體專案(包含全球首款WiMAX 4G手機),總出貨量超過 1,500 萬支。亦曾於趨勢科技、友立資訊、華康科技、文生真空科技等企業擔任研發部門主管、產品經理,以及總經理室協理等職務,領導軟體研發團隊與管理專案之實務經歷超過20年。 盧老師在教學上善於利用遊戲化教學,將真實情境轉換為模擬個案,引導學員透過動手實作來學習管理知識。授課經驗包含兩岸多家知名企業,例如台達電子、華碩電腦、揚智科技(台北/上海/珠海)、久元電子、飛宏科技、宜鼎國際、精技電腦、震旦集團、南僑集團 (上海)、杏輝醫藥集團、新北市政府等。