7.2 專案回顧與檢討
專案執行階段的管理當然重要——但真正讓下一個專案變強的,是這個專案結束之後做的事:回顧與檢討。
這一節會講怎麼把成果、流程、團隊與組織一起回頭看,並用結構化的方法,把值得重複的成功與值得避開的錯誤,都浮現出來。
為什麼要做回顧
專案一結束,大多數成員會立刻投入下一個任務。如果跳過回顧,通常會留下:
- 沒人能說出口的成功因素——所以也無法重複
- 會悄悄重演的錯誤與疏漏
- 卡在某個人腦子裡、永遠到不了團隊的洞察
回顧不是在追究過去的責任;它是一個策略性的動作,提高下一個專案成功的機率。
回顧的四個面向
要看得完整,從四個角度看專案:
- 成果:目標達成了嗎?品質、交付、成本、滿意度
- 流程:規劃、進度追蹤、變更管理運作得好嗎?
- 團隊:協作、角色、溝通清楚嗎?
- 環境:外部因素——利害關係人、組織結構、工具——合適嗎?
同時看四個面向,對話就會超越「這次走得好/不好」,走向有真正深度的洞察。
檢討方法:KPT、5 Whys、360 度回饋
KPT(Keep / Problem / Try)
- Keep:進行得好、應該繼續做的
- Problem:進行得不好的
- Try:下次想嘗試的改善點子
5 Whys
連問五個「為什麼?」,把問題追到根。它會把你從表象推到真正的原因。
360 度回饋
從所有相關人那邊收集回饋,讓團隊從多個角度看見自己——把任何單一視角都看不到的動態揭露出來。
用 AB 進行回顧
AB 給回顧一個能站的基礎:
- 回放任務的歷史與留言,看決策實際上是怎麼流動的
- 用燃盡與甘特檢視分析節奏,看延遲在哪裡冒出來
- 把回顧範本(KPT 格式)以共用文件的形式分享
- 用匿名留言或問卷蒐集真實的回饋
結果是以事實為基礎、以對話驅動的回顧——而不是一場記憶比賽。
怎麼讓回顧真的留下來
要避免回顧滑落成儀式:
- 把它排進收尾裡,不是當成可選項
- 讓整個團隊參與,不只是 PM
- 把對話框成「未來的改善」,而不是究責
- 把產出回灌到下次的專案範本與 WBS
結論:回顧能引發改善
回顧不是在後悔過去——它是在設計一個更好的下一次專案。把洞察變成團隊共有的知識、而不是個人的心得,就是會學習的團隊的標誌。
在 AB 裡長這樣
在 AB Project Management 裡,在專案 Wiki 裡有一頁「回顧」,以下一個團隊找得到的格式保存 KPT。把它從專案首頁釘起來,讓未來任何人第一個看到的就是它。標籤為「Lesson」的任務,則承載著有負責人的個別心得——透過 MCP 連線的 AI 助手,還可以被請求來總結…