高頻面試題：為什么需要寫產(chǎn)品需求文檔？
當我們從用戶那里收集到需求后經(jīng)過初步的市場調研、需求篩選和可行性分析后會將需求轉化為一條條用戶需求，而在產(chǎn)品經(jīng)理的規(guī)劃和分析下會對這些需求進行去重、歸類然后轉化為產(chǎn)品需求，形成產(chǎn)品功能列表也就是我們常說的（功能列表） List。這時候我們需要將大大小小的功能點匯總成為一個產(chǎn)品并最終實現(xiàn)它就需要將我們的意圖系統(tǒng)的表達給設計獅、程序猿，然而此時任何的表達不清或錯誤都會造成后續(xù)工作的無法進行或返工，因此產(chǎn)品需求文檔應運而生。
所以對這種文檔的判斷要求也就變得清晰明了，第一要規(guī)范化的格式，不能一個項目一套文檔標準，采用統(tǒng)一的規(guī)范可以在最大的程度上避免產(chǎn)品設計上的內容疏缺。第二則是要以程序猿、設計獅能理解的語言來描述，專業(yè)的術語不僅能減少分歧更能使產(chǎn)品經(jīng)理給相關各方留下一個專業(yè)認真的形象，有利于團隊的凝聚力。
一份可讀性強、文脈和思路清晰、流程和功能闡述明白、頁面元素、輸入和輸出都定義明確的產(chǎn)品需求文檔，通常都是需要經(jīng)過幾次持續(xù)的迭代和梳理，才能逐漸完善起來。
產(chǎn)品需求文檔包括的內容
（1）概述
概述部分是概括地說明產(chǎn)品背景，簡述產(chǎn)品功能，預期實現(xiàn)的目標，分階段實現(xiàn)的階段性目標。
l背景介紹：是基于什么樣的考慮要做這個需求。
l產(chǎn)品目的：解釋說明該產(chǎn)品是干什么的，為什么需要這樣的產(chǎn)品。同時產(chǎn)品想要達到什么樣的目標。產(chǎn)品概述及目標就是對產(chǎn)品核心功能講解，同時希望可以達到的期望。
l產(chǎn)品（路線圖）：產(chǎn)品分期目標，階段描述，以及時間點的確定，產(chǎn)品是個不斷演進的過程，很多時間一期產(chǎn)品只完成了產(chǎn)品70%的功能，二期才會繼續(xù)去完善剩下的30%，同時有可能會推翻了重新推出第二版。產(chǎn)品并不及著全部規(guī)劃好所有的階段目標，而是更多的通過維護來保持產(chǎn)品的更新和迭代。
l名詞解釋：聲明文檔中出現(xiàn)的名詞含義。
l數(shù)據(jù)詞典：介紹本產(chǎn)品中數(shù)據(jù)的數(shù)據(jù)項、數(shù)據(jù)結構、數(shù)據(jù)流、數(shù)據(jù)存儲、處理邏輯、外部實體等。
l文檔閱讀對象：聲明本文檔輸出的閱讀對象和注意事項。
l產(chǎn)品風險：描述產(chǎn)品可能存在的風險，比如商務談判的風險，外部合作的風險，不當使用的風險等等。風險級別為高中低。
（2）產(chǎn)品描述
產(chǎn)品描述介紹用戶使用產(chǎn)品的邏輯流程，概括性的描述產(chǎn)品需求、產(chǎn)品版本規(guī)劃、產(chǎn)品整體的框架結構以及功能列表。產(chǎn)品整體流程與產(chǎn)品框架都需要使用相應的圖表展現(xiàn)。
l產(chǎn)品整體流程：展示產(chǎn)品框架圖和用戶流程圖。
l產(chǎn)品需求描述：描述產(chǎn)品核心功能，解決哪些情景下的哪些需求。
l產(chǎn)品版本規(guī)劃：敘述產(chǎn)品版本迭代計劃，版本號、主要模塊、功能點、計劃開發(fā)時間、計劃結束時間、備注。
l產(chǎn)品框架：展示頁面層級，展現(xiàn)產(chǎn)品框架中各一級頁面、二級頁面、三級頁面及備注信息。
l功能列表：展示產(chǎn)品功能名稱、對應模塊、功能說明、備注等信息。
（3）功能描述
功能需求這部分需詳細描述產(chǎn)品所涉及的各個功能點。將整體框架拆成數(shù)個獨立的功能點，分別描述每個功能點的邏輯流程圖、界面、字段說明以及業(yè)務說明。統(tǒng)一采用Use Case的方式進行描述。
l流程圖
l界面原型
l字段說明（包括數(shù)據(jù)字典）
l業(yè)務說明（Use Case）
（4）效果預期
做任何一個需求，我們都有明確的目的，有了目的還不夠，我們應當根據(jù)產(chǎn)品的現(xiàn)狀，對此次需求上線后的效果有一個預期，效果預期主要通過數(shù)據(jù)層面來體現(xiàn)。
有了效果預期，PDR的讀者就知道在需求上線后產(chǎn)品需求文檔用什么寫，會對產(chǎn)品帶來多大的變化和影響，在需求實施的時候，也能更全面的考慮各種情況。
（5）數(shù)據(jù)埋點指標
這部分跟上述效果預期相關聯(lián)，有效果預期以后，需要有相應的指標來評判效果，因此，需要在PRD中將詳細的數(shù)據(jù)指標列出來，以便研發(fā)對數(shù)據(jù)指標的提取進行埋點，以及后續(xù)數(shù)據(jù)提取。這部分和效果預期常常容易被忽略，等到需求上線了，才發(fā)現(xiàn)需要的數(shù)據(jù)沒有，導致需求效果難以評估，后續(xù)的迭代也沒有數(shù)據(jù)支撐。
（6）非功能需求
非功能需求，也就是關于產(chǎn)品的其它方面的要求。一般情況下非功能性需求包括以下幾個部分：產(chǎn)品營銷需求、規(guī)則變更需求、產(chǎn)品服務需求、法務需求、財務需求、幫助需求、安全性需統(tǒng)計需求、性能需求、可用性需求等。與其說是全方位的掌握技能，還不如說是溝通，如何與不同的部門人員之間的溝通，讓更多的人協(xié)助產(chǎn)品的正常使用與上線。
（7）運營計劃
說明產(chǎn)品的后續(xù)運營計劃。包括與運營部的協(xié)作運營。更多的是給產(chǎn)品經(jīng)理如何讓更多的產(chǎn)品功能展示給用戶，產(chǎn)品經(jīng)理是核心需求的把握者，參與到產(chǎn)品整體運營計劃顯得特別的重要。
（8）PRD迭代記錄
這部分也是容易被忽略的一部分，尤其是核心的產(chǎn)品需求，在初版需求文檔出來以后，沒有后續(xù)的迭代記錄，會導致產(chǎn)品迭代多個版本以后，不知道早期某些功能是如何考慮，又是如何一步步演變成今天這個樣子。
PRD從第一版誕生以后產(chǎn)品需求文檔用什么寫，經(jīng)過多次需求評審，設計評審，詳細設計評審、用例評審，其中有許多細節(jié)，甚至頁面布局、功能點都會有變化，當時可能都是通過郵件、會議紀要來說明，如果不整理到需求文檔中，時間長了，或者是人員變化，可能就沒有人知道這部分需求最終的實現(xiàn)方案了。
因此，PRD迭代記錄也是非常重要的一部分，記錄下每一次討論后需求的變化點，幫助各方使用者及時了解需求變化，以及對最終的實現(xiàn)方案做記錄，方便后續(xù)查閱。