因為寫的是針對產(chǎn)品經(jīng)理入門的文章，在前面兩篇中主要談了作為產(chǎn)品經(jīng)理兩項底層的核心能力，從這篇文章開始，包括后面連續(xù)幾篇，都可能都講一些非常具體的，可拿來即用的技能。對于任何行業(yè)亟待入門的人來說，講太多抽象的理論大家都是聽不懂的，身不在其中、沒有躬身實踐過，對于那些被別人總結(jié)出來的頭頭道道一般是難以領會的，除非悟性極強。
這篇文章，主要講作為一個入門的產(chǎn)品經(jīng)理，怎么寫好一篇合格的需求文檔。
??01 ???什么是產(chǎn)品需求文檔
產(chǎn)品需求文檔，英文全稱Product Requirement Document——簡稱PRD（以下簡稱PRD文檔），其面對的核心用戶是開發(fā)人員，也許你聽人說過，產(chǎn)品需求文檔市場人員也要看、老板也要看、xxx也要看——Bullshit!!!
簡直鬼扯，我可以很負責任地說，看需求文檔的只有開發(fā)人員，你只要服務好他們，你的工作就合格了，不用擔心會有人對你地文檔說三道四，包括你地老板，因為他們根本看不懂、也沒時間去看、有時間也不會去看，可以說他根本不關(guān)心這些事情，要不要你干嘛，他們關(guān)系地只是一個結(jié)果，不必詫異，這對于產(chǎn)品經(jīng)理來說是大有裨益。
PRD文檔可以說就是開發(fā)人員開發(fā)產(chǎn)品的指導手冊，如果說原型是圖紙，那么PRD文檔就是詳細的指標說明書，有關(guān)產(chǎn)品的所有參數(shù)細節(jié)，都能夠在這里找到記錄與說明。文檔還有另一個好處就是，便于下一個人接手你的工作時，他只需要看文檔就可以了解有關(guān)產(chǎn)品所有的詳細事項，這件事對于公司來說意義極大。
??02 ???PRD文檔的組成
2.1文檔說明
這個部分是文檔的開頭部分，主要說明當前文檔所對于的產(chǎn)品名稱、所屬的產(chǎn)品線、所處部門等，如果開發(fā)工作面對的是多個部門，那么這部分的存在是很有必要的。
? ?產(chǎn)品名稱? ?所屬部門
? ?產(chǎn)品線? ?xxx? ?負責人? ?xxx
? ??產(chǎn)品編號?? ?xxx? ?項目編號??xxx
2.2版本記錄
這個部分是用于記錄當前產(chǎn)品的版本號，一個產(chǎn)品做好之后，后期大迭代、小迭代肯定不斷，這些瑣碎的事項是需要進行記錄的，便于以后回溯。
? ?版本號? ?修訂內(nèi)容? ?修訂人??修訂時間
? ?v1.0.0? ??1.xxxx
? ??2.xxxxx
? ?3.xxxxxx
? ?xxxx? ?xx-xx-xx
版本號：這里的版本號不是已發(fā)布的產(chǎn)品的產(chǎn)品版本號，只是當前文檔的版本號，文檔使用版本號好的原因是，迭代很多，而每次迭代的需求，不應該在原來的文檔中進行修改，而是應該另起一個副本，在副本上進行增刪改查，如果文檔的管理沒有版本號的概念，最后的結(jié)果就是之前做了哪些、后面做了哪些，再后面做了哪些，直接傻傻分不清，這時候便給了開發(fā)、測試復仇的機會，只能坐等挨批。
修訂內(nèi)容：這里記錄當前版本相比于上一個版本，新增了哪些、修改了哪些、刪除了哪些，切忌不要在此處長篇大論，做簡明扼要，概括性的敘述即可。
修訂人：當一個產(chǎn)品需要多個人進行協(xié)作時，增加修訂人這一項是保險之舉，其他人看文檔如果有不明白之處可以直接找當事人，省去找人的麻煩。
修訂時間：這個沒什么可多說的，好不容易花了幾天時間，整理出來的文檔，蓋上時間戳是一件利己利人的事情。
2.3全局說明
這一項并不是必須，但是如果你有一些通用的規(guī)則需要進行說明，那么，在全局說明里進行統(tǒng)一的描述是一個比較高效的選擇，否則會像懶婆娘的裹腳布又臭又長，畢竟沒有人喜歡在一個文檔里看到許多重復的東西，再說后續(xù)修改的時候，那么多處，萬一某個地方漏掉了可咋整，至于說這里要寫什么，別人說了沒用，只有你自己的總結(jié)的才是合理的、實用的。
2.4各模塊需求說明
這部分是整個文檔的主體，是重頭戲，在這里你需要根據(jù)產(chǎn)品的模塊分別進行詳細的注釋說明，但表達格式應該統(tǒng)一，示例如下：
??數(shù)據(jù)名稱??數(shù)據(jù)類型??交互說明??注釋? ?備注
? ?xx??xxx? ?xxx? ?1.xxxx
?2.xxx
??xxx
2.4.1. 數(shù)據(jù)名稱、數(shù)據(jù)類型：
這里的數(shù)據(jù)名稱為所有文字能表達的東西，包括字段、以及各種組件，其類型包括：
文本、按鈕、輸入框、復選框、單選框、下拉框、時間、日期組件等等。
2.4.2 交互說明：
交互說明需要詳細描述對于數(shù)據(jù)名稱的所有動作，包括鼠標懸停、單擊、雙擊、下拉、長按、三指、四指等等有什么效果，并把對應的效果進行詳細的介紹。
2.4.3. 注釋
這部分是對應數(shù)據(jù)名稱需求的重點描述部分，需要在這里澄清當前需求所有的具體邏輯、規(guī)則、業(yè)務流程、影響等，如果比較復雜時，可以在這里對業(yè)務的背景、用戶的使用場景也做簡短的介紹。
2.4.4. 備注
在大多數(shù)文檔、甚至產(chǎn)品中，備注就好像是萬能藥，也更像是保險絲，當無法預料用戶的操作時，通常都用該功能來兜底，但在產(chǎn)品設計中切記保持克制，不可濫用。
以上便是一個份需求文檔的基本框架。
? ?03 ??? ?兩種需求文檔的表現(xiàn)形式
在這幾年的職業(yè)經(jīng)歷，見證了這個職業(yè)井噴式發(fā)展的歷程，有關(guān)產(chǎn)品的社區(qū)、協(xié)作平臺也是這段時間突然興起的，對此，我在前面的一篇文章中表達對于未能抓住這個機遇的遺憾。期間PRD文檔對外的表現(xiàn)形式從純word格式，衍生出完全用AXURE來進行表達，其實并無本質(zhì)不同，只是把原型和文檔結(jié)合來起來。
但是根據(jù)自己的實踐經(jīng)驗，以及開發(fā)的反饋來講，大多數(shù)情況下，后者可能會比較友好。
但是某些視覺設計本身較少的產(chǎn)品來說，使用純文檔能夠更加專注地表達。所以具體使用哪種形式，需要根據(jù)具體情況來決定，但原則只有一個：哪種能更高效、更清晰地給開發(fā)人員傳達需求就用哪種。
? ?04 ???潑一盆冷水
在我的職業(yè)經(jīng)歷中，大部分開發(fā)人員（尤其是前端）很少看需求文檔，你不厭其煩地在需求評審會上給他們耳提面命地講完需求后，他們會自以為是地都聽懂了，然后就“扔掉書包、扔掉手表、扔掉外套”，倔強地開干，盡管UI設計稿已經(jīng)精確到了像素級別，盡管他們犯的錯誤都是厘米的級別，測試、產(chǎn)品、UI都能看見，但他是就眼瞎看不到，有時甚至后端實在看不下去了，便會良心發(fā)現(xiàn)說幾句。
情景雖然稍顯夸張，但基本屬實，所以為什么把產(chǎn)品經(jīng)理稱為母親+保姆，需要全程陪護，因為出了任何問題，首先你需要站出來解釋，解釋不了就是你的鍋，這點沒有夸張。
相比于枯燥的文檔，開發(fā)人員更傾向于看原型交互，這是人性使然，無可厚非，這也是為什么我建議大多數(shù)產(chǎn)品一定要學學AXURE，為什么是建議，因為，我碰到過不少產(chǎn)品經(jīng)理，把畫原型視為一件比較低級的工作，也許是因為他們公司有交互設計師、也許是因為自己手下帶了幾個小弟讓手下的人畫就可以了，但是殊不知，這是一種偏見，理論從實踐來，沒有實踐，高談理論不免淪為空談，一個不會開車的人，他沒大可能成為優(yōu)秀的汽車修理師、或產(chǎn)品設計師。
不要說什么產(chǎn)品專家、產(chǎn)品總監(jiān)人家從來不畫原型，是啊，那你也得先成為那個層面的人，作為一個沒有背景、沒有關(guān)系的主兒，就老老實實從小做起，現(xiàn)在年輕人都是實用主義者，大話空話他們懂得比你多，只是人家嘴上不說而已。
不要放低了自己對于PRD文檔的標準，羅曼羅蘭說過：“真正的英雄是那些看清了生活真相，卻依然熱愛生活的人”。
你所用心走過的每一步都算數(shù)！
? ?未完待續(xù) ??
由于這個主題比較大，一篇文章難以講完，所以我會連續(xù)出一個系列進行翔實的講述，還請同學們耐心期待，文中觀點如有不妥之處請留言指正~
關(guān)注公號（lumyouth）看首發(fā)
