今天我們來聊聊如何撰寫 User Story，這就像是寫一篇小故事，只不過主角是我們的使用者，而故事情節是他們希望系統解決的問題。那麼，我們該怎麼開始寫這個故事呢？

基本上，User Story 包含兩個核心內容：描述（Description）、（Acceptance Criteria，AC）

描述（Description）

這裡常見的結構是三段式句子，講清楚三件事——誰是使用者、他們的需求是什麼、以及他們為什麼需要這個功能。

身為 [某類型的使用者]
我想要 [某個需求]
這樣我能夠 [達到某個目的]

身為一位    HR 人員
我想要 新  增職務主檔
這樣我能夠  管理新的職位需求

為什麼我們需要寫這樣的描述呢？

在傳統的需求規格書中，我們常常一頭栽進功能的細節，像是「按下這個按鈕會發生什麼事」、「這個流程應該怎麼走」，結果陷入了技術細節的無底洞。但問題來了，功能設計得再精巧，如果沒有解決使用者的真正需求，那不就像是拿著高級廚具去烤一個根本不想吃的蛋糕嗎？User Story 的描述，就是要避免這個陷阱。

功能的目的是為了幫助使用者解決問題，而不是因為規格書說要加什麼就加什麼。

實例——查詢職務主檔

假設我們有一個需求：「我想要查詢職務主檔，這樣我能找到特定職位的詳細資訊。」這時，你可能會下意識地想著：「嗯，這個列表要有多少個欄位呢？搜尋條件怎麼設計？要不要分頁？」再深入一點，你可能開始列出一大串的欄位：「職務名稱、職務代號、新增人員、新增時間、異動人員、異動時間...」好像沒完沒了。

這個時候，我建議你深呼吸一下，喝口茶，再回頭看看最開始的描述——使用者只是想「查詢某個特定職務」。那麼，列表上只顯示「職務名稱」和「職務代號」，是不是就夠了？其實這已經能解決使用者的問題了，那其他一大堆欄位真的需要嗎？答案可能已經呼之欲出了。

描述是驗收條件的最佳校準器

描述的目的不僅是幫助我們清晰理解使用者需求，還是在我們撰寫 驗收條件（Acceptance Criteria，AC） 前的一個提醒。每當你準備增加一條新的需求規則，問問自己：這個規則是為了解決當下這個問題，還是因為我們「習慣」這麼做？當你思路卡住、不知該如何規劃功能時，回到這個簡單的描述上，它會提醒你：先解決使用者的核心問題，別被無關的細節困住。

User Story 的描述就像是故事的靈魂，它幫助我們不忘初衷，在寫每條驗收條件時，也提醒我們保持簡潔明確。下一次當你覺得規格細節無限膨脹時，不妨停下來，想想這則故事想講的是什麼，也許這樣你就能清醒過來，放下那些無謂的執著。