曼陀號月會|PRD 產品開發文件的撰寫方式分享

2022/10/01閱讀時間約 3 分鐘
此篇文章是紀錄 7/9 參加曼陀號 PM 組第二次的月會的活動心得,雖然很可惜因為個人因素,這次是線上參加,但整場三小時的活動,仍然收穫滿滿!
這次的主題是 PRD 的撰寫,PRD 的全文是 Product Requirement Document,是每個產品經理工作中最常接觸的工作內容。
船長 Calre 說,其實在台灣的中小企業公司,大部分的 PRD 都同時整合的 BRD (商業分析)與 MRD(上市計畫)的部分,也因此在介紹時,是以最完整的架構做說明,實務上不一定每家公司、每次專案,都可以完全符合,但可以依照自己的需求從中依照專案性質、團隊需求的狀況去萃取需要的部分。
曼陀號月會|PRD 產品開發文件的撰寫方式分享

為什麼需要 PRD?

但在討論一個好的 PRD 應該包含什麼內容之前,要先定義跟理解為什麼需要 PRD?直接口頭溝通不行嗎? 只用票裡用幾句話溝通需求難道不行嗎?
其實專案開發過程中,沒有絕對的準則,例如:敏捷精神會認為溝通大於文件,快速溝通才能快速迭代;但金融支付相關產業,法規等規定的限制下,有明確的文件規範才能清楚規則並且易於查找。
PRD 的存在的核心精神,是為了讓所有利害關係人都有共識,並且協助這份專案的開啟前中後,任何階段參與進來的人,都能共享同樣的文件跟知識庫,當作開發、迭代的參考。
好的 PRD 不是只有在專案進行中發揮作用,專案開發後的文件記錄完善,也更能讓後續接手的人了解狀況與脈絡。

PRD 包含什麼?

除了一般常見的背景說明、目標、時程、需求功能描述等內容,因應公司或專案類型的不同,還可能需要加上後端的循序圖、第三方的 API 文件、業務相關知識、甚至是名詞定義等細節。
也會因應 PM 的工作職掌範圍,加入流程圖、UI flow、Wireframe 等頁面規格的說明、數據分析需求,與發佈計畫的制定。
每個部分都可大可小,說明的越仔細,例如:用圖片代替文字敘述、或用表格代替列點文敘,越能降低後面溝通上的誤會。

實務上大家的做法

除了船長 Clare 的分享,還讓大家各自準備自己的 PRD 來交流討論,透過另一個第三方的眼睛來協助檢視,更能看出盲點,也因為大家都來自各自不同的公司,可以很快地觀摩到不同類型的文件規格。
以目前我在方格子的工作流程來說,是以 Notion 的軟體紀錄 PRD,好處是快速可以建立,學習成本低;但缺點則是當置入表格或圖片等說明時,不易閱讀與查找。
其他也有人使用 Word、Google Doc、Axure 等不同軟體工具撰寫,跟公司本身的習慣或工作流程也有相關,PRD 的重點不是形式而是內容。
其中我最印象深刻的是有航海士分享,自己家的 RD 不喜歡規格訂得太細,因為這樣會沒有技術可以施展創意的地方。的確 PRD 只是一個專案合作的開始,實際上仍然需要跟工程師、設計師等團隊合作,才能促使專案的完成。比起由 PM 完整規範要開發的細節,在過程中討論,讓大家各自從自己的專業中提供想法建議,更是團隊合作真正有效率且順利地達成專案的目標的核心。
而這也更考驗團隊合作的默契與經驗,除了自己跟團隊之間合作的默契培養,也透過曼陀號月會的交流,更快地吸取其他人在不同情境下的做法,累積自己的見識。
為什麼會看到廣告
illustration
贊助支持創作者,成為他繼續創作的動力吧!
102會員
42內容數
喜歡閱讀「設計、心理學、自我成長」等類別書籍。相信每個人都有自己的時區,不快不慢剛剛好,所以紀錄在閱讀成長的路上,覺得深刻又值得推薦的內容。
留言0
查看全部
發表第一個留言支持創作者!
從 Google News 追蹤更多 vocus 的最新精選內容