自學系列
自學背景
Q 這次要偷學什麼？
產品規格書怎麼寫
Q 為什麼想學這個？
因為沒有這個，工程師不知道要做什麼（會罵你）
Q 所以學習的動力來自？
不想被罵
產品規格概念
開始前先消毒一下，每家公司會需要的規格書都不同，僅供參考。
一個產品規格需要寫到怎樣？
- 最高規格：寫到工程師可以直接看到就會做了，然後做完驗收還都對
- 基本規格：User story、製作方式、驗收條件
- 最低規格：要有 User story 讓工程師知道要做什麼
堪用的產品規格可以長怎樣
可以包含以下項目：
- 為什麼要做＆要達成什麼目標
- 使用者需求（要做什麼）
- 規格與相關資源（怎麼製作）
- 驗收項目（怎麼知道有做對）
- 時程規劃（知道什麼時候要）
以下逐項介紹：
1. 為什麼要做＆要達成什麼目標
為什麼要寫這個？
驅動工程師開發的動力不同，有些工程師如果知道為什麼而做，會比較動力。
所以可以說明一下為什麼要做，做了之後會帶來什麼改變，這樣也可以讓他們在做的時候，更有方向。
例子：
- 為了增加網站效能
- 減少機器費用
- 加速 build code 速度
- 業務需求
- …
2. 使用者需求（要做什麼）
為什麼要寫這個？
因為不寫，沒有人知道要做什麼。
一般功能的使用者需求
要達成什麼需求？
- 我是 <會員／編輯／使用者>
- 我想要 <做某件事>
- 以達成 < 某種目的>
要製作的裝置
- web （桌機/平板/手機）
- App（iOS/Android）
debug 版的使用者需求
此問題在什麼情況下發生？
- 在<某種狀況/操作某個環節>下，
- 當執行<某個行為>，
- 發生了<什麼事情>，
- 應該要發生的是<另一件事情>。
發生問題的裝置？
- web （桌機/平板/手機）& 瀏覽器（chrome / safari / firefox / IE / in app browser / 其他）
- App（iOS/Android）
重現 bug 的步驟：
- （網址輸入… > 輸入文字 > 點選黃色按鈕 > 出現無法贊助的提示）
3. 規格與相關資源（怎麼製作）
為什麼要寫這個？
因為不寫，不知道要怎麼做。或是說，做了可能不是 PM 要的。
簡單說就是，PM 要什麼寫清楚，不要寫不清楚做錯又叫我改（工程師上身？）
以新聞網站 RSS 為例
- 去哪裡抓資料：哪個資料表，欄位為什麼
- 要抓取的資料方式：抓 published at 最新的文章
- 要抓取的數量：每次抓 75 篇
- 要抓取的資料欄位與類別（動態）
- 要寫死的欄位
- 更新條件（每過幾分鐘更新？每天固定何時更新？有新內容時更新？）
- 列出官方文件說明
- 抓取的特殊規則（哪些文章不抓；哪些欄位沒有時不抓）
- 要放在哪個資料夾內
- 網址規格（組成規則是什麼？是否要根據資料欄位組成？）
以文章輪播 slideshow 為例
- 設計稿（桌機／平板／手機／其他素材）
- API（最好連要打什麼參數都直接寫好）/story/${id}
- 排序方式：根據 sort order 從小到大排序；若都一樣，則依據 published at 從新到舊排序
- 抓取數量與條件：抓取 state 為 published 的前 8 篇編輯精選
- 抓取欄位：標題：抓 title／圖片：優先抓抓 image，如果沒有則使用 default image（附上連結）
- 資料不全時 / 錯誤處理（標題文字最多 2 行，超過截斷，顯示 …；若沒有抓到任何資料，則整個 Feature不顯示；若只有一篇，則不顯示左右箭頭）
- 動態處理（點擊 Feature 為圖片、標題整塊長方形；點右 = 下一篇 sort order +1；會自動輪播，每 2 秒換下一則）
4. 驗收項目（怎麼知道有做對）
為什麼要寫這個？
寫這個可以讓工程師知道你會怎麼驗證，幫助他們在製作的時候，可以先自行驗證。
在驗收的時候彼此也可以有所依據，知道這些項目都達成了就代表做完了。
以新聞網站 RSS 為例
- 內容包括：標題、文章網址、圖片（規格所開的項目）
- 內容共有 75 則文章
- 文章依據 published at 排序
- 每 15 分鐘會更新一次內容
- 不會抓到 status=draft 的文章
- 在 gcs 的 RSS 資料夾內可以看到檔案
- 網址格式為 domain/RSS/category/${id}
- 合作廠商有順利抓到資料，並正確顯示在合作廠商頁面上
- 通過驗收工具測試（例如：W3C Feed Validation Service, for Atom and RSS）
以輪播 slideshow 為例
- 輪播 slideshow 會自動輪播，每 2 秒換下一則
- 在後台上稿 1 篇，前台顯示 1篇，並不顯示左右箭頭，也不輪播
- 在後台上稿 2 篇，不設定 sort order，前台顯示 2 篇，顯示左右箭頭，第一篇為 published at 比較新的，按左右鍵都會到第二篇 published at 比較舊的
- 在後台上稿 3 篇，設定 published at 時間新到舊，前台顯示 3 篇，顯示左右箭頭，第一篇為 published at 最新的，按右鍵都會到第二篇 published at 第二新的，再按右鍵會到第三篇 published at 最舊的，再按右鍵都會回到第一篇 published at 最新的。按左鍵會反向呈現
- 按鈕 hover 過去時有 active / inactive 的呈現
- 當沒有任何文章時，整個輪播 slideshow 不顯示，下方 component 往上推
5. 時程規劃（知道什麼時候要）
為什麼要寫這個？
讓彼此心裡有譜，知道什麼時候可以完成什麼。如果太趕的話的做法是否可以改變，或是優先順序調整等。
建議可以列出階段性里程碑，比較容易進度追蹤。
寫在最後
理想上是希望 PM 可以花時間寫出完整的產品規格給工程師，然後工程師邊看規格邊製作，有問題來討論。不過實際上很多時候產品的規格會一直變動，加上時間很趕。常常能擠出的規格就只有 user story 和設計稿，工程師常常要通靈去想功能到底要是什麼，或是會來問 PM 才知道要怎麼做，這其實是很不好狀態，目前自己也在想可以怎麼改進中。
期待可以將規格模組化，最好是有一個服務勾一勾 PRD 就寫完了哈。
如果你也想要這個服務，那拍 17 下好了。
很多人想要，那就 side project 做起來好了哈哈哈
