產品經理在日常工作中，不可避免地要接觸產品需求文檔這類產出物。那麼，產品需求文檔要怎麼寫，才是一份合格的需求文檔呢？這篇文章里，作者梳理了核心思路，並從五個方面進行了講解，一起來看。
產品經理在日常工作中，不可避免地要接觸產品需求文檔這類產出物。那麼，產品需求文檔要怎麼寫，才是一份合格的需求文檔呢？這篇文章里，作者梳理了核心思路，並從五個方面進行了講解，一起來看。
產品需求文檔（Product requirements document 簡稱PRD）是產品經理在工作中最重要的產出物，是承上啟下的核心文檔。
圖：
因此，PRD文檔是產品經理職業生涯中必須要掌握的技能。
我會從以下幾個方面講解，到底怎麼才能寫好PRD文檔。
寫PRD最重要的目的是：把需求講清楚，但一份優質的需求文檔一定是合適的方案+表達清晰。
合適的方案是指：我能分析清楚業務的現狀是什麼，期望是什麼，要解決什麼問題，用什麼方案解決。
表達清晰是指：我能把我希望用的解決方案表達清楚，傳遞清晰。
如何分析需求並找到合適的方案，我會在另外的文章中來講解，本文的重點會著重放在表達清晰上，但在我多年的實際文檔經驗中，往往合適的方案和表達清晰是一個交替生成的，當你儘可能想表達清晰時也能促使你獲得更加合適的方案，所以表達清晰不僅僅是應該，而是必要。
如果把需求講清楚是總綱，它還能分為三個小目標：
文檔受眾能精準理解文檔並轉化為他們的產出物：
多個角色間的無歧義標準：涉及研發、測試、UXD以及跨域的產品等角色時，需求文檔應作為在發生分歧時的唯一標準，幫助多個人之間消除歧義而不是引發新的歧義。
可追溯性文件：
一般來講，需求文檔總是圖表和文字的形式出現，幾乎沒有人會使用視頻和音頻，需求文檔一般會伴隨著需求評審，以便能夠進一步解釋說明和對文檔查漏補缺。
三、技巧-結構
技巧分為結構和表達，本篇文章會著重介紹結構部分，表達不分：圖表的介紹和使用以及其他文字性技巧、習慣會在後續的文章中體現。
從宏觀到微觀的描述順序，能夠讓文檔受眾在獲取到背景信息的前提下理解文檔的內容。比如當你看到Chair is blue時會認為它是什麼含義？
想要正確的理解這個句子，需要是加一些背景，比如在一個辦公室里，他得知公司將要破產，這樣我們才能順利成章的理解他作為主席，聽到這個消息非常沮喪。
因此，我會推薦將整個需求文檔都變為總分的結構，這會更加的便於文檔受眾的理解，也恰好符合金字塔原理。
金字塔原理是一種重點突出、邏輯清晰、層次分明,簡單易懂的思考方式、溝通方式、規範動作。
金字塔原理的基本結構是:結論先行,以上統下,歸類分組,邏輯遞進。
先重要後次要,先總結後具體,先框架後細節,先結論後原因,先結果後過程,先論點論據。
金字塔原理是一種重點突出、邏輯清晰、層次分明,簡單易懂的思考方式、溝通方式、規範動作。
金字塔原理的基本結構是:結論先行,以上統下,歸類分組,邏輯遞進。
先重要後次要,先總結後具體,先框架後細節,先結論後原因,先結果後過程,先論點論據。
針對整個文檔，我會將他們分為兩大部分：為什麼要做 和 要做什麼。
1. 為什麼要做？
此部分著重交待清楚背景、問題、價值、目的。
背景：用來描述此需求發生的業務背景，比如業務將要開拓一個新的市場，這個市場上大家普遍都會以貨到付款作為交易的方式。一番描述之後會讓對這個需求不熟悉的人更快的進入到這個需求的情境中。
問題：用來描述業務的預期與現在現狀的落差，這個落差是問題也是需求。如果能正確的描述歸納和描述問題，就能更快找到問題所對應的「答案」。
價值：做這個需求有什麼價值？我發現大多數產品經理，尤其是新手，往往會忽略價值的思考和表達。認為這可能是上一級或者業務應該思考的事情。我在產品經理的任何階段都建議大家去思考價值，價值背後所隱藏的信息有：
描述價值的同時，一方面是對自己工作的肯定，我在做有意義的事情，另一方面也是在說服文檔受眾，告訴他們：為什麼你的需求非做不可。
深入思考價值也你後續在跟業務溝通時判斷是否為偽需求打好基礎，沒有價值的事情堅決不浪費時間做。
在盈利性組織中，價值只來源於兩個方面：盈利和成本。
目的：此處的目的更多的是從系統建設的角度給出一些比較精簡的目標，比如需要在XX模塊兼容貨到付款的業務。
2. 要做什麼
此部分著重講方案的主體。
整體設計：也稱為概要設計，主要的目的有2個：
需求詳情：在這個大模塊里需要對需求要實現的功能/特性做詳細的邏輯說明，一般寫需求時先要對功能（也叫用例）進行拆分，拆分完在針對不同的功能點做詳細補充。
功能拆分：拆分完需求一般可以輸出一份功能地圖（Roadmap），需求拆分核心需要遵守MECE原則，即不重不漏。
功能描述：需要對邏輯做最詳盡的說明，根據團隊協作的習慣儘量細化，需細化到是或否應該走哪個分支流程，甚至細化到要用什麼表的什麼欄位。
四、環境
良好的環境能夠幫助產品經理在文檔能力上快速成長，此處羅列一些我認為較重要的因素：
文檔規範：良好的規範有助於產品快速融入團隊整體的表述方式，同時也能夠幫助一些產品些人快速成長，我曾經待過一個團隊，全部都是在需求卡片中寫一句話的需求，既沒有沉澱也沒有規範，導致需求上線後沒有人知道會有這樣一條邏輯。
需求模板：產品團隊一般都會有需求模板，但是模板也只能約束整體格式，具體的寫作風格還是會因人而異。
管理方式：文檔的管理方式大致有三種。
研發測試的嚴格要求：同事的高標準、嚴要求，評審會上的「挑戰」都會促使你精進文檔能力，將需求描述的更加簡練清晰，無歧義。
能有機會做大項目：只有較大的項目才會涉及到多個模塊、多個系統，這會有效提升整體設計的能力，全局設計的能力。
有人帶：團隊中有人帶可遇不可求，一方面能手把手讓你快速上手現有業務，一方面可以階梯式的給你分配項目，並不是項目越大越好，循序漸進的增加項目難度會更適合新手。
五、態度
沒有人可以叫醒一個裝睡的人，不管在什麼樣的環境中，我們都不要成為那個「裝睡的人」。
精益求精：
為他人著想：你寫的明白，別人看的清楚，需求文檔就是建立信任最基本的產出物。
保持高標準：認認真真寫一個文檔簡單，認認真真寫每個文檔就很難，但某天當你回首以望時，你早已從小草長成參天大樹。
本文由 @秀明 原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。