產品需求文件 PRD 的應用難題

這篇文章想與你聊聊產品需求文件（Product Requirement Document，簡稱 PRD）這是一個軟體開發工作中的「房間裡的大象」，大家都知道有這麼一回事，但這件事情太痛苦了，以致於大多數情況下沒什麼好印象。

​

其實我是一個很喜歡寫文件的人，一方面是我不信任自己的記憶力，另一方面是透過寫作可以更深度的思考，所以通常我會盡可能的建立各式各樣文件，這不是為了別人而寫，而是為了與其他人溝通的過程，我可以幫自己準備好。

​

但坦白說，在我擔任產品經理的時期，即使以我自己的標準來看，我的產品需求文件 PRD 還是經常處於一塌糊塗的狀態。

​

這是因為擔任產品經理的時候，最重要的職責與大多數的時間，都花在溝通上面，換句話說就是開不完的會議。

​

在一整天的會議上，要處理客戶意見、蒐集跨部門需求、整合利害關係人意見、為懸而未決的事項找出推進辦法、調整排程與資源、對齊中短期目標、提議下階段的產品策略等等等一萬件大小事。

​

往往到了晚上八九點的時候，好不容易有獨處時間，才能坐下來打開軟體，將各式各樣的想法梳理寫成文件。

​

但是人的認知資源是有限的，一整天的會議消耗下來，晚上寫文件的時候狀態處於低谷，此時產出的文件品質可想而知極度糟糕。

​

接手 PRD 的設計師或工程師打開文件一看，自然會頭痛萬分，因為文件中會有各種的漏洞與矛盾沒有仔細評估過，甚至有些功能機制部分描述的很徹底，有些部分乾脆只有標題以及兩三句描述。

​

到頭來，與其閱讀這麼一份不知道可不可信的 PRD 文件，設計師與工程師會覺得還不如把 PM 抓來開會，討論清楚才開始工作，這樣才不會浪費一堆時間在沒有用的地方。

​

近日與朋友討論到關於 PRD 的議題之後，我也在個人臉書上發起了游擊訪談，蒐集到不少同業朋友的回饋，大家紛紛的與我分享他們在工作上關於 PRD 的痛苦經驗，這包括了：

• 文件可讀性差，用字語意不清或排版令閱讀體驗不舒適
• 文件冗長，難以掌握重點
• 不同的人各行其是，一間公司有 N 種版本的 PRD，每次閱讀都很痛苦
• 外行人套用 PRD 模版改寫，每個段落都在換句話說
• 文件內容偏離現狀，不具參考價值
• 即使花費心力撰寫，開發時依然發現許多沒有考慮清楚的地方，一直修改
• 開發相關的文件散落在各處，新功能與舊檔案連動，經常漏掉東西
• 不確定什麼情況要用什麼格式或流程圖來表達
• 沒有寫出驗收情境，對交付沒有產生實用意義
• 寫了對工程師有用的驗收情境，但老闆看不懂

​

除了負面的痛苦經驗之外，有軟體開發經驗的朋友們也分享了許多覺得 PRD 有積極意義的方面，這包括了：

1. 有明確的依據來開發
2. 討論比較容易對焦
3. 產品團隊知識資產管理

​

不論是設計師或者工程師，如果沒有明確的需求依據，就很難規劃工作項目，更何況經常都要評估時程與難度，這個時候有一份需求描述明確的文件在，可以幫助開發團隊迅速對齊目標，有足夠清楚的情境，用來判斷工作的範圍，發想合理的解決方案。

​

軟體需求的溝通經常是討論很抽象或複雜邏輯的議題，這個時候如果有一目了然的可視化文件來輔助討論，能夠幫助開發團隊迅速對焦，也能降低非技術人員參與討論的難度。

​

專業工作者經常熱衷於解決問題，但也很容易迷失在細節當中。

​

產品發展的過程除了「為什麼要做」的事情之外，那些「經過思考決定不做」的事情也很重要。

​

有時候當初決定不做的事，只是因為階段性的考量，等到條件成熟、水到渠成的那天就會納入產品路線當中，但如果不記得這樣的理由，以訛傳訛形成了錯誤的認知，可能後面反而變成「一開始就說好不做，為什麼現在又要考慮」的矛盾問題。

​

因此從積極意義的面向來看，PRD 文件所扮演的角色都是為了輔助溝通，讓開發團隊能提昇確定性，快速聚焦目標，以及能了解過去的決策經過哪些評估。

​

回到我自己的經驗中，我是在開始接手大型專案，需要同時跟三、四個不同團隊一起協作的情境中，才意識到自己需要跟超多人時時對齊認知。

​

如果每個人有一個問題就跑來打斷我一次作討論，那我一整天不就什麼事情都不用幹了？

但如果身為產品經理又找不到人，沒辦法解決開發團隊的疑惑，一樣也會耽擱進度。

​

這個時候花費時間維護 PRD 文件的好處就凸顯了出來，當我把已經達成共識的部分有條理、視覺化的記錄下來，往後每次有人詢問，我就可以快速丟出線上連結，告知對方他需要的情報怎麼尋找。

​

如果這樣不能解決對方的問題，那可能是發現了新問題，那就應該列為追蹤事項找時間解決。

​

如果文件上的描述與現況不符合，那通常是兩種情形，一個是我自己假掰寫了太詳細的規格，以致於成為幻想文，等到有人要實作才發現不合理。

​

另一個是需求已經變更，但我沒有更新到被影響的其他部分，這就屬於要找時間局部更新的例行巡邏事項。

​

需求文件的更新維護也是需求變動的成本之一，只是我們經常貪圖方便而忽略這件工作，就像煮完飯之後廚房髒亂放著不管，這些代價只是當下可以逃避，但依然存在。

​

舉個例子，例如你招待一大群人去餐廳宴會請客，但點餐時店員完全不作任何記錄，也沒有給你任何菜單作為討論依據，往往你點了某個菜，過了十幾分鐘才出來告知你沒辦法作，要換一個方式。

​

大家吃吃喝喝一面改菜單，一片混亂之後經過兩三個小時用餐結束，才發現你點了八道菜卻來了十二道，然後大部分的菜都跟你一開始點的不一樣。

​

你付錢的時候會覺得滿肚子氣，廚房也覺得委屈，認為是經過討論才發生的結果。

​

軟體開發過程的時間跨度少則數個月，多則以年為單位，許多利害關係人也不在開發團隊裡面，這意味著與開發團隊討論需求時，只是把他們從百忙之中撈出來諮詢，此時的溝通對於開發團隊來說，難度是很高的。

​

開發團隊會發現每一件事情都要從很基礎的概念說起，而利害關係人也會覺得很多議題都去脈絡化，搞不懂為什麼要討論，就被迫要做出選擇，因此防衛心態就會迅速升起。

​

像這類情境，我們需要的就是可視化的資料，用來幫助溝通的雙方降低認知落差。

​

最後簡單作個結論，關於 PRD 文件的難題與應用情境如下：

• 重視文件可讀性，要讓人易懂、好查找、好理解，才會有人願意花時間讀
• 維護與管理，PRD 的維護也是開發成本之一，忽視只是延後代償
• 產品發展路線，幫助團隊記得決策歷程
• 溝通可視化，輔助與開發團隊內外溝通時可以迅速對焦，降低認知落差

如果你對於產品需求文件 PRD 有什麼希望討論的議題，歡迎來信，我們可以一起聊聊。