起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識3個方法，寫對用戶畫像產品需求文檔（PRD）
需求是科技網絡產品開發的基礎，對需求的描述載體是需求文檔。文檔質量決定了產品的質量和生存周期，因此任何公司都會想辦法提升產品需求文檔質量。那么要如何做呢，讓我們看看筆者是如何說的：
高質量的需求文檔具有如下兩個特征：
- 完整、正確性：每一項需求的功能都描述清楚、準確、無沖突，使后續開發、測試人員獲得所有必要信息；
- 可行性：每一項需求都必須能在已知能力和約束條件內實現，對于技術上無法實現，或者成本。
上無法負擔的需求，則不可行。例如：此前有報道某公司產品經理提出根據手機殼換APP顏色的需求，那么在當時那個場景下產品的需求可行性為較低。
本文先從一個落地用戶學生畫像的產品需求文檔（PRD）展開，接著分析需求文檔的產生過程，然后講述需求文檔產生過程中容易產生的問題，最后提出提升需求文檔質量的措施。本篇順道提一下AI產品需求文檔注意要點，本篇AI及數據產品需求文檔不是重點，希望看AI產品相關的請繼續關注LineLian的文章。
一、已落地的學生用戶畫像的產品需求文檔（PRD）
內容較長建議耐心閱讀，因為往往有的產品的需求比較硬核，所以產品需求文檔的內容也比較長。為了練習產品經理的基本功，需要有足夠的耐心，加上筆者LineLian總結的方法方向將需求用PRD邏輯清晰地表達出來。
下面為用戶學生畫像產品需求文檔案例：
1. 對PRD編號
2. 程式化的版本修訂記錄
3. 生成目錄
4. 對項目進行背景綜述
（1）背景
用戶學生畫像v4.0迭代項目主要是對已有畫像平臺功能結構重新梳理和整合。項目基于用戶學生畫像v3.2、江南大學用戶學生畫像項目以及參考浙大用戶學生畫像相關要求，以通用性為原則，將原有功能梳理重新定義，對用戶學生畫像、群體對比、個人畫像結構都有所調整，同時增加自定報告功能模塊。后續的項目都會基于這個版本進行開發。
（2）目標
明確用戶學生畫像結構，使得產品結構清晰，將原有畫像系統分為數據結果呈現和數據應用兩大塊：
- 數據結果呈現：對應群體畫像、自定義畫像、群體對比以及個人畫像重點在已有數據結果呈現；
- 數據應用：對應預測預警和自助報告，前者是根據已有數據對行為預測，后者是根據已有數據形成總結報告。
統一原有用戶學生畫像系統，減少后續項目個性化定制。
（3）閱讀對象
本文檔閱讀對象為項目經理、UI設計師、開發工程師、測試工程師
5. 對產品進行描述
用戶學生畫像產品是XX科技畫像系列產品重要組成部分，是一款服務于高校學生管理與教育引導的大數據產品。圍繞學生在校期間的安全、學業、生活、就業等方面的具體問題，通過刻畫學生全維度畫像，幫助管理者全面認識學生，精準定位異常人群，以大數據+畫像技術服務于大學生精細化管理。
6. 產品思維腦圖：邏輯清晰地表達概要功能結構
這個模塊往往對上級匯報產品內容時用處多。
產品功能結構，如下所示：
7. 幫前期的產品Feature lists生成產品功能列表
產品功能表，如下所示：
8. 定義產品用戶的角色
用戶角色：這里“角色”的概念不是根據這些角色查看數據范圍或功能權限一致分類的，因為學院、輔導員所對應學生數據范圍是不一樣的；這里根據學校數據，如果有對應信息課進行對應分組
示例：
9. 產品功能需求說明正正文部分
- 找到合適的產品需求文檔框架模板，根據適應原則做裁剪處理；保證文檔整體結構的完整性；
- 邏輯一致和完備；任何功能都要能夠清晰地描述思維邏輯過程和采用的方法，同時要注意臨界值和異常值的處理；可以使用正向邏輯檢查或使用反向測試邏輯走查；
- 描述內容在正確的前提下盡量簡潔明了，能用界面截圖或圖例的不用文字，重點內容鮮明標注；補充解釋或者舉例。
文檔分類：文檔的目標用戶不同，用途不同，文檔的內容和風格差異就會比較大。從0-1的產品需求文檔和迭代升級的產品需求文檔側重點和關注的內容不同，目標用戶有差異的文檔內容不同；不同身份撰寫者提交的文檔重點不同。
功能需求說明，這部分主要的查看對象是Coding和test及產品經理自己驗證產品時所用。由于原PRD過長，筆者LineLian僅截取一部分，如果實在有需要可以跟筆者LineLian聯系或者聯系起點。但是從筆者所列的部分仔細閱讀的同學，一定能夠看出一份用戶畫像和數據型產品需求文檔需要講清楚模塊優先級、功能名稱、用戶對象，特別是需求描述需要講清楚功能的交互邏輯、業務對應的需求規則、操作的流程、字段、圖表說明、算法模型建議和保密需求等等。
具體如下所示：
基礎模塊：
群體畫像：
二、分析需求文檔的產生過程
產品開發一般需要經歷五個階段：
需求分析階段、設計階段、編碼階段、測試階段、驗收交付階段，后續還有運營維護階段。而需求分析階段產生的需求文檔，是后續幾個階段的依據和必備條件。
上述需求文檔是為第4版迭代重新進行需求分析的文檔。
需求文檔是需求分析階段的工作產品，是需求開發和分析的結果，是用戶和開發人員之間交流的橋梁，也是設計和編碼的基礎，又是測試和驗收的依據。需求文檔需精確地闡述一個軟件必須提供的功能、性能、設計和實現的限制條件，并盡可能完整地描述軟件預期的外部行為和用戶可視化行為，還需包括設計、構造、測試或工程管理的細節。
一般需經歷如下幾個過程：
1. 產品需求開發過程
需求開發的主要目的是全面發掘用戶的需求，盡量避免后期的需求變動，一般采用現場調研、調查問卷、樣機、樣例等方式，此時的需求都是從用戶的角度提出，盡量保證全面，不要求詳細、具體。
例如：上文PRD中，我們當時采用到學?，F場調研了解每一個角色對當下系統的使用情況，傾聽客戶和用戶的需求。然后確定軟件開發任務書。
2. 產品需求分析過程
產品需求分析就是解答產品做什么的問題。本過程是需求文檔形成的主要過程，是在前述任務書確定了開發任務的基礎上，對用戶的需求進行去粗取精、去偽存真、正確理解，然后把它用軟件工程開發語言（形式功能規約，即需求規格說明書）表達出來的過程。這個過程中需要明確每個功能的具體要求，例如：如何操作、如何展示結果、界面的樣式、要求、通信協議、接口、處理的數據、功能間的交互關系等等。
例如：上述PRD中充分挖掘學校對學生心理健康數據尤為關注，那么產品需求分析就要結合心理學和實際學生心理數據相結合來設計產品。最后一般是以軟件需求規格說明書的形式呈現全部分析結果。
3. 需求評審過程
主要是從用戶的角度和產品設計的角度，由用戶、軟件設計人員共同對需求規格說明和初步的用戶手冊進行評審，以確保產品需求的完整、準確、清晰、具體，并使用戶和產品設計人員對需求規格說明和初步的用戶手冊的理解達成一致。
因此，任務書和需求規格說明形成后，均需進行需求評審，評審文檔中的每一條需求是否符合用戶要求、是否有遺漏、是否模糊、前后是否一致、是否無歧義等，使開發方和用戶方的理解達成一致，并固定用戶需求。
例如：筆者LineLian在日常產品相關工作中，會安排一些時間，來幫年輕的產品經理過需求和評審需求文檔的質量。
三、需求文檔產生過程中容易產生的問題
上述需求文檔產生的三個過程，理論上可以保證需求文檔的質量，實際實施時會有較多的原因導致控制失效，甚至會導致需求與用戶的要求不一致，造成這種情況的主要原因有：
1. 市場環境變化導致場景變化
例如：針對學校學生為主的用戶開發大數據人工智能軟件，某一天市場突然要求校園不能以軟件開發為目標讓學生使用校外面的產品，那么這個政策下來后，許多原來的需求就不得不停止甚至終止。
2. 需求不是來自直接用戶
例如：上述文檔中征集需求時只收集了訂購方校方的意見，未能面對真正的使用用戶學生，導致訂購方的需求不能代表最終用戶的需求等。
3. 產品需求分析人員技能不足
這一點也是考察產品經理是否為高階段資深產品經理與否的一個客觀標準，分析需求時未能真正了解到用戶的具體要求。
例如：用戶要求數據保密功能，需求人員對保密缺乏相關知識，使得只設計了密碼登陸的功能，未能提出更多的需求分析問題，以征集到用戶的不同角色權限不同、數據保密、密碼長度、強度等要求全面的保密需求。
四、提升需求文檔的措施
1. 需求開發過程是否合理
- 是否制定了需求開發計劃，計劃的合理性經過評審；
- 需求開發的執行人是否有相應的技能；
- 選擇的調查對象是否能代表最終用戶的意見；
- 是否采用了規定的方法、流程、模板、表格等；
- 是否未經調查直接編制需求文檔。
2. 需求分析過程是否合理
- 是否制定了需求分析計劃，計劃的合理性經過評審；
- 需求分析人員是否具備相應技能；
- 是否采用了規定的或者合適的需求分析方法；
- 是否采用了規定的模板、表格；
- 是否針對軟件的行業特性制定了相應的分析措施。
五、總結一下用戶畫像類PRD的寫法
PRD產品需求文檔主要有MRD、競對分析、原型、開發任務書、軟件規格說明書等形式，均包含在PRD（產品需求文檔內）。
一款產品不是所有的文檔均需要撰寫，例如文中所述的學生用戶畫像產品主要撰寫產品功能的具體定義。所以，我們撰寫產品需求文檔不一定把上述文檔撰寫一遍，在強調敏捷開發的環境下，可以用原型配合產品經理的口頭表達也是常見的開發方法。
隨著人工智能產品需求的增多，產品經理還會面臨新的需求。例如：配合算法工程師設計模型調教算法，這一點需要產品經理持續地學習。
這里先順道提一下AI產品需求文檔的幾個要點，日后筆者將會寫AI產品需求文檔：
- 目標用戶包含算法工程師的文檔：需要清晰地交代需求背景、現有的數據支持情況、預期的結果及功能設計采用的AI技術和設計的邏輯；
- 采用第三方的AI技術支持的產品：需要完整地描述產品的整體實現過程、期間調用第三方技術的方式、第三方技術的支持范圍和實現邏輯，以協助自己團隊技術人員順利對接，確保設計的功能能夠實現；并明確邊界和異常情況的處理方式；
- AI產品都離不開底層數據的支持，對數據的采集、計算和處理需要特別注意；
- AI產品的界面及交互與互聯網產品有明顯的差異：界面少，算法更強；交互方式科技感更強，更簡潔。
以上是為正確撰寫用戶畫像產品需求文檔的內容。
如果你想系統化入門AI產品經理，掌握AI產品經理的落地工作方法，戳這里>http://996.pm/7bjab
#專欄作家#
連詩路，公眾號：LineLian。人人都是產品經理專欄作家，《產品進化論：AI+時代產品經理的思維方法》一書作者，前阿里產品專家，希望與創業者多多交流。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
。。應該增加一個踩的功能，什么水文章都能上
口才表達不行，還能繼續產品這條路嗎
你好，我是linelian老師的學生。聽過他的課，也線下越過他的面授。個人感覺你也可以約他，值得！他微信firstbodytm。我是花了5K約他學習交流的。