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

產(chǎn)品經(jīng)理的生涯中，肯定遇到過如下的痛點(diǎn)吧：

1.含辛茹苦地寫完了需求文檔（PRD），開發(fā)人員卻將文檔束之高閣；

2.開發(fā)人員反復(fù)來回地確認(rèn)需求、細(xì)節(jié)邏輯等，問的你一臉懵逼，只能默默地去修改文檔；

3.開發(fā)完成，進(jìn)入測(cè)試階段，想著一鍋香噴噴的米飯就要上桌了，打開一看，居然是熱騰騰的一鍋粥～；

以上問題之所以會(huì)發(fā)生，主要的罪魁禍?zhǔn)桩?dāng)然是你的需求文檔：

1.文檔不簡(jiǎn)潔明了，讀起來吃力，給到開發(fā)，猶如給他們吃了安眠藥，開發(fā)當(dāng)然不愛看。

2.文檔的功能需求描述不清晰、邏輯不嚴(yán)謹(jǐn)，開發(fā)需要反復(fù)確認(rèn)、浪費(fèi)了大量時(shí)間，最后讓開發(fā)對(duì)你越來越不信任（產(chǎn)品狗，你過來，我保證不打死你……）。

3.沒有很好的把控進(jìn)度，項(xiàng)目跟不緊，中途容易出問題，產(chǎn)品難以達(dá)到預(yù)期。

那么，如何寫一份用戶體驗(yàn)好、開發(fā)喜歡看、靠譜的需求文檔呢？筆者將從以下幾個(gè)方面展開闡述：

一、產(chǎn)品簡(jiǎn)介

1.簡(jiǎn)要說明產(chǎn)品的使用價(jià)值

• 我是誰（一兩句話寫清楚產(chǎn)品的身份）？
• 我有什么用（我是做什么的，我能提供什么服務(wù)等）？
• 為什么選擇我們（與競(jìng)爭(zhēng)對(duì)手相比，我們產(chǎn)品的優(yōu)勢(shì)，核心競(jìng)爭(zhēng)力是什么）？

2.目標(biāo)用戶、使用場(chǎng)景

• 產(chǎn)品的主要用戶群是誰？
• 用戶主要在什么場(chǎng)景下使用我們的產(chǎn)品。

二、行業(yè)概要

• 簡(jiǎn)要闡述行業(yè)現(xiàn)狀
• 未來的發(fā)展趨勢(shì)
• 競(jìng)爭(zhēng)對(duì)手情況分析

補(bǔ)充：如何快速了解一個(gè)行業(yè)？

1.通過艾瑞咨詢、易觀等網(wǎng)站查看行業(yè)的分析報(bào)告，深入了解整個(gè)產(chǎn)業(yè)的上下游結(jié)構(gòu)；

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

三、版本

按照版本來分類，點(diǎn)擊版本鏈接可進(jìn)入查看每個(gè)版本的文檔。

文檔的第一頁(yè)如下圖：

（一）、排期

每次的大版本開發(fā)，最好對(duì)應(yīng)有一個(gè)排期表（與開發(fā)溝通確認(rèn)時(shí)間的安排），開發(fā)過程中，根據(jù)進(jìn)度情況，適當(dāng)調(diào)整時(shí)間安排。

開發(fā)人員可以根據(jù)自己負(fù)責(zé)的模塊，進(jìn)入排期詳情查看當(dāng)天的任務(wù)，完成的模塊可以進(jìn)行標(biāo)記，如圖。

（二）、產(chǎn)品設(shè)計(jì)（重點(diǎn)）

1.實(shí)體關(guān)系圖

當(dāng)你做的產(chǎn)品是從0到1時(shí)，為了讓數(shù)據(jù)庫(kù)的開發(fā)人員更快速的了解你的產(chǎn)品，實(shí)體關(guān)系圖（E-R圖）將會(huì)發(fā)揮很大作用，數(shù)據(jù)庫(kù)的開發(fā)人員可以參考此圖來做數(shù)據(jù)表結(jié)構(gòu)的設(shè)計(jì)（具體這里就不說了，大家可以網(wǎng)上詳細(xì)了解E-R圖）。

廠家、經(jīng)銷商、客戶等這些都是屬于實(shí)體，實(shí)體包含的的屬性（字段）最好也要寫出來，如下圖舉例：

2.用戶角色權(quán)限表

涉及到角色和權(quán)限的，需要做一份全面的角色權(quán)限表格，方便開發(fā)人員參考。??

3.業(yè)務(wù)流程圖

通過業(yè)務(wù)流程圖，可以在大方向上知道產(chǎn)品的整體邏輯，業(yè)務(wù)流程圖拆解可以得到任務(wù)流程圖，任務(wù)流程圖拆解可以得到頁(yè)面流程圖。

4.全局說明

一些通用的控件、狀態(tài)等，不需要每次都說明，比如空數(shù)據(jù)、網(wǎng)絡(luò)異常、加載失敗、刷新狀態(tài)等等，只需說明一次即可。

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

很多人在寫功能說明、交互說明時(shí)，總是會(huì)遺漏一些細(xì)節(jié)，邏輯不嚴(yán)謹(jǐn)。從以下幾個(gè)維度去說明，將會(huì)讓你考慮的更加全面：

• 字段、字段說明、數(shù)據(jù)來源
• 前置條件、排序機(jī)制、刷新機(jī)制
• 狀態(tài)流轉(zhuǎn)（一個(gè)頁(yè)面可能有多個(gè)狀態(tài)，需要說明）
• 交互操作（正常操作、異常操作）

下面，筆者將以一個(gè)頁(yè)面做舉例說明：

產(chǎn)品設(shè)計(jì)模塊里的結(jié)構(gòu)如圖：

（為了方面查看以及和視覺頁(yè)面的對(duì)照，每個(gè)頁(yè)面需要標(biāo)注編號(hào)）

（三）、非功能需求

1.埋點(diǎn)需求

頁(yè)面的打開率、按鈕點(diǎn)擊率等，如果需要記錄，則需要做說明。

埋點(diǎn)是數(shù)據(jù)分析的基礎(chǔ)，建議使用“GrowingIO” 這個(gè)工具進(jìn)行可視化埋點(diǎn)，操作簡(jiǎn)單、方便，能減少很多的工作量。

2.性能需求

請(qǐng)求數(shù)據(jù)的響應(yīng)時(shí)間要求、并發(fā)數(shù)要求等。

3.兼容性需求

系統(tǒng)版本的支持、多終端的支持、瀏覽器的支持等。

（四）、修改記錄

文檔的第二頁(yè)如下圖：

為了讓開發(fā)人員更方便的瀏覽，增強(qiáng)閱讀體驗(yàn)，使用markdown語(yǔ)言來輔助寫需求文檔是最好不過了，瀏覽體驗(yàn)會(huì)大大提升。

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

作者：dreamer，微信公眾號(hào)：拳頭產(chǎn)品

本文由 @dreamer 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Pexels，基于CC0協(xié)議