傳產也可以運用敏捷思維，提升專案管理效率的 3 個關鍵

keariaouo@gmail.com — Wed, 18 Jan 2023 09:30:17 +0000

近年來火紅的敏捷，是在 1990 年代被提出，用在開發軟體的專案管理方式，重視成果交付、迭代，順應變化，相信在專案管理領域的工作者都不陌生。敏捷不僅只有字面上的快速而已，而是追求團隊的高效及品質。前陣子大人學發佈的 2020專案經理產業調查報告中也特別將敏捷式開發列入調查主題，然而其中有 65.3% 公司未採用敏捷式開發，也有 70.4% 專案經理未在工作中使用敏捷開發，不過仍有 45.4% 的專案經理對敏捷抱持開放、想嘗試的態度。

顯然敏捷在企業中的運用與落實還有發展空間。而面對高效的專案管理方法，非軟體業難道只能望洋興嘆嗎？以下分享我在傳產製造業的自身案例，透過敏捷思維改善專案的經驗的 3 個步驟，以及簡單分享何謂敏捷工作法 OTPR。

故事的主角 K 剛從原單位調轉過來半年，是負責新專案的設計師，配合部門常一口提出好幾個臨時需求，而且需求日不明確，每個都是越快越好的急件。我看她一進辦公室就黏在座位上，已經連續好幾週加班超過晚上 8 點了，加班也沒吃晚餐，手上似乎永遠有畫不完、改不完的渲染圖，原本身形就嬌小的她，連續熬夜看起來更加羸弱憔悴。

好不容易那天 K 設計師交付了這幾週加班產出的設計圖，其實眼看著品質不如預期的圖面，連我心中都犯嘀咕，更遑論其他高標準的各部門主管了，在群組中受到主管們嚴厲的批評和無情打槍，她終於按耐不住情緒，走來我主管身旁，想了解到底是哪裡不滿意。她臉漲紅著越講越激動，眼眶含著淚水，氣氛相當凝重，我們基於同理心，有耐心地聽完陳述，一方面安撫她的情緒，告訴她現在手上這個急迫的專案應該沒機會調整成常規進行步驟處理，但接下來的案子我們將從旁協助，改善流程，避免重蹈覆徹。

大致上了解問題以及與 K 設計師詳聊工作狀況後，我在一週內進行以下調整：

一、召開啟動會議，明確定義需求

身為末端執行單位，我仍然發起一個啟動會議，主管請我在專案中溝通協調、釐清需求，並且串接各部門的交付物。會議上我在各部門主管面前將各工作項目的合理的工作日明定下來，未來專案的需求全都比照處理。除此之外，請需求單位詳列出所需圖面的確切需求日、配合單位的交付日，排定優先次序，當真的有臨時的急件安插進來時，才得以辨別專案中重要、有價值的事情，引導專案朝合理的方向前進。並且我們在會議上確認專案的需求與目的，對齊所有部門主管看待交付物品質的共識，在跨部門溝通上也比較不費力。

二、專案 size 切小，逐步交付

K 設計師平時很少遇到主管，通常一週只見一次面，而 K 便會將手頭上的工作累積到一定的量後，在見面時一口氣提出來，因為數量可觀，如此一來主管提供回饋的時間跟著往後延，再加上修改也是一次得改很多，時常無法準時交付。我建議她將專案的任務再細拆，把專案 size 變小，執行任務的期間從 1 週縮短為 0.5 或 1 日，2~3 天就把手上進度給主管確認，若遇上需要調整至少量不會太龐大，增加工作效率。

三、持續迭代，致力於提供有價值的事

每個專案投注了時間和眾多人力，過去較少針對專案的價值進行效益評估，除了在結案留下 lessons learned 描述專案的成果，無論好壞都將專案經驗傳承外，在過程中只要遇上值得檢核的問題、寶貴的經驗都可以記錄下來，即使是從失敗中學習，也是有價值的，也降低日後踩雷的機會。

然而敏捷式管理要大刀闊斧導入不是件容易的事，不妨先從小的專案著手進行，將任務切小、執行站立會議。站立會議顧名思義是站著開會，每次會議 15 分鐘，每人發言不超過 3 分鐘，只聚焦在「昨天完成了哪些事」、「今天的規劃」、「碰到的問題」。不過以我自己而言，雖然與主管的溝通相當密切，但與主管並非每天都會見面，站立會議在公司還是無法落實，就把它轉為文字用通訊軟體來陳述，就像回報工作進度般，讓主管掌握狀況，需要主管出馬協調的事情也適時反映。