上一篇和大家分享了我對(duì)需求的理解以及如何評(píng)估需求的優(yōu)先級(jí)，接下來(lái)我們將從生命周期的視角去梳理一遍需求的全流程，方便各位建立整體視角。同時(shí)，通過(guò)對(duì)各個(gè)環(huán)節(jié)的復(fù)盤，尤其是平時(shí)容易忽略的環(huán)節(jié)，可以發(fā)現(xiàn)影響需求預(yù)期效果和工作效率的瓶頸點(diǎn)，更有助于各位PM提高自己的工作效率。

需求全生命周期

通常情況下，一個(gè)需求的完整生命周期可以劃分為六個(gè)部分：

1. 需求搜集及評(píng)估階段：以最終需求確定為節(jié)點(diǎn)，在這個(gè)階段，需要和產(chǎn)品運(yùn)營(yíng)及相關(guān)業(yè)務(wù)方確認(rèn)“這一版要做哪些事”；
2. 需求方案設(shè)計(jì)階段：以需求方案評(píng)審為節(jié)點(diǎn)，在這個(gè)階段，需要和技術(shù)明確上一階段確認(rèn)的最終需求要以怎樣的技術(shù)方案實(shí)現(xiàn)，該階段必須產(chǎn)出PRD文檔;
3. 測(cè)試評(píng)審及排期確認(rèn)階段：以需求排期確定為節(jié)點(diǎn)，在這個(gè)階段，單獨(dú)將測(cè)試用例列出，也是想提醒各位PM們：一定要重視分支邏輯和異常情況。最好自己用腦圖將用戶可能遇到的情況遍歷一下，必須做好托底邏輯，因?yàn)锽UG是一定會(huì)有的，而且會(huì)以各種你想不到的方式出現(xiàn)；
4. 需求跟進(jìn)階段：在這個(gè)階段，所有的邏輯和不確定情況必須落實(shí)到PRD文檔里。很多團(tuán)隊(duì)會(huì)建立自己的協(xié)作平臺(tái)，方便跟蹤不同階段的文檔，如果有協(xié)作平臺(tái)的話，盡量做到及時(shí)更新；
5. 需求驗(yàn)收階段：在這個(gè)階段，需要產(chǎn)品經(jīng)理完成產(chǎn)品自查或者是交叉走查，此時(shí)暴露出來(lái)的問題要快速反饋，看能否灰度期間修復(fù)或者熱修復(fù)，驗(yàn)收的標(biāo)準(zhǔn)以PRD文檔為準(zhǔn)；
6. 需求review階段：需求可以正常按照預(yù)期上線并不是需求的終點(diǎn)，產(chǎn)品經(jīng)理做需求的目的不在于kill一個(gè)需求，而在于驗(yàn)證是否滿足了用戶的demand，在這個(gè)階段，需要產(chǎn)品跟進(jìn)用戶反饋，對(duì)線上數(shù)據(jù)進(jìn)行對(duì)比分析，形成可靠的結(jié)論。對(duì)于需要后續(xù)改進(jìn)的功能，重新列入需求池，跟進(jìn)下一版迭代。

需求方案設(shè)計(jì)中的要點(diǎn)

如果業(yè)務(wù)或者運(yùn)營(yíng)提出的需求過(guò)于直白，比如“在哪個(gè)位置加個(gè)button，實(shí)現(xiàn)XX功能”，產(chǎn)品經(jīng)理一定不要將需求直接“路由”給研發(fā)。在工作中我們也會(huì)發(fā)現(xiàn)，優(yōu)秀的產(chǎn)品經(jīng)理在這種情況下總是會(huì)不停地詢問，“這么做是要實(shí)現(xiàn)XX功能，對(duì)吧？ ”“實(shí)現(xiàn)XX功能的數(shù)據(jù)預(yù)期是多少？”“實(shí)現(xiàn)同樣的功能，我認(rèn)為B方案更友好更方便，要不要一起討論下？”——實(shí)現(xiàn)功能的方案絕對(duì)不止一種，重要的不是button放在哪里，而是怎么實(shí)現(xiàn)這個(gè)功能更符合用戶的習(xí)慣，同時(shí)更與產(chǎn)品架構(gòu)契合。

在需求方案設(shè)計(jì)階段：

1. 產(chǎn)品需要將需求“翻譯”為技術(shù)能讀懂的實(shí)現(xiàn)方案。這里的實(shí)現(xiàn)方案并不是指要親自寫代碼，而是要明確功能設(shè)計(jì)的流程和分支邏輯：你可以將自己設(shè)想為用戶，在腦海里走一遍所有的流程，就好比在游戲中一樣，如何前進(jìn)，后退后怎么處理，遇到障礙要如何躲避，等等。
2. 在設(shè)計(jì)方案時(shí)，要考慮產(chǎn)品架構(gòu)的可擴(kuò)展性。這里涉及到一個(gè)經(jīng)典問題“產(chǎn)品經(jīng)理需要懂技術(shù)嗎？”答案當(dāng)然是肯定的呀。產(chǎn)品經(jīng)理懂技術(shù)，不是說(shuō)要文能寫文檔，武可寫代碼，而是說(shuō)，產(chǎn)品在設(shè)計(jì)功能時(shí)，不能跳脫現(xiàn)有的技術(shù)架構(gòu)和技術(shù)瓶頸，而且必須要考慮到后續(xù)產(chǎn)品的演進(jìn)和架構(gòu)的可擴(kuò)展性，千萬(wàn)不要為了一個(gè)功能做一錘子買賣。

嘗試用測(cè)試用例遍歷

遍歷這個(gè)說(shuō)法是我自己的一個(gè)小竅門， 當(dāng)我還是產(chǎn)品小白時(shí)，很幸運(yùn)地遇到一個(gè)專業(yè)測(cè)試，他輸出的測(cè)試用例不管從架構(gòu)還是細(xì)節(jié)都讓你服氣，包括很多看起來(lái)不起眼但是萬(wàn)一遇到你就會(huì)懵逼的細(xì)節(jié)，他都能cover。在最開始的階段，我發(fā)現(xiàn)自己總是在需求跟進(jìn)階段不斷被詢問，某個(gè)分支的分支的邏輯是怎樣的，然后再臨時(shí)起意定一個(gè)，如果cover的內(nèi)容少，你還能hold。但是當(dāng)你切換到multi-tasks模式，就會(huì)陷入困境。

解決困境的方法其實(shí)很笨，就是遍歷。最好用腦圖記下作為小白用戶走過(guò)的所有路徑，然后再針對(duì)不同的路徑設(shè)計(jì)交互的流程。很多時(shí)候產(chǎn)品經(jīng)理會(huì)有一種自我麻醉心理，或者是高估了自己的用戶。遍歷的時(shí)候每走一步，可以停下來(lái)想想這一步還可能怎么走，按照自上而下的結(jié)構(gòu)將所有節(jié)點(diǎn)走一遍。當(dāng)你“遍歷”完每個(gè)功能的時(shí)候，你就會(huì)發(fā)現(xiàn)基本上形成的腦圖可以作為測(cè)試用例使用了，如果團(tuán)隊(duì)配有專業(yè)的測(cè)試人員，正好可以交叉對(duì)比下，可以互為補(bǔ)充。

Kill需求并不是終點(diǎn)

很多產(chǎn)品將自己定義為“需求killer”，殺一個(gè)需求就Mark一次，多多益善。對(duì)于這種思路，我不是很認(rèn)同，當(dāng)然量變是質(zhì)變的基礎(chǔ)，但是如果將完成需求作為需求的終點(diǎn)，而不對(duì)需求的完成效果進(jìn)行評(píng)估和review時(shí)，成長(zhǎng)的密度就會(huì)大大降低。

完成需求，只是將需求轉(zhuǎn)化為了已經(jīng)實(shí)現(xiàn)的功能，但是這個(gè)需求是不是偽需求？用戶會(huì)買賬嗎？這才是產(chǎn)品存活的關(guān)鍵問題。假設(shè)你加個(gè)一個(gè)button，可以讓用戶實(shí)現(xiàn)某種功能。你自認(rèn)為功能非常酷炫，交互非常友好。但是產(chǎn)品經(jīng)理的直覺往往是南轅北轍的，如果上線后數(shù)據(jù)表現(xiàn)很差怎么辦？你可以直接砍掉迅速否認(rèn)，然后下一版重來(lái)一遍，但是一個(gè)產(chǎn)品的反復(fù)對(duì)于用戶是不小的傷害，而且單就數(shù)據(jù)表現(xiàn)差這一點(diǎn)，就有很多點(diǎn)可以挖掘。比如，是整個(gè)功能本身就不是用戶需要的？還是這個(gè)入口隱藏太深？或者是交互影響核心操作路徑？諸如此類，必須要結(jié)合數(shù)據(jù)和用戶反饋對(duì)需求進(jìn)行校驗(yàn)，然后再形成可靠的結(jié)論。

以上就是我對(duì)需求全流程的梳理，歡迎大家分享自己相關(guān)的心得。

相關(guān)閱讀

資深產(chǎn)品經(jīng)理是如何做需求管理的（一）：需求的優(yōu)先級(jí)判定原則

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