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