想像一下，你拿到一份需求文件，上面寫著「當使用者點擊 1 000 次，就支付 2 英鎊」，聽起來很明確，對吧？但如果把這一句丟給開發或測試，他們腦中跑的可不只快樂路徑。

開發會問：「那要是 999 次呢？還要給錢嗎？」
測試則可能跳出來挑戰：「假設同一台機器人在 5 秒內狂按 1 000 下，這算不算？我們還是要付嗎？」
更別說有人再追問：「同一聯盟夥伴今天如果多送了 3 000 次點擊，我們是要再多付 6 英鎊，還是通通打槍？」

看看，光是把範例寫進文件，卻完全無法涵蓋大家的疑問。

於是，我們把所有人——客戶、產品負責人、業務專家、開發和測試——聚到一面能畫圖、貼便利貼的白板前，隨手寫下那些真實案例，然後輪流抒發意見。這場以範例為核心的頭腦風暴，我們稱它為「需求梳理工作坊」。

工作坊的重點，是建立對問題與解決方案的共同理解，並確保所有功能缺口，在迭代初期就被發現，而非待業務人員可能不在場時才曝光。

高階業務利害關係人與領域專家常是資訊傳遞的瓶頸，因為他們既要處理日常工作，又要參與專案。工作坊有效善用他們的時間，讓他們全神貫注於關鍵議題，並將領域知識傳遞給實作團隊。

對於兩週一次的迭代，通常3 到 4 小時的工作坊就足夠；如果無法在 4 小時內說清楚要做什麼並達成共識，很可能就無法在兩週內完成。

工作坊大綱

• 開場說明
  由業務代表（通常是產品負責人、商業贊助人或分析師）簡要介紹待開發的軟體。

• 範例演示
  以具體、貼近業務的範例說明程式完成後的行為。

• 集體提問與補充
  參與者提出問題，建議額外範例，釐清功能或暴露新的邊緣情境。

• 範例懷疑與精煉
  在開發開始前，盡可能將所有額外案例都「刷乾淨」，因為此時業務人員就地可解答。

透過討論範例，不僅能高效傳遞領域知識，也提供一個讓所有人確認共識的方法：在任何使用案例或使用者故事的討論中，開發與測試人員負責提出所有尖銳問題並舉出各種範例；客戶、領域專家與業務分析師則回應這些問題，並確保所有人都正確理解。

工作坊輸出 (Workshop Output)

• 一組具體的、能說明系統在下個階段完成後，應如何運作的真實範例。
• 針對每個用戶故事，都必須討論關鍵範例，包括主要成功情境以及重要的邊緣案例。
• 這些範例要以足夠的細節寫下來，讓所有參與者都同意這個故事代表什麼、產出物有哪些，以及如何驗證其正確性。

為了維持流程順暢，你可以拍下白板照片，或請專人即時將範例整理成文件。使用何種格式或工具並不重要，之後會有時間進行清理與整理。

這些範例通常會有以下特性：

• 要提供足夠的資訊，讓開發人員能據以實作、讓測試人員能針對迭代中的故事驗證。
• 應該能回答開發或測試人員，在接下來幾週工作中，通常會提出的大部分規格問題。
• 若有部分不常見案例可留待日後討論，先知道有這些案例。
• 務必討論成功情境與例外情境，但不要浪費時間列舉所有參數的可能排列──每個重要情境一個範例就足夠。

為了讓工作坊保持聚焦並維持討論節奏，最好把範例與對話控制在較高層次。我們想討論的是「系統要做什麼」（what），而非「如何實作」（how）。實作細節可留待後續深究，不一定要利害關係人或領域專家參與，除非某些可能的實作方式會限制功能可行性。原則上，避免在工作坊中深入討論實作或基礎建設細節，這樣能節省時間並保持流程順暢。

建立共識與知識傳遞

客戶與業務分析師不應僅僅填寫範例模板的空白，而應詳細解釋決策背後的邏輯，確保團隊成員真正理解需求。

例如，在設計一個電商平台的訂單處理系統時，業務分析師不僅提供「用戶取消訂單」的範例，還需說明取消的原因（例如庫存不足或用戶改變心意）及其對後續流程的影響（如退款或庫存更新）。這有助於開發人員理解業務邏輯，避免誤解。

透過工作坊，將領域知識傳遞給實作團隊，幫助他們在發現異常時能快速反應並與業務有效溝通。在討論範例的過程中，團隊可能發現更簡潔的解決方案，從而更好地滿足客戶需求。

例如，在醫療系統開發中，工作坊可模擬「患者資料異常」（如血壓數據超出正常範圍）的場景，讓開發人員學習如何辨識問題，並與醫療專家討論解決方案。這不僅提升技術實現的準確性，也增強團隊對領域的信心。

工作坊結束的標準是所有參與者同意已涵蓋足夠的範例，包括重要情境和邊緣案例。

例如，在一個財務報表系統中，範例需涵蓋正常交易、負數餘額、跨月結算等情境，並針對罕見情況（如系統當機後的資料恢復）提供處理方式。只有達成共識，工作坊才算完成。

若團隊沒有常駐的客戶代表，工作坊的重要性更加凸顯。它提供定期（例如每兩週的星期五下午）與領域專家面對面交流的機會。

雖然工作坊能在短時間內達成大量成果，但必須保持高度專注才能獲得效益。若你發現參與者開啟筆電回覆郵件、寫程式或瀏覽網頁，表示工作坊已經失敗，原因可能是：

• 時機不當：大家實在太忙，應重新安排。
• 對象不對：在場人選無法就關鍵議題達成共識，需調整參與者名單。

利用模糊投票來收集回饋

在專案早期，團隊成員常會「以為大家都懂」，但實際上對同一個需求或情境有不同解讀。模糊度投票的重點，就是找出這些潛藏的差異與不確定性，透過集體討論，讓大家「站在同一頁」。

Donald Gause 和 Gerald Weinberg 在《Exploring Requirements: Quality Before Design》一書中，提出一個技巧，目的是揭露團隊在需求理解上的隱含假設與不一致的認知，幫助建立共識。過程如下：

• 挑選評估指標：選擇一項需要紮實領域知識才能估算的指標（如效能、成本或完成任務所需時間）。
• 獨立估算：參與者私下給出估值。
• 比較與討論：一次公開所有估值，由最高與最低者分享背後假設，揭露可能遺漏的子工作、限制或捷徑；
• 重複至收斂：反覆投票與討論，直至估算趨於一致。

後來這樣的流程在敏捷實踐中，這已演化為「規劃撲克牌」（Planning Poker）：
團隊成員各自選卡估算工作量，再同時亮卡，並由極端估算者說明理由，最終形成一致預期。

在 SBE（Specification by Example）工作坊或規格審查過程中導入「模糊投票（Ambiguity Polls）」，是一種簡單但強大的方法，用來快速揭露團隊對需求的不同解讀。下面是一些常見的應用時機：

• 當大家以為都懂某句話，但沒人能明確說出來時
• 當出現含糊的詞句（如：盡快、合理範圍、正常流程、有效資料）
• 當某個 GWT 範例引發爭議或反覆修改
• 當對成功條件或例外處理沒有共識

下面我們就來看看一些場景：

(1) 在範例撰寫前（探索需求時）
在撰寫範例之前，用來確認關鍵詞是否含義一致。

例如PM 說：「用戶若在合理時間內付款，就視為訂單成功」。有人會問到：「什麼是『合理時間內付款』？」這時候可以利用模糊投票，請大家寫下心中的秒數（匿名或公開），可能的結果如下：

• 開發 A：30 秒
• 測試 B：5 分鐘
• PO：24 小時

這時候你就會發現有問題，彼此的時間概念差距非常大！所以接下來團隊會討論：付款是指點擊付款？還是金流系統完成確認？付款完成的時間點是否因支付方式不同而異？

(2) 在範例撰寫中（GWT 撰寫中）
例如有個範例如下：

Scenario: 使用者付款超時後重新付款
Given 使用者點擊結帳超過「允許時間」
When 再次付款成功
Then 顯示「訂單已失效，請重新下單」

這時候可以詢問團隊成員，「允許時間」應該是多少？讓 PO、開發、測試、UX 各自填數值。如果投票後，發現大家認知落差很大，大家可以一起調整用字或新增範例的情境：

Scenario: 使用者於結帳 5 分鐘後付款
Given 結帳已過 5 分鐘
When 用戶完成付款
Then 顯示「訂單已失效」

(3) 在審查現有範例時（Refinement 或 Pull Request review）
在審查時看到範例內容如下：
Then 系統應回傳「合理錯誤提示」

此時會詢問團隊：「什麼是『合理錯誤提示』？請各自寫下你想看到的訊息範例」

這時候你會發現到，現開發想的是技術訊息（HTTP 400），而測試期待的是對使用者友善的文案，PO 則關心是否能導向補救流程。大家角度不同，在意的東西不同，可能就會出現不同的需求期待。

需求梳理工作坊常見的誤會

當我們在舉辦這樣的工作坊時，常常會遇到一些誤解。以下我們來說明這些「常見誤區」，並透過實際例子讓大家更容易理解什麼是該做的、什麼是不該做的。

(1) 工作坊不是一場會議
開工作坊，不是要大家來聽報告、做例行公事，而是要聚焦處理某個明確的需求議題。曾經我辦過一場十幾個人的工作坊，雖然最後有產出，但過程中很多時間都在「繞遠路」——有人討論測試策略，有人開始問其他功能進度，整場分心了。後來我改採小規模方式：兩位開發、兩位測試，加上兩三個業務代表，大家直接對焦，效率大幅提升。

例如：假設我們在討論「外送餐點取消」的規則，一開始開發問「取消後要退多少錢？」業務說「看是否已備餐」，測試接著提問：「那如果取消發生在接單後10秒內呢？」這時大家一起站在白板前討論，而不是一個人在那邊輪流發表意見，這就是重點。

(2) 工作坊不是一場簡報
工作坊不是一人講、其他人聽的場子。若只有 PO（產品負責人）拿出 PowerPoint 滿場講規則，那不如直接寄簡報就好。真正有價值的，是透過來回討論釐清每個邊界情境，避免誤解。

以下是一個互動場景：
PM：「這邊是用戶取消後的流程圖。」
開發：「請問這裡的“取消成功”是指什麼狀態？備餐中也算嗎？」
測試：「那如果是在備餐剛開始的瞬間按取消？要退多少？」
這樣的互動，才是 Workshop 的靈魂。

(3) 工作坊不是設計會議
有時候大家會在討論範例時興奮過頭，開始聊起系統該怎麼設計，甚至討論要用哪個框架或資料表要怎麼設計。這樣很容易讓討論變得太技術導向，失焦。

下面便是一個常見的不合適的場景：
PO：「餐廳接單後取消，要退50%。」
開發：「那我是不是可以在 DB 裡加個欄位 cancelled_after_preparing？」
這時 facilitator 應該說：「我們現在先釐清規則，不進資料表設計，請專注在‘怎麼算退款’這件事。」

SBE 工作坊的關鍵不是討論多熱烈，而是每個人都能清楚知道系統應該怎麼做、什麼時候該怎麼反應。如果大家能透過範例講清楚邏輯，開發做得準、測試測得透、業務也能回報管理層，這場工作坊才算成功。