重來的第一步不是打開編輯器，是打開名單：這個需求的每一條規則，到底誰說了算？

重新開工的第一天

昨天說好了：同一個專案、同一批人、資深工程師依然被借調不在——重新來一次。

第四部從重啟會議開始。

會議室跟 Day 15 那場月會是同一間。不一樣的是氣氛：上一次，大家覺得需求很清楚；這一次，大家記得自己曾經覺得需求很清楚。

PM 開場第一句話：「退款案重啟。前兩天，一行程式都不寫。」

後端工程師舉手——就是下架那晚說「回去寫完整規格書吧」的那位：「所以，是要先寫規格書？」

「也不是。」PM 說，「就算今天把規格書寫出來，也得有人有權在上面說『對，就是這樣』。我們連那個人是誰都還不知道。」

說完，白板上多了五個問題。第一部出現過的那五個（Day 06）：誰提出、誰決定、誰付成本、誰使用、誰驗收。

「前兩天只做這件事：拿這五個問題去問真的人。然後，寫下來。」

這次團隊怎麼想

反對意見當場就有，而且每句單獨看都有道理。

「需求還要問？我們對這個功能熟到不能再熟了——都翻車過一遍了。」

「時程已經延過一次，現在還拿兩天出來問問題，上面會怎麼看？」

「上次炸的是 webhook、是欄位語意、是完成語意——技術問題。找利害關係人是能解決 webhook 嗎？」

第三句最有力，也錯得最深。

回去翻第三部的帳就知道：webhook 重送，炸掉的是財務的對帳；欄位語意對不上，是因為「怎樣算退款成功」從來沒有一個有權拍板的答案；完成語意做到一半才被問出來，是因為知道答案的人根本不在對話裡。

每一筆技術帳往上追，都有一條沒被問出來的規則；每一條規則背後，都有一個沒被找到的、能說了算的人。

技術問題是帳單。決定權問題才是消費紀錄。

兩天，零行程式

第一天，先去找客服主管。

她把 Day 19 那天說過的話又說了一次：七天內的全額退款，客服可以自己核；超過七天、或是部分退款，要財務核准。不同的是，這次有人接住了這句話，追問下去：

「所以退款的規則，不是妳一個人說了算？」

她愣了一下，然後給出一個第三部從來沒人拿到過的答案：「當然不是啊。錢的事，一半以上是財務的規矩。」

第二天，團隊第一次正式約了財務人員。

上一次財務出現在這個專案裡，是月底對帳對不上、回頭追著工程團隊跑的時候——那不是參與，是受災。這次坐下來，財務的第一句話是：

「你們終於想到要問我了。」

兩天結束，白板上的五問，第一次有了寫下來的答案：

誰提出？    客服主管。原話至今只有一句：「幫我加一個線上退款功能」

誰決定？    規則的決定權拆成兩半——
            七天內全額退款的流程，客服主管說了算；
            其餘（超過七天、部分退款、發票折讓）歸財務

誰付成本？  工程團隊建置與維護；
            上線後每天拿對帳檔核對的是財務，對不上時追帳的也是財務

誰使用？    客服人員——不是客服主管本人，
            是她底下每天收退款信的第一線

誰驗收？    要兩個人都點頭：
            客服主管點「好不好用」，財務點「帳對不對得上」

沒有一行程式。花了兩天。而這五格答案，是這個專案開始以來，第一次被寫在人腦以外的地方。

把它跟 Day 15 並排，鏡子就出現了：

當時：一句話當天變 Ticket，效率驚人
這次：兩天過去，一張 Ticket 都沒開

當時：三個人腦中三個功能，沒有場合互相對質
這次：五個問題攤在桌上，答案當場對質

當時：所有的對齊，都對著提出需求的那個人
這次：先找出每一條規則誰能拍板

當時：財務人員從頭到尾沒出現在那場月會
這次：財務第一次坐上桌

當時：什麼都沒寫下來
這次：第一次有人寫下來

一直在跟沒有決定權的人對齊

名單攤開之後，第三部有幾件事突然說得通了。

第一，客服主管只是提出者。她有原話、有痛點、也真的握有一半規則，但只有一半。第三部所有的 Demo、所有的「跟客戶確認過了」，對象都是她——團隊以為在跟決策者對齊，其實是在跟半個決策者對齊。另一半決定權的主人，直到功能下架，都沒有被正式問過一句。

第二，第三部不是沒有驗收，是驗收找錯了人、排錯了時間。財務的驗收一直存在，它叫做月底對帳。財務不出現在任何會議裡，但每個月都會用對帳檔投一次票。第三部就是被這一票否決的。

第三——這是今天的主論點。第三部喊得最大聲的那句「需求一直改」，Day 19 拆掉了第一層：那不是 Change，是 Discovery。今天拆第二層：為什麼 Discovery 會拖到 Demo 那天才發生？

因為團隊從頭到尾，只跟提出需求的人對話。

跟沒有決定權（Decision Authority）的人對齊，有一個殘忍的特性：對齊會成功。會議有結論、氣氛很好、大家點頭——然後在有權的人出現的那一刻，整批作廢。Day 06 的儀表板是這樣，退款案也是這樣。

「需求一直改」的另一個名字，常常是「一直在跟沒有決定權的人對齊」。

這件事瀑布和敏捷都有解法：瀑布要求需求基準由有權拍板的人確認，敏捷要求一個真正被授權的決策者持續在場。兩邊共同的前提是同一個——你得先知道那個人是誰。第三部兩邊都沒做，第四部從這個共同前提做起。

找對人不會讓問題變少，接下來要決定的事還多得很。它只保證一件事：每個問題浮出來的時候，桌邊坐著能拍板的人；拍下去的板，不會再被別人翻掉。

順帶一提，這件事有人做過。Day 06 那位資深工程師的版本是私下兩通電話：求證誰說了算、找第一線的人聊十分鐘。這次團隊做的是同一件事，差別有三個：公開做、一起做、寫下來。電話簿換成一張卡，人情換成流程。

大神依然不在。而這件事，第一次不需要他。

這次到底誰在吸收代價？

老規矩。但今天先注意一件事：這是系列開始以來，第一次在事前勾格子，而不是事後結算。

Scope       □   還沒人碰它——碰它之前，先知道誰有權碰
Time        ■   有意識地花掉兩天   ← 這兩天買回了三週
Cost        □   兩天的人力事先講明，不必事後追認
Quality     □   還沒有東西可以壞
Risk        □   沒被問的問題，第一次在變少而不是變多
人          □   沒有任何事，靠某個人的記憶或加班吸收

Time 那格的 ■，跟第三部的每一個 ■ 都不同。第三部的 ■ 是事後結算：代價已經付了，才在帳上補記。這個 ■ 是 Day 05 說的報價：花多少、換什麼、誰同意，在付之前講清楚。

短註那句「買回三週」怎麼算的？第三部從整合日爆炸到下架，返工、聯調、救火，是用週在計算的；而那筆帳往上追，大半是「問題問錯人、或根本沒問人」的利息。兩天問對人，付的是本金。

再看最下面那格。「人」是空的——Day 15 它也是空的，但那次是因為以前負責吸收的人不在場；這次是因為沒有東西需要被吸收。同一個空格，兩種意思，這就是第三部與第四部的差別。

代價被事先講明、被同意，叫做交換；事後才發現、由人吞下，叫做吸收。第四部要練的，就是把後者一格一格換成前者。

今日 Artifact｜Decision Authority 卡

把這兩天的成果收成今天的 Artifact。一張卡管一條規則，不要整包打包給「客戶」：

□ 這條規則：關於＿＿＿＿（一張卡寫一條，不要寫「全部」）
□ 誰說了算：由＿＿＿＿決定；要改它，也得他點頭才算
□ 誰要被告知：這條規則變動時，＿＿＿＿必須第一時間知道
□ 驗收誰點頭：做出來對不對，最後由＿＿＿＿判定

填卡的時候留意一個警訊：如果每張卡的每一格填的都是同一個人，而那個人剛好是需求的提出者——你正站在第三部的起點上。

今日一句

需求的起點不是一句話，是一個名字：那個有權說「對，就是這樣」的人。找到他之前，寫下來的一切都只是猜測的謄本。

名單有了，能拍板的人都坐上桌了。但桌上攤著的，還是那句「幫我加一個線上退款功能」。

明天，跟這些人開工的第一個問題不是「功能要長什麼樣」，而是：這一輪，我們真正要解決的是什麼問題？