在我先前的文章中，我向大家介紹了「受控環境下的專案管理（PRINCE2）」這套經典的專案管理方法論，並簡述了它「四位一體」的架構（包含 7 大原則、7 大主題、7 大流程與裁適應用），也深入探討了第一項原則的內涵。如果你還沒看過，歡迎回頭複習，這能幫助你對專案管理建立更全面的認知。
今天，我們繼續來拆解 PRINCE2 這套方法論的第二項核心原則：「從經驗中學習（Learn from experience）」，或者我們常說的「吸取經驗教訓」。身為專案經理（PM），我們到底該如何把這項原則落實在日常工作中？而在實踐的過程中，又會遇到哪些難以克服的心魔與挑戰？現在，就讓我帶你一探究竟。
原則二：吸取經驗教訓
這項原則的核心要求很簡單：專案團隊必須吸取過去的經驗教訓，並且在專案執行的過程中，持續地發現、記錄，並運用這些經驗來應對眼前的挑戰。
其實，市面上有不少專案管理方法論（例如美國 PMI 所推廣的 PMP 體系）都強調過「經驗教訓」的重要性。但即便如此，我相信許多剛踏入專案管理領域的新手，並沒有真正理解這四個字的意義。
這讓我想到，在最初剛考到專案管理證照時，我的一位同學曾問過我一句話：「到底什麼是經驗教訓啊？」
歸根究柢，「經驗教訓」聽起來就像個抽象的概念，它不是看得見、摸得著的實體。當時的我也和這位同學一樣充滿疑惑：經驗教訓到底長什麼樣子？怎樣才算是經驗教訓？今天，就讓我用自己的實戰體會，為大家具象化這個概念。
什麼是「吸取經驗教訓」？為什麼它如此重要？
經驗，其實每天都散佈在我們工作的每個角落。除了我們自己腦中對於「麻煩事」的血淚認知外，更多時候是「別人」留下來的智慧。
如果要我用最簡單的例子來形容，「書」某種程度上就是經驗教訓的載體。 特別是那些技術類或工具書，裡面記載的往往是作者一路走來踩過的坑與解決方法。當然，除了文字，圖片、影片、語音，也都是傳遞經驗的媒介。
但這項原則不僅僅是「記錄」，它最重要的一面在於「吸取」。
試想一下：當你看過別人的書或教學影片後，你得知了前方某個轉角是條死路。下次當你拿著地圖走到那裡時，你就不會傻傻地撞牆，而是會提前繞道，順利抵達目的地。這就是「吸取」的意義——讓現在的團隊，不用再受前人受過的苦，讓專案能更順利地走到終點。
【軟體開發專案的真實情境】
以我所在的軟體開發專案為例，軟體的正式運行環境（即伺服器資源）通常需要一段時間來申請與建置。如果專案團隊直到「軟體開發完成」的那天才去申請資源，專案有極高的機率會面臨延遲。
但如果團隊「一開始就知道」這個地雷的存在，也清楚準備環境所需的前置時間，PM 就能在軟體完工前提前啟動申請流程。這一個簡單的「經驗教訓」，就能完美避開因缺乏伺服器而無法如期交付的窘境。
如果一個團隊不主動去查閱過去的經驗，就等於把專案成敗完全押注在「每個成員的個人智慧」上。
有時候運氣好，團隊裡剛好有個人踩過類似的坑，並主動出聲提醒，專案就能逃過一劫。而在大部分的情況下，這個「擁有個人智慧的人」，往往就是專案經理本人。你可能會發現，經驗豐富的 PM 所帶領的專案通常比較順利，這正是因為他們腦中有一個龐大的經驗庫。
但我將這種依賴個人經驗的模式稱為「超級英雄式專案管理」。對於企業來說，過度依賴少數英雄來撐起專案，其實是極度危險的。試想一下，如果這位資深 PM 身上同時卡了太多專案，或者突然生病、離職，他手上的專案必然會瞬間陷入混亂，嚴重影響最終交付。這對任何一家企業而言，絕對不是可持續發展的健康模式。
同時，缺乏企業經驗資料庫的團隊，只能無止盡地壓榨這些資深成員；而那些缺乏經驗的新手，則必須自己把所有的坑都親自踩破一次，才能換來成長。這對企業和個人來說，都是極大的資源浪費。
專案經理該如何實踐這項原則
其實，在我解釋概念的時候，答案已經呼之欲出了。簡而言之，實踐這項原則的第一步，說穿了就是一個字：「記」。
PM 與團隊成員必須把專案中發生的重要事件記錄下來（無論是文字、錄音或其他形式），核心關鍵是：要讓團隊裡的所有人，都能在需要時方便地查閱。
另一部分則是「查」。專案在執行過程中，要主動查閱前人留下來的紀錄，藉此調整做法來避開風險。很多人以為查閱資料庫是「專案啟動時」才要做的事，但我覺得這是不夠的。在專案毫無波瀾的時候看紀錄，你可能對裡面的警語完全無感；相反地，當你感覺專案「有點不太順利」的苗頭出現時，立刻去查閱資料庫，往往能帶來如獲至寶的幫助。
當然，有些人會反駁：「每個專案都是獨特的，看過去的資料庫沒什麼用。」
我同意專案具有獨特性，但專案過程中的「某個環節」，絕對與過去的其他專案有相似之處。所謂的獨特性，通常只是各種不同的小環節以不同比例混合而成罷了。只要資料庫夠豐富，絕對能找到可供借鏡的蛛絲馬跡。退一萬步說，就算真的找不到，對專案也毫無損失。
【我的實戰經驗分享：專案日記與 AI 知識庫】
每天快下班時，我會打開我的「專案日記」，記錄當天發生的重要小事：可能是跟客戶溝通的決議、發生的突發問題，或是我們找出的解決方案。
舉個真實案例：某次我們團隊的開發工程師在「串接外部系統」時，對方系統回傳了非預期的資料格式，導致我們的程式大當機（Bug）。雖然工程師本來已經寫好功能了，卻不得不回頭大幅修改程式碼，才讓系統恢復正常運作。
事件解決後，我馬上和團隊一起檢討發生原因，並制定了具體的防範方案。所以我在日記寫下這段話：
「未來在串接任何外部 API（應用程式介面）前，即使對方已經提供了規格文件，我們也不能預設立場以為自己知曉一切。團隊必須先和對方開會，逐一確認每一個資料欄位中，接收和發送的具體數值是什麼。此外，必須要求對方先提供『測試環境』與測試數據，以確保雙方對每一支 API 所傳送的內容具備完全的共識。」
這，就是我會寫進專案日記裡的內容。
當然，PM 每天忙得焦頭爛額，我也不是神，不可能什麼都知道，也不一定真的能「每天」記下所有事。但對我來說，「主動去記」才是這條原則的靈魂。 不管你是日更、會議後記錄，還是每週寫一次週報，只要有寫下來，就一定比大腦的魚的記憶來得可靠。
更棒的是，得益於現今 AI 技術的發展，我們現在記錄下來的東西，都能匯入專案的知識庫中。遇到問題時，PM 不用再像無頭蒼蠅一樣搜尋舊文件，只要用自然語言去「問 AI」，AI 就能從龐大的知識庫中精準抓取答案。這完美解決了過去「資料記了一堆，要用時卻找不到」的痛點。
透過我的經驗，希望能讓大家知道：實踐這項原則其實一點都不難，最大的阻礙，往往只是自己或團隊的「不作為」而已。
遵循此原則的挑戰：信、記、律
既然這項原則這麼好，為什麼實務上卻很少人能做好？我認為，困難點主要落在三個字上：「信」、「記」、「律」。
- **信（信任與謙卑）**這點特別容易發生在經驗豐富的「老鳥」身上。他們可能不信任過去的資料，也不屑去查閱經驗庫；就算查了，也可能無視前人的警告，堅持用自己的一套方法行事。這種自視甚高的態度，不僅會讓他們錯失有用的避坑指南，也難以察覺自身盲點。
- **記（記錄與脈絡）**當我們面對一張白紙，被要求「寫點經驗下來」時，最常發生的就是腦袋一片空白。很多人覺得專案每天都在做一樣的事，沒什麼好記的，於是把任務推給了「明天的自己」。另一方面，有些人雖然寫了，但缺乏前因後果。因為懶惰，預設「大家都看得懂」，結果寫出了一堆只有當下自己才懂的密語。時間一久，連作者本人都忘了當初寫那句話是什麼意思，這樣的記錄就毫無價值。
- **律（自律與習慣）**試想一下，主動查資料、寫專案日記，如果沒有高度的自律，通常不出一個月就會放棄。人類天生是短視近利的，對於「當下看不到立即成效」的事情往往缺乏動力。因此，想辦法讓「查閱」與「記錄」變成工作習慣，是不可或缺的。 你可以設定每日或每週定時的行事曆提醒，強迫自己靜下來回顧。哪怕只寫下短短幾句話，也絕對比什麼都不留好得多。
寫在最後：成為創造價值的 PM
雖然各大專案管理體系都在提倡「經驗教訓」，但在實務現場，多數的專案經理仍只專注於眼前的「產出任務」。
畢竟，你很難去考核一個 PM「今天有沒有去查資料庫？」就算查了，也不保證專案絕對不失敗。在沒有強制 KPI 壓力的情況下，「從經驗中學習」往往成了最容易被犧牲的原則。
但是，如果你是一位充滿好奇心、渴望持續成長的專案經理，認真實踐這項原則，將會是你與平庸 PM 之間最大的分水嶺。它能讓你的專案少走彎路、減少救火的頻率，並大幅提升成功率。
請不要成為那個眼光短淺、只看著眼前專案的人。把眼光放遠，透過累積與運用經驗教訓，將別人的智慧轉化為自己的武器，你將能在職場與企業中，發揮無可取代的巨大價值。
如果各位喜歡本文，歡迎留言討論。我是Andy，一位在小城中默默耕耘的專案管理者。謝謝。
