為何敏捷式專案管理在我組織內效益普普,諸多問題依舊?


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

    副執行長首先說明其管理眾多專案時的痛點,接著 IT 主管說明其專案執行的實際做法與相關痛點,從上到下的觀點都表達得相當清晰,我把它們歸納如下。
    1. 團隊對專案的進度延誤不痛不癢。
    2. 缺乏掌握專案整體全局視野的人員。
    3. 各單位對自己的需求講不清楚、說不明白。
    4. 各單位立場迴異,需求經常互相衝突,專案執行單位無所適從。
    5. 即使需求互不衝突,也無人可以整合各方需求,理順工作流程(work-flow)。
    這些痛點乍聽之下相當複雜,但在我看來,其根本原因與多數組織的專案管理經驗並無太大不同。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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