中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

分析核心需求

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

先填寫軀干

為保持簡短性，需求描述主要寫成，提取關鍵詞，關鍵詞字數不要超過6個字，這樣可以讓開發哥最快的速度以內了解功能點；最好使用約定俗成的語言，因為產品與開發部在有些點上面的描述和說法是不一樣的，如果使用大家能馬上看得懂的言語就能提高效率，這個需要平時的積累和溝通的沉淀，最好每次項目結束總結范例，那下次開展項目可以更快更速度。

再增加枝葉

寫完關鍵詞后，圍繞關鍵詞展示具體內容，內容長度最好不要超過20個字，還把需要顯示的具體內容放入了解釋中，因為這些內容并不會影響開發，如果放在需求描述中，反而會降低閱讀的速度和增加理解上的負擔。

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

備注說明

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

時刻維護

文檔還需要保持時刻更新，因為在產品開發階段，會遇到零零散散的提升用戶體現或者修改功能需求，如果是到了最后上線期間才去補很容易產生遺漏，這里也推薦避免3個遺漏的方法：

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

項目總結

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

作者：畢振杰（微信公眾號：畢生說產品），蓋網產品經理。多年互聯網產品設計經驗，追求極致的用戶體驗。

本文由 @畢振杰 原創發布于人人都是產品經理?，未經許可，禁止轉載。