把 Spec 寫成生死狀，團隊只會更不敢負責
SBE 的精髓不是把文件寫到滴水不漏，而是用範例逼出對話，讓 RD 主動提出邊界情境，重建開工前的共識與信任。
我看過不少團隊把 Spec 寫成「生死狀」。
PM 以為寫越完整越安全，於是把每個 case 都塞進文件；RD 則反手把文件當成免責條款：你沒寫我就不做，出事也跟我無關。
表面上是需求文件問題，本質上是合作關係出了裂縫。
SBE 不是防禦性文件，它是用來把話講清楚
SBE（Specification by Example / 實例化需求）常被誤解成「更細的 Spec」，結果變成：
- PM 用範例把每一條路都寫死
- RD 只做範例裡出現的事
- 兩邊都很累，還是會漏
SBE 的精髓其實是：對話 ＞ 文件。
範例的作用，是把抽象需求拉到可討論的層級，讓大家在開工前對齊「通靈頻率」。
真正的警訊：RD 只願意做範例裡的事
如果 RD 的工作方式是「範例之外一概不碰」，那不是謹慎，是把思考外包給文件。
這種團隊常見的後果是：
- 需求稍微變動就全盤崩解
- 邊界情境永遠到最後一刻才爆
- 規格越寫越厚，信任越寫越薄
更現實一點：在 GenAI 時代，單純照著例子做的人，價值會被快速稀釋。
SBE 要寫到什麼程度才夠
我很認同一個判準：
寫到 RD 會反問你：「那如果發生這種狀況怎麼辦？」為止。
這句話的重點是「反問」。
當 RD 開始主動提出邊界情境、補上例外與風險，你才知道範例真的在「釐清需求」，而不是在「畫地自限」。
我會怎麼把 SBE 寫成團隊習慣
幾個我覺得實用的做法：
- 每個 SBE 範例都寫清楚：前置條件 / 行為 / 期望結果 / 例外
- 範例後面一定留一段：「還有什麼沒被覆蓋到？」讓 RD 提邊界
- 把「範例」與「規則」分開：範例是案例，規則才是可擴展的判斷準則
- 開工前用 SBE 做一次對齊會議，會議結論再回寫到文件
文件可以很完整，但它永遠替代不了對話。
如果你需要把 SBE 變成一個「能讓大家更敢討論、也更敢負責」的流程，它就不該被當成防禦工具，而應該是重建信任的橋。
原文連結：Threads 貼文
