產(chǎn)品經(jīng)理實(shí)習(xí)生怎樣提高文檔書(shū)寫(xiě)能力？有哪些好的文檔書(shū)寫(xiě)規(guī)范可以學(xué)習(xí)？

最近一直在思考「輸出需求文檔」這件看上去的「小事」，發(fā)現(xiàn)太多產(chǎn)品實(shí)習(xí)生/產(chǎn)品經(jīng)理連需求都沒(méi)辦法完全表達(dá)清楚，在需求評(píng)審會(huì)上支支吾吾，被各種挑戰(zhàn)，或者開(kāi)發(fā)階段中多次重復(fù)確認(rèn)，疲于各種溝通。

相信每個(gè)產(chǎn)品新人都有過(guò)這種痛苦，解決的方法只有一種：「產(chǎn)品邏輯想得比任何人都多」。而需求文檔是其中一種思維工具，利用好文檔幫助自己梳理邏輯，掌握自己的節(jié)奏。

同時(shí)，需求文檔能夠在復(fù)雜需求流程中起到重要作用。

1. 表達(dá)產(chǎn)品設(shè)計(jì)的需求，提高團(tuán)隊(duì)協(xié)作效率，是最重要的「協(xié)作工具」

2. 作為可驗(yàn)收的「產(chǎn)品標(biāo)準(zhǔn)」

「輸出需求文檔」是每個(gè)新人很長(zhǎng)一段時(shí)間都要做的事情，發(fā)現(xiàn)竟然大部分導(dǎo)師或者前輩都不會(huì)系統(tǒng)講解的。「輸出需求文檔」是產(chǎn)品經(jīng)理產(chǎn)品設(shè)計(jì)能力中最基本的基本功，就像UI同學(xué)用PS畫(huà)圖，開(kāi)發(fā)哥敲代碼一樣，后兩項(xiàng)技能/工具是需要花4年大學(xué)時(shí)間或者甚至更長(zhǎng)的時(shí)間學(xué)習(xí)的，而大部分產(chǎn)品經(jīng)理竟然都沒(méi)有學(xué)習(xí)過(guò)需求文檔這件事情，如果大學(xué)開(kāi)產(chǎn)品經(jīng)理專(zhuān)業(yè)，「輸出需求文檔」一定是大一就要學(xué)的課程。

我這里一直講的是「輸出需求文檔」，不僅僅包括寫(xiě)需求文檔這件事，「輸出」應(yīng)該是一個(gè)動(dòng)作。可以看到需求的完整流程，「輸出需求文檔」應(yīng)該分為需求前、需求中、需求后，寫(xiě)文檔只是其中的一部分。

一、寫(xiě)需求文檔

推薦這種結(jié)構(gòu)的需求文檔，采用的是結(jié)構(gòu)化導(dǎo)航模式（網(wǎng)上已經(jīng)有很多模板了），這樣的好處是清晰明了，開(kāi)發(fā)、測(cè)試、設(shè)計(jì)不同角色可以根據(jù)自己需要看自己關(guān)注的部分，不用對(duì)著文字版需求說(shuō)明書(shū)來(lái)回找。

再來(lái)，完整又簡(jiǎn)潔的需求文檔應(yīng)該包括：文檔簡(jiǎn)介、需求分析、結(jié)構(gòu)流程、原型交互、埋點(diǎn)說(shuō)明。

沿用了這種模板和結(jié)構(gòu)的不一定是好需求文檔，更重要是每一部分里的思維和邏輯，模板和結(jié)構(gòu)只是表面。

#文檔介紹-版本說(shuō)明

讓參與人員能第一眼清楚看到這次版本或者功能包括哪些部分，能大概有預(yù)期工作量。為了清楚描述需求概況應(yīng)該包括：

1. 序號(hào)：有幾個(gè)功能需求點(diǎn)。

2. 類(lèi)型：將需求分為新增、修改、刪除。

3. 功能點(diǎn)：功能名字。

4. 需求描述：簡(jiǎn)要描述功能點(diǎn)，理解功能概況。

5. 優(yōu)先級(jí)：功能重要性，分為P0,P1,P2(當(dāng)然也可以直接分為高中低，或其他寫(xiě)法)，不建議超過(guò)3個(gè)優(yōu)先級(jí)，意義不大。P0定義為必須完成，P1定義為無(wú)意外的話需要完成，P2可做可不做。

6. 詳情：我這里只是為了方便點(diǎn)擊跳轉(zhuǎn)到相應(yīng)需求說(shuō)明的位置。

#文檔介紹-修改歷史

是的，很多情況下需求從開(kāi)始，到結(jié)尾從來(lái)沒(méi)有更新過(guò)。這樣導(dǎo)致的問(wèn)題會(huì)很?chē)?yán)重，需求版本不同步，驗(yàn)收時(shí)錯(cuò)誤或漏掉需求，反復(fù)修改。需求同步不是一件容易的事情，文檔修改歷史可以幫助需求同步。

1. 詳細(xì)描述文檔改動(dòng)點(diǎn)，包括時(shí)間、版本號(hào)、類(lèi)型（增刪改）、嚴(yán)謹(jǐn)?shù)男薷恼f(shuō)明。以下是兩類(lèi)示例：

a. 不合格的修改說(shuō)明： 修改標(biāo)簽庫(kù)邏輯

b. 嚴(yán)謹(jǐn)?shù)男薷恼f(shuō)明：在評(píng)論提醒中

- C回復(fù)B不需要通知A的，因?yàn)锳不會(huì)非常在乎B與C討論的內(nèi)容

- 點(diǎn)擊通知欄的時(shí)候如果沒(méi)登錄是調(diào)起登錄的

- 小紅點(diǎn)邏輯：?jiǎn)?dòng)的時(shí)候拉取

- 列表刷新：每次都進(jìn)入都刷新

- 定位位置，點(diǎn)贊定位問(wèn)題

特別多人討論確定邏輯后需要修改在文檔里，詳細(xì)描述。

2. 同步給所有參與人

#文檔介紹-詞匯說(shuō)明

并不是項(xiàng)目組每個(gè)人都明白產(chǎn)品經(jīng)理在需求分析、交互原型里說(shuō)的名詞，將名詞解釋明白即可。

#需求分析

需求文檔里的需求分析，目的很簡(jiǎn)單，是說(shuō)服項(xiàng)目組認(rèn)可這個(gè)功能或需求，能將需求安排下去，常用的方式兩種方式：

1. 邏輯型說(shuō)服：闡述明白需求是如何產(chǎn)生的，價(jià)值是什么，為了達(dá)到產(chǎn)品最終目標(biāo)，這個(gè)需求是什么的作用。在我另外一篇文章里已經(jīng)詳細(xì)描述，并且詳細(xì)舉例說(shuō)明，這里不再贅述。請(qǐng)看另外一個(gè)回答 如何分析和確定產(chǎn)品需求？ - 知乎

2. 數(shù)據(jù)型說(shuō)服：通過(guò)估算這個(gè)需求帶來(lái)的直接數(shù)據(jù)增長(zhǎng)，比如用戶(hù)數(shù)、收入、點(diǎn)擊率等等

#原型交互

「最容易理解的需求方式是界面長(zhǎng)得怎么樣」，別讓項(xiàng)目組其他同學(xué)對(duì)著文字版需求理解。原型交互式整個(gè)需求文檔中最重要的部分，也是最需要詳細(xì)描述的部分，包括客戶(hù)端邏輯、服務(wù)端邏輯、交互邏輯、邊緣場(chǎng)景（并不是每個(gè)需求都有客戶(hù)端邏輯或服務(wù)端邏輯）。

#原型交互-客戶(hù)端邏輯

描述客戶(hù)端界面元素的展示和操作邏輯，推薦圖文結(jié)合的方式。

1. 界面原型：可以用各種原型工具完成，積累自己的素材庫(kù)能更快的完成高保真原型。（示意圖用的是sketch）

2. 入口：說(shuō)明功能觸發(fā)的入口，哪里觸發(fā)是理解的第一步

3. 展示元素：描述界面需要的每個(gè)元素和展示邏輯

4. 行為交互：分為加載和點(diǎn)擊，數(shù)據(jù)/界面是如何加載出來(lái)，點(diǎn)擊后會(huì)有什么效果

#原型交互-服務(wù)端邏輯

服務(wù)端部分指為用戶(hù)提供產(chǎn)品服務(wù)時(shí)涉及的數(shù)據(jù)邏輯等等，完整梳理應(yīng)該包括后臺(tái)功能和服務(wù)端數(shù)據(jù)邏輯。

1. 后臺(tái)功能：指后臺(tái)配置功能部分，目的是給運(yùn)營(yíng)同學(xué)配置內(nèi)容。一般包括后臺(tái)前端，配置項(xiàng)、增刪改功能，可以根據(jù)功能難易是否需要后臺(tái)原型。

（簡(jiǎn)單版）

（可交互后臺(tái)原型）

2. 服務(wù)端數(shù)據(jù)邏輯：定義數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)下發(fā)邏輯，以熱文庫(kù)這個(gè)功能為例子解釋下。

#功能背景

通過(guò)挑選熱點(diǎn)內(nèi)容，覆蓋頭部?jī)?nèi)容，提高內(nèi)容質(zhì)量和點(diǎn)擊率

#數(shù)據(jù)定義

熱文：分別與內(nèi)容庫(kù)(XX庫(kù)、XXX庫(kù))內(nèi)容匹配，匹配度2.0以上,TOP1匹配度作為熱文

熱文庫(kù)：每天XX:00點(diǎn)、XX:00點(diǎn)、XX:00點(diǎn)更新和重新匹配，將文章入庫(kù)，這些文章集合為熱文庫(kù)

#數(shù)據(jù)下發(fā)邏輯

1.目標(biāo)：用戶(hù)刷新時(shí)，將熱文按XX順序下發(fā)到XX位置

2.其他邏輯...

#原型交互-交互邏輯

指的是界面和元素之間的交互行為。即使公司里有專(zhuān)職的交互設(shè)計(jì)師，產(chǎn)品經(jīng)理也不應(yīng)該省略這一部，只有完整考慮流程和細(xì)節(jié)，才能和設(shè)計(jì)師、項(xiàng)目組任何成員流暢討論。

與客戶(hù)端邏輯不同的是，這部分更多是界面之間操作流程，輔助界面的交互說(shuō)明（點(diǎn)擊、加載、動(dòng)畫(huà)），兩個(gè)注意點(diǎn)：

1. 交互設(shè)計(jì)的本質(zhì)是「讓用戶(hù)更快更便捷的使用服務(wù)或產(chǎn)品內(nèi)容」

2. 始終考慮交互設(shè)計(jì)五個(gè)要素，媒介、場(chǎng)景、行為、目的、用戶(hù)

#原型交互-邊緣場(chǎng)景

如果你完成了上面的主要邏輯場(chǎng)景，一般來(lái)說(shuō)功能只完成了一半，甚至沒(méi)有。邊緣場(chǎng)景的梳理這部分是最容易遺漏的地方，一旦遺漏就會(huì)陷入各種溝通和反復(fù)中。總結(jié)了常見(jiàn)的邊緣場(chǎng)景，寫(xiě)完原型說(shuō)明必檢查。

1. 網(wǎng)絡(luò)狀況：移動(dòng)、WIFI、斷網(wǎng)、弱網(wǎng)

2. 最大限制：字符、數(shù)據(jù)、等待時(shí)長(zhǎng)等等

3. 缺省狀態(tài)（為零）：輸入/展示為零

3. 多場(chǎng)景：夜間、橫屏、豎屏、不同渠道等等

4. 賬號(hào)狀態(tài)：未登錄/已登陸、多設(shè)備登陸、狀態(tài)切換不同步

5. 服務(wù)器異常處理

#結(jié)構(gòu)流程-信息架構(gòu)

當(dāng)信息項(xiàng)特別多而復(fù)雜的時(shí)候有必要將信息架構(gòu)列出來(lái)，按照界面、界面元素、信息項(xiàng)逐項(xiàng)拆解，目的是在測(cè)試同學(xué)在寫(xiě)用例時(shí)更方便查找。

#結(jié)構(gòu)流程-業(yè)務(wù)流程

業(yè)務(wù)流程在技術(shù)同學(xué)開(kāi)發(fā)時(shí)關(guān)注的部分，分為數(shù)據(jù)流程和用戶(hù)流程兩類(lèi)流程。

1. 數(shù)據(jù)流程：數(shù)據(jù)交互邏輯，描述前端、客戶(hù)端、服務(wù)端數(shù)據(jù)情況。

2. 用戶(hù)流程：用戶(hù)交互流程，描述用戶(hù)操作流程。

#埋點(diǎn)說(shuō)明

埋點(diǎn)的作用是為了功能上線后做分析調(diào)整，也是迭代的關(guān)鍵輔助，一定要做到「有功能必埋點(diǎn)」。埋點(diǎn)包括三個(gè)部分：事件ID、事件名稱(chēng)、統(tǒng)計(jì)口徑、事件描述。

1. 事件ID 事件唯一標(biāo)識(shí)，一般使用英文表述意義，單詞間使用下劃線隔開(kāi)，如 click_add_bookmark_folder

2. 事件名稱(chēng)：事件的中文名稱(chēng)。

3. 統(tǒng)計(jì)口徑 指埋點(diǎn)類(lèi)型，分別為計(jì)數(shù)事件、內(nèi)容計(jì)數(shù)事件、計(jì)時(shí)事件、狀態(tài)事件。

a) 計(jì)數(shù)事件:只計(jì)算次數(shù)的事件類(lèi)型

b) 內(nèi)容計(jì)數(shù)事件:除了計(jì)算次數(shù)，還有其他參數(shù)上傳，參數(shù)一般用英文區(qū)分，如 from=下載來(lái) 源，package=下載包名， host=下載鏈接 host，此類(lèi)型多用 于減少計(jì)數(shù)事件埋點(diǎn)和用于報(bào)表生成。

c) 計(jì)時(shí)事件:用于計(jì)算用戶(hù)使用事件，多用于頁(yè)面停留計(jì)算，進(jìn)入頁(yè)面開(kāi)啟計(jì)時(shí) 器，離開(kāi)頁(yè)面時(shí)停止計(jì)時(shí)器，并生成事件。

d) 狀態(tài)事件:用于上報(bào)開(kāi)關(guān)狀態(tài)情況，通常用 0,1 表述。

4. 事件描述：什么時(shí)候觸發(fā)埋點(diǎn)

需要關(guān)鍵點(diǎn)是：

1. 減少重復(fù)埋點(diǎn)，盡量使用內(nèi)容計(jì)數(shù)方式

2. 埋點(diǎn)名稱(chēng)和參數(shù)盡量使用有意義的英文表示，別埋點(diǎn)AA或者BB

3. 埋點(diǎn)的目的是為了生成報(bào)表分析，先想好功能要分析什么部分，需要什么埋點(diǎn)，「以終為始」不容易漏掉埋點(diǎn)或者參數(shù)。

4. 做好版本管理，云同步或在線協(xié)同文檔功能都是不錯(cuò)的選擇

5. 善用前綴命名，拓展更強(qiáng)

二、輸出動(dòng)作

需求文檔只是整個(gè)流程中將思路文檔化的過(guò)程，可見(jiàn)項(xiàng)目完整流程圖，文檔只是很小的一部分。本文先不講需求跟進(jìn)部分，僅僅「輸出需求文檔」就容易忽略前期和后期，導(dǎo)致需#求流程不可控。

#需求輸出前

輸出前做好兩件事情分析和溝通，能在需求后續(xù)流程中更順暢。

1. 需求分析：想清楚為什么要做這個(gè)需求，可以從用戶(hù)場(chǎng)景和反饋思考，可以從數(shù)據(jù)分析，可以從競(jìng)品中參考，但是一定要比任何人都要想得更多。

2. 溝通：提前將想法和需求參與人員溝通，比如開(kāi)發(fā)、設(shè)計(jì)。讓他們提前了解需求大概和評(píng)估可行性，這樣能避免將需求評(píng)審會(huì)變成需求討論會(huì)，團(tuán)隊(duì)一群人開(kāi)一整天討論會(huì)效率極低。

#需求輸出輸出后

將需求文檔發(fā)出去之后就完事了嗎？在需求跟進(jìn)過(guò)程中，需求文檔是需要維護(hù)。

1. 有疑點(diǎn)及時(shí)討論（越早發(fā)現(xiàn)坑越少），討論后必定要總結(jié)，總結(jié)必定文檔化

2. 做好需求歷史版本管理，上面已經(jīng)說(shuō)過(guò)版本歷史是非常好用的技巧，另外文件命名上也需要加上版本號(hào)和時(shí)間，變更時(shí)通知所有參與人（郵件或團(tuán)隊(duì)協(xié)助工具）

三、目的和原則

分享了「輸出」和「需求文檔」兩件事情的心得，目的絕不是讓大家下載模板，直接套用，而是參考的同時(shí)能理解PRD里每個(gè)部分的作用和方法，在實(shí)際積累中形成自己的PRD模板，關(guān)注需求內(nèi)容本身而不是需求形式，提高思維效率。

另外，想掌握一個(gè)方法，形成自己的方法論和認(rèn)知必須經(jīng)過(guò)具體到抽象，抽象再到具體的過(guò)程。

具體- >抽象：在探索中總結(jié)經(jīng)驗(yàn)。比如我這份需求文檔總結(jié)，也是從無(wú)開(kāi)始不斷迭代，最終總結(jié)了所有經(jīng)驗(yàn)得到抽象的結(jié)果。

抽象- >具體：結(jié)合實(shí)際運(yùn)用。比如我理解了每個(gè)部分的意義，在每個(gè)項(xiàng)目時(shí)間和不同條件下輸出不同的需求文檔。

Anyway,「方法只是思維層級(jí)里底層的事情」。

四、最后

需求文檔以「梳理清楚需求思路，減少溝通成本」為目標(biāo)，而不是寫(xiě)出漂亮的萬(wàn)字需求說(shuō)明書(shū)，不寫(xiě)空話廢話；

需求文檔不僅僅是個(gè)名詞，更應(yīng)該加「輸出」這個(gè)動(dòng)詞，關(guān)注完整輸出過(guò)程，能夠使需求流程更加流暢；

產(chǎn)品經(jīng)理應(yīng)該有自己的技能樹(shù)，每次積累總結(jié)都能點(diǎn)亮一項(xiàng)技能，「需求文檔」這件“小事”是最應(yīng)該前期先點(diǎn)亮的技能。

希望有幫助。

關(guān)注公眾號(hào)WinsonL，后臺(tái)回復(fù)"原型文件"可以下載完整版axure需求文檔一份。