產品需求說明書怎么寫（手把手教你寫產品需求文案）

要活學活用，之前說的產品設計的內容，不要用一套自我主義思維打天下，強調下產品結構的幾種特點：矩陣結構【一個頁面闡述大量的內容，并不是有大量的分層，多個維度來統計能功能】，線性結構【某個骨干流程按照某個線的方式，某個場景往下串】，層級結構【按照用戶自行選擇，需要干的事情，做的層級，1.足夠偏，功能足夠的多。2.層級足夠的深，每次選擇的足夠少，統一認為第二種的用戶體驗比較好】。不要小看產品的結構設計，這是產品經理的基礎。結構設計是思考一個功能第一想的問題，不先想界面長什么樣子，先想是什么層級，什么結構的產品，然后在想有幾個界面有幾個判斷。開始今天的內容，畫原型和寫PRD，主要是PRD和原型的對應關系，核心是說說PRD。

（一）回顧下上篇文章

• ① 交互所在層級

主要說了界面交互，低保真原型的設計。

• ② 交互設計三步走

（二）產品原型及需求文檔的撰寫

• ① 開發人員最討厭的PRD

PRD里面講的邏輯限制開發了代碼，這塊就去查某個表，做某個參數，定義的變量都寫出來了，覺得很崩潰，照這樣寫出了問題算誰的，明明理解了業務，有別的方式不這么做，用更好的處理方法，出了bug算誰的？PRD到底寫成什么樣的，描述業務好不好。

• ② 產品設計階段

早期的PRD不叫PRD，叫開發規格，真的很限制人的，PRD是產品設計的第三個環節，根據原型設計進行討論，修正原型的正確性，也可以跟研發進行評判，對整個系統的開發工作量進行估值，需求文檔往往是后置的，一般來需求文檔就是需求評審之后，代碼就開工了。在原型設計之后研發就會做一些開發的準備。PRD也不能當飯吃，一堆人在寫PRD，寫了這些也不能產生價值，寫這些文檔干什么用呢。

• ③ 為什么要寫需求文檔

1. 需求文檔給誰看？

交互設計、視覺設計【需要了解場景進行設計】、項目經理【PRD認領，符合PRD管理規范的】、開發【開發的基本，開發需要PRD中將業務邏輯講清楚】、測試【依據PRD出測試用例的，怎么進行測試，測試用例的變更和新增】、其他產品經理【講述可能有遺漏不如直接看PRD】、其他需要了解業務邏輯的人。

2.需求文檔的作用是什么？

準確、直觀、完整傳達產品需求，保證各角色溝通有依據，保證產品質量控制有標準，存檔。

• ④ 需求文檔覆蓋的范圍

• ⑤ 需求文檔主要結構

• ⑥ 需求背景及目標
  1.需求背景

讓項目參與者明白為什么啟動該項目，如果來此競品分析，分析下競品，競品實現的功能是什么樣子的。

2.項目目標

讓項目參與者共識目標，找到價值感。目標盡量量化。上線后驗證目標達到情況的依據。

3.編寫人

修訂日期、修訂人、修訂說明、修訂原因、修訂文檔版本號。

• ⑦ 功能列表

拆分成最小的功能點功能點之間相互獨立方便參與者理解需求，評估工作量

• ⑧ 功能點拆分

拆分：一定要拆出來一個功能的組合。一定有個優先級最高的就是產品的靈魂，需求點。P0級的功能.P0是靈魂，沒有它就不是這個產品。P1和P2是對用戶體驗有絕對性意義的東西。P3是對產品的存活有決定性作用的東西，拉新留存。P4是錦上添花的作用。功能拆分的時候不光光的講有幾個按鈕，幾個值，首先優先級。是不是拆分出來的每一個功能列表。

• ⑨ 邏輯展示

為什么需要邏輯展示？彌補與程序員的種族差異，幫助自己梳理思路。不免需求遺漏，考慮不周。

多角色流程圖（泳道圖，跨職能流程圖：多角色，多系統，多模塊流程）

單角色流程圖（基本流程圖：單角色，單系統，單模塊流程）

流程圖：基本元素

基本結構：順序結構

選擇結構

循環結構

頁面流程，這是UED和前端最喜歡看的流程圖

• ⑩ 詳細描述

想不到那么多情況怎么辦？善用工具，幫助整理思路，表達清晰。向測試學習，多看測試用例，善于總結。

• ? 數據需求

數據需求的采集標準

1. 理論上所有用戶端新增功能都需要采集。
2. 改動、優化需要進行前后數據對比
3. 版本的核心數據指標

數據采集的類型基礎數據，交互數據，用戶路徑

業務數據，服務端存庫，用戶行為數據，前端埋點。

• ?數據需求

如果沒有BI支持，需要茶品經理自己定義埋點事件，不同的數據統計工具，不同的埋點的規范

• ?風控說明

可能出現的風險點和策略

PS：PRD是一個文件，文件是寫給人看的，文件什么樣不取決于產品經理想寫成什么樣，取決于讀者。大家認為好才好，為別人寫的不是為自己。文檔是核心：以表達為目的，讓查看的人清晰易懂，文檔完整性很重要，文檔表達方式靈活：axure、word、wiki、腦圖、表格，邏輯嚴密，表達清晰。產品經理技能宏觀至戰略，又能微觀至一個文本框的各種邊界和異常