軟體產品的功能規格到底怎麼寫才算完整？我曾經面試過一位 PM ，一個功能的規格寫了滿滿超過 40 頁的 PDF，真的是先昏倒！因為寫得太多反而工程師都不想看了，直接用問的還比較快。今天將提到為什麼產品開發需要規格書，以及撰寫的方法與範例。
寫功能規格書的目的
寫規格關鍵的目的，並不是給團隊未來查詢用，也不是給老闆或銷售部門了解功能用。功能規格主要用於，當產品需要更新時，讓產品開發團隊了解『我需要做什麼？』（這邊指的是設計師、開發者、測試人員、可能還有數據分析師）這邊先不展開談從 0 到 1 的情況。
那你應該明白了，規格能夠清晰的描述需變更了什麼內容（What）才是最重要的。因此，我個人不習慣用規格書這個詞，因為我認為規格應該言簡意賅，而『書』給人一種...讀起來很累的感覺。
完善的規格
檢查清單
✅檢查清單：
- 任務標題：以『主功能頁面 - User Story』的方式撰寫
- 目標：為什麼要做這個任務
- 預期成效：以數據指標去定義成效（順道一提，PM 的績效主要看這項）
- 截圖畫面 + 設計稿連結：1~2 頁 Mockup 或是以 Mockup User Flow 的方式呈現
- 起始點與限制 (Trigger Point) ：使用者如何進入這個使用流程？
- 資料欄位：頁面上需要呈現哪些資料？
- 正向使用流程 (User Flow)：大部分的情況，使用者會如何完成這個任務？
- 錯誤情境：當錯誤發生時該如何引導使用者回到正向流程？
- 新功能提示：此功能需不需要在軟體更新後，以某些方法提示給用戶知道？
- 附件：第三方 API 文件、相關的簡報或討論串
實際應用
以大家熟悉的網銀轉帳功能為例：
- 任務標題：轉帳 - 使用者可以發送自己的台幣資產至特定的帳戶
- 目標：網路銀行的基本功能（屬於最小可行產品的功能，所以此項非必要XD）
- 預期成效：一個月內的轉帳成功率達 90% (如果有數據團隊會進一步做定義)
- 設計稿：{一張 Mockup User Flow} + {設計稿連結}
- 起始點：點擊首頁的『轉帳』按鈕
- 限制：該使用者帳戶已經開通台幣帳戶並有轉帳權限
- 使用流程（6. 7. 8. 項寫在一起）
轉帳頁：
1. 選擇欲轉出帳戶，預設帶入第一個台幣帳戶
- 資料：用戶的帳號名下的台幣帳戶
- 戶名
- 帳戶號碼
2. 輸入轉帳金額
- 跳出數字鍵盤
- 資料：戶頭的台幣餘額
- 錯誤情境：輸入金額大於餘額，顯示錯誤訊息
3. 輸入或選擇收款的銀行代碼
4. 輸入收款的銀行帳戶
5. 輸入備註
6. 點擊『確認』按鈕，進入驗證流程（以下省略驗證頁）
成功畫面：
- 點擊『完成』回到首頁
- 點擊『再轉一筆』回到轉帳頁
失敗畫面：
- 資料：錯誤代碼與訊息
- 點擊『再轉一次』回到轉帳頁並帶入剛才輸入的資訊
- 點擊『取消』回到首頁
有問題或其他建議歡迎在底下留言，有興趣了解更多產品經理的知識請按讚及追蹤讓我知道呦，謝謝！
