「講清楚了，卻還是做錯」：需求溝通最常見的問題其實是知識的詛咒
你一定看過這種需求對話：
- RD：「文件沒寫啊。」
- PM／使用者：「這不是理所當然嗎？」
兩邊都沒說謊。
真正的問題通常也不是能力，而是知識的詛咒（Curse of Knowledge）：你越熟某個領域，就越容易把自己的背景知識當成「大家都知道」。
於是你自以為講清楚了，對方卻在另一套假設下把事情做完，最後變成重工與互相抱怨。
## 需求不是「規則」，需求是「在真實情境下會發生的事」
很多需求文件一開始就想寫規則：
- 這個功能應該要怎樣
- 這個流程必須要怎樣
- 這個欄位不可為空
問題是：規則背後藏著大量未寫出的假設。
而這些假設，往往就是錯誤的來源。
## 解法：用例子把隱藏假設逼出來（Specification by Example）
實例化需求的思路很簡單：
不要先談抽象規則，先談「會發生的場景」。
把需求寫成三段：
- Given：在什麼情境下（前置條件）
- When：做了什麼操作（行為）
- Then：會得到什麼結果（可驗收的輸出）
例子一攤開，很多「理所當然」就會暴露出它其實不那麼理所當然。
## 為什麼它特別有效：它讓所有人站在同一張照片裡
抽象規則像是各自腦補。
具體例子像是一張照片：大家看的是同一件事。
- RD/QA 會看到邊界條件
- PM 會看到漏掉的場景
- 使用者會看到期待與實際的落差
於是溝通從「你怎麼不懂」變成「這個例子我們到底是不是同意」。
這會大幅降低對人的猜測，改成對具體行為的對齊。
## PM 的實務寫法：先寫 5 個例子，勝過寫 3 頁規則
如果你要把它落地，我會建議：
- 先挑 1 個最核心的使用流程
- 列出 3～5 個最常見的操作例子
- 再補 2～3 個你最怕出事的邊界例子（例：權限、錯誤、例外）
例子不用多，但要能代表「真實世界」會踩到的坑。
## 結尾
需求會出問題，很多時候不是誰不專業。
反而是大家都太專業，專業到以為彼此看到的是同一個世界。
用例子說話，是解除知識詛咒最有效的方法。
#產品管理 #需求分析 #SpecificationByExample #Agile #溝通
