需求先講清楚：User Story 與驗收標準怎麼幫團隊少走冤枉路

2025/09/28約 5 分鐘

2025 年我主要在開發公司的能源管理系統（EMS）。半年多下來最有感的不是技術，而是「需求規劃」這件事：畫面改了兩三次、時程一度很趕，後來把需求確認的順序補起來，並引入 User Story 與驗收標準之後，整個團隊才開始順。這篇整理我們怎麼做，還有我從中學到的事。

2025 年我主要負責公司 EMS（能源管理系統）的前端開發，簡單說是一套監控跟管理電力設備的平台。這篇不談程式，想談的是需求規劃，這是這半年多來讓我最有感的一件事。

這半年發生了什麼

EMS 從年初開始做，畫面的設計跟規劃前前後後大幅修改了兩三次。每一次改，前端就要跟著重切，切好的頁面常常還沒接上真實資料就被推翻了。

到了八月，部分功能在客戶端確認的時候發現有落差，於是那個月變得很趕。也是在八月，新的 PM 加入團隊，需求規劃才開始被真正確認下來。九月，客戶需要的功能陸續開發完成，團隊接著進行下一個客戶的需求，我也把 EMS 交接給新同事，轉去做其他專案。

回頭看，前面半年的反覆並不是因為誰不夠努力，而是流程裡少了一段。

一個功能從無到有，大致會經過需求探討、畫面設計、程式開發、成果驗收這四段。後面三段都有明確的負責人跟產出，設計師出設計稿、工程師寫程式、PO 驗收。但最前面的需求探討在我們團隊裡沒有固定的做法，常常是有了一個方向就直接進設計、進開發。

結果就是設計稿畫得很精美，程式也寫得很認真，但做出來的東西不一定是客戶要的。等到客戶看到成品才發現落差，修改的成本已經是最高的時候了。

這套做法其實不是我發明的。之前待過緯創這種規模較大、制度完整的公司，需求怎麼確認、故事怎麼寫、怎麼估點都有一套既定的流程。到了現在的小團隊，我把當時學到的東西整理成適合小團隊的版本帶進來。

我在團隊裡提出重新審視工作流程，把順序固定下來。PO 跟 PM 先討論出具體的需求，這個階段不談畫面，只談「誰、在什麼情況下、要完成什麼事」。接著 UI 設計師用線稿（Wireframe）把想法畫出來，拿給 PO 確認，線稿畫得快改得也快，不用等精美的設計稿。確認之後才交給 RD 開發。

線稿這一步很關鍵。很多需求上的誤解，是用文字講的時候大家各自想像了不同的畫面，一張粗糙的線稿就能把這種落差提早攤開來。

接著我建議團隊引入 User Story 的寫法，格式很簡單：

身為（某種角色），我想要（做某件事），以便（達成某個目的）。

以 EMS 的趨勢分析頁為例：

身為廠區的能源管理人員，我想要在趨勢分析頁看到某個設備過去七天的用電曲線，以便判斷這台設備的用電是否異常。

寫成這樣有兩個好處。第一，「以便」後面那句逼大家把目的講出來，而目的常常才是客戶真正在意的東西，畫面只是手段。第二，角色講清楚之後，權限、資料範圍這些問題會自然浮現，像是廠區的管理人員能看到哪些設備？總公司的人呢？

User Story 講的是方向，驗收標準（Acceptance Criteria，簡稱 AC）講的是邊界。我們用 Given / When / Then 的形式來寫，同樣用趨勢分析頁舉例：

有了 AC，開發的時候不用猜「沒資料要顯示什麼」，驗收的時候也不會出現「我以為會有最高值的標示」這種對話。它同時也是測試案例的雛形。

每個 Planning 會議之後，我會把自己寫的 User Story、AC 跟估點結果整理好，提供給新上任的 PM 參考。不是為了規範誰，而是因為範例比規範有用。與其解釋 User Story 的格式，不如直接給一份這個專案裡真實的例子，照著改最快。

PM 不一定有軟體開發的背景，但只要有幾份對的範例，很快就能自己寫出讓工程師看得懂的需求。

八月到九月之間，團隊把客戶的需求陸續開發完成，整體成效 PO 是滿意的。更明顯的變化是在團隊裡。需求變得明確之後，大家知道自己在做的東西是為了什麼，開發成果受到肯定，做起來也更有成就感。這跟前半年做完又被推翻的感覺完全不一樣。

經過 EMS 這半年多的開發，我真正認識到需求規劃在整個流程裡的重要程度。畫面設計、程式開發、成果驗收當然都重要，但最重要的其實是一開始的需求探討。PO 跟 PM 先討論出具體的需求，配合 UI 用線稿的方式確認，最後才進到開發，可以少走很多冤枉路，甚至有事半功倍的效果。

另外有兩件事我會記住。想在團隊裡推一個新做法，先寫幾份真實的範例給大家抄，比講規範有用。還有，我不是 PM，但我是被需求變動影響最深的人，提出改善的建議其實是很自然的事。