同樣的坑，為什麼每半年都要再踩一次？
有些工作上的問題很奇怪。你第一次遇到的時候，大家忙得要死，開會、找原因、問人、翻紀錄、找廠商、改設定，最後終於解掉。當下每個人都會有一種感覺：
「這次真的學到了，下次一定不會再發生。」
結果半年後，差不多的問題又出現，然後所有人又開始：
「這個以前是不是有遇過？」
「我記得好像有。」
「是不是某次上線有發生？」
「那時候是誰處理的？」
「以前好像有一份文件……」
最後還是重新調查一次。
這種時候我常常會想：
我們到底是真的學到了，還是只是當下把事情解掉了？
問題被解決，不代表經驗有被留下
這兩件事情其實差很多，一個 Bug 修好，代表問題解決了；一個版本順利上線，代表這次專案完成了；一個客戶抱怨被處理，代表事件告一段落。
但這些事情結束之後，真正有沒有留下：
為什麼會發生
當時怎麼判斷
哪一條路試過沒用
最後怎麼解決
哪個地方最容易漏
下次應該提前做什麼
這就不一定了。
大部分時候，我們留下的是「結果」，卻沒有留下「經驗」。
系統裡常常只剩下最後一個狀態
例如一張 Bug 最後會變成：Closed
一張 Task 最後會變成：Done
一個 Release 最後會變成：Released
這些狀態都沒有錯。
但它們幾乎沒有告訴下一個人：
「這件事情為什麼值得注意？」
假設半年後又有一個類似的第三方 API 專案。
你搜尋到以前的 Task。
上面寫：串接 Vendor A API
狀態：Done
你還是很難知道：
這個專案其實曾經因為正式環境 whitelist 晚了兩天，差點延期、QA 當初還漏測 timeout、Production YAML 也曾經少改一個欄位。
這些才是真正對下一次有幫助的東西。
可是通常，它們都留在人的腦袋裡。
我們很常把「經驗」誤會成「文件」
這也是一個很常見的情況。
有人會說：「我們有文件啊。」
確實有，SOP 有、需求文件有、技術文件有、Release note 也有，但文件不一定等於經驗。
文件比較像是在描述：「正常情況應該怎麼做。」
經驗則比較像：「實際做的時候，哪裡最容易出問題。」
例如 SOP 可能寫：
確認正式環境設定
確認 API credential
確認 callback URL
執行 QA
看起來都很合理，但真正的經驗可能是：
Vendor A 的 Production credential 通常比 QA 晚提供，至少要提前三天追。
或者：
這個遊戲商文件裡寫的 timeout 值和正式環境實際不同。
又或者：
上次不是 API 本身有問題，而是代理層多了一個 cache。
這些才是團隊真正花時間換來的東西。
可惜的是，這些東西最容易消失
因為它們通常不是正式欄位，它可能出現在：
某個 Slack thread
LINE 群裡的一段對話
某個人的私人筆記
會議最後一句話
Bug 裡的一則 comment
PM 腦袋裡
RD 的記憶裡
事情剛發生時，大家都記得。一個月後，只剩部分人記得，半年後，就變成：
「我記得以前好像有發生過。」
再過一年，如果當初的人已經不在團隊裡，這件事情可能就完全消失。
團隊真正流失的，很多時候不是人，而是人的判斷
我們常常會說：「某某很資深。」
資深的人厲害在哪裡？
很多時候不是因為他記得所有文件。
而是他看到一個狀況時，會說：
「這個你先不要急著做，我覺得可能不是這裡。」
或者：
「這家廠商你最好提早問正式環境。」
又或者：
「這種 Bug 如果只在 iOS Safari 出現，先看 Cookie。」
這些判斷看起來很快。
但背後其實是很多次踩坑累積出來的，所以一個資深同事離開團隊時，真正帶走的往往不是文件，而是：
很多沒有被寫下來的判斷方式。
新人真正缺的，也不是更多 SOP
新人進來，大家通常會丟很多東西給他，文件、SOP、流程、系統帳號、歷史紀錄，這些當然都需要，但新人最常卡住的不是：「流程怎麼走？」
而是：
「什麼情況要特別小心？」
「這個供應商是不是比較麻煩？」
「這種問題通常要先找誰？」
「這個看起來很急，實際上重要嗎？」
「這個流程哪一步最容易漏？」
這些內容，很少會完整出現在正式文件裡。
它們通常叫做：經驗。
我後來開始覺得，每一個「事件」都可能是一筆資產
這也是我做 PMORY 時，慢慢改變的一個想法。
以前我會把 Task、Bug、Release 當成工作紀錄，做完就結束。
後來我開始覺得：
每一件事情其實都可能是未來的教材。
例如：
一個 Bug，不只是 Bug，它可能告訴我們：
某種裝置在某個條件下特別容易失敗。
一個 Release Delay，不只是延期，它可能告訴我們：
某類型外部依賴平均需要比原本預估多三天。
一個需求被退回，不只是返工，它可能告訴我們：
這類需求如果一開始沒有先確認營運規則，後面很容易重做。
所以我會很喜歡一句話：
事件是一次性的，但經驗可以重複使用。
但也不是什麼東西都要進知識庫
這一點我反而很保守。
如果什麼都存，什麼都叫經驗，最後一定會變成另一個垃圾場。
例如：
「今天 PM 說晚點再看。」
這不是經驗。
「RD 說這個先改一下。」
也不是。
真正值得留下的，應該是那些：
未來遇到類似情況時，會幫助我們做出更好判斷的內容。
例如：
為什麼失敗
怎麼修正
哪個方法有效
哪個方法沒效
哪裡容易漏
有什麼前兆
下次應該提前做什麼
這些才值得沉澱。
所以我會希望「經驗」是事件之後的一個小動作
不是要大家每次結案都寫一篇三千字心得，那一定不會有人做。
而是像這樣：
某個 Bug 關閉。
系統問：
這次有值得留下的經驗嗎？
你可能只寫三行：
原因：
Production whitelist 與 QA 不一致
影響：
正式上線延後半天
下次：
Release 前一天再次確認正式環境 whitelist就夠了。
或者一個 Release 做完，PM 補一句：
這次 QA 太晚介入，下次這種類型至少提前三天送測。
這些小小的紀錄，長期其實非常有價值。
我覺得真正重要的不是「有沒有寫 Retro」
很多團隊也會做 Retro。
這很好，但 Retro 有一個常見問題：
當下講得很好、白板上寫得很好、最後大家拍張照，然後下一個專案開始。半年後誰還記得那張照片？
所以 Retro 真正重要的不是：
「我們有沒有開這場會。」
而是：
這次學到的東西，下一次有沒有真的被用到。
如果沒有，那 Retro 很可能只完成了反省，沒有完成學習。
這就是為什麼我後來很在意 Memory
我做 PMORY 的時候，真正開始覺得有意思的，不是 Task 越做越多。
而是：
如果這些 Task、Bug、Release、SOP、文件，最後都可以慢慢累積出一個團隊自己的 Memory，會發生什麼？
假設你下一次新增：
串接第三方 Payment API
系統不是只看到一張新的 Task。
而是可以回頭找到：
以前做過的類似 Task
當時發生過哪些 Bug
哪一個 Release 曾延期
哪份 SOP 曾經補過
哪一筆經驗提過 whitelist
哪個供應商曾經出過相同問題
然後提醒你：
這類工作過去曾經在正式環境設定上出現問題，建議這次提前確認。
這時候，我才會覺得 AI 真的開始有點像「經驗傳承」。
而不是一個比較會說話的搜尋框。
AI 真正需要的，其實不是更多 Prompt
很多人談 AI，會一直研究 Prompt。
Prompt 當然重要。
但如果 AI 根本不知道你們團隊以前發生過什麼，再漂亮的 Prompt 也只是請它用一般常識回答。
例如你問：
這次上線有什麼風險？
沒有歷史資料的 AI，只能回答：
記得測試
記得備份
記得 rollback
記得確認設定
這些都沒有錯，但也很普通，真正有用的是：
你們團隊過去五次類似 Release，有三次都在 Production config 出問題。
這才是團隊自己的智慧。
所以「AI 越用越聰明」之前，要先做到「團隊越做越有記憶」
我覺得這個順序很重要。
不是：
先買 AI
↓
AI 自己變聰明而是：
事情發生
↓
留下結果
↓
整理經驗
↓
累積 Memory
↓
下次 AI 才有東西可以參考如果前面這幾步沒有做，AI 就沒有真正的養分。
這件事情長期最有價值的地方，其實是「人可以換，但經驗不一定要歸零」
團隊一定會有人來，也會有人走，PM 會換、RD 會換、QA 會換、供應商也會換。
如果所有經驗都綁在人身上，那每次人員變動，團隊都要重新付一次學費。
但如果重要經驗有被留下，新人接手時就不是：
「從零開始。」
而是：
「從前人的經驗開始。」
這兩者差非常多。
最後
我現在越來越覺得，專案管理真正值得留下的，不只是：
做了什麼。
更重要的是：
做完之後，我們知道了什麼。
Task 可以完成。
Bug 可以關閉。
Release 可以上線。
SOP 可以勾完。
但如果事情結束後，所有判斷、踩坑、修正方式也跟著消失，那下一次遇到類似問題，我們還是得重新來一次。
所以我覺得一個團隊真正變成熟的指標，不一定是：
「做得越來越快。」
有時候反而是：
同樣的錯誤，越來越少需要重學。
這也是我開始做 PMORY 之後，很想留下來的一件事情：
不是讓系統只記得工作做完了。
而是讓它慢慢記得：
我們是怎麼把工作做好的。
下一篇，我想接著聊：
AI 專案管理，真的不是多一個 Chatbot 就叫 AI。
留言
張貼留言