上一篇和大家分享了我對(duì)需求的理解以及如何評(píng)估需求的優(yōu)先級(jí),，接下來(lái)我們將從生命周期的視角去梳理一遍需求的全流程，方便各位建立整體視角,。同時(shí),，通過(guò)對(duì)各個(gè)環(huán)節(jié)的復(fù)盤(pán)，尤其是平時(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)的問(wèn)題要快速反饋，看能否灰度期間修復(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)下一版迭代。

如果業(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ì)不停地詢問(wèn)，“這么做是要實(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)方案并不是指要親自寫(xiě)代碼，而是要明確功能設(shè)計(jì)的流程和分支邏輯：你可以將自己設(shè)想為用戶,，在腦海里走一遍所有的流程,，就好比在游戲中一樣，如何前進(jìn),，后退后怎么處理,，遇到障礙要如何躲避,，等等。

2. 在設(shè)計(jì)方案時(shí),，要考慮產(chǎn)品架構(gòu)的可擴(kuò)展性,。

   這里涉及到一個(gè)經(jīng)典問(wèn)題“產(chǎn)品經(jīng)理需要懂技術(shù)嗎？”答案當(dāng)然是肯定的呀,。產(chǎn)品經(jīng)理懂技術(shù),，不是說(shuō)要文能寫(xiě)文檔，武可寫(xiě)代碼,，而是說(shuō),，產(chǎn)品在設(shè)計(jì)功能時(shí)，不能跳脫現(xiàn)有的技術(shù)架構(gòu)和技術(shù)瓶頸,，而且必須要考慮到后續(xù)產(chǎn)品的演進(jìn)和架構(gòu)的可擴(kuò)展性,，千萬(wàn)不要為了一個(gè)功能做一錘子買(mǎi)賣(mài)。

遍歷這個(gè)說(shuō)法是我自己的一個(gè)小竅門(mén),， 當(dāng)我還是產(chǎn)品小白時(shí),，很幸運(yùn)地遇到一個(gè)專業(yè)測(cè)試，他輸出的測(cè)試用例不管從架構(gòu)還是細(xì)節(jié)都讓你服氣,，包括很多看起來(lái)不起眼但是萬(wàn)一遇到你就會(huì)懵逼的細(xì)節(jié),，他都能cover。在最開(kāi)始的階段,，我發(fā)現(xiàn)自己總是在需求跟進(jìn)階段不斷被詢問(wè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ǔ)充,。

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

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