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 文檔!