同一張 Story 卡，有對話，是需求的起點；沒有對話，只是把一句話需求換上格式正確的衣服。

一張格式標準的卡片

昨天 MVP 邊界定案：信用卡、單筆、全額、未出貨、7 天內、客服操作。範圍定了，下一個問題自然浮上來：需求該寫成什麼樣子？昨天結尾先把結論說了——User Story 的格式不是重點。今天來看為什麼。

先從一張格式完全正確的卡片開始。PM 是做過功課的，他把需求寫成了標準的 Story 格式：

As a 客服人員，
I want 對一筆 7 天內、未出貨的信用卡訂單發動全額退款，
So that 客戶不用再等三個工作天，我也不用再開單給財務。

卡片貼上看板，無可挑剔：有操作者、有動作、有目的。比起第三部那張「幫我加一個線上退款功能」，看起來進化了不少。

後端工程師盯著卡片看了一會兒，說：

「這不就是上次那句話，多了主詞跟目的嗎？」

沒有人反駁。因為他說得對。

拿 Day 15 的開工前五問來考這張卡：給誰用——答了，客服。解決什麼問題——答了一半。怎樣算成功——沒答。碰到誰的規則——沒答。誰說了算——沒答。

五問，兩格半。格式正確的卡片，跟一句話需求之間，只隔了兩行字。

當時團隊怎麼理解 User Story

差一點，這個團隊就要走上另一條歪路。當時有一種聲音，每句單獨聽都有道理：

上次翻車是因為需求只有一句話；上過的課都教需求要寫成 Story；格式會逼你想清楚使用者跟目的；所以這次把格式寫好寫滿，需求就清楚了。

順著這個邏輯，結論會是：把卡片寫得更滿——規則、狀態、例外全部塞進去，最好一張卡就是一份小規格書。

這條路的問題不是太累，是方向錯了。上一次缺的從來不是格式。Day 15 那句話就算當天被改寫成完美的 Story，該炸的照樣一顆不少地炸——五問裡沒被問的那三問，不會因為換了格式就自動有答案。

缺的是把那三問問完的場合。

那場兩小時的對話

於是這次做了一件第三部從來沒做過的事：開工之前，把人約在同一張桌子上。

三方：提需求的（客服主管）、動手做的（前端、後端、金流串接三位工程師）、負責驗證的。團隊沒有專職測試，最後那個位子由 PM 兼任——他的任務不是寫測試，是對每一條答案追問同一句：「這條到底怎麼驗？」

議程只有一頁：把 Day 15 的五問，真的問完。兩個小時裡，發生了幾件事。

「怎樣算成功」問得最久。金流串接工程師把上次聯調第三天才被問出來的事實，這次在第四十分鐘就講完了：200 只是受理、結果要等 webhook、webhook 可能重送、對帳檔隔天才有。同樣的知識、同一個人，上一次是用「炸」的方式進入專案（Day 18），這一次是用「問」的。附帶一提：重送這件事，上次他說出口過一次，沒有人接話，會議記錄上也沒有那一行；這一次它被寫上白板，後面跟著一個負責人。

「碰到誰的規則」問出了一條連翻車都沒教會大家的事：7 天內的全額退款，客服自己就可以核准。也就是說，MVP 邊界內的每一筆都不需要走簽核，整條流程可以少一個步驟。第三部從頭到尾沒有人知道這件事——大家只在 Demo 上被「超過 7 天要簽核」炸過，沒有人回頭問過反面的那一半。

「已出貨不能退」昨天已經劃出邊界，但對話把它往下逼了一層。客服主管補了一句：「那已出貨的訂單，按鈕就不該讓人按得下去。」一句話，替前端擋掉一個日後必然出現的客訴。

有兩條跟錢有關的細節，客服主管答不了。沒有人用猜的，也沒有人先做再說——列進「去問財務」的清單，隔天早上答案就回來了。誰說了算，Day 22 已經畫好，所以連「不知道」都有明確的去處。

兩小時結束，白板半面是「怎樣算成功」的句子，半面是規則與點頭的人。

而程式，一行都還沒寫。

Story 是對話的門票，不是需求的容器

現在可以把今天的主張講清楚了。

Story 是對話的門票，不是需求的容器。

卡片小到裝不下所有細節——這是設計，不是缺陷。它本來就不打算取代規格書。它打算做的是：用兩三行字圈出一個值得討論的範圍，逼你把細節拿到對話裡問完，再把問出來的答案放進真正該放的地方——規則有紀錄、成功有定義、介面有契約。

所以同一張卡片，價值可以差到天上地下：

同一張卡片
＋那場三方對話 → 五問有答案、規則有出處、
　　　　　　　　 「怎樣算成功」有半面白板等著落地
－那場三方對話 → 「幫我加一個線上退款功能」，
　　　　　　　　 換上格式正確的衣服

這也不是敏捷獨有的發明。瀑布把這場對話做成需求訪談與規格評審，形式重得多，意圖一模一樣：動工之前，把問題問完。敏捷只是把它變小、變頻繁、貼著一張卡片發生。兩邊都沒有一條規則叫做「格式填完就可以開工」。

把格式當成魔法的團隊，等於買了門票卻不進場：卡片再標準，對話沒有發生，Story 就退化回一句話需求——那正是第三部的第一天。

把大神的問題，變成所有人的議程

還記得 Day 08 嗎？同樣是一句話需求，資深工程師接手後，一個人把十件沒人問的事全問完了。當時看起來是天分，拆開來其實是兩樣東西：一份他腦中的清單，跟一個他習慣性佔住的位置——動工之前先發問的位置。

今天這場對話做的，就是把這兩樣東西搬出他的腦袋：清單變成五問，位置變成議程。知識原本就在場——金流的事實一直在金流串接工程師腦中，規則一直在客服主管與財務那裡——缺的只是一個逼大家坐下來互相提問的場合。

大神不在，第三部證明了沒有人會自動補位。第四部的做法不是等他回來，是把「他會問的問題」變成所有人的例行公事。

這次到底誰在吸收代價？

老規矩。這場對話花了五個人整整兩小時，這是真實的成本，記帳：

Scope       □   邊界昨天定案，今天沒有再動
Time        ■   兩小時的三方對話，換掉了三週聯調   ← 有意識地花
Cost        □   沒有加人
Quality     □   還沒有東西可以壞——這次是真的，因為還沒開工
Risk        □   五問問完，未爆彈在桌上被逐顆拆掉，不再堆進這格
人          □   沒有人需要腦補，沒有人需要事後加班吸收

對照組不用遠求：第三部同一批問題的價格，是三週聯調、品質賠付、上線延期、功能下架，外加全隊救火的加班。這次，兩小時買斷。

對話從來不是免費的，它只是便宜；真正貴的是不對話。

今日 Artifact｜Conversation 檢查單

今天留下的不是 Story 範本——格式你早就會了。留的是那場對話的檢查單，任何一張卡動工之前過一遍：

□ 三方到齊了嗎：提需求的＿＿＿、動手做的＿＿＿、
  負責驗證的＿＿＿都在場
□ 五問問完了嗎：給誰用／解決什麼問題／怎樣算成功／
  碰到誰的規則／誰說了算，每一格都有答案或去處
□ 問出的規則寫在哪：＿＿＿＿（「大家都聽到了」不算一個地方）
□ 誰負責把答案落地：＿＿＿＿在＿＿＿之前，
  把白板上的答案變成＿＿＿＿

四格都打得了勾，這張卡才算真的用過；打不了勾，你手上那張 Story 只是門票買了沒進場。

今日一句

一句話需求與一張好 Story 的差別，從來不在卡片上多的那兩行，而在卡片外發生過的那場對話。

散會前，有人對著白板拍了照。半面白板都是「怎樣算成功」：要先看到處理中、webhook 回來狀態才能變、同一筆通知來兩次不能退兩次、隔天的帳要對得上……

照片不是 Artifact。此刻它們還是白板上的字：句子鬆散、彼此打架，換一個人讀就是另一個意思——這正是通靈的溫床。

明天把它們一條一條寫成可以驗收的樣子。Acceptance Criteria：不要靠大神通靈完成條件。