PRD（Product-Requirement-Document，產(chǎn)品需求文檔），這對于任何一個產(chǎn)品經(jīng)理來說都不會陌生的一個文檔，在網(wǎng)上搜索也很容易找到關(guān)于PRD的干貨，但會寫還是不夠，很多產(chǎn)品新人都問我為什么我的文檔開發(fā)哥都不看？怎樣才能寫好PRD呢？

Ruby語言的創(chuàng)始者松本行弘說過：“代碼越少，有可能出現(xiàn)bug的機(jī)會也越少?！蔽臋n也是一樣，越是簡短，可能出現(xiàn)的錯誤也會越少，同時也更利于閱讀、維護(hù)和更新，所以建議大家的PRD要寫成“簡單易懂”。

產(chǎn)品需求文檔作為一種和開發(fā)人員溝通的重要工具，如果梳理得不好，會直接影響后續(xù)與開發(fā)人員的溝通質(zhì)量，“簡單易懂”顯得十分重要。但很多剛做產(chǎn)品的同學(xué)不太了解其重要性，會走不少彎路，他們會發(fā)現(xiàn)：在開完需求會議后開發(fā)人員在開發(fā)的過程中很少去翻看需求文檔，通常情況下都是口頭詢問，同學(xué)們就覺得很奇怪，他們寫文檔寫得那么詳細(xì)，為什么開發(fā)人員就不看文檔呢？既然不看，就不用寫了，直接用口頭溝通不是更好嗎？其實(shí)，能用口頭闡述都小問題和小項(xiàng)目，如果是中、大型項(xiàng)目，參與人員比較多，文檔是有助于減低溝通成本和提高共走效率；還有一點(diǎn)，很多時候開發(fā)不看文檔，是嫌棄文檔的內(nèi)容太長了，他們只需要簡單了解這個功能大概是做什么的，怎樣去實(shí)現(xiàn)就可以了。反觀很多同學(xué)在寫的時候會進(jìn)入一個誤區(qū)，事無巨細(xì)地描述規(guī)則，總害怕開發(fā)同事看不懂，一個比較復(fù)雜的功能可能寫個300字，結(jié)果人家直接不看了。

怎樣才能寫出簡單易懂的需求文檔呢？

分析核心需求

明確開發(fā)需求實(shí)現(xiàn)哪些功能需求，PRD很多時候只是對原型上沒有的說明進(jìn)行補(bǔ)充，你總不能輸入框限制多少個字符都寫在原型上面，所以第一步需要看一下哪些是說明并沒有在原型上面提現(xiàn)，然后在PRD上面進(jìn)行補(bǔ)充。例如，原型上面更多的是交互說明與規(guī)則說明，但對字段的控制一般都很少去解釋，還有時候原型上很難包含所有情況頁面，所以PRD也有時候需要補(bǔ)充一下。

先填寫軀干

為保持簡短性，需求描述主要寫成，提取關(guān)鍵詞，關(guān)鍵詞字?jǐn)?shù)不要超過6個字，這樣可以讓開發(fā)哥最快的速度以內(nèi)了解功能點(diǎn)；最好使用約定俗成的語言，因?yàn)楫a(chǎn)品與開發(fā)部在有些點(diǎn)上面的描述和說法是不一樣的，如果使用大家能馬上看得懂的言語就能提高效率，這個需要平時的積累和溝通的沉淀，最好每次項(xiàng)目結(jié)束總結(jié)范例，那下次開展項(xiàng)目可以更快更速度。

再增加枝葉

寫完關(guān)鍵詞后，圍繞關(guān)鍵詞展示具體內(nèi)容，內(nèi)容長度最好不要超過20個字，還把需要顯示的具體內(nèi)容放入了解釋中，因?yàn)檫@些內(nèi)容并不會影響開發(fā)，如果放在需求描述中，反而會降低閱讀的速度和增加理解上的負(fù)擔(dān)。

就前三點(diǎn)舉個例子：我曾經(jīng)做過一個功能消息待閱讀，一級軀干為欠費(fèi)提醒、賬單提醒、生日提醒，二級枝葉為欠費(fèi)提醒中對象、內(nèi)容、時間等元素，最后對元素進(jìn)行描述。

備注說明

在備注的加入需求來源、需求提出時間、需求提出人，避免出現(xiàn)產(chǎn)品開發(fā)完成后，由于開發(fā)周期太長，很多需求來源都淡忘了，無法得知為什么當(dāng)初有這樣的功能和需求，為什么增加這個字段，如果遇到項(xiàng)目需求確認(rèn)人或者開發(fā)人員離開了，同時文檔中沒有留下任何確認(rèn)過的需求來源記錄，在產(chǎn)品上線驗(yàn)收的時候，需求出現(xiàn)了問題，那麻煩就大了，其實(shí)文檔也是保護(hù)雙方的一種手段。

時刻維護(hù)

文檔還需要保持時刻更新，因?yàn)樵诋a(chǎn)品開發(fā)階段，會遇到零零散散的提升用戶體現(xiàn)或者修改功能需求，如果是到了最后上線期間才去補(bǔ)很容易產(chǎn)生遺漏，這里也推薦避免3個遺漏的方法：

• 一定要及時把變更的需求寫入需求文檔中，不要拖到下次在寫
• 用高亮的顏色標(biāo)記出變更的細(xì)節(jié)，如需要顯示的字段內(nèi)容
• 對于做了刪改的需求要標(biāo)明原因以及時間
• 如果中途修改次數(shù)過多，建議專門做個文檔來記錄變動情況

項(xiàng)目總結(jié)

每經(jīng)過一次項(xiàng)目，總結(jié)是必不可少的，在PRD方面也需要總結(jié)，在總結(jié)大會上需要收集開發(fā)對此項(xiàng)目PRD的意見和修改方向，如何才能更清晰簡單地闡述我們的觀點(diǎn)，“簡單易懂”不單單是產(chǎn)品部為這個目標(biāo)奮斗，開發(fā)的同事也應(yīng)該參與其中，這個在下一個項(xiàng)目開發(fā)中才能取得更大的進(jìn)步。

作者：畢振杰（微信公眾號：畢生說產(chǎn)品），蓋網(wǎng)產(chǎn)品經(jīng)理。多年互聯(lián)網(wǎng)產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)，追求極致的用戶體驗(yàn)。

本文由 @畢振杰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。