這2件事沒做好,「敏捷式管理」將難以發揮功效

這2件事沒做好,「敏捷式管理」將難以發揮功效

日前與前來邀課的客戶進行課程對焦會議,與會人員有副執行長、承辦人資以及 IT 主管,涵蓋了高層決策主管與關鍵受訓對象,會議成員組成完整,人人謙沖樸實,顛覆了我對該組織原有的一些刻板印象。

副執行長首先說明其管理眾多專案時的痛點,接著 IT 主管說明其專案執行的實際做法與相關痛點,從上到下的觀點都表達得相當清晰,我把它們歸納如下:

1. 團隊對專案的進度延誤不痛不癢。

2. 缺乏掌握專案整體全局視野的人員。

3. 各單位對自己的需求講不清楚、說不明白。

4. 各單位立場迴異,需求經常互相衝突,專案執行單位無所適從。

5. 即使需求互不衝突,也無人可以整合各方需求,理順工作流程(work-flow)。

 

這些痛點乍聽之下相當複雜,但在我看來,其根本原因與多數組織的專案管理經驗並無太大不同。

根據 IT 主管說法,IT 單位已自行實施敏捷式專案管理方法好幾年了,照理說,這個組織對於敏捷式專案管理的手法應該已經相當熟悉,可是不知道為什麼,卻還有這麼多的痛點,並且痛到下定決心尋求外部顧問的協助。

我想,客戶的組織不是缺了兩個重要角色,就是這兩個重要角色因某些因素(如組織結構設計)而無法發揮應有的功能。這兩個角色分別應執掌:(一)統籌協調一個產品或系統的所有相關需求並負完全成敗責任(二)領導相關人員如期完成一個產品或系統。


1. 統籌協調一個產品或系統的所有相關需求並負完全成敗責任

一般而言,商業組織都需要不斷打造新產品或服務,以對外銷售,營利生存。然而,組織也往往需要打造不少的系統供內部使用,以提升組織營運績效,本文客戶案例即屬後者。

對外銷售的產品或服務,我們通常有產品經理的角色來統籌協調一切相關事宜,可是供內部使用的系統卻經常缺乏這樣的角色,正因為如此,內部用系統才更容易功能逐漸發散、複雜化,並且無人聞問。

舉個例子,去年財會單位的某用戶 A 向 IT 單位提出過系統需求,IT 單位派甲工程師照需求修改系統,今年同單位的某用戶 B 又向 IT 單位提出另一需求,IT 單位再派乙工程師照需求去修改系統,如此運作幾年下來,結果這個財會系統變得愈來愈難用。原因可能就在於,A 和 B 完全沒有協調討論過,甲和乙也在不同的時空去更改系統,可能也都沒有商量過。

您也許會問,IT 單位不是應該有系統分析師(System Analyst)的角色來統籌管理這些相關的需求和系統變更嗎?Well,這就得看組織是否有明確賦予系統分析師這樣的責任,以及系統分析師自己對一個系統的 ownership 而定了。

就我觀察,系統分析師多半只做到「把需求『翻譯』成工程人員聽得懂的語言」,以讓工程人員可以開工,而這裡的『翻譯』卻常缺乏「與既有使用者經驗完善融合」的完整一致性考量,這樣就容易造成原本良好的使用者經驗被一點一滴地侵蝕破壞,讓整個系統愈來愈沒有整體一致感,像隨意拼湊出來的東西。

那麼,到底誰應該扮演一個內部系統的產品經理角色呢?以財會系統為例,我認為,該系統的重度使用者最合適擔任此系統的產品經理,而非財會主管,只要主管能充分尊重並授權此人做決定即可。

這樣建議的理由是,重度使用者通常使用最廣泛的系統功能,也使用得最為頻繁,各種體驗相對深刻,而財會單位主管卻未必能達此境界。此外,坦白講,主管也未必有空或有意願去深入瞭解這麼多的旁枝細節,並及時給 IT 單位回饋。

此產品經理的角色,在敏捷式專案管理的做法,就相當於產品負責人(Product Owner)的角色。


2. 領導相關人員如期完成一個產品或系統

據此客戶的說法,IT 部門內已經成立了一個專案管理小組,下轄三位專案經理,而專案經理的角色在敏捷式專案管理的做法裡就相當於敏捷大師(Scrum Master)的角色,這個部分初步看來沒什麼大問題,但有些專案經理和敏捷大師之間職責差異的細節,倒是可以再注意一下。

例如,在敏捷式專案管理做法下,向專案贊助人等級的上級主管(也就是副執行長)做進度報告的人應該是產品負責人,而不是敏捷大師,因為審查驗收開發團隊成果,並向客戶(副執行長)報告進度的就是產品負責人。

敏捷大師是一個「不斷想辦法提升開發團隊效能(包含排除團隊障礙)」的領導者角色,進度是由開發團隊自己承諾並承擔的,因為敏捷團隊應該事先已經得到了來自高層的高度自主運作授權。

關於工作流程(workflow)的設計,可能會牽涉到跨職能單位的溝通協調,也就是跨產品或跨系統的溝通協調,可以由系統分析師召集相關的產品負責人一起討論制定,這樣才能在保持系統完整性與一致性的前提之下,盡可能滿足各方的需求。

 

為什麼要花錢花時間上課?

網路上的確有很多 Scrum 敏捷式專案管理方法的相關資源可以參考,不過這些資訊不是瑣碎片段,就是以純軟體專案開發為觀點,對於非軟體開發背景的人來說,實在難以消化理解。

加上 Scrum 的原始設計極為精簡,以致於許多自學者,在不了解各種設計的背後原因之下,就匆匆導入,誤以為這樣就可以迅速看到成效,其實,這是對 Scrum 敏捷式專案管理方法的一大誤解。

本客戶在自行嘗試施行 Scrum 敏捷式專案管理方法多年,遭遇許多不明原因困境後,並未因此歸咎於方法本身,也未因此而放棄敏捷方法,反倒是開始深思自省,向外尋求專業顧問/講師與系統化的課程,以求精進,更上一層樓,這樣的學習態度讓我非常敬佩。相信,這個組織在專案管理上,很快就能夠大幅躍進。

 

本文轉貼自:威廉網紙(原文標題:為何敏捷式專案管理在我組織內效益普普,諸多問題依舊?

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

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