規格書怎麼寫?工程師與業主的共同語言

很多專案的糾紛,追根究柢都是同一句話:「我以為你說的是那個意思。」業主以為「會員功能」包含點數,工程師以為只是登入註冊;業主以為手機版理所當然,報價單上卻沒這一項。規格書存在的目的,就是在花大錢之前,把這些「以為」全部攤在紙上。它不是官樣文章,是雙方的共同語言——寫得好,驗收時拿出來對照就好;沒有它,驗收就是各說各話。

一份看得懂的規格書,長什麼樣子

先講一個常見誤解:規格書不是越厚越專業。我們看過上百頁、充滿術語、業主根本讀不下去的規格書——那種文件只有一個功能,就是出事時拿來打官司。真正有用的規格書,業主要能在一兩個小時內讀完並指出「這裡不對」。我們的規格書固定有三種材料:

• 流程圖:用箭頭和方框畫出「一筆訂單從成立到出貨經過哪些關卡、誰做決定」。流程圖是給業主看的主菜,因為營運流程你比誰都熟,畫錯了你一眼就會發現。
• 線框稿:每個主要畫面的草圖,只畫版位和元素,不上色不做美術。重點是讓你看到「這一頁有哪些東西、按下去會發生什麼」,而不是爭論按鈕好不好看。
• 欄位定義:每張表單的每個欄位——名稱、必填與否、格式、預設值。這部分最無聊,但爭議最少發生在畫面,最常發生在欄位:「統編要驗證格式嗎?」「電話可以填市話嗎?」這種小事,上線後才發現就是資料庫要改、舊資料要洗。

規格書裡最值錢的一頁:不做什麼

多數規格書只寫「要做什麼」,但我們一定會加一節「明確不包含」。例如:「本期不含多語系」「不含 App,僅響應式網頁」「報表僅提供匯出,不含圖表」。這一頁在簽約時看起來多餘,在專案後期是救命的——當「順便加一下」出現時,雙方翻開這一頁,就知道哪些是加購、哪些是本來就該做的,不用傷感情。

規格書的價值不在於它寫了多少,而在於它讓多少誤會沒有機會發生。

例外流程,才是工程量的大宗

「主流程」通常只佔開發工作的一半,另一半在例外:付款失敗怎麼辦?客人下單後要改地址怎麼辦?兩個店員同時改同一筆庫存怎麼辦?我們自己營運進銷存系統服務加盟門市,深知現場的例外比想像多——退貨遇到跨月結帳、盤點時發現負庫存、活動價和會員價撞在一起,每一種都要有明確的處理規則。規格書如果只寫晴天劇本,報價一定低估,上線後一定追加。所以看到一份把例外寫得很細的規格書,別嫌囉唆,那代表這個團隊真的做過系統。

規格書是活的,但改要有紀錄

最後一個務實建議:規格書不是簽完就鎖進抽屜。開發過程中一定會有變更——市場變了、老闆想法變了、做出來發現不順手。變更本身不是問題,問題是口頭變更。我們的規矩是:任何規格調整都要落回文件,標註日期與影響範圍(要不要加錢、會不會延期),雙方確認後才動工。這聽起來官僚,實際上是保護雙方:業主不會被「當初沒說清楚」反咬,團隊不會被「我上次不是說過了嗎」追殺。

規格書的源頭是紮實的需求訪談,訪談沒做好,規格書寫得再漂亮也是精美的錯誤。如果你手上有一份廠商給的規格書想找人幫忙看,或想知道自己的需求該怎麼落成文件,可以參考我們的客製化系統與 SaaS 服務,或直接帶著文件來聊,我們見過夠多好的與壞的規格書,能很快告訴你缺了什麼。