PRD 撰寫與實例說明——The MentorShip 曼陀號 PM 組月會 02
2022/07/24閱讀時間約 3 分鐘
The MentorShip 曼陀號是由 Girls In Tech 主辦的職涯探索計劃，透過四次月會，在船長的帶領下讓同領域學員們彼此交流。
2022 年有幸錄取計畫，與街口支付產品長 Clare 及各位 PM 伙伴們一起在每月週日早上交流成長 💪
透過文字紀錄月會經驗，希望分享給更多伙伴 🙌
本次月會的主題是 PRD (Product Requirement Document; 產品需求文檔)，月會過程由船長 Clare 以自身經驗分享 PRD 的重點，以及成員間以事前攜帶的過往 PRD 來進行交流。此文會重點摘要月會中彼此分享的 PRD 重點給大家 ✨
PRD：將開發內容紀錄成文
PRD 紀錄了開發範圍、時程、各角色負責內容、變更與決策原因迭代歷程，它可以提供的有——
- 對於當下的參與者：釐清利害關係人職責，確保理解一致。歧異發生時，以此作為參考
- 對於未來的參與者：讓新進人員透過文件快速上手，將知識傳承從可能流動的人轉移至檔案
PRD：撰寫與溝通原則
一份好讀、資訊正確的 PRD 可以協助閱讀者快速掌握內容
作為 PM，在撰寫時可以掌握兩個寫作原則
- 以索引、段落強調內容優先級
- 以圖片、表格代替純文字描述
作為 PM，以 PRD 溝通時需要注意
- 內容變更後即時更新 PRD 並告知相關人士
- 明確標示 PRD 狀態（in progress or froze）
PRD vs BRD vs 與營運模式
在職場上除了 PRD，部分公司還會有 BRD (Business Requirement Document; 商業需求文檔)。PRD、BRD 的撰寫與應用，會因著個別公司需求而易，寫作者可能是 PM、也可能是其他分析師，以下依據不同公司的協作模式，介紹兩種模式——
- 模式一：跨國團隊，由 local office 完成市場分析 BRD，提交給總公司 PM，總公司 PM 不做 local market 分析
- 模式二：本國團隊：PM 完成 BRD 與 PRD
【延伸討論一】PRD 要寫到多細？
不同公司、團隊的溝通模式不同，PRD 扮演的角色、被期望的完整度也會有差異。在某些團隊，PRD 需要記錄所有相關細節，但也有些團隊僅將 PRD 作為大方向的參照，細節以 Ticket 為主。
月會當天與隔壁 Engineering 組私下交流時，發現過於細節的 PRD 對於部分 Engineer 來說，是沒有參考性的。有些直觀的交互內容，不必逐字逐句紀錄；有些可以交給 RD 發揮的細節，其實不需要 PM 完全定下來，只需要提供欲達成目標就好了。
PRD 終究只是一種溝通的媒介，具體該怎麼書寫、如何拿捏，就有待 PM 們發揮良好的溝通技巧，與團隊中的人們討論出最適解啦。
【延伸討論二】App 開發的三種模式：Native App、Hybrid App、Web App
在彼此討論 PRD 的環節，成員們分享起 App 開發的三種不同模式，Native App 與 Web App 都是兩種極端值，現在有許多 App 是採取混合的方式進行開發了。哪些版塊適合何種開發模式，則依據產品需求而定。在此先以簡單的表格介紹，讓各位了解三種模式的特性。
當日月會結束之後，PM 組還有午餐小聚！非常感謝船長 Clare 以及各個曼陀號籌辦團隊們的用心規劃，也很開心與各個成員交流，看到不同公司實作時的 PRD 文檔！
留言0
查看全部