歡迎客官來到又一期的壹佰干貨鋪~
你有沒有這樣的時候，在對產品經理一知半解的階段，瘋狂怒補網上的各種教程與干貨？
到處尋找「模板」與「規范」，可能你不是想要把他看懂，只是想知道，那些玄乎其神的文檔、原型究竟長什么樣。
你是否曾在網上找過各種各樣的PRD模板，感覺這貨簡直就是最神秘的東西，看到各種求職招聘信息都寫，熟練撰寫PRD文檔？
因為，寫PRD已然成為PM的基本技能了。
而作為一個產品新人，成功入職之后，首先就要開始撰寫各種文檔。而其中最重要的非產品需求文檔（PRD）莫屬。
而PRD也是令很多產品新人比較頭疼的東西，那么PRD到底該怎么寫？
本期干貨鋪帶來產品壹佰網站人氣最高的22篇實戰干貨，教你十步搞定PRD文檔寫作！趕緊收藏起來~
本期干貨鋪內容大綱：
第一步：什么是產品需求文檔（PRD）【干貨 x1】
第二步：為什么需要寫產品需求文檔【干貨 x1】
第三步：一份優秀的PRD應該包含的內容【干貨 x1】
第四步：一個完整的PRD應該具備的要素【干貨 x2】
第五步：一份完整的PRD的寫作步驟【干貨 x2】
第六步：0-1歲產品新人的產品需求文檔寫作方法【干貨 x2】
第七步：怎樣將你的PRD寫得更好【干貨 x2】
第八步：寫PRD文檔會遇到的問題和細節【干貨 x3】
第九步：優雅地利用Axure進行PRD文檔寫作【干貨 x2】
第十步：參考模版和案例【干貨 x6】
學完后你將獲得：
學習到更專業的PRD文檔寫作方法，對PRD文檔寫作有更清晰的思路。全面搞定PRD文檔寫作！
第一步：什么是產品需求文檔（PRD）
PRD是英文“ProductRequirement Document”的縮寫，翻譯為中文就是“產品需求文檔”，主要用于完整描述產品需求，向研發部門明確產品的功能和性能。
PRD的面向對象是研發部門，用于向他們說明需要開發的產品功能和這些功能的性能要求。PRD質量的好壞，在很大程度上不僅直接影響著研發部門是否可以明確產品的功能和性能，而且在很大程度上決定了產品的最終質量。
推薦干貨>>>產品經理小技巧——詳解產品需求文檔（PRD）
第二步：為什么需要寫產品需求文檔
在學習如何撰寫PRD之前，我們先要明白寫PRD的目的是什么：
①概念化”階段進入到“圖紙化”
我們之前在市場需求文檔(MRD)中闡述到的功能，都是表達的一個意向，不考慮實現方法和細節。而PRD則是將概念圖紙化，需要闡述詳細的細節和實現模型。產品人員可以通過撰寫PRD，梳理清楚方案實現過程中的各種問題和影響。
②向項目成員傳達需求的意義和明細
PRD的主要面向對象是項目經理、開發、設計和測試。如何向這些不同的角色表達清楚需求明細，就需要一份規范的PRD文檔來描述。項目經理通過文檔可以迅速了解任務的規模和相關接口，而開發設計人員通過文檔可以了解頁面元素和用例規則，測試人員可以提前根據文檔撰寫測試用例。PRD文檔在形式上是項目啟動的必要元素之一。
③ 管理歸檔需求
大都數的新需求都需要迭代幾個版本后才能走向成熟穩定的階段，如果沒有PRD文檔，在大型項目中，需求的迭代變更將變的無據可循。PRD的文檔修訂編號和命名也是項目規范化管理的主要方法之一。
......
推薦干貨>>>干貨 | 一篇文章搞懂移動應用prd怎么寫
第三步：一份優秀的PRD應該包含的內容
PRD從整體上看可以劃分為總體說明部分和UC部分，總體說明部分按照功能的不同又可劃分為以下幾個模塊，分別為修訂歷史——用以交代每次修改的責任人和修改內容，項目概述——從業務背景和意義入手從整體上告訴讀者為什么要做這個產品，功能范圍——從全局視角交代產品的功能點，重點描述系統中角色的職責，優先級劃分——對功能點進行優先級的排序，以便相關人員快速定位產品的核心功能和規劃后續工作安排，非功能性需求——對如性能和埋點等非功能型需求做出相關要求和說明。
UC部分則是由多個用例組成，每個用例對應產品的一個或多個功能點，由用例名、設計圖、流程圖、用例圖、狀態圖、序列圖、用例說明、交換說明、邊界條件等部分共同組成，這其中具體采用哪些類型的UML圖需要根據產品的業務類型而定。舉個栗子，偏向后臺流程管理的產品應將重點放在流程圖、時序圖、類圖等能表達清楚業務流程的UML圖上，而手機APP類以頁面交互為主的產品則應將重點放在用例圖、狀態圖等能夠表達頁面之間交換和關聯關系及用戶操作順序的UML圖上。以上內容就是是PRD的核心部分。
......
推薦干貨>>>一份優秀的PRD應該包含哪些內容？
第四步：一個完整的PRD應該具備的要素
PRD的能力映射出的是一個產品經理的產品能力，這種能力分基礎和高級兩類，毋庸置疑，PRD應該是一種基礎能力，產品經理必備的一種技能，PRD的能力反映的就是產品經理對用戶需求的理解能力，這種能力其實是建立在對行業的專業知識（表現在對業務的理解力）基礎上，再加之良好的溝通能力，一個優秀的產品經理寫出的PRD必然是準確度高，開發出來的產品擴展性好，同時受用戶歡迎。因此產品經理在日常必須深入學習行業知識，了解用戶的操作規則，多與用戶溝通，多傾聽問題，從而發現問題，解決問題，隨著對行業和用戶的理解及把控的逐步深刻，PRD闡述的內容將越來越全面，越來越有深度，這份PRD將成為其他人的學習資料，會產生深遠的影響。都說產品經理引領著產品的發展方向，是產品的“爸爸”或“媽媽”，衷心的希望每個產品經理都能做個稱職的父母親。
......
推薦干貨>>>如何寫出好的產品需求文檔（PRD）？
推薦干貨>>>產品經理該如何正確輸出一份PRD文檔
第五步：一份完整的PRD的寫作步驟
做好產品需求文檔的這十步，是經過長期的實踐經驗和反復驗證而得到的。可能這里描述的不是很全面，但他已經足夠讓你做一個成功的產品需求文檔。做好這幾步花費的時間要以項目的大小、復雜程度、個體學識、基本技能熟練度而定。
第一步：做好準備工作
你要做的是一個讓人無可爭議的產品，為了做好他，你必須做好前期的準備工作。你需要去了解你的顧客、競爭對手、產品團隊的實力和需要的技術。你需要從顧客、用戶、競爭對手、分析師、產品團隊、銷售隊伍、市場、公司職員等收集他們能發現的問題和可能的解決辦法。這里有很多的工作需要你去完成,在“成功的產品背后”這篇文章中有詳細的描述。
建立良好的交流也非常重要，它會影響著產品團隊。如果你的準備工作做的夠好，你也會變得越來越有信心和說服力。
第二步：確定產品的目的
任何一個好的產品都開始于一個需求。你必須清楚的了解這個需求，你的產品如何達到這個需求。
......
推薦干貨>>>產品需求文檔的10步
推薦干貨>>>如何完整高效地制作一款APP產品需求文檔
第六步：0-1歲產品新人的產品需求文檔寫作方法
作為一個產品新人，入職之后，首先就要開始撰寫各種文檔。而在我看來，其中最重要的非產品需求文檔莫屬。該文檔是將一個產品由抽象到具體最重要的步驟之一，也是讓技術人員詳細了解一個產品的【三部曲】之一，其他兩步分別是產品原型和語言溝通，會在接下來的兩篇文章中細說。而PRD也是令很多產品新人比較頭疼的東西，那么PRD到底該怎么寫？
要明白寫文檔的直接目的！
一般PRD大約會給以下這三類人看：技術人員，公司BOSS以及客戶，而本文以及接下來的兩篇文章所說的內容目標用戶均是【技術人員】。
即然目標人群已經明確，那么將PRD交給技術人員最直接的目的是什么?那就是讓技術人員看完PRD之后，便會知道你的產品具體是一個什么樣子。一個好的PRD會有什么樣的效果?那就是技術人員只有你的PRD，沒有原型，不經過語言溝通，他做出來的東西依然是你心中理想的樣子。
......
推薦干貨>>>0歲產品經理：如何寫需求文檔
推薦干貨>>>從思考到撰寫，產品新人如何寫出自己風格的「需求文檔」
第七步：怎樣將你的PRD寫得更好
Ruby語言的創始者松本行弘說過：“代碼越少，有可能出現bug的機會也越少。”文檔也是一樣，越是簡短，可能出現的錯誤也會越少，同時也更利于閱讀、維護和更新，所以建議大家的PRD要寫成“簡單易懂”。
產品需求文檔作為一種和開發人員溝通的重要工具，如果梳理得不好，會直接影響后續與開發人員的溝通質量，“簡單易懂”顯得十分重要。但很多剛做產品的同學不太了解其重要性，會走不少彎路，他們會發現：在開完需求會議后開發人員在開發的過程中很少去翻看需求文檔，通常情況下都是口頭詢問，同學們就覺得很奇怪，他們寫文檔寫得那么詳細，為什么開發人員就不看文檔呢？既然不看，就不用寫了，直接用口頭溝通不是更好嗎？其實，能用口頭闡述都小問題和小項目，如果是中、大型項目，參與人員比較多，文檔是有助于減低溝通成本和提高共走效率；還有一點，很多時候開發不看文檔，是嫌棄文檔的內容太長了，他們只需要簡單了解這個功能大概是做什么的，怎樣去實現就可以了。反觀很多同學在寫的時候會進入一個誤區，事無巨細地描述規則，總害怕開發同事看不懂，一個比較復雜的功能可能寫個300字，結果人家直接不看了。
......
推薦干貨>>>升級版丨寫PRD怎樣思考的更加全面
推薦干貨>>>怎樣才能寫出簡單易懂的需求文檔？
第八步：寫PRD文檔會遇到的問題和細節
換位思考
寫PRD一定要時刻想著換位思考，你得想著你的文檔是給開發、設計、測試等看的，語言上盡量好理解，盡量不要用形容詞，描述功能時，可以嘗試用開發的邏輯去思考書寫方式。
不要求大求全
這部分是我踩的一個深坑，我之前總想著把所有的邏輯都整理在一個流程圖上，然而這在很多情況下是不可能的，除非你做的這個產品比較簡單。即便你真能夠將所有邏輯整理在一個流程圖上，那么這個流程圖也會很復雜，不容易讓團隊其他人看懂。功能最好分點說明，正常邏輯和異常邏輯分開說明。
所見即所得
這是一個讀圖的時代，圖片展現是最清晰明白的。有的功能點，邏輯比較復雜，這時可以考慮用原型圖展現，原型圖可以做到所見即所得。
......
推薦干貨>>>編寫需求文檔常遇到的問題有哪些？
推薦干貨>>>產品需求文檔中容易被忽視的10個細節
推薦干貨>>>產品經理寫PRD文檔時需要注意的事項有哪些？
第九步：優雅地利用Axure進行PRD文檔寫作
就我所見，行業大多產品經理都是用Word+Axure原型的方式組成產品需求文檔。那這種方式，是否真的能方便地表達出產品需求？我問了很多程序猿，他們在開發時，一般都是看著效果圖和原型圖寫代碼，只有在遇到問題時，才會查看word文檔。也就是說，開發需要一邊寫代碼，一邊看效果圖，一邊看原型，還要時不時查看文檔。而且，大多數程序猿都不會逐字逐句去讀產品經理的長篇大論。那產品經理寫word真的合適嗎？這樣的用戶體驗真的好嗎？花費大量時間寫word真的有價值嗎？在Axure畫原型的同時，我們為什么不能直接在旁邊標注呢？這樣豈不是方便快捷很多嗎？
其實，當下流行一種直接在原型圖上標注的需求文檔撰寫方式。在新版的Axure8中，也已經推薦了原型加標注的需求文檔樣式。Axure8新增了一組部件—不干貼，就是方便產品設計人員進行功能標注。
......
推薦干貨>>>善用Axure寫PRD，全局規范一個都不能少
推薦干貨>>>Word產品需求文檔，已經過時了
第十步：參考模版和案例
記得自己在學習PRD文檔撰寫的時候，總希望能找到一份比較全面詳細又易懂的模板。如果你也曾有相同的困惱或者尚未遇到滿意的答案，或許本文可以提供不錯的參考。
......
推薦模版>>>這也許是最美的產品需求文檔模板
推薦模版>>>產品需求文檔模板，不用找了（附“簡”例）
推薦模版>>>喬不死帶你實戰項目：PRD通用模板
推薦案例>>>干貨丨“密碼管家”PRD需求文檔誕生記（絕密產品原型文檔）
推薦案例>>>PRD實用案例|「趕公交」App產品需求文檔
推薦案例>>>一個“廣場舞APP”的PRD文檔（含交互原型）
-完
-本期專題互動-
PRD寫作這一項產品經理的基本功，你掌握了多少？
你在寫PRD時，遇到過的最大的困難是什么？
把你的感想和大家分享一下吧~
「壹佰干貨鋪」——互聯網產品、運營、設計、職場精品干貨，應有盡有！
咱們下期再見~
