起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識3個角度，聊聊產品經理的PRD基本功
本文從三個角度，分析了PRD這項基本功的培育方法~
曾有一個段子：
第一個問題：如果把你派到競品公司搗亂，作為產品你會怎么做？
產品經理答：每天瘋狂提需求，不管是否有用。研發排期我不管。
第二個問題：你現在做的主要工作是什么？
產品經理：……
這篇文章，雖然不會讓你瞬間越階，但至少會讓你對產品需求文檔有個相對系統的認識，提升工作效率。只要你在做產品相關工作或是想往這方向就業做準備，都可以學習一下。
作為一只有夢想的產品狗，每天必備功課就是和各部門溝（si）通（bi）。
但你是否還能回憶起，被程序猿挑戰邏輯漏洞的恐懼？還有被UI設計獅質疑需求價值的尷尬？
更有當你興致勃勃準備驗收需求，突然發現實現方案完全不是自己想要的，是不是只能無可奈何，忍氣上線。
如果你經常遇到上面的情況，說明你的產品基本功：PRD需求文檔撰寫能力還不到家。
一份好的產品需求文檔，可以減少開發人員與設計人員對需求的理解難度，避免產品經理陷入無休止的溝（si）通（bi）中….
今天就想和你聊聊這項基本功的培育方法~
01?什么是PRD產品需求文檔
傳說中產品經理一生要面對三大文檔：商業需求文檔（BRD）、市場需求文檔（MRD）、產品需求文檔（PRD）。
其中產品需求文檔PRD的撰寫是很多產品新人首先要掌握的，因為它是在項目過程中給設計、開發、測試這樣的實施人員看的，
它仔細描述了產品功能應該怎么做，是產品落地前的指南針、方向盤。也就是說，PRD的目的是給實施人員講述產品最終要做成什么樣。
較完整的PRD目錄結構包括：概述、產品描述、功能需求、非功能需求、上下線需求、運營計劃、附錄。
如下圖所示：
PRD的展現形式，行業內有2種：
一種是傳統WORD，有清晰的目錄結構，自頂向下閱讀，以圖文方式說明各個功能模塊的設計思路，業務邏輯，如下圖PRD目錄：
WORD格式的PRD在大公司會比較常見，優點是結構完整，閱讀順暢，也不會有遺漏，適合成熟產品；
還有一種是把PRD和Axure交互原型混排在一起，如下圖：
這種做法適合要求快速迭代的產品：
- 對產品人員：能夠做到PRD快速產出；
- 對開發人員：不必一頁頁的翻文檔，可以直接可視化查看頁面交互情況，對照頁面標記去查看對應功能，所見即所得；
- 對測試人員：則可以根據頁面交互跳轉去寫測試用例，對后期測試可提供更加完整的測試思路。實際做的時候，可以二者結合，取最適合自己團隊的方法。
02?哪些人會關注PRD文檔
如上所述，PRD面向的是產品落地的實施人員，涉及到多個角色，每個人關注的點都不同。
具體如下：
- 產品經理：自查產品功能點，更加透徹和完整地梳理產品需求；
- 交互設計師：檢查自己的交互稿是否滿足需求，是否有遺漏特殊情況、異常情況、極限情況等；
- 開發工程師：檢查自己的程序開發是否符合PRD中描述的相關要求；
- 測試工程師：將PRD中的功能描述和用例轉化為測試用例的一部分，進行產品可用性測試；
- 運營/財務/法務等：確認產品上線前的準備工作
優秀的產品經理會在寫PRD時換位思考：
一方面，會在語言描述上更客觀，使用“支持、顯示、要求”字樣。
盡量不用形容詞、模棱兩可的詞，比如“可能、以后、盡量、很好地、快速地”。
另一方面，會在描述功能時，更多以開發邏輯去思考書寫方式，使用流程圖、數量級、優先級這樣的表達方式。
或者用開發語言來闡述概念，比如“接口定義、數據結構、云端存儲”。做到精確無歧義。（產品懂點研發沒有壞處，只會讓你和研發溝通更順暢）
03?如何寫出優秀PRD?
PRD作為產品經理的第一個產出物，也應該以做產品的思路來實施。
- 第一，站在用戶，也就是讀者（上文提到的其他團隊伙伴）角度去想他們想從PRD中獲得什么；
- 第二，保證文檔結構清晰、排版美觀，閱讀舒適；
- 第三，保持文檔的持續更新，并及時通知修改情況；
- 第四，邏輯嚴謹，需求說明有理有據。
OK，如果你現在還一頭霧水的寫不出沒關系，最簡單的辦法，人人都是產品經理上找一份成熟的需求文檔，逐條閱讀理解以你的話復述一遍。這是深度理解需求文檔最簡單粗暴的方法了。
本文由 @Jason?原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于 CC0 協議
學習了 ??
我覺得原型+說明詮釋prd比較實用，不然prd如果寫的不好，開發人員也看的是一頭霧水