需求文檔作為產品經理的基本功，其重要性不言而喻，那麼如何寫好需求文檔呢？作者分享了自己的一些心得。
提到需求文檔，不少人認為寫需求文檔就和寫論文一樣，只要按照模板順下來就可以了，還有人認為只要把問題說明白就好，寫不寫需求文檔就是一個形式：”與其寫PRD，還不如寫測試用例”。那麼，PRD是產品經理最”底層”的技能嗎？是不是“會寫”就達到要求了？產品經理應該將一部分精力放在完善PRD上嗎？還是像不少人認為的將這些完善的時間用在跟進進度等更”實際”的工作上？
下面我將就一下幾個方面和大家聊聊什麼是需求文檔，為什麼我建議產品經理要將“寫好”需求文檔作為工作要求。
- 需求文檔（ProductRequirement Document）是什麼；
- 需求文檔的使用對象有哪些；
- 寫好需求文檔分幾步；（乾貨在此）
需求文檔是什麼
需求文檔，ProductRequirement Document，簡稱PRD， 就是對產品的說明文檔。
這裡要說明的是，需求文檔的說明對象不只是限於產品的功能。產品文檔不僅要告訴別人你要幹什麼，還要說明為什麼這麼做，你的目標是什麼，驗收標準是什麼，如何不能一步到位，是否有分步的實現路徑。
第一，你要幹什麼，就是說明產品的功能邊界。要新增某個功能？或者改變原功能？ 最好能用簡潔的一句話來總結你要幹什麼，比如，在某產品內新增發紅包功能。
第二，為什麼這麼做，就是要明確新增或改變功能的原因。這個問題與產品經理對產品的定位和策略有關，建議將原因量化到你的KPI上，比如，新增發紅包功能的目的是提高與用戶的互動程度，以提高用戶粘性。
第三，產品目標是什麼，就是在團隊中建立共同目標。共同目標對團隊而言是非常重要的問題，後續你的研發、運營、測試、項目等都要圍繞產品目標開展工作。 比如，本階段某產品的目標是將用戶粘性提高至X%。建議設定目標時，要具體化到某個指標某個數字。
第四，驗收標準是什麼，就是要量化細化產品的驗收指標。建立驗收標準有助於後續走查，同時也能告訴團隊要做到哪一步。和產品目標相比，驗收標準是具體到某個版本某個階段的短期指標。因為很多時候，某個產品目標的實現需要分拆到不同的版本，你需要為團隊建立每個版本一步一步的驗收標準。
假如設計的產品功能負責，涉及系統性的迭代，可以將大的迭代拆分成更小的更新步驟。分步的實現路徑就是說明大的目標是什麼，通過幾個版本的迭代，要達到整體的效果是怎樣的，為了實現這種效果，每個版本要做什麼事等。
需求文檔的使用對象
很多產品經理把寫需求文檔當做“作業”或者“存檔”，總以為按照模板寫完就可以了。尤其是大公司，成熟的團隊一般都會有PRD模板，在這種情況下，不少人會有“填充型”的思維：反正我按照模板寫完也不會落什麼內容，何必自己再搞一份呢？
不管是新人還是老手，我不推薦直接複用模板。因為需求文檔是基於公司面向研發的。之前我的mentor和我說過一句話，我覺得非常在理。“將需求文檔也當做是你的產品”，從整個角度出發，從實際的使用者的角度出發去構想你的PRD要寫什麼，怎麼寫。
首先，需求文檔的使用對象是哪些人呢？
第一，研發人員。這也是需求文檔的主要使用者。需求文檔就是產品和研發溝通的工具。作為一個過來人，踩過不少口頭協議達成卻紮在需求文檔細節上的坑，我從中學到的最大的教訓就是，作為一名合格的產品，永遠不能將口頭協議作為驗收標準，不僅出了問題說不清，而且也不利於後續產品的繼承以及覆盤等。關於產品，要以需求文檔為準，當然這也非常考驗產品經理對框架的認知和對細節的把控力，以及對可能的風險的預知以及防禦能力。一份優秀的PRD，不僅能和研發說明“產品要幹什麼”，“要實現什麼功能”，而且也得交代清楚“交互的邏輯和跳轉的邏輯是什麼”以及“每種情況下的託底邏輯”。
第二，項目經理以及項目其他成員。這裡可能不同的公司會有不同的情況，整體來看，作為產品的leader，建議產品經理及時和項目組成員同步關鍵的項目進展，同時產出關鍵節點上的各種文件，這裡面最重要的就是PRD。
第三，產品經理本身。首先，驗收研發交付的產品時，要以需求文檔為準，不要過分相信自己的記憶能力，其次，強烈建議定期覆盤，找時間看看自己寫的歷史文檔，再回顧下每個版本出了哪些bug，想想是否對風險有預期，如何避免類似的bug,後續如何改進。這一點，對於產品經理的成長而言至關重要。
寫好需求文檔分幾步
那麼，如何產出一份優秀的需求文檔呢？
第一步，明確產品目標及框架。
其實在動手開始寫PRD之前，就應該對產品的目標及框架有成型的方案。如果寫的時候還不清楚自己到底要設計一款怎樣的產品，一定要停下來梳理清楚。
第二步，拆分產品目標至版本，制定產品roadmap。
如果產品目標本身設計得比較大，不能一個版本內完成迭代，可以拆分至不同的版本，這時候，產品經理要制定產品roadmap,也就是每個版本做什麼事。
第三步，建立自己的模板。
如果是老手的話，一般都會有自己熟悉和擅長的表達方式，可以根據上述兩個點對格式進行刪減更改。
如果是新人的話，建議先按照產品的目標和功能用mind畫一下每個模板的關鍵點，儘量列出來，先不用想著各個點之間的關係，列完之後再分類，比如可以按照前後端分開，其次，將自己作為小白用戶完整的過一遍流程，要注意用戶的分叉點，走到這一步，接下來怎麼走，這樣走會遇到什麼問題等。
第四步，按照你喜歡的方式開寫。
想清楚上面的這些問題，就可以開始“寫”了。有的產品習慣有完整的時間一次完成， 有的產品碎片化寫作也沒有關係，總之，你喜歡怎麼寫，就怎麼寫。不要糾結於一次完成還是多次完成。因為我在工作中，發現有的新人經常會有這樣的抱怨：根本沒有完整的時間寫PRD。其實這個問題很簡單，要麼你適應碎片化的工作方式，要麼你學會管理出完整的時間。
第五步，復讀PRD。
這個方法是我自己總結的一個小竅門，可以很好地查漏補缺。寫完之後，不要馬上發給研發，可以先換個腦子，然後自己復讀一遍，不要遺漏每一條用戶的路徑，也要注意各種細節，託底邏輯是什麼，用戶會不會有各種奇葩的操作，等等。
最後的最後，個人認為，寫好需求文檔是產品經理技能中最重要的一塊。因為產品經理最主要的輸出就是PRD，需求文檔的質量是產品經理水平的直觀體現。
另外，這裡有一份硅谷產品經理組的關於如何寫好PRD的資料，供各位參考學習。（https://svpg.com/assets/Files/goodprd.pdf ）
相關推薦
