Day 285

簽約時最大的痛點：需求對齊

接案其中一個大痛點，就是合約怎麼寫：怎麼把規格寫進合約裡，讓雙方有更明確的共識、更明確的邊界。不然對方永遠可以說「這個怎麼沒有？」「這不是很基本嗎？」，然後東西一直往上加。

我現在的做法是：訪談完，直接做一個按鈕按得下去、但背後還沒接資料庫的介面給客戶看，把訪談時提到的需求列在畫面右側，讓客戶一條一條蓋章或給意見。全部確認完，連同畫面一起印出來，當成合約附件。

用 BDD 寫規格，連我自己都看不下去

我最先想到的是 BDD（行為驅動開發：先用具體情境把功能該怎麼表現寫下來，再照著開發）。用舉例的方式（spec by example），把每個功能在什麼情況下該有什麼結果描述清楚，直接拿給對方看。

但光是我自己看這份規格，都覺得難以下嚥，更不用說讓客戶知道這東西有多重要。凡是牽扯到觀念、要教育客戶的東西，永遠是成本最高的。

以往的做法，可能是用 Figma（常見的介面設計工具）做一個 mockup（還不能真的操作的畫面樣稿），給對方確認，再把內容條列出來，印成合約附件。

現在 vibe coding（用口語描述需求，讓 AI 把程式寫出來）這麼成熟了，其實直接做一個沒有接資料庫的介面來確認就好。按鈕按得下去、頁面切得過去，但背後沒有真的資料，做起來快，客戶看到的又是接近成品的樣子。

訪談時提到的內容，就列在介面右側。客戶一邊看畫面、一邊讀文字，比較能想像、也比較能理解那段文字在講什麼。整個流程大概是這樣：

這裡有一個細節很重要：介面上每個位置的元件都要有明確的名稱。客戶蓋章的是「右上角的匯出按鈕」，不是「可以匯出」這種各自解讀的說法。

這樣做不代表就能完全消弭雙方的歧見。這種東西，即使雙方花費大量時間，也不可能完全避免。

那不如在有限的時間、精力下，盡可能讓成品具象化，出現在客戶眼前，降低未來產生變數的機率。對很多案子來說，這是非常有商業價值的。

隨著經驗累積，我們可以用現在的技術盡早取得共識，提供更好的服務，把不確定性降到最低。

合約是用來保護雙方的。簽一份模糊不清的合約，只是在賭運氣跟人品。