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

需求全生命周期

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

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

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

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

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

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

嘗試用測試用例遍歷

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

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

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

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

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

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

相關(guān)閱讀

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

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