上回分享的從需求到最終的解決方案，產品經理該怎么做？得到了許多人的認可，在這里，非常感謝大家的支持，同時也給筆者很大的信心，接下來分享的文章，希望大家能夠喜歡，enjoy～

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

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語言來輔助寫需求文檔是最好不過了，瀏覽體驗會大大提升。

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

作者：dreamer，微信公眾號：拳頭產品

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

題圖來自Pexels，基于CC0協議