編輯導(dǎo)讀：需求管理對(duì)于項(xiàng)目來(lái)說(shuō)很重要，甚至?xí)绊懙巾?xiàng)目的成功與否。我們應(yīng)該如何進(jìn)行需求管理？本文作者將從實(shí)際的工作中體會(huì)，以實(shí)踐和理論相結(jié)合的角度對(duì)產(chǎn)品經(jīng)理日常中需求管理的流程方法進(jìn)行了總結(jié)，與大家分享。

需求管理不同于產(chǎn)品驗(yàn)收：產(chǎn)品驗(yàn)收，一般指的是產(chǎn)品同學(xué)在測(cè)試完成后，驗(yàn)證產(chǎn)品交互物是否符合自己的產(chǎn)品設(shè)計(jì)預(yù)期。但產(chǎn)品的工作目標(biāo)是順利產(chǎn)出，拒絕翻車(chē)。

因此，需求評(píng)審?fù)旰?，等到測(cè)試完成才驗(yàn)收是不夠的，產(chǎn)品同學(xué)應(yīng)該對(duì)整個(gè)產(chǎn)研過(guò)程進(jìn)行過(guò)程管理，在各個(gè)節(jié)點(diǎn)進(jìn)行階段性驗(yàn)收，即需求管理。

需求管理一條龍，全流程介紹：

01 需求輸出（PRD）自查

1.1 功能邏輯

邏輯閉環(huán)，不遺漏判斷；描述清楚，無(wú)歧義。

（1）PRD是否有按照需求文檔規(guī)范編寫(xiě)？

一般公司內(nèi)部都會(huì)有需求文檔規(guī)范，這個(gè)PRD規(guī)范就是一個(gè)非?；镜男枨笏伎伎蚣芎托畔鬟f框架，而且是在公司內(nèi)部經(jīng)過(guò)磨合以及實(shí)操驗(yàn)證的。

按規(guī)范來(lái)寫(xiě)，至少需求的框架是成型的，在信息傳輸上需要達(dá)成共識(shí)的模塊也會(huì)考慮進(jìn)去了。（如果小團(tuán)隊(duì)沒(méi)有需求文檔規(guī)范，可以自己總結(jié)一份。）

（2）是否有異常狀態(tài)的處理?

正向過(guò)程是相對(duì)容易考慮全面，因此功能邏輯自查的重點(diǎn)是逆向過(guò)程，異常狀態(tài)?？梢詮囊韵聨追矫嬷郑?/p>

1）業(yè)務(wù)異常

• 逆向流程：如訂單取消，退貨退款，優(yōu)惠券退回
• 不可用：如賬號(hào)未注冊(cè)，賬號(hào)被凍結(jié)，校驗(yàn)未通過(guò)
• 超時(shí)效：如優(yōu)惠券過(guò)期
• 無(wú)權(quán)限：常見(jiàn)2B產(chǎn)品，不同角色權(quán)限不同

2）數(shù)據(jù)異常

• 輸入異常：不符合輸入要求；輸入錯(cuò)誤
• 返回異常：無(wú)搜索結(jié)果
• 顯示異常：空數(shù)據(jù)；加載異常；排序異常

3）網(wǎng)絡(luò)異常

• 無(wú)網(wǎng)絡(luò)：無(wú)網(wǎng)絡(luò)權(quán)限；沒(méi)有聯(lián)網(wǎng)
• 網(wǎng)絡(luò)慢

4）服務(wù)器異常

• 接口調(diào)用超時(shí)
• 收不到回調(diào)

（3）與產(chǎn)品其他模塊是否有關(guān)聯(lián)影響？

• 如涉及功能消息通知：短信/push/Email
• 如需求涉及到的管理后臺(tái)系統(tǒng)改造

1.2 交互體驗(yàn)：交互稿驗(yàn)收/自查

記住，用戶是很懶很懶很懶的。懶得想，懶得動(dòng)，懶得等！

• 用戶路徑是否清晰？

用戶能很輕松知道當(dāng)前自己在哪，從哪來(lái)，可以去哪，如何能完成目標(biāo)。

“三次點(diǎn)擊法則：如果用戶在3次單擊中未找到他們想要的信息或了解到該網(wǎng)站的功能，他們將離開(kāi)。該法則強(qiáng)調(diào)了清晰導(dǎo)航，邏輯結(jié)構(gòu)和易于理解的網(wǎng)站層次結(jié)構(gòu)的重要性。”

• 用戶路徑是否直接順暢？

盡量少讓用戶選擇，已知用戶要做的選擇，提前幫他選好。但同時(shí)用戶可以隨時(shí)中止或退出。

• 用戶操作是否簡(jiǎn)單？

業(yè)內(nèi)通用模塊的交互設(shè)計(jì)，已經(jīng)培育了一代用戶的操作習(xí)慣。如果沒(méi)特殊情況，新設(shè)計(jì)也沒(méi)有質(zhì)的飛躍，比如從文字交互到語(yǔ)音交這種變化，那就別標(biāo)新立異，否則反而增加了用戶使用門(mén)檻。

• 是否及時(shí)反饋？

尤其是異常提示，錯(cuò)誤提示，是否及時(shí)反饋給用戶，并告知下一步需要做哪些事情來(lái)結(jié)束當(dāng)前的異常狀態(tài)。

• 用戶等待時(shí)間是否再短一些？

等待時(shí)間越短，用戶體驗(yàn)就越好。能否通過(guò)業(yè)務(wù)流程優(yōu)化或者性能優(yōu)化減少用戶的等待時(shí)間，不能的話，那就需要考慮是否需要通過(guò)其他方式分散用戶注意力，拒絕產(chǎn)生“度秒如年”的感受。

• 文案是否確認(rèn)，文案風(fēng)格是否友好？

涉及到不同語(yǔ)言版本的，提前準(zhǔn)備好翻譯。同樣的表述，不同語(yǔ)言的文字長(zhǎng)度是有差別的，提前準(zhǔn)備好，方便交互，設(shè)計(jì)根據(jù)文字長(zhǎng)度進(jìn)行設(shè)計(jì)。

• 復(fù)雜/特殊的交互方案，是否描述清楚？

一文字描述 二口頭溝通 三模擬效果展示

• 復(fù)雜的交互方案，性價(jià)比高么？

產(chǎn)品的核心工作是平衡需求和資源，做最優(yōu)決策。所以，開(kāi)發(fā)資源不足的時(shí)候，非核心流程的交互，就不要死磕了。

1.3 視覺(jué)效果：UI稿

• 頁(yè)面信息顯示優(yōu)先級(jí)明確

產(chǎn)品/業(yè)務(wù)上需要強(qiáng)調(diào)的內(nèi)容，視覺(jué)上是否足夠強(qiáng)調(diào)

• 彈窗等全局組件是否盡量統(tǒng)一？

全局組件，通用組件盡量統(tǒng)一，一是風(fēng)格統(tǒng)一好看，二是開(kāi)發(fā)起來(lái)復(fù)用性好。

• 審美

交給專業(yè)的設(shè)計(jì)同學(xué)

• 復(fù)雜/特殊的視覺(jué)是否描述清楚？

一文字描述 二口頭溝通 三模擬效果展示

• 復(fù)雜/特殊的視覺(jué)效果，性價(jià)比高么？

同樣，開(kāi)發(fā)資源不足的時(shí)候，非核心流程的視覺(jué)效果，勸一勸設(shè)計(jì)同學(xué)~

1.4 數(shù)據(jù)邏輯

（1）數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)處理

這主要考量的就是數(shù)據(jù)表結(jié)構(gòu)的設(shè)計(jì)。

什么是數(shù)據(jù)表？什么是數(shù)據(jù)表結(jié)構(gòu)？

“數(shù)據(jù)表是由表名、表中的字段和表的記錄三個(gè)部分組成的。設(shè)計(jì)數(shù)據(jù)表結(jié)構(gòu)就是定義數(shù)據(jù)表文件名，確定數(shù)據(jù)表包含哪些字段，各字段的字段名、字段類型、及寬度，并將這些數(shù)據(jù)輸入到計(jì)算機(jī)當(dāng)中?！?/p>

產(chǎn)品為什么要關(guān)注數(shù)據(jù)表結(jié)構(gòu)？

需求的確不一定都需要關(guān)注表結(jié)構(gòu)才能完成，是可以完全交給開(kāi)發(fā)設(shè)計(jì)。但是底層的數(shù)據(jù)邏輯思維，對(duì)于產(chǎn)品來(lái)說(shuō)是很關(guān)鍵的。

互聯(lián)網(wǎng)產(chǎn)品本質(zhì)結(jié)構(gòu)都是數(shù)據(jù)，業(yè)務(wù)邏輯是否清晰就看數(shù)據(jù)邏輯是否清晰。數(shù)據(jù)從哪來(lái)，去哪，如何變化，都是在表里發(fā)生的。不過(guò)是多復(fù)雜的產(chǎn)品，實(shí)質(zhì)就是一堆數(shù)據(jù)在表里的流轉(zhuǎn)。數(shù)據(jù)邏輯清晰了，業(yè)務(wù)邏輯也就清晰了。

從項(xiàng)目的完整生命周期來(lái)看，數(shù)據(jù)表結(jié)構(gòu)是地基，決定了拓展性。上線后，前端UI展示等要優(yōu)化的話是很好改的，但如果涉及要改底層的數(shù)據(jù)表結(jié)構(gòu)，那就是一個(gè)龐大的工程。

所以，數(shù)據(jù)表結(jié)構(gòu)，產(chǎn)品可以不參與設(shè)計(jì)，但是一定要和開(kāi)發(fā)同學(xué)保持充分的溝通。因?yàn)?，開(kāi)發(fā)一般是基于當(dāng)前的需求進(jìn)行技術(shù)設(shè)計(jì)，這樣的情況下，架構(gòu)很可能有局限性，無(wú)法適應(yīng)日后的業(yè)務(wù)拓展。而上線后的重構(gòu)是很痛苦的，成本也很高。因此，產(chǎn)品的介入，能幫助開(kāi)發(fā)在架構(gòu)設(shè)計(jì)時(shí)有更好業(yè)務(wù)前瞻性，也有助于產(chǎn)品自己對(duì)技術(shù)架構(gòu)設(shè)計(jì)的了解。

產(chǎn)品要關(guān)注哪些點(diǎn)？

主要關(guān)注存儲(chǔ)的字段，和表關(guān)系。

單張表：表中字段名稱，字段所屬對(duì)象，字段值類型，取值來(lái)源，最長(zhǎng)長(zhǎng)度，字段說(shuō)明

多張表之間的關(guān)系：一對(duì)一，一對(duì)多，多對(duì)多。關(guān)系盡量簡(jiǎn)單。比如多對(duì)多的關(guān)系，可以增加一個(gè)第三方，改為兩個(gè)一對(duì)一的關(guān)系。

（2）接口設(shè)計(jì)

一般而言，內(nèi)部的接口無(wú)需額外關(guān)注，但平臺(tái)類產(chǎn)品，接口對(duì)第三方開(kāi)放的，則需要從業(yè)務(wù)角度，思考如何設(shè)計(jì)接口，從而對(duì)第三方調(diào)用會(huì)更友好，有更好的兼容性。

入?yún)?返參：產(chǎn)品不需要定義API所有的字段，但涉及到業(yè)務(wù)需求的字段，需要明確出入?yún)⒁蟆?/p>

接口性能要求：產(chǎn)品需要對(duì)業(yè)務(wù)充分評(píng)估，給出TPS/QPS限制，保證業(yè)務(wù)順暢運(yùn)行的同時(shí)，也不浪費(fèi)服務(wù)器資源。

（3）數(shù)據(jù)指標(biāo)體系

明確業(yè)務(wù)目標(biāo)，根據(jù)業(yè)務(wù)目標(biāo)，用戶路徑確定數(shù)據(jù)指標(biāo)：

• 注意數(shù)據(jù)的準(zhǔn)確性，可獲取性，時(shí)效性，統(tǒng)計(jì)口徑是否一致
• 建立報(bào)表并搭建相應(yīng)的監(jiān)控告警體系

（4）埋點(diǎn)

埋點(diǎn)定義：基于業(yè)務(wù)需求，為日后進(jìn)行數(shù)據(jù)分析，提前在應(yīng)用中特定流程植入代碼采集數(shù)據(jù)，從而達(dá)到追蹤用戶行為，輔助決策的目的。

觸發(fā)事件分類：

1. 曝光：每被用戶看到一次，就是一個(gè)曝光事件。比如商品的曝光。
2. 點(diǎn)擊：用戶每進(jìn)行一次點(diǎn)擊，就是一個(gè)點(diǎn)擊事件。比如按鈕的點(diǎn)擊。

舉例：

（不同公司，埋點(diǎn)規(guī)范不同，按公司要求來(lái)就好）

1.5 拓展性

需求功能點(diǎn)是否考慮做成可配置

需求功能點(diǎn)是否可做成通用模塊，提高復(fù)用性

1.6 監(jiān)控報(bào)警

是否需要對(duì)關(guān)鍵數(shù)據(jù)指標(biāo)進(jìn)行監(jiān)控，并設(shè)置報(bào)警閾值。

1.7 部門(mén)協(xié)同

需要協(xié)同的部門(mén)，是否都確認(rèn)和周知？

非常重要，不要閉門(mén)造車(chē)，然后辛辛苦苦開(kāi)發(fā)完，結(jié)果安全/風(fēng)控/合規(guī)部門(mén)一句say no，上不了線…

02 了解技術(shù)實(shí)現(xiàn)方案

開(kāi)篇提到，產(chǎn)品不是寫(xiě)完P(guān)RD，需求評(píng)審?fù)昃屯晔?，一定要跟蹤產(chǎn)研整個(gè)過(guò)程。

為啥不懂技術(shù)的產(chǎn)品要去了解技術(shù)實(shí)現(xiàn)方案呢？

• 如”上文1.4數(shù)據(jù)邏輯”所述，開(kāi)發(fā)一般是基于當(dāng)前的需求進(jìn)行技術(shù)設(shè)計(jì)，這樣的情況下，架構(gòu)很可能有局限性，無(wú)法適應(yīng)日后的業(yè)務(wù)拓展。產(chǎn)品的介入，能幫助開(kāi)發(fā)在架構(gòu)設(shè)計(jì)時(shí)有更好業(yè)務(wù)前瞻性，也有助于產(chǎn)品自己對(duì)技術(shù)架構(gòu)設(shè)計(jì)的了解。
• 以防自己留坑。產(chǎn)品的規(guī)則沒(méi)有細(xì)化并明確，開(kāi)發(fā)按照自己的理解進(jìn)行了功能設(shè)計(jì)，多溝通才能發(fā)現(xiàn)自己埋的坑。
• 產(chǎn)品規(guī)則明確了，但開(kāi)發(fā)有可能沒(méi)仔細(xì)看PRD，PRD寫(xiě)得再好，也架不住開(kāi)發(fā)不看。

和團(tuán)隊(duì)保持積極良好的雙向溝通是非常重要的。一個(gè)60分的產(chǎn)品，如何提高自己的需求質(zhì)量？很重要的一點(diǎn)就是溝通。開(kāi)發(fā)/運(yùn)營(yíng)/測(cè)試提出問(wèn)題，一定要重視，并且及時(shí)給到正向的反饋。否則，別人就算覺(jué)得需求有問(wèn)題，也不愿意和你說(shuō)，反正鍋不在他那。

03 UI驗(yàn)收

UI驗(yàn)收，是由UI設(shè)計(jì)同學(xué)來(lái)驗(yàn)證開(kāi)發(fā)完的系統(tǒng)UI還原度，是否能夠達(dá)到預(yù)期的效果。這里產(chǎn)品同學(xué)要介入的是ui驗(yàn)收?qǐng)?bào)告，沒(méi)有報(bào)告的話，就保證和ui及時(shí)溝通，了解當(dāng)前的問(wèn)題。

04 測(cè)試

這一步，產(chǎn)品主要關(guān)注的是測(cè)試用例。

測(cè)試用例是否完善：

• 流程：正向流程，逆向流程，異常流程是否全部涵蓋
• 操作：執(zhí)行步驟，預(yù)置條件，預(yù)期結(jié)果
• 數(shù)據(jù)：數(shù)據(jù)的記錄是否完整，流轉(zhuǎn)是否正確

萬(wàn)一翻車(chē)了，咋整？

測(cè)試完成，產(chǎn)品在上線前進(jìn)行最后的驗(yàn)收，確認(rèn)程序開(kāi)發(fā)是否符合需求預(yù)期。

萬(wàn)一到這步還有遺留問(wèn)題，四步解決：

1. 定位問(wèn)題：發(fā)現(xiàn)問(wèn)題的時(shí)間；所屬模塊；具體問(wèn)題描述（附上截圖）
2. 明確優(yōu)先級(jí)：是否影響工期，是否本期一定要修改。小bug，可以安排迭代更新，大bug，涉及核心流程或者緊急的話就得加班或者delay了。
3. 確定處理方案及處理人
4. 事后總結(jié)：不是為了甩鍋，這個(gè)時(shí)候翻車(chē)就是產(chǎn)品的鍋，知道是哪個(gè)環(huán)節(jié)出的問(wèn)題，以后才能避免。建議寫(xiě)定期寫(xiě)工作總結(jié)。沉淀下經(jīng)驗(yàn)教訓(xùn)。

作者：石青；微信公眾號(hào)：shiqingzixishi

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

題圖來(lái)自Unsplash，基于CC0協(xié)議