PM必備技能: 產品需求/規格文件(上)
PM成長之路:產品經理訓練營#7
Mar 10, 2021
→為什麼PM要寫產品需求/規格文件?
→產品需求/規格文件:說明專案範疇的文件
→spec.(Product specifications):說明功能如何運作的產品規格文件
→PRD（Product Requirement Document）: 說明專案範疇的產品需求文件
→總結為什麼PM需要寫產品需求/規格文件?
- 產品功能/想法永流傳:
(1)透過文件讓knowhow流傳,一個好的文件可以不斷迭加。
(2)專案若有人員異動, 新成員可快速了解產品發想歷程, 減少教育成本,減少再走冤望路。 - 替所有利害關係人大腦開外掛:
人的記憶力有限, 且同樣一場會議, 與會人只會記得跟自己有關的事情(嚴重甚至不會記得), 文件讓利害關係人隨時翻閱確認對照。 - 提升利害關係人工作效率、降低溝通成本:
-PM: 減少協助客服或其他利害關係人確認操作功能上的問題。
-設計師: 快速理解產品設計。
-工程師: 了解哪些功能要串接後台資料庫, 避免認知落差造成bug。
-行銷: 了解功能賣點、快速進行產品定位及行銷相關規劃。
-客服: 先了解產品全貌,可及時協助解答客戶問題,減少和PM確認時間。
-既有團隊成員: 隨時查找。
-新進團隊成員: 快速上手。 - 保命鐵證:
當衝突發生時, 可把文件視為佐證, 降低爭議溝通協調時間成本。
以上三點接在"有用的"文件狀態下,也就是說一份文件沒有經過邏輯脈絡撰寫, 造成其他利害關係人看不懂外, 自己也有可能金魚腦遺忘當初寫的原因為何…
以下為PM常會接觸的PRD產品規格相關文件:
產品需求/規格文件: 說明專案範疇的文件
→原則:
- 把話說清楚:若文字無法表達清楚,可用表格/圖片輔助,清楚是指肯定指令,不該出現模糊文字(如:應該、好像、上方按鈕、下方方框),避免灰色空間造成文件無效。
- 讓設計師/工程師知道每個步驟:如按下按鈕後會如何。
- 不做的功能也都要寫出來:例如某些功能現在沒有,但未來可能會增加,讓設計師/工程師知道可擴充,避免程式寫死耗費更多成本修改。
➳tips:
1.若專案為敏捷式開發,無法等到規格都逐一確認好後在發布時,規格待釐清的地方可做標註。
2.PM確認文件順利溝通傳達後,讓負責利害關係人溝通執行,不再干涉執行細節,將重心放在產品面任務,除非有衝突需要調停,再依文件協調。spec.(Product specifications):說明功能如何運作的產品規格文件
→原則:
- 以功能拆分一個功能一份spec.。
- 對象為不特定人,必要情況下才使用專有名詞,降低閱讀門檻。
- 目標為將想法化為圖紙,任何人看就知道功能如何運作,只剩沒有寫程式碼。
- 邏輯/介面可視化:
*邏輯可視化:
(1)例外情況需要留意層級設計(符合程式迴圈思維)。
(2)無/有順序(無順序代表無關聯不需按照順序處理)。
(3)修訂紀錄,留存發展脈絡。
*介面可視化:透過以下繪圖方式呈現,實際依專案資源/時效性斟酌wireframe+mockup,甚至wireframe的線框加上mockup的互動都有可能
➳wireframe線框稿/mockup視覺稿/prototype原型差別:
(wireframe推薦工具:figma/mockup推薦工具:axure)
➳tips:介面可視化檢查清單:
產生、空值、消失、刪除、移轉、離線、刷新、排序、失效處理、Load More、圖片形狀、圖片比例、文字格式、文字字數、點擊、滑動、其他交付。PRD（Product Requirement Document）: 說明專案範疇的產品需求文件
閱讀對象為產品開發團隊, PRD板模參考架構:
- 修訂紀錄:放置文件最上方, 一目瞭然產品的迭代過程
- 大綱
- 商業目的
- 問題定義
- 解決方法
- 目標用戶
- 利害關係人
- 時間紀錄:文件建立/著手開發/預計完成/實際完成
- 基本要件:資訊架構/spec./設計稿
- 成功指標:自家資料庫指標/第三方工具指標
- 階段拆分
- 其他
總結
依專案產業/性質/資源/時效性,不一定都會撰寫spec.和PRD,有可能只撰寫spec.(再加入一些PRD內容),我覺得沒有一定的撰寫格式/用語,會因應不同團隊/公司而有所調整,就像一樣是使用中文, 但北部人習慣說橡皮擦、南部人習習慣說擦子/布一樣。
最重要的是團隊要有共識、文件迭代更新, 確保所有利害關係人都看得懂產品需求/規格文件, 避免PM一相情願寫了一堆文件結果只有流於形式, 工程師還要不斷的和PM確認功能(或工程師直接以自己理解的功能去寫程式, 讓PM獲得大大的驚嚇)。
產品需求/規格文件看起來不難, 但寫起來就會感受到文件需要縝密的邏輯思考,納入工程師構想的程式思維順序,但又沒有艱深的專業用語, 且讓每個利害關係人都看得懂, 實在是一門比口說還艱深的藝術。
下一篇會再跟大家分享我的產品規格/需求文件演化史。
➳產品需求/規格文件好文分享:
感謝你的閱讀及支持，任何問題都歡迎來信和Elaine交流｜ela71930@gmail.com
如果喜歡這篇文章，請給我1–10個拍手(越喜歡當然可以拍越多，甚至按住不放!這也是我持續寫作的動力！)此外還可以動動手指「Follow」Elaine ☺