使用者提出的功能，真的能解決他的困難嗎？

接到需求文件時，我們通常會開始想：畫面怎麼做、API怎麼設計、資料要怎麼存。但在動手前，我會先弄清楚這個功能要改善使用者的哪段工作。若 BA、SA 已經把使用情境、例外和驗收條件寫清楚，這些答案就在文件裡，開發者也能據此設計與實作。

不過，需求從討論到開發，可能經過好幾個人。有時是部分背景沒寫進文件，有時是實作時對照現有系統，才發現文件描述的流程和實際行為有落差。這些問題不一定在前面的討論中看得出來。

大多情況下工程師不會是從頭負責訪談需求的人。碰到疑問時，我會先查文件和現有程式；有答案，就依照已確認的條件做。如果某些狀態或例外沒有交代，或文件與系統行為不一致，就把問題帶回團隊確認，由團隊把確認結果補進文件。

這些確認會影響實作時的判斷：遇到異常時怎麼處理？哪些資訊要讓使用者看到？時間不夠時，什麼可以先簡化？如果不知道功能想改善什麼，答案就容易變成「文件沒寫，先不管」或「這樣做比較快」。等到上線後才發現流程走不下去，再補上一個個條件，程式也慢慢變得難以維護。

使用者說的是功能，背後藏著的是問題

假設我們維護一套接單系統。使用者送出訂單後，系統會呼叫庫存服務扣減可售數量，再更新訂單狀態。某天，營運人員提出需求：「可以在後台加一個『重新處理』的按鈕嗎？」

從開發角度看，這件事似乎很明確：畫面加上按鈕，後端提供 API，再讓指定的訂單重新走一次庫存處理流程。按下去能執行，狀態也會更新，任務看起來就完成了。

接手實作時，我會先看文件有沒有回答一個問題：「營運人員在什麼情況下，需要按這個按鈕？」

假設文件只描述了按鈕，沒交代目前的異常處理流程，和相關的人確認後才知道：有些訂單呼叫庫存服務時發生逾時，後台可能一直停在「處理中」，也可能把逾時記成「失敗」。但庫存服務也許已經扣減了可售數量，只是結果沒有傳回來。目前營運人員無法自行查明，只能找工程師看 Log、核對庫存紀錄，再決定要不要補送。

他提出按鈕，是希望下次遇到同樣的狀況，不用每次都等工程師。可是一旦知道這段背景，原本看似單純的需求就多了幾個問題：

• 哪些訂單可以重新處理？如果庫存其實已經扣減，再執行一次會不會重複扣掉數量？
• 按完之後，營運人員怎麼知道庫存處理與訂單狀態都正確了？

如果規格裡已有答案，就依此設計與驗收；如果還沒有，就要在實作前和需求方一起確認，並補進文件。

假如這些問題沒有釐清，按鈕上線後，他可能還是得問工程師：「這筆可以按嗎？」或「我按過了，庫存到底扣了幾次？」

按鈕做出來了，等待工程師的流程卻還在。

知道目的，才有辦法做取捨

問清楚情境之後，我們才有依據討論要做到哪裡。也許需要補上更清楚的處理狀態；也許重送前得先確認下游的結果；也可能現有機制已經足夠，只缺一個讓營運人員操作的入口。

這不代表每次多問一句，都要把小需求做成大變動。如果異常一個月只發生一次，人工確認也很快，先提供有限制的操作方式，可能就能改善流程。但如果每天都有大量訂單卡住，單靠一個按鈕，恐怕只是把工程師的補救工作轉交給營運人員。

理解目的，能幫團隊判斷現在必須處理什麼、哪些可以留到後面。驗收時也不只確認「按鈕能不能重新送出訂單」，還要看看營運人員能否判斷何時可以操作，並知道操作後的結果。

AI 寫得越快，越要先弄清楚方向

我們可以把需求文件、現有流程與程式碼提供給 AI，請它一起分析例外情況、討論做法，再協助實作和測試。但若團隊始終只把目標定在「新增重新處理功能」，產出的程式即使符合規格，也無法證明營運人員原本的困難已經解決。

所以接到需求時，我想先試著說清楚：誰在什麼情境下遇到什麼困難？這個功能預期讓什麼事情變得更好？

在這個例子裡，答案可能是：「營運人員遇到訂單傳送異常時，無法確認結果，只能等工程師協助；我們希望讓他能判斷目前狀態，並在允許的情況下自行恢復處理。」

如果這句話還說不清楚，就先找相關的人補上背景。後面的設計、取捨和驗收，才有一個共同的依據。

程式寫對了，是交付的基本要求。至於問題有沒有解決，還是得回到使用者實際工作的地方看。

寫到「庫存到底扣了沒有」，我想到好幾年前剛接手一個老系統時，看過一段更刺激的程式：提款紀錄的更新和呼叫轉帳 API，被放在同一段資料庫 Transaction 裡。

當時看起來像是「成功就一起成功，失敗就一起回滾」。但資料庫能回滾，對方已經完成的轉帳可不會跟著回來。API 一逾時，我們這邊把提款判成失敗，對方卻可能已經把錢轉出去了。

想到那幾天為了出報表、對帳，一筆一筆翻紀錄，確認錢到底出去了多少，到現在還是有點頭痛。

如果那幾天，地球也能整顆包在 Transaction 裡 Rollback 就好了。