大神的不可替代性，有一半只是「他比你早知道使用者會說什麼」。Review 做的事很樸素：不猜、不查任何人的記憶，直接讓本人動手。

兩週到了，拿給誰看

昨天第一條路走通了：一筆測試訂單，從按下退款、金流受理、webhook 回來改狀態，到畫面亮出結果，整條線是通的；第二刀也加寬了錯誤路徑與重送防護。兩週的節奏走到底，來到 Review。

Review 前一天，有人開始做投影片：架構圖、完成清單、下一步規劃。做得很認真。

PM 看了一眼，把投影片收了。隔天的 Review 改成這樣安排：

會議室裡擺一台客服平常在用的那種電腦，接測試環境。客服主管坐在鍵盤前——不是看展示，是自己操作：自己挑一筆測試訂單、自己按下退款、自己等結果。財務人員手上有一份真的對帳檔——金流商日結、對帳檔隔天才有，所以團隊前一天就先退了一筆，讓今天桌上有帳可對。

工程團隊的任務只有一個：不講解、不代操作，看，然後記。

三十分鐘後，兩個沒有人想到的問題被放上了桌。

第一個發生在客服主管按下退款後的第七秒。畫面顯示「處理中」。她停下來，回頭問：

「這是當掉了嗎？我要重按嗎？」

團隊一時沒反應過來。「處理中」是 Day 18 之後全隊最引以為傲的三個字——它誠實、它尊重非同步的現實、它寫進了 AC 而且驗過了。當掉？

她解釋她的世界：客服操作退款的時候，客戶多半正掛在線上等。她需要的不是一個誠實的狀態，是一句可以轉述給客戶的話——申請收到了沒有、大概要等多久、結果出來誰會告訴我。「處理中」三個字，一題都沒回答。在她的經驗裡，畫面停住又不講話的系統，就叫當掉。

有工程師差點脫口而出「重按也不會重複退，我們有防護」。話吞回去了——防護擋得住重複退款，擋不住她根本不該需要猜這件事。

第二個問題出在財務這邊。她把昨天那筆測試退款跟對帳檔對了一遍，單號、金額都對得上——AC 最後一條，過。然後她問：

「退款原因記在哪裡？」

人工時代，客服開給財務的單子上有一格「原因」，月底結帳要照原因歸類。新系統把開單流程整個做掉了，那一格也跟著消失。金額對得上，帳還是做不完。

會議室當場的決定：兩個都改，排進下一輪。「處理中」的文案補上已受理、請勿重複操作與後續通知方式；退款申請加一個原因欄位。沒有人加班，沒有人覺得被推翻，Review 準時散會。

當時團隊怎麼理解 Review

回頭說前一天那份投影片。做投影片的人沒有錯，他只是照著多數人對 Review 的理解在準備，而那套理解每句單獨看都有道理：

Review 就是成果發表，要讓利害關係人放心；Demo 要挑穩的路徑走，當場出包很失禮；操作交給最熟的工程師，比較流暢；意見嘛，會後再收就好，會議時間寶貴。

合在一起，就是 Day 03 那個對照組的 Review：觀眾是主管與 PM，簡報者控制路徑，全場確認的是「進度有沒有跑」，沒有人確認「方向有沒有對」。三個月後，做完的東西有一半要重做。

這個團隊在第三部也付過一次同樣的學費：上一次「拿成果給客服主管看」，她一連說了三個「不是這樣」（Day 19）——而那時候，程式已經在錯的假設上蓋了三週。

Review 到底在確認什麼

先看一個值得停下來想的事實：這條切片，五條 AC 全數通過，Review 仍然挖出兩個要改的地方。

這不是 AC 寫得不好。這是 AC 跟 Review 本來就在回答兩個不同的問題：

Acceptance Criteria 驗的是
→ 做出來的東西，符不符合「說好的」
→ 有沒有把東西做對

Review 確認的是
→ 「說好的」，是不是你真正需要的
→ 有沒有做對的東西

「處理中」與原因欄位，都不是 Bug——系統完全照著 AC 運作。它們是「說好的」與「真正需要的」之間的縫。這種縫，測試測不到，簡報也照不到：簡報的路徑是做的人挑的，皺眉頭卻發生在用的人自己操作的第七秒。要看見它，只有一種方法：讓真的要用它的人，在貼近真實的情境裡，親手走一次。

這也是為什麼 Day 03 說，Feedback 必須從真實使用者身上取得。Review 不是 Sprint 結尾的儀式，它是回饋迴圈上「取得 Feedback」那一環的正式名字。觀眾坐錯人，這一環就是斷的——會照開，迴圈不轉。

再看這兩個發現的身分。嚴格說，它們又是 Requirement Discovery（Day 19）：客服要應付線上等待的客戶、財務月底要照原因歸類，這些規則一直都在，只是現在才被問出來。第三部我們已經知道 Discovery 擋不住；第四部學到的是它的另一個性質——

Discovery 不會停止發生，但你可以決定它發生在哪裡：測試環境的 Review 桌上，或上線之後的客訴與對帳裡。同一個發現，兩個地方的標價差一個量級。

大神腦袋裡藏了什麼

現在把 Day 10 的場景搬過來對照。

第二部那位資深工程師，在交付前一週自己「再修一輪」：空值、位數、檔名、loading——因為他知道客戶驗收那天會點哪裡、皺哪種眉頭。當時我們說，那是一份寫在他腦中的 AC；Day 03 給過另一個名字：大神的直覺，是一份快取的 Feedback——用他過去累積的使用者反應，代替這個專案該取得的使用者反應。

今天這場 Review，做的其實是同一筆查詢，只是換了資料來源：不查他的快取，查本人。

值得誠實比較一下兩種來源。如果大神在場，「處理中會讓第一線的人緊張」這種事，他大概真的料得到——被使用者問過「是不是當掉」的人，看到那三個字會有反應。但退款原因欄位呢？那是財務月底結帳的內規，他的快取裡不一定有這一筆；就算有，也可能是好幾個案子以前的版本。本人永遠比快取新，而且本人給的答案自帶拍板的人——客服主管與財務說要改，這件事當場就能決定排不排，不需要再繞一圈去確認「大神猜的對不對」。

所以把話說完整：大神的不可替代性，有一半只是「他比你早知道使用者會說什麼」。這一半，不需要天分就能取代——把對的人放到鍵盤前，看三十分鐘，記下來。第二部裡那些住在他腦中的判斷，就這樣一筆一筆，搬進了團隊自己的 Feedback Loop。

他仍然被借調中，不在場。這是第四部開始以來，團隊第一次覺得：好像沒有那麼需要他了。

這次到底誰在吸收代價？

老規矩。兩個修正排進下一輪，下一輪的切片計畫因此重排——注意，是「排入」，不是「插單」：跟其他項目一起排序，排得進去是因為有東西被往後挪。

Scope       ■   下一輪排入兩個修正——用重新排序付帳，不是用加班付帳
Time        □   Review 三十分鐘，本來就在兩週的節奏裡
Cost        □   沒有加人
Quality     □   問題在變成客訴之前，先變成了一句話
Risk        □   兩個沒人想像過的真實用法，提早出土
人          □   ← 沒有人需要通靈，也沒有人需要救火

對照 Day 10 那張表：同樣是「使用者會怎麼反應」的不確定性，第二部由一個人在交付前一週默默吸收，六格有五格是白的，白得看不出危險；這次由 Scope 吸收，勾在明處，代價有人點頭。

Feedback 沒有讓不確定性變少，它只是讓不確定性在還便宜的時候現形，並且讓你可以選擇用哪一格付帳。

今日 Artifact｜Feedback Record

把這場 Review 收成今天的 Artifact。每一場 Review、每一條回饋記一份，四行就夠：

□ 誰操作了什麼：＿＿＿＿（真實使用者本人）當場實際做了＿＿＿＿
□ 說了什麼：記原話「＿＿＿＿」（皺一次眉頭也算一句話，補記情境）
□ 決定改不改：＿＿＿＿——不改也要寫下來，附上為什麼
□ 排進哪一輪：要改的話，排進＿＿＿＿，擠掉或延後了＿＿＿＿，由＿＿＿＿點頭

第三行是這張表的脊椎：Feedback 的價值不在收集，在於它改變了什麼決定。第四行則是它跟「插單」的分界線——說得出用什麼交換，才叫排序；說不出，就只是比較有禮貌的救火。

今日一句

Review 不是把做完的東西唸給別人聽，是把還來得及改的東西，放到真正要用它的人手上——「這是不是你真正需要的」，問本人永遠比問任何人的記憶便宜。

散會之後，看板上多了兩張排好順序的卡，氣氛不錯。

不過 Review 看的是產品。這兩週裡還有幾個瞬間，是產品看不出來的——某件事沒有爆炸，僅僅因為某個人剛好知道。還有一場會，看的是我們自己。

明天，Retro：今天又有哪些事情，差點只能靠大神？