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

最近一直在思考「輸出需求文檔」這件「小事」，發(fā)現(xiàn)太多產(chǎn)品經(jīng)理連需求都沒辦法完全表達(dá)清楚，在需求評(píng)審會(huì)上支支吾吾，被各種挑戰(zhàn)，或者開發(fā)階段中多次重復(fù)確認(rèn)，疲于各種溝通。相信每個(gè)產(chǎn)品新人都有過這種痛苦，解決的方法只有一種：「產(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)講解的?！篙敵鲂枨笪臋n」是產(chǎn)品經(jīng)理產(chǎn)品設(shè)計(jì)能力中最基本的基本功，就像UI同學(xué)用PS畫圖，開發(fā)哥敲代碼一樣，后兩項(xiàng)技能/工具是需要花4年大學(xué)時(shí)間或者甚至更長(zhǎng)的時(shí)間學(xué)習(xí)的，而大部分產(chǎn)品經(jīng)理竟然都沒有學(xué)習(xí)過需求文檔這件事情，如果大學(xué)開產(chǎn)品經(jīng)理專業(yè)，「輸出需求文檔」一定是大一就要學(xué)的課程。

我這里一直講的是「輸出需求文檔」，不僅僅包括寫需求文檔這件事，「輸出」應(yīng)該是一個(gè)動(dòng)作?？梢钥吹叫枨蟮耐暾鞒?，「輸出需求文檔」應(yīng)該分為需求前、需求中、需求后，寫文檔只是其中的一部分。

這次分享的是與需求文檔相關(guān)的動(dòng)作，需求跟進(jìn)和管理又是另外一個(gè)大課題，這次框架里不包括。

一、寫需求文檔

推薦這種結(jié)構(gòu)的需求文檔，采用的是結(jié)構(gòu)化導(dǎo)航模式（網(wǎng)上已經(jīng)有很多模板了），這樣的好處是清晰明了，開發(fā)、測(cè)試、設(shè)計(jì)不同角色可以根據(jù)自己需要看自己關(guān)注的部分，不用對(duì)著文字版需求說明書來回找。
再來，完整又簡(jiǎn)潔的需求文檔應(yīng)該包括：文檔簡(jiǎn)介、需求分析、結(jié)構(gòu)流程、原型交互、埋點(diǎn)說明。

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

（1）文檔說明

#版本說明

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

1. 序號(hào)：有幾個(gè)功能需求點(diǎn)。
2. 類型：將需求分為新增、修改、刪除。
3. 功能點(diǎn)：功能名字。
4. 需求描述：簡(jiǎn)要描述功能點(diǎn)，理解功能概況。
5. 優(yōu)先級(jí)：功能重要性，分為P0,P1,P2(當(dāng)然也可以直接分為高中低，或其他寫法)，不建議超過3個(gè)優(yōu)先級(jí)，意義不大。P0定義為必須完成，P1定義為無意外的話需要完成，P2可做可不做。
6. 詳情：我這里只是為了方便點(diǎn)擊跳轉(zhuǎn)到相應(yīng)需求說明的位置。

#修改歷史

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

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

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

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

• C回復(fù)B不需要通知A的，因?yàn)锳不會(huì)非常在乎B與C討論的內(nèi)容
• 點(diǎn)擊通知欄的時(shí)候如果沒登錄是調(diào)起登錄的
• 小紅點(diǎn)邏輯：?jiǎn)?dòng)的時(shí)候拉取
• 列表刷新：每次都進(jìn)入都刷新
• 定位位置，點(diǎn)贊定位問題

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

2. 同步給所有參與人（這部分目前我是通過公司的協(xié)助工具上傳文件，這樣能夠郵件通知，暫時(shí)還沒有更好的工具）

（2）詞匯說明

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

（3）需求分析

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

1. 邏輯型說服：闡述明白需求是如何產(chǎn)生的，價(jià)值是什么，為了達(dá)到產(chǎn)品最終目標(biāo)，這個(gè)需求是什么的作用。在我另外一篇文章里已經(jīng)詳細(xì)描述，并且詳細(xì)舉例說明，這里不再贅述。請(qǐng)看《如何從分析到需求全過程 | 全民K歌“你點(diǎn)TA唱”實(shí)例講解》
2. 數(shù)據(jù)型說服：通過估算這個(gè)需求帶來的直接數(shù)據(jù)增長(zhǎng)，比如用戶數(shù)、收入、點(diǎn)擊率等等

（4）原型交互

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

#客戶端邏輯

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

1. 界面原型：可以用各種原型工具完成，積累自己的素材庫(kù)能更快的完成高保真原型。（示意圖用的是sketch）
2. 入口：說明功能觸發(fā)的入口，哪里觸發(fā)是理解的第一步
3. 展示元素：描述界面需要的每個(gè)元素和展示邏輯
4. 行為交互：分為加載和點(diǎn)擊，數(shù)據(jù)/界面是如何加載出來，點(diǎn)擊后會(huì)有什么效果

#服務(wù)端邏輯

服務(wù)端部分指為用戶提供產(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è)功能為例子解釋下。

功能背景：通過挑選熱點(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)：用戶刷新時(shí)，將熱文按XX順序下發(fā)到XX位置
2. 其他邏輯…

#交互邏輯

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

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

1. 交互設(shè)計(jì)的本質(zhì)是「讓用戶更快更便捷的使用服務(wù)或產(chǎn)品內(nèi)容」
2. 始終考慮交互設(shè)計(jì)五個(gè)要素，媒介、場(chǎng)景、行為、目的、用戶

#邊緣場(chǎng)景

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

1. 網(wǎng)絡(luò)狀況：移動(dòng)、WIFI、斷網(wǎng)、弱網(wǎng)
2. 最大限制：字符、數(shù)據(jù)、等待時(shí)長(zhǎng)等等
3. 缺省狀態(tài)（為零）：輸入/展示為零
4. 多場(chǎng)景：夜間、橫屏、豎屏、不同渠道等等
5. 賬號(hào)狀態(tài)：未登錄/已登陸、多設(shè)備登陸、狀態(tài)切換不同步
6. 服務(wù)器異常處理

（5）結(jié)構(gòu)流程

#信息架構(gòu)

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

#業(yè)務(wù)流程

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

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

2. 用戶流程：用戶交互流程，描述用戶操作流程。

（6）埋點(diǎn)說明

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

1. 事件ID 事件唯一標(biāo)識(shí)，一般使用英文表述意義，單詞間使用下劃線隔開，如 ?click_add_bookmark_folder
2. 事件名稱：事件的中文名稱。
3. 統(tǒng)計(jì)口徑 ?指埋點(diǎn)類型，分別為計(jì)數(shù)事件、內(nèi)容計(jì)數(shù)事件、計(jì)時(shí)事件、狀態(tài)事件。

• 計(jì)數(shù)事件:只計(jì)算次數(shù)的事件類型
• 內(nèi)容計(jì)數(shù)事件:除了計(jì)算次數(shù)，還有其他參數(shù)上傳，參數(shù)一般用英文區(qū)分，如 from=下載來 ? 源，package=下載包名， host=下載鏈接 host，此類型多用 于減少計(jì)數(shù)事件埋點(diǎn)和用于報(bào)表生成。
• 計(jì)時(shí)事件:用于計(jì)算用戶使用事件，多用于頁(yè)面停留計(jì)算，進(jìn)入頁(yè)面開啟計(jì)時(shí) 器，離開頁(yè)面時(shí)停止計(jì)時(shí)器，并生成事件
• 狀態(tài)事件:用于上報(bào)開關(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)名稱和參數(shù)盡量使用有意義的英文表示，別埋點(diǎn)AA或者BB
3. 埋點(diǎn)的目的是為了生成報(bào)表分析，先想好功能要分析什么部分，需要什么埋點(diǎn)，「以終為始」不容易漏掉埋點(diǎn)或者參數(shù)。
4. 做好版本管理，云同步或在線協(xié)同文檔功能都是不錯(cuò)的選擇
5. 善用前綴命名，拓展更強(qiáng)

二、輸出動(dòng)作

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

（1）需求輸出前

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

1. 需求分析：想清楚為什么要做這個(gè)需求，可以從用戶場(chǎng)景和反饋思考，可以從數(shù)據(jù)分析，可以從競(jìng)品中參考，但是一定要比任何人都要想得更多。
2. 溝通：提前將想法和需求參與人員溝通，比如開發(fā)、設(shè)計(jì)。讓他們提前了解需求大概和評(píng)估可行性，這樣能避免將需求評(píng)審會(huì)變成需求討論會(huì)，團(tuán)隊(duì)一群人開一整天討論會(huì)效率極低。

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

1. 有疑點(diǎn)及時(shí)討論（越早發(fā)現(xiàn)坑越少），討論后必定要總結(jié)，總結(jié)必定文檔化
2. 做好需求歷史版本管理，上面已經(jīng)說過版本歷史是非常好用的技巧，另外文件命名上也需要加上版本號(hào)和時(shí)間，變更時(shí)通知所有參與人（郵件或團(tuán)隊(duì)協(xié)助工具）

三、目的和原則

分享了「輸出」和「需求文檔」兩件事情的心得，目的絕不是讓大家下載模板，直接套用，而是參考的同時(shí)能理解PRD里每個(gè)部分的作用和方法，在實(shí)際積累中形成自己的PRD模板，關(guān)注需求內(nèi)容本身而不是需求形式，提高思維效率。另外，想掌握一個(gè)方法，形成自己的方法論和認(rèn)知必須經(jīng)過具體到抽象，抽象再到具體的過程。

• 具體 -> 抽象：在探索中總結(jié)經(jīng)驗(yàn)。比如我這份需求文檔總結(jié)，也是從無開始不斷迭代，最終總結(jié)了所有經(jīng)驗(yàn)得到抽象的結(jié)果。
• 抽象 -> 具體：結(jié)合實(shí)際運(yùn)用。比如我理解了每個(gè)部分的意義，在每個(gè)項(xiàng)目時(shí)間和不同條件下輸出不同的需求文檔。

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

四、最后

• 需求文檔以「梳理清楚需求思路，減少溝通成本」為目標(biāo)，而不是寫出漂亮的萬字需求說明書，不寫空話廢話；
• 需求文檔不僅僅是個(gè)名詞，更應(yīng)該加「輸出」這個(gè)動(dòng)詞，關(guān)注完整輸出過程，能夠使需求流程更加流暢；
• 產(chǎn)品經(jīng)理應(yīng)該有自己的技能樹，每次積累總結(jié)都能點(diǎn)亮一項(xiàng)技能，「需求文檔」這件“小事”是最應(yīng)該前期先點(diǎn)亮的技能。

附上axure原型文件，鏈接: https://pan.baidu.com/s/1o8K87Ui 密碼: gtkx，僅供參考。

作者：WinsonL，微信公眾號(hào)：WinsonL，魅族科技Flyme產(chǎn)品經(jīng)理，成長(zhǎng)焦慮人群的其中一員，用實(shí)例干貨分享思考和經(jīng)驗(yàn)。

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