產品經理的必修課 - 規格書如何撰寫

軟體產品的功能規格到底怎麼寫才算完整？我曾經面試過一位 PM ，一個功能的規格寫了滿滿超過 40 頁的 PDF，真的是先昏倒！因為寫得太多反而工程師都不想看了，直接用問的還比較快。今天將提到為什麼產品開發需要規格書，以及撰寫的方法與範例。

寫功能規格書的目的

寫規格關鍵的目的，並不是給團隊未來查詢用，也不是給老闆或銷售部門了解功能用。功能規格主要用於，當產品需要更新時，讓產品開發團隊了解『我需要做什麼？』（這邊指的是設計師、開發者、測試人員、可能還有數據分析師）這邊先不展開談從 0 到 1 的情況。

那你應該明白了，規格能夠清晰的描述需變更了什麼內容（What）才是最重要的。因此，我個人不習慣用規格書這個詞，因為我認為規格應該言簡意賅，而『書』給人一種...讀起來很累的感覺。

完善的規格

檢查清單

✅檢查清單：

1. 任務標題：以『主功能頁面 - User Story』的方式撰寫
2. 目標：為什麼要做這個任務
3. 預期成效：以數據指標去定義成效（順道一提，PM 的績效主要看這項）
4. 截圖畫面 + 設計稿連結：1~2 頁 Mockup 或是以 Mockup User Flow 的方式呈現
5. 起始點與限制 (Trigger Point) ：使用者如何進入這個使用流程？
6. 資料欄位：頁面上需要呈現哪些資料？
7. 正向使用流程 (User Flow)：大部分的情況，使用者會如何完成這個任務？
8. 錯誤情境：當錯誤發生時該如何引導使用者回到正向流程？
9. 新功能提示：此功能需不需要在軟體更新後，以某些方法提示給用戶知道？
10. 附件：第三方 API 文件、相關的簡報或討論串

實際應用

以大家熟悉的網銀轉帳功能為例：

- 任務標題：轉帳 - 使用者可以發送自己的台幣資產至特定的帳戶

- 目標：網路銀行的基本功能（屬於最小可行產品的功能，所以此項非必要XD）

- 預期成效：一個月內的轉帳成功率達 90% (如果有數據團隊會進一步做定義)

- 設計稿：{一張 Mockup User Flow} + {設計稿連結}

- 起始點：點擊首頁的『轉帳』按鈕

- 限制：該使用者帳戶已經開通台幣帳戶並有轉帳權限

- 使用流程（6. 7. 8. 項寫在一起）

轉帳頁：

1. 選擇欲轉出帳戶，預設帶入第一個台幣帳戶

• • • 資料：用戶的帳號名下的台幣帳戶
    • 戶名
    • 帳戶號碼
      

2. 輸入轉帳金額

• • • 跳出數字鍵盤
    • 資料：戶頭的台幣餘額
    • 錯誤情境：輸入金額大於餘額，顯示錯誤訊息
      

3. 輸入或選擇收款的銀行代碼

4. 輸入收款的銀行帳戶

5. 輸入備註

6. 點擊『確認』按鈕，進入驗證流程（以下省略驗證頁）

成功畫面：

• • 點擊『完成』回到首頁
  • 點擊『再轉一筆』回到轉帳頁
    

失敗畫面：

• • 資料：錯誤代碼與訊息
  • 點擊『再轉一次』回到轉帳頁並帶入剛才輸入的資訊
  • 點擊『取消』回到首頁
    

有問題或其他建議歡迎在底下留言，有興趣了解更多產品經理的知識請按讚及追蹤讓我知道呦，謝謝！