一句話需求看起來最清楚的時候，通常是每個人都用自己的想像把它補完的時候。

一個大家都聽得懂的需求

昨天最後我們問：如果今天，那個人真的不在呢？

第三部就是這個問題的答案。接下來七天講同一個小專案的完整翻車過程，案例一樣經過去識別化與合併改寫。後面的事都發生在同一個舞台上，所以今天先把舞台交代清楚。

一個運作多年的電商平台：Web 前端、後端 API，金流串接第三方的信用卡收單。訂單、出貨、對帳都是既有模組。系統不算漂亮，但每天安穩地跑。

只有一件事一直不安穩：退款。

這個平台的退款是純人工的：客服收信、到後台查單、開單給財務、財務登入金流商後台操作、回信給客戶。一趟平均三個工作天。客戶在這三天裡會再寄兩封信問進度，客服疲於奔命，財務嫌單開得亂，大家都知道這件事該解決。

某次月會，客服主管終於提出來了：

「幫我加一個線上退款功能。」

PM 說好。當天開了一張 Ticket，標題就是這句話。

還有一件事要交代：那位資深工程師——第二部裡默默補掉所有洞的那位——在幾週前被借調去救另一個更大的專案，歸期未定。開會那天，他的位子是空的。

沒有人覺得這有什麼關係。因為這次的需求「很清楚」。

退款嘛，誰不懂？

當時團隊怎麼理解這件事

當時團隊的想法，每句單獨看都有道理。

需求很清楚：誰沒有退過款？這又不是什麼晦澀的領域知識。

功能很小：訂單模組都在了，金流也早就串好收款，只是多一個反向的動作。

我們跑敏捷：不用寫規格書，開 Ticket 就能動工，這正是我們比別人快的地方。

大神不在沒關係：這種等級的小功能還要靠他，也太誇張了。

四句合在一起，得到的做法是：一句話需求，一張 Ticket，外加每個人腦中自己版本的想像。

一張 Ticket，三個功能

問題就出在「想像」這兩個字。這句需求之所以人人都覺得清楚，是因為每個人都毫無障礙地把它補完了——用自己的版本。

客服主管腦中的退款功能
→ 三個工作天變三分鐘：客服自己按一按，
  不用再開單給財務、不用再回信安撫客戶

前端工程師腦中的退款功能
→ 訂單頁多一顆「退款」按鈕，按下去看到結果

後端工程師腦中的退款功能
→ 多一支 API：查訂單、呼叫金流、把狀態改掉

同一張 Ticket 上寫的
→ 「幫我加一個線上退款功能」

三個人，三個功能，一張 Ticket。每個版本在各自的腦中都完整、自洽、清楚到不值得開會討論。

沒有人發現彼此想的不是同一個東西——因為沒有任何場合，會讓這三個想像互相對質。

至於錢實際上怎麼從平台回到客戶的卡上、財務月底怎麼知道這筆帳、金流商那邊有什麼自己的規矩——這些問題不在任何人的版本裡。順帶一提，現行人工流程裡真正動手退錢的財務人員，從頭到尾沒有出現在那場月會。

缺席的不是需求，是把問題問完的人

把 Day 08 拿出來對照，會看得特別清楚。

同樣是一句話需求——那次是「加一個匯入功能」——資深工程師接手後，順手把十件沒人問的事全問完了：格式、量級、失敗、權限、邊界。功能順利上線，Ticket 上依然只有一句話，於是組織學到一課：

「一句話需求是可行的，我們一直都這樣做。」

這一課少寫了一個前提：一句話需求的可行性，是跟那個人綁定的。組織把它記成了流程的屬性。

現在那個人不在了。前提消失，結論還掛在牆上。

而 Requirement 澄清這件事，本來不管哪套方法都有人負責。瀑布的做法：動工前把這句話展開成 Requirement，凍成 Baseline，估算與驗收都掛在上面（Day 02 的邏輯鏈第一環）。敏捷的做法：用一場所有相關角色都在場的對話把問題問完，再把答案變成排序過的小塊承諾，每一輪用 Feedback 修正（Day 03）。

兩邊都沒有一條規則叫做「一句話直接變 Ticket、Ticket 直接變 code」。

這個團隊兩邊都沒做。攤開來，當天沒被問出口的問題至少有五個：

這個功能給誰用？
→ 客服？客戶自己？沒人問

它要解決什麼問題？
→ 「三天太慢」跟「加一個退款功能」不是同一句話

怎樣算成功？
→ 按下去之後，誰、在哪裡、看到什麼，才叫退好了？

它會碰到誰的規則？
→ 錢的事情，向來不會只有工程規則

誰說了算？
→ 需求是客服主管提的，退款的每一條規則都是她說了算嗎？

如果大神在場，這五個問題會在 Ticket 開出的當天下午被問完——Day 08 我們看過完整示範。他不在，於是這五個問題保持未問狀態，跟著 Ticket 一起貼上了看板。

更麻煩的是：沒有人看見「有洞」。過去每一次，洞都在被看見之前就被同一個人默默補掉了，所以它從未出現在任何帳面上。團隊不是選擇不問，是根本不知道有這些要問。

這次到底誰在吸收代價？

老規矩，做一次檢查。今天一行 code 都還沒寫，看起來風平浪靜：

Scope       □   看起來很小，因為還沒有人打開來看
Time        □   Ticket 當天開出，效率驚人
Cost        □   沒有人估過，自然沒有超支
Quality     □   還沒有東西可以壞
Risk        ■   五個沒問的問題，全數轉成未爆彈   ← 這格正在堆
人          □   以前吸收這些的人，這次不在

注意兩件事。

第一，這是系列開始以來，「人」這格第一次是空的。不是因為問題被解決了，而是因為以前負責吸收的人不在，而制度上沒有任何東西接手。不確定性沒有消失，它換了一個科目記帳，存進了 Risk。

第二，Risk 是六格裡唯一可以先記帳、後付款的一格。今天勾下去的這一筆，代價尚未兌現——帳單稍後寄達，收件人是接下來六天的整個團隊。

大神在的時候，不確定性由人即時吸收；大神不在的時候，不確定性不會消失，只會先掛在 Risk 名下，連本帶利，稍後寄達。

今日 Artifact｜開工前五問

把上面那五個沒人問的問題收成今天的 Artifact。在任何 Ticket 動工之前，花五分鐘填：

□ 給誰用：這個功能的操作者是＿＿＿＿
□ 解決什麼問題：做完之後，＿＿＿＿的＿＿＿＿會從＿＿＿＿變成＿＿＿＿
□ 怎樣算成功：操作之後，＿＿＿＿能在＿＿＿＿看到＿＿＿＿，才算數
□ 碰到誰的規則：這件事會踩到＿＿＿＿（部門／外部系統／錢）的規則
□ 誰說了算：以上答案由＿＿＿＿確認，而且他真的有權決定

五格都填得出來，再動工不遲；填不出來的那幾格，不會因為開工就消失——它們只是換個名字，叫做你專案的未爆彈清單。

今日一句

一句話需求最貴的地方，不是資訊太少，而是它讓每個人都以為自己已經聽懂了。

公平地說，團隊裡不是完全沒有人感覺到不對勁。明天會有人提議：開工之前，大家先坐下來把問題對齊一下吧。

他會得到一句在很多會議室都聽過的回答：

「我們敏捷啊，先做再說。」