自學系列
自學背景
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 做起來好了哈哈哈