做為一個產品經理，撰寫需求文檔可說是產品經理PM無可避免的任務，同時要思考如何將產品規劃內容清楚表達給利害關係人(Stakeholder)了解並獲得支持。
在探討該問題時，我們回歸到人與人之間如何進行有效的資訊傳遞？口說與文字（文件）。
面對面溝通是最有效率傳遞資訊的方式，但隨著每天資訊爆炸與時間過去，我們99%已經忘記當時做某件事的時空背景與思緒；然而文字則是替我們保留了關鍵節點與脈絡，讓我們能夠回頭檢視與探討。
撰寫文件可說是產品經理最基本的工作。每個產業中，無論是產品經理、專案經理、產品負責人往往會被各式各樣的「會議溝通」填滿，為了有所考察與依據，許多文件需求與撰寫因此誕生了。舉個例子，軟體業常撰寫PRD，硬體業常寫SPEC文件，每個領域有不同的說詞，但其屬性與功用其實大同小異。
2019年我在#PM361° — PM知識社群與大家分享過這個主題，這篇就回顧一下，來聊聊軟體領域常用的PRD以及概述他的兄弟好友們，BRD與MRD。
- BRD: Business Requirement Document
- MRD: Market Requirement Document
- PRD: Product Requirement Document
說到這裡，大概有不少人對「PRD」是抱持各種疑問與是否有必要存在的眼神？常被討論的問題不外乎如下：
- 開發過程中，一直變動，文件一直改，那不如不要寫，反正寫了還是改？
- PRD內容要寫到多細？要涵蓋什麼內容？什麼時候更新？
- Roadmap 跟 PRD 有什麼不同，PRD不就是Roadmap嗎？
- RD又不會仔細看，幹嘛寫？
BRD、MRD、PRD 到底是什麼？
BRD在告訴利害關係人目前要進行的專案的商業價值與商業策略，短小精簡，沒有太多產品細節，主要溝通對象是高階管理者C-Level（eg：CEO、CTO、COO）。
為什麼要做這件事？商業價值是什麼？向C-Level闡明值得投入時間與金錢進行這項投資
我將BRD文檔中主要項目概括整理如下
MRD在告訴我們市場概況，我們要前進的戰場的情報概覽與分析，強調市場各種現況以及趨勢，屬於承上啟下的文檔，承接BRD開啟PRD方向，主要溝通對象主管、產品、運營、研發等團隊。
市場現況是什麼？存在機會是什麼？產品價值定位與主張在市場的哪裡？向產品、運營、研發等團隊以及主管說明產品模式、業務模式、運營模式、市場模式等，明確客戶及市場方向！
我將MRD文檔中主要項目整理概括如下
PRD著重於產品實作方法與流程，涉及交互、文案、頁面邏輯等，具體將產品各個細節解釋清楚，向研發團隊、設計團隊、測試團隊、UX團隊等說明產品規格
產品功能是什麼？邏輯流程是什麼？交互流程是什麼？use case有哪些？錯誤態如何處理以及時間、人力、資源等配置，向開發團隊說明清楚。
我將PRD文檔中主要項目整理概括如下
💡BRD — MRD — PRD是一個從高層次到低層次的關係，BRD從策略高度告訴我們做什麼產品，MRD從戰術的觀點告訴我們怎麼突圍，PRD非常細化的告訴我們產品做成什麼樣。
為什麼需要PRD？需要知道的價值三部曲
溝通，對象是誰？為了什麼目的？什麼時候進行？如何進行？
先歸納PRD要面對的利害關係人，如工程師、設計師、UX等，決定要對他們表明什麼目的，每個角色重視的點都不同；是分別說明或是集中說明；文件撰寫方式是協作或是單一人撰寫。別忘記我們的目的是推動產品開發，如何藉由這份文件跟各角色溝通，讓他們「清楚知道」目標（Goal），如何拆解進行任務（Task），產出產品才是最核心價值的地方。
文件本身格式是有彈性，需多方向的理解與更新，不會有最完美的文件範本，不斷嘗試找出適合團隊的文化，就是最有效的方式。
💡Tips：
1. 釐清利害關係人(Who)
2. 了解開發流程與時長，此時此刻團隊成員需要的PRD粒度如何 (When)
3. 觀察團隊協作的方式，彼此角色任務關聯性，重視項目是什麼 (What)
4. 了解團隊過去對開發文件如何分工，如何撰寫 (How)
5. 了解項目含義與功能，挑選適合團隊的方式來編制 (Idea & Action)
6. 透過詢問閱讀人員，了解自我盲點，不斷嘗試迭代更新 (Iteration)
歷史紀錄，過去做了什麼？原因是什麼？邏輯方法是什麼？
紀錄是用來復盤與釐清走過的道路，產品會不斷的堆疊上去，債務會不斷的累積，良好的紀錄是幫助我們遇到問題時，可以知道從什麼地方切入與檢驗，同時可以檢視產品開發的過程脈絡，減少猜測與不確定性。另一個面向就是當產品交接給下一任產品經理時，該產品經理會比較容易上手，增加onboarding效率。保持善念，不要留黑盒子（屎）給接手的人。
自我保護，白紙黑字留底，別讓口說無憑困住你
遇到這樣的對話，大概悔恨自己當初怎麼不寫文件，然後被迫吃下去，同時還要扛下產品責任，在老闆面前丟失credit。
💡Tips：
1. 清楚寫下事項A、B、C與負責人（責任分配）
2. 在眾人會議上討論與畫押，會後寄出會議記錄與該文件（責任歸屬）
溝通、歷史紀錄、自我保護，利大於弊，花點時間投資，長遠來看是有助益個人與組織發展。
問題：要寫多細節？什麼時候要完成？開發團隊不看，還是都直接跑來問我！
換位思考，站在閱讀者、實作者的角度來思考
複習一下，PRD有溝通、歷史紀錄、自我保護等主要三價值。先確認你的目標是什麼，探究問題，定義問題後再去嘗試解決。例如，是要拿來跟工程師溝通產品流程，但是寫完了他們都不看，一直跑來問我，那不如不要寫？
Step1：確立目標，「工程師，產品流程闡述」
確立溝通對象是工程師，目的是讓他們清楚了解產品流程設計
Step2：定義問題，他們不看文件，跑來問我！
那他們不看的理由是什麼？動機是什麼？分析一下可能原因
- 文件冗長不精準，看到天荒地老，重點在哪裡
- 文件需求、規格細節寫的不清楚，缺漏一堆
- 文件總是都一直改或沒更新
- 文件總是一堆文字，簡單一張圖可以說明吧
Step3：可能解決方法
針對定義好的問題，站在對方角度來思考嘗試提出解決方案
- 檢視自己的敘述方式並修正，是否用了太多形容詞。
例如：使用者查閱多次後，不再跳出通知訊息；當使用者心情愉悅時，他們會滾動更多頁面，我們要讓頁面滾動更通順。
「查閱多次」是幾次？
「心情愉悅」開發團隊在乎嗎？
「更多頁面」「更通順」是要表達什麼？ - 規格不清楚，文字一大堆，請多跟相關人員討論後撰寫.
RD在乎的是規格方向，不要一天到晚要RD通靈，具體的將步驟節點記錄下來，或是用流程圖更讓人了解到思路與規則。 - 文件一直改卻沒更新
當多次遇到照規格文件實作之後，事後卻發現文件過時，規格已經改了，RD就會對文件感到沒有可信度，轉而直接問PM確認意圖。建議可以跟RD團隊溝通好文件lock down時間（階段性文件、完整文件）、更新的頻率以及更新後主動透過IM通知給相關人員。
文件只是一個溝通的方式，別忘記還要搭配口頭溝通
文件只是一個溝通的工具 ，跟自己溝通（釐清思緒）、跟團隊溝通（闡明任務）、跟未來交接同事溝通（Onboarding）。
文字，具有保存性與可傳遞性，在時間與空間轉換的情況下，能夠讓所有人得到一致的訊息，確保大家都在同一個溝通平面。從公司角度來看，文件也是提供知識資產的保存，員工來來去去，如何將公司特有知識傳遞下去，文件就是其中一種方式。
何不把PRD當作是小產品經營？
產品開發大概會經過，Understand、Define、Sketch、Prototype、Development、Validation等，把PRD作為產品來展開，思路其實差不多。
- Understand：探索、釐清並了解目標用戶對PRD的需求
- Define：根據需求，定義PRD涵蓋項目元素
- Sketch/Prototype：嘗試撰寫大綱版本，並透過訪談驗證可行性
- Development：開工，寫起來
- Validation：完整PRD與實際產品產出落差距離，有驗證有迭代
PRD實作撰寫經驗分享
Step1： 建立目錄、索引
涵蓋的欄位有版本號、項目、優先序、負責人、發布日期，相關文件連結等等，主要目的是幫助在看文件前可以清楚知道這份文件的基本資訊，幫助查找。
Step2：需求闡述
涵蓋內容有目標、背景資訊、價值、方案、驗證指標、附件
- 目標：展示形式例如使用user story或是直述，端看團隊偏好
As I am ___, I want to ___, so that___
- 背景資訊與來源：市場、用戶、趨勢、老闆等，需求有根據並非無中生有
- 價值：營收、成本、市佔、使用者體驗、系統優化等，盡量將價值量化，提高感受度
- 方案：邏輯流程圖、業務流程圖、頁面流程圖、動作邏輯、錯誤處理等
- 驗證指標：定義可以衡量需求的量化指標，如預期提高營收多少%、提高DAU多少%等等，來檢視執行前假設與實際落差多少，幫助團隊做下一次決策與迭代
Step3：佐證需求
提供支持該需求的佐證，可能是數據、市調、競品分析等，強化需求可行性，同時是展現分析能力與洞察力的地方，提高團隊對我們的信任度。
Step4：審查（完善內容）
- 內容必要，正確，清晰，一致和明確，過多形容詞請省略
- 區分段落結構，可輕鬆查找信息（錨點、URL）
- 在正確的時間使用適當字體和顏色，但不要五花八門，三種顏色差不多
- 視覺化、具象化複雜的流程與細節，搭配圖示可以讓人更容易理解
Step5：回饋與迭代（訂模板，非第一次可跳過該步驟）
- 這裡指的是如果初步撰寫PRD，還不確定團隊想要看到什麼欄位資訊，可以按角色諮詢閱讀者，讓他們說明解讀到什麼資訊跟我們預期是否有差異，差異點是什麼？
- 修正它，修正它，還是修正它，然後訂出PRD大原則模板
Step6：更新（資訊補充或是補齊）
- 定期更新與歸檔，可能是按照開發週期，可能是按照自己的節奏，但建議要讓團隊能隨時知道最新資訊，才能發揮文件最大公用。
There is no perfect standard for PRD.
Think about what PRD does and deliver it with empathy.
相關資源
網路上其實有很多PRD的範本資源與其他產品經理如何應用撰寫，可多搜尋，其中個人認為中國互聯網這部分很多大佬分享與分析，可多多參考培養自己的方式。
關鍵字：
PRD、Product Requirement Document、Product SPEC、產品規格書、產品規格文件、產品開發文件、需求文檔、規格說明書、產品設計文件、PRD撰寫、PRD範本、PRD範例等等
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我
有任何互動或想法想私下聊聊，歡迎寄信聯絡我：[email protected]
