關於PRD的小小調查
在寫完關於寫PRD的小小心得後，我在去年年底做了一個關於大家在工作上使用文件溝通的小小調查，雖然一個不小心拖稿了一下，但是希望大家還是對這個主題有些興趣，趁著過農曆年前來把調查結果分享給大家。
這次的調查總共蒐集了 100 份有效回覆，發放的管道是在台灣關於軟體開發、UIUX 設計、軟體產品管理相關社群，在正式進入結果之前，想先小小免責一下：
- 本調查結果無法代表整個業界群體，這不是普測，只是我在有限範圍內進行的小小調查。
- 本調查結果不具統計意義，這並不是大規模的抽樣調查，因此如果單看統計數據一定會與整體業界有偏差。
- 本調查沒有針對特定產業、商業模式、公司規模進行調查，因此結果無法代表特定類型團隊運作方式。
- PRD 不是萬靈丹，請回到團隊一起討論，尋找合適的運作方式。
1. 問卷架構
這一份調查的問項相當單純，主要將填答者分成兩群：所在團隊已經有在使用文件用於協作溝通 和 所在團隊尚未使用文件在協作與溝通。
分群後再個別詢問兩個群體關於：負責撰寫者是何種職能、一份文件的範圍邊界和文件內具備的內容有哪些。
最後再以大哉問的方式蒐集填答者的想法。
2. 填答者分群
首先，本次填答者使用文件的比例：大約有一半多一點的人所處的團隊已經有專門撰寫文件的成員。
3. 已將文件作為開發流程一環的團隊狀況
3–1. 在團隊中的主要負責撰寫文件者
在已經使用文件在開發流程中的分群中，大部分的填答者的團隊主要由產品經理 Product Manager 或產品負責人 Product Owner 撰寫，如果是專案型團隊則是由專案經理 Project Manager 負責。
但是也可以看到由其他職能角色撰寫的團隊也不少，從設計到系統分析師都有。
3–2. 一份文件包含的範圍
以我自己的經驗來說，因為是自己公司營運的產品，並且會隨著市場或客戶聲音不斷的擴充功能，因此一份文件的顆粒通常是一支功能。
但調查結果也有不少是一整支產品一份文件，專案型團隊的話則是以專案作為顆粒。
另外也有其他回饋：
- 一個專案一份文件會包含功能細項
- 新專案通常是一個產品一份，迭代的時候看範疇牽涉大小
- 一個 Sprint 可以交付的範圍，1 Sprint 2 weeks
- 看狀況
3–3. 一份文件包含的內容
文件內容來說，最多填答者團隊內會撰寫的有「產品（功能）價值或目標」、「使用情境」和「功能流程邏輯圖（Flow Chart）」。
另外其他有被選擇的有：
- 產品（功能）價值或目標
- 版本變更紀錄
- 使用情境
- 開發排程 （Priority）
- 時程甘特圖
- 資訊架構圖（IA）
- Functional Map
- 功能流程邏輯圖（Flow Chart）
- 流程線框圖（Wirefame）
- 介面設計稿（Mockup）
- 互動原型（Prototype）
- 產品指標（Metrics）
- 字串表
- 工作時間表
- 會議記錄
- 介面切圖
- Demo code
- 因為放在雲端工具中，還會連結 issue
- 機制的 use case
- 應該要看團隊需要什麼
並不是所有內容都一定要寫在文件裡，我個人的想法也是和團隊成員們討論開發或完成各自工作時所需要的內容，再把這些內容寫到文件裡面。
4. 團隊還沒有將文件正式納入開發流程當中。
4–1. 期待負責撰寫文件者
在未正式使用文件的分群中，大部分的填答者期待文件是由 產品經理 Product Manager 、產品負責人 Product Owner 或專案經理 Project Manager 負責撰寫。
其次則是產品設計師、 UX/UI 設計師或系統分析師與架構師，選擇工程師的也不在少數。
我想這可能會和團隊文化和產品類型息息相關，我身邊朋友待過的團隊的經驗是產品已經規模龐大且成熟了，通常每次改動的範圍小且負責開發的工程師通常可以決策大部分的流程，因此就會直接由負責的開發工程師撰寫文件。
4–2. 認為一份文件包含的範圍
這題可以和已使用文件的團隊做一個有趣的比較，已經有使用文件經驗的團隊多提供了更多拆分範圍的方式，可能是真的進到開發流程時會開始發現各種意想不到的需求吧。
4–3. 認為一份文件包含的內容
在未使用文件的團隊的填答者期待文件可以紀錄的內容也是以「產品（功能）價值或目標」、「使用情境」和「功能流程邏輯圖（Flow Chart）」為最多，這部分和已使用文件的團隊相符。
另外其他有被選擇的有：
- 產品（功能）價值或目標
- 版本變更紀錄
- 使用情境
- 開發排程 （Priority）
- 時程甘特圖
- 資訊架構圖（IA）
- Functional Map
- 功能流程邏輯圖（Flow Chart）
- 流程線框圖（Wirefame）
- 介面設計稿（Mockup）
- 互動原型（Prototype）
- 產品指標（Metrics）
- 字串表
- 工作時間表
- 會議記錄
- 介面切圖
- Demo code
- 功能限制條件
- 可能會依團隊對於 PRD 的期望目標有所不同
4–4. 填答者的角色
我在未使用文件的這個分群有多加上一題填答者本身的職能，主要是為了避免調查太多偏向單一職能而放的驗證題。
結果確實也是以設計師為最大宗（70%），大家在看這份調查的時候可以記得這會是偏向設計師的觀點。
5. 對「產品需求文件（PRD — Product Requirement Document）」或開發流程中的文件交付有什麼想法
最後的大哉問題我自己有提供一些預設項讓大家選，但回覆也蠻踴躍的，很有趣，大家也可以參考看看：
- 文件對我個人的工作幫助很大（預設項）
- 文件對團隊溝通的幫助很大（預設項）
- 不管有沒有幫助，只要有文件就是好文件（預設項）
- 寫文件好麻煩，不如不寫（預設項）
- 文件寫完就沒用了，放著生灰塵（預設項）
- 文件不夠詳細，還是都要靠通靈（預設項）
- 被制度逼著寫，也不知道寫得對不對（預設項）
- 寫得夠好，就有價值
- 文件除了可以協助在職的團隊從0了解要怎麼到1的初步全貌，亦能協助新到職的同事了解過去團隊在做什麼，但有時候撰寫的時間跟其他會議或是實作的時間會強碰到時，就會覺得很麻煩
- 許多功能需要往文件找才會知道開發的細節，非常重要
- 開發過程中，只要能溝通順暢不一定要有PRD 文件
- 很難寫出好文件
- 沒有寫過 也沒被要求要寫…
- 文件可以幫助團隊回顧 也能幫助新人了解產品
- 工程師只看圖，文字一律不看。文件是釘他們的唯一解
- 不同PM寫的PRD水準差蠻多的，有沒有用還要看是誰寫的XD
- 了解開發歷史來龍去脈
- 因為目前公司的開發狀態是沒有這份”寶典”，但我知道其重要性，這對於整體的專案的執行流程必定有極大的輔助效益
- 設計師若有餘力可以了解文件如何寫，對於跟其他職能溝通會有幫助
- PRD文件不是重點，文件只是一個幫忙溝通的東西，重點是團隊是怎麼合作溝通的，所以我覺得調查這東西有點沒意義，應該問自己現在身處的團隊，大家需要什麼，還有這應該不是設計師的工作，是PM的工作，因為團隊的需要什麼文件和溝通協調本來就不是設計師的工作，不然為什麼要花錢聘請一個PM職位，專業是要分工的，各個工作角色互相基本的尊重專業和分工，是團隊協作的基本
- 文件化的好處是還能作為討論或會議紀錄的證明
- 寫文件可以在回頭看的時候，對於自己做了甚麼決策和為什麼做這個決策更清楚
- 對於公司產品團隊來說有記錄留著是好的，因為即使是自己設計的東西久了也會忘記細節和脈絡。
- 文件應該是確保一致性，但通常實作上會完全按照文件開發的，是 少數 吧🙂不曉得
- 這裡的PRD跟敏捷裡的Backlig一樣嗎？
YH 回覆：是指Backlog嗎? 我的經驗裡是不一樣的，PRD是記錄已經開發或正準備開發的功能細節，
Backlog則是蒐集未開發需求的地方。
謝謝大家看到這邊，我個人認為這次的調查結果和我個人經驗沒有差很多，但是可以蒐集到這麼多回覆我還是很感動，也覺得很有趣！
那就先祝大家農曆年快樂、 2023 心想事成啦！
