此篇文章是紀錄 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 完整規範要開發的細節，在過程中討論，讓大家各自從自己的專業中提供想法建議，更是團隊合作真正有效率且順利地達成專案的目標的核心。
而這也更考驗團隊合作的默契與經驗，除了自己跟團隊之間合作的默契培養，也透過曼陀號月會的交流，更快地吸取其他人在不同情境下的做法，累積自己的見識。
