產品經理的生涯中，肯定遇到過如下的痛點吧：

1.含辛茹苦地寫完了需求文件（PRD），開發人員卻將文件束之高閣（一萬隻草泥馬在你的後腦勺奔騰而過……）；

2.開發人員反覆來回地確認需求、細節邏輯等，問的你一臉懵逼，只能默默地去修改文件；

3.開發完成，進入測試階段，想著一鍋香噴噴的米飯就要上桌了，開啟一看，居然是熱騰騰的一鍋粥～；

以上問題之所以會發生，主要的罪魁禍首當然是你的需求文件：

1.文件不簡潔明瞭，讀起來吃力，給到開發，猶如給他們吃了安眠藥，開發當然不愛看。

2.文件的功能需求描述不清晰、邏輯不嚴謹，開發需要反覆確認、浪費了大量時間，最後讓開發對你越來越不信任（產品狗，你過來，我保證不打死你……）。

3.沒有很好的把控進度，專案跟不緊，中途容易出問題，產品難以達到預期。

那麼，如何寫一份使用者體驗好、開發喜歡看、靠譜的需求文件呢？筆者將從以下幾個方面展開闡述：

一、產品簡介

1.簡要說明產品的使用價值

• 我是誰（一兩句話寫清楚產品的身份）？
• 我有什麼用（我是做什麼的，我能提供什麼服務等）？
• 為什麼選擇我們（與競爭對手相比，我們產品的優勢，核心競爭力是什麼）？

2.目標使用者、使用場景

• 產品的主要使用者群是誰？
• 使用者主要在什麼場景下使用我們的產品。

二、行業概要

• 簡要闡述行業現狀
• 未來的發展趨勢
• 競爭對手情況分析

補充：如何快速瞭解一個行業？

1.通過艾瑞諮詢、易觀等網站檢視行業的分析報告，深入瞭解整個產業的上下游結構；

2.通過商業模式畫布工具，分析行業主要玩家的商業模式

三、版本

按照版本來分類，點選版本連結可進入檢視每個版本的文件。

文件的第一頁如下圖：

（一）、排期

每次的大版本開發，最好對應有一個排期表（與開發溝通確認時間的安排），開發過程中，根據進度情況，適當調整時間安排。

開發人員可以根據自己負責的模組，進入排期詳情檢視當天的任務，完成的模組可以進行標記，如圖。

（二）、產品設計（重點）

1.實體關係圖

當你做的產品是從0到1時，為了讓資料庫的開發人員更快速的瞭解你的產品，實體關係圖（E-R圖）將會發揮很大作用，資料庫的開發人員可以參考此圖來做資料表結構的設計（具體這裡就不說了，大家可以網上詳細瞭解E-R圖）。

廠家、經銷商、客戶等這些都是屬於實體，實體包含的的屬性（欄位）最好也要寫出來，如下圖舉例：

2.使用者角色許可權表

涉及到角色和許可權的，需要做一份全面的角色許可權表格，方便開發人員參考。››

3.業務流程圖

通過業務流程圖，可以在大方向上知道產品的整體邏輯，業務流程圖拆解可以得到任務流程圖，任務流程圖拆解可以得到頁面流程圖。

4.全域性說明

一些通用的控制元件、狀態等，不需要每次都說明，比如空資料、網路異常、載入失敗、重新整理狀態等等，只需說明一次即可。

5.需求、功能、互動說明

很多人在寫功能說明、互動說明時，總是會遺漏一些細節，邏輯不嚴謹。從以下幾個維度去說明，將會讓你考慮的更加全面：

• 欄位、欄位說明、資料來源
• 前置條件、排序機制、重新整理機制
• 狀態流轉（一個頁面可能有多個狀態，需要說明）
• 互動操作（正常操作、異常操作）

下面，筆者將以一個頁面做舉例說明：

產品設計模組裡的結構如圖：

（為了方面檢視以及和視覺頁面的對照，每個頁面需要標註編號）

（三）、非功能需求

1.埋點需求

頁面的開啟率、按鈕點選率等，如果需要記錄，則需要做說明。

埋點是資料分析的基礎，建議使用“GrowingIO” 這個工具進行視覺化埋點，操作簡單、方便，能減少很多的工作量。

2.效能需求

請求資料的響應時間要求、併發數要求等。

3.相容性需求

系統版本的支援、多終端的支援、瀏覽器的支援等。

（四）、修改記錄

文件的第二頁如下圖：

為了讓開發人員更方便的瀏覽，增強閱讀體驗，使用markdown語言來輔助寫需求文件是最好不過了，瀏覽體驗會大大提升。

好了，本次分享到這裡，感謝您的閱讀。