一句話需求之所以可行，從來不是因為需求真的只有一句話；是有人把沒問出口的另外九成，全部自己回答掉了。

一張只有一句話的 Ticket

第一部結尾停在一個觀察上：那句「可以，但代價是什麼」，是最資深的人才說得出口。

第二部要處理的，就是這件事的全貌。接下來七天，每天看一個現場，主題只有一句話：**大神在的時候，所有流程看起來都很好。**每一篇的結構會很像——某個工程責任缺席了，某個人默默把它補掉了，然後所有人都覺得流程沒問題。

今天從最常見的那個洞開始：需求。案例照舊經過去識別化與合併改寫。

某個內部系統的維護案。業務部門透過窗口提了需求，PM 開了張 Ticket，內容完整引用如下：

「加一個匯入功能。」

沒有了。沒有附件、沒有欄位說明、沒有誰要用。這張 Ticket 被指派給資深工程師。

他看了一眼，沒有抱怨，也沒有退回去要求補需求。他打開筆記，開始列問題：檔案是什麼格式？編碼是什麼？一次會匯幾筆？十萬筆會不會 timeout？欄位對不上怎麼辦？匯到一半失敗，要 rollback 還是保留？同一份檔重複匯兩次會怎樣？誰有權限匯？匯完要通知誰？這次哪些不做？

其中兩三題，他抓著窗口十分鐘問完；剩下的，他自己回答——憑他對這個系統、這個部門、這群使用者的多年理解。

三週後功能上線。沒有炸、沒有客訴，業務部門用得很順。而那張 Ticket 從開單到結案，內容始終只有那一句話。

結案時 PM 順口說了一句：

「這種需求最好做了，一句話就講完。」

沒有人接話。包括那位工程師自己。

當時團隊怎麼理解這件事

大概是這樣：我們溝通成本很低，一句話就能開工，不像某些團隊要寫十頁文件才敢動；資深工程師本來就熟這個 domain，讓他直接判斷最快；需求寫再細也會變，不如做出來再說；真有問題，他自然會去問。

每一句單獨看都有道理。合在一起，效果是：組織開始相信「一句話需求」是一種可行的工作方式——而且證據充分，你看，上線都很順。

一句話與能動工之間，隔著什麼

把那句話跟實際上線的功能攤開對照，中間隔著一整層工作：

「加一個匯入功能」
        ↓
輸入：什麼格式？什麼編碼？檔案由誰產生？
量級：一次幾筆？尖峰多大？十萬筆會不會 timeout？
失敗：錯一筆是整批擋下，還是跳過記錄？
中斷：匯到一半掛掉，要 rollback 還是保留？
重複：同一份檔匯兩次，會發生什麼？
權限：誰能匯？匯錯了誰負責？
驗收：怎樣算匯入成功？誰說了算？
範圍：這一次不做什麼？
        ↓
可以動工的需求

這層工作有名字：Requirement 澄清。它不是文件格式問題，是一項工程責任——在動工之前，把「這句話到底是什麼意思」問到可以被實作、可以被驗證為止。

瀑布用它的方式承擔這個責任：需求分析是正式階段，產出 Requirement Specification，凍結成 Day 02 說過的 Baseline——答案必須先存在，承諾才能建立。敏捷用另一種方式：把需求拆小，澄清延後到接近動工的時刻，用對話與 Acceptance Criteria 承接——形式輕得多，但那層工作一樣要發生。

兩邊沒有任何一個版本說：這層工作可以不做。

而這個團隊的實際狀況是：這層工作每次都有做——做在一個人的腦內，不留任何輸出。

大神腦袋裡藏了什麼

回頭看那十個問題。真正值得注意的不是他「會問問題」，而是大部分的問題，他根本不必問：

檔案格式
→ 他知道業務部門要匯的其實是月底那份對帳檔，格式他看過

量級
→ 他知道那個檔案月底會暴增，所以一開始就做了分批處理

失敗處理
→ 他處理過半途中斷留下髒資料的事故，預設就做了 rollback

權限
→ 他記得之前有人誤匯過測試檔，把功能入口收進了管理權限

驗收
→ 他知道窗口驗收那天，會拿一份欄位故意對不上的檔案來試

換句話說，他不是在寫程式之前「順便」澄清了需求。他是把整個需求分析階段，在腦內快轉跑完，然後只交付結果。輸入一句話，輸出一個考慮周全的系統，中間的推導過程不落地。

這就是 Tacit Knowledge（隱性知識）補位的標準畫面。危險不在這一次——這一次的品質其實很好——在於組織從這次成功學到的東西：

「一句話需求，可行。」

於是下一張 Ticket 更短，下下一張連窗口都懶得抓來問。一句話需求成功一次是僥倖，成功十次就成了制度。而這個制度真正的規格是：需求的品質，取決於接單的人是誰。同一句話派給大神，上線順利；派給資淺工程師，炸在「欄位對不上」那格——然後檢討會的結論會是「他經驗不足」，而不是「需求從來沒被澄清過」。

Requirement 澄清是一項工程責任，不是個人美德。責任可以被分配、被檢查、被留下紀錄；美德只能祈禱今天上班的人剛好有。

這次到底誰在吸收代價？

老規矩。這次的專案，帳面上近乎完美：

Scope       □   功能齊全，連沒人提過的邊界都處理了
Time        □   如期上線
Cost        □   沒加一個人
Quality     □   品質很好——好到看不出有任何問題
Risk        □   沒人評估過，因為沒人知道賭了什麼
人          ■   ← 一整個需求分析階段，由一顆腦袋免費供應

注意這張表跟第一部的不同。第一部的故事多半是出了事，回頭才發現是人在吸收；第二部的故事會一直是這樣：什麼事都沒出，帳面全綠，而「人」那格照樣是黑的。

這才是第二部真正麻煩的地方。大神吸收代價的方式太安靜了，安靜到組織以為根本沒有代價。要等到某天他請假、調職、離開，那些一句話 Ticket 還是會照樣寄來——只是再也沒有人把另外九成補上。

那格 ■ 不是事故的紀錄，是事故的預告。

如果沒有大神，應該留下什麼

不是要求每張 Ticket 附十頁規格書——那是往 Day 02 那種假瀑布的方向逃跑。

看一眼大神做的事就會發現：答案很貴，問題很便宜。他腦中那些答案來自多年經驗，一時半刻複製不了；但他動工前自問的那些問題，其實高度重複——輸入、量級、失敗、權限、邊界、驗收、範圍，幾乎每個功能都是同一組。

答案留在他腦裡沒關係，問題不行。把問題變成清單，資淺的人拿到一句話需求時，至少知道自己還有七個洞沒填——填不出來，就知道該去問，而不是憑想像動工。

今日 Artifact｜一句話需求最小澄清清單

七格。收到任何一句話需求，動工之前先填：

□ 輸入：這個功能吃什麼進來？格式、來源、由誰產生：＿＿＿＿
□ 量級：一次多少、多常用、最大會到多大：＿＿＿＿
□ 失敗：做到一半壞掉，系統該停在什麼狀態：＿＿＿＿
□ 權限：誰可以用？誰不可以？出錯誰負責：＿＿＿＿
□ 邊界：重複執行、超出預期、格式不符時，各發生什麼：＿＿＿＿
□ 驗收：誰、拿什麼案例，判定這個功能算完成：＿＿＿＿
□ 不做：這一次明確不包含什麼：＿＿＿＿

七格都有答案，一句話才升格成需求。填不出來的格子並不是不存在——它只是還在排隊，等某顆腦袋墊付。

今日一句

一句話需求從來不是真的只有一句話；它只是把另外九成，存放在某個人的腦袋裡，而且不開收據。

需求可以靠一顆腦袋腦補，因為推導再複雜，至少都發生在同一顆腦袋裡。但有些東西橫跨兩個團隊，一顆腦袋管不到兩邊——比如介面。

明天來看第二個洞：介面沒定義沒關係，他們兩個很熟。