兩次深刻復盤：我以為在解題，其實連題目都看錯

之前提到要寫關於復盤（反思）的文章，這個想法在我腦中躺到都長灰塵了。
想到要從早期的文件重新檢視那些現在看來淺顯易見的錯誤，同時也得面對自己當初的不足，心裡的抗拒比想像中大太多了。畢竟剛轉職時踩過的坑又痛又深。趁著過年長假慢慢寫下來，總算把這段思考整理完成。如果你也對復盤在實作中的實際應用有興趣，以下紀錄我的思考歷程。

工作一段時間之後，我發現過去很多錯誤不是因為技術不好，而是因為太快開始解題。過去習慣看到問題就動手優化、修正、調整。好像只要把手段做漂亮，事情就會自然變好。

但有時候，真正應該先做的，是停下來確認：這個問題本身對嗎？我們要解的到底是什麼？成功的定義是什麼？那些「看起來理所當然」的前提，真的成立嗎？

這篇文章是我用現在的視角，回頭檢視兩年前的自己，並紀錄我當時怎麼利用復盤跟反思，一步步改正自己的思考習慣，把自己從「急著答題」拉回「先把題目問清楚」。用兩個印象很深的踩坑案例，拆解我剛當工程師時在驗證標準、責任邊界、以及對既有邏輯的假設上，常犯的錯。

情境回放：電子發票上線的意外 — Staging OK 卻卡在 Production

2023 年我做了發票系統，但是沒有在當季完成預期進度 — 電子發票上線 production。我把當時的情境跟思維詳細做了紀錄，並對低於預期的事情進行不斷地向下追問。（復盤時細節越完整，越能看清自己當時站在哪個思考層級）

第一輪復盤：我只檢討自己不夠細心

Ｑ：為什麼這一季只有達到電子發票功能 A/B 測試上線 production，而非完全上線？

• 要做上線測試時，才暴露出需要新增發票字軌的問題（類似發票的身分證，對發票的時候為用到的那串英文 + 數字），導致多花了一週時間做申請，A/B 測試時間也跟著 delay，無法按照預期進度
• 新增發票字軌並沒有放進要確認的項目之一，staging 測試環境並不會遇到這個問題，因此在測試的時候無法及時發現
• Ｑ：為什麼會在測試的時候才發現有這個問題？
  • 後期主要規劃人員休假，其他負責執行的人員也沒有檢查到這塊，另外當時合作平台只有提到開通就可以用電子發票了，但實際上開通需要的東西不只這些。
  • 當時我給自己的結論是：若接手人員為後期加入，即使 OKR 已經有整體規劃，參與時仍應該將串接外部 API 流程文件跟內部相關文件看過並確認是否遺漏

雖然嘗試用 Why-Why-Why 去復盤，我實際上是一直在檢討自己是不是不夠仔細。提問問題都圍繞著：「怎麼沒看清楚文件？」、「怎麼環境沒對齊？」，當時我以為，只要再仔細一點、把文件看清楚、把 checklist 寫完整，下次就不會再發生。後來才意識到，我根本沒有問對問題。

被點醒的時刻：他問的不是「哪裡漏了」，而是「你怎麼定義完成？」

我把字軌漏掉這件事寫進復盤後，其實很快就得到一個看似合理的結論：下次要更細心、文件要看清楚、checklist 要寫更完整，最好把外部 API 流程跟內部文件都過一遍。

資深工程師看完，沒有先問我「你漏了什麼」，而是反過來問：

Q：為什麼在 Staging 階段沒發現問題？

我第一反應其實是把責任往流程上丟：規劃的人休假、後面接手的人也沒注意到。

他聽完之後看了我一下，接著追問了一句讓我卡住的：

Q：那你當時怎麼判斷「這季完成了」？你測試的標準是什麼？

我心裡其實一直有個默認的標準：「Staging 測試 OK = 功能完成。」既然 Staging 是 production 前的保障，那測過了就算完成。

我把測試重點放在驗證程式邏輯能不能跑、API 回傳有沒有符合預期——但其實只代表邏輯在一個受控環境下可以運作。

他又問了一句：

Q：如果程式碼都對了，客戶還是拿不到正確的電子發票，你會覺得任務完成嗎？

這句話直接把我拉出原本的問題層級。
因為這個 OKR 的目標不是「程式碼可以開出發票」，而是「開立正確的電子發票給客戶」。如果照著這個目標去驗證，我會去確認 Production 的配置、字軌是否申請完成、發票最終呈現是否正確，甚至和 PM 做最後的產出確認。我停在 Staging，因為那是我習慣的完成定義。我測的是系統內部邏輯，他看的是業務結果。

回頭想想，我為什麼會把這件事排除在自己責任之外？

因為我潛意識把「申請字軌」歸類成 PM 的事，認為工程師只要把程式邏輯寫對就好。我把「開發職責」跟「業務達成」切得太開。
他其實不是在跟我討論程式碼，而是在提醒我：只要發票沒有成功開給客戶，任務就還沒完成。

以下是當時候被給予的回饋：

在做功能上線前的 QA，目標應該著重在是否解決問題，而不只是程式碼的運作正確。

原來我們在講的是不同層級的問題

被提點之後我才意識到，我做檢討時站的層級，和他完全不同。那種落差大到讓我一瞬間覺得自己很渺小。原本我覺得自己只是「不夠細心」，沒有再查看官方文件。但他其實在質疑的，不是是否細心，而是我對「測試成功」的定義。

那種感覺很奇怪，很像是思維被硬生生拉出舒適圈——當下還一知半解，他說的都對，但是我不曉得怎麼問他，因為我根本從來沒想過那一層。
現在回頭看，這類錯誤在當時其實是必然會發生的，畢竟自己根本沒有站到那個層級去思考。

以為學會了，卻又在同樣的地方跌倒

事實上就算當時被當頭棒喝，在後續任務中仍然有可能犯同一種錯誤，畢竟解題習慣已經深植我的腦神經，一個不留神就會拉回舊路線，是需要自己一直提醒，才能建立新的思維跟習慣。

第二個坑：被「複雜」迷了眼

就在我以為我經過上次的反思之後，我又變強了！！！已經學會「先確認目標再動手」之後，很快又掉回舊路線。

Follow-up 信件 Timeout 的任務。看起來很明確：資料量太大、SQL 太慢，舊功能已經不適合現在。我幾乎沒有懷疑問題本身，就直接進入優化模式。加 index、改查詢、調整結構。我假設這段 SQL 既然存在，就一定有它的理由。

我做的是最優雅的解法嗎？

我以為自己在解決問題，但資深工程師沒有急著優化，而是先回頭確認業務邏輯。他指出，其實根本不需要確認最後一次寄信時間。原始的 SQL 變成超簡單，也直接解決了效能問題。

當下我真的笑了出來。作為接手者，我理所當然地假設這段複雜的 SQL 必有其道理，畢竟是前人留下的，一定考慮過我沒想到的 edge case 但它根本不需要被優化，而是應該被直接超渡。我差點就成了那種「用最厲害的技術，去解決一個不存在的問題」的工程師。

這次我特別去問他，為什麼他能第一時間往那個方向想。他只說了一句話：「修 bug 前，先確認業務邏輯，不然可能只是優化了一個不該存在的東西。」

兩次踩坑，一個共通點

回頭看這兩個踩坑經驗，我意識到問題不在技術難度，也不是解題能力，而是我在定義問題時就已經站錯位置。我太急著當一個「答題者」——看到問題就想立刻給出解法，而不是先質疑問題本身是否成立。電子發票那次，我接受「Staging OK 等於完成」的假設。SQL 那次，我接受了「既有邏輯一定合理」的前提。我沒有質疑問題本身，只是在優化它。

從「知道」到「做到」的漫長內化

第一次被點醒時，我以為自己學會了。但第二次任務來臨時，我的第一反應還是衝進去修 SQL。理解和做到之間的距離遠比想像中長。看到初始問題的瞬間太開心，帶著「這題我懂的！！」興奮感，馬上衝去解題，快到我還來不及停下來問：這個問題真的成立嗎？

那些寫在復盤裡的提醒，不會自動變成直覺。它們需要一次又一次地被驗證、被打臉、被修正。或許成長不是不再掉進同一個坑，而是能更早意識到自己正往坑裡走。

成長不是不再出錯，而是更快察覺

事過兩年多後回頭看，我已經比較能看清當時的思維盲點。現在動手前，我會刻意停一下，重新定義完成。

但我也知道，這些不是一次就學會的。那些現在看起來理所當然的反射動作，都是經過好幾次跌撞才慢慢內化的。 或許成長不是不再犯錯，而是能看懂自己為什麼會犯錯。也或許幾年後，我會再回頭看這篇，明白現在的理解仍然有限。但至少現在，我知道自己曾經站錯在哪裡。

後記

新年期間出去外面走了一圈。平常安靜的巷子，過年忽然變得擁擠起來，車子貼著車子停。兩側門口的春聯也都很新，紅得很乾脆。
記得以前馬年，春聯總愛寫「馬到成功」，那種祝福有點老派，但聽起來還留著一點從容。

今年卻幾乎清一色是「馬上有錢」。字寫得又大又亮，貼得格外用力。
走在路上，看著一整排門口同樣的願望，
門一扇扇排開，話也說得很白。

或許不只春聯如此。我也曾這樣直奔答案。