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

需求全生命周期

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

1. 需求搜集及評估階段：以最終需求确定為節點，在這個階段，需要和産品運營及相關業務方确認“這一版要做哪些事”；
2. 需求方案設計階段：以需求方案評審為節點，在這個階段，需要和技術明确上一階段确認的最終需求要以怎樣的技術方案實現，該階段必須産出PRD文檔;
3. 測試評審及排期确認階段：以需求排期确定為節點，在這個階段，單獨将測試用例列出，也是想提醒各位PM們：一定要重視分支邏輯和異常情況。最好自己用腦圖将用戶可能遇到的情況遍曆一下，必須做好托底邏輯，因為BUG是一定會有的，而且會以各種你想不到的方式出現；
4. 需求跟進階段：在這個階段，所有的邏輯和不确定情況必須落實到PRD文檔裡。很多團隊會建立自己的協作平台，方便跟蹤不同階段的文檔，如果有協作平台的話，盡量做到及時更新；
5. 需求驗收階段：在這個階段，需要産品經理完成産品自查或者是交叉走查，此時暴露出來的問題要快速反饋，看能否灰度期間修複或者熱修複，驗收的标準以PRD文檔為準；
6. 需求review階段：需求可以正常按照預期上線并不是需求的終點，産品經理做需求的目的不在于Kill一個需求，而在于驗證是否滿足了用戶的demand，在這個階段，需要産品跟進用戶反饋，對線上數據進行對比分析，形成可靠的結論。對于需要後續改進的功能，重新列入需求池，跟進下一版叠代。

需求方案設計中的要點

如果業務或者運營提出的需求過于直白，比如“在哪個位置加個button，實現XX功能”，産品經理一定不要将需求直接“路由”給研發。在工作中我們也會發現，優秀的産品經理在這種情況下總是會不停地詢問，“這麼做是要實現XX功能，對吧？ ”“實現XX功能的數據預期是多少？”“實現同樣的功能，我認為B方案更友好更方便，要不要一起讨論下？”——實現功能的方案絕對不止一種，重要的不是button放在哪裡，而是怎麼實現這個功能更符合用戶的習慣，同時更與産品架構契合。

在需求方案設計階段：

1. 産品需要将需求“翻譯”為技術能讀懂的實現方案。這裡的實現方案并不是指要親自寫代碼，而是要明确功能設計的流程和分支邏輯：你可以将自己設想為用戶，在腦海裡走一遍所有的流程，就好比在遊戲中一樣，如何前進，後退後怎麼處理，遇到障礙要如何躲避，等等。
2. 在設計方案時，要考慮産品架構的可擴展性。這裡涉及到一個經典問題“産品經理需要懂技術嗎？”答案當然是肯定的呀。産品經理懂技術，不是說要文能寫文檔，武可寫代碼，而是說，産品在設計功能時，不能跳脫現有的技術架構和技術瓶頸，而且必須要考慮到後續産品的演進和架構的可擴展性，千萬不要為了一個功能做一錘子買賣。

嘗試用測試用例遍曆

遍曆這個說法是我自己的一個小竅門， 當我還是産品小白時，很幸運地遇到一個專業測試，他輸出的測試用例不管從架構還是細節都讓你服氣，包括很多看起來不起眼但是萬一遇到你就會懵逼的細節，他都能cover。在最開始的階段，我發現自己總是在需求跟進階段不斷被詢問，某個分支的分支的邏輯是怎樣的，然後再臨時起意定一個，如果cover的内容少，你還能hold。但是當你切換到multi-tasks模式，就會陷入困境。

解決困境的方法其實很笨，就是遍曆。最好用腦圖記下作為小白用戶走過的所有路徑，然後再針對不同的路徑設計交互的流程。很多時候産品經理會有一種自我麻醉心理，或者是高估了自己的用戶。遍曆的時候每走一步，可以停下來想想這一步還可能怎麼走，按照自上而下的結構将所有節點走一遍。當你“遍曆”完每個功能的時候，你就會發現基本上形成的腦圖可以作為測試用例使用了，如果團隊配有專業的測試人員，正好可以交叉對比下，可以互為補充。

Kill需求并不是終點

很多産品将自己定義為“需求killer”，殺一個需求就Mark一次，多多益善。對于這種思路，我不是很認同，當然量變是質變的基礎，但是如果将完成需求作為需求的終點，而不對需求的完成效果進行評估和review時，成長的密度就會大大降低。

完成需求，隻是将需求轉化為了已經實現的功能，但是這個需求是不是僞需求？用戶會買賬嗎？這才是産品存活的關鍵問題。假設你加個一個button，可以讓用戶實現某種功能。你自認為功能非常酷炫，交互非常友好。但是産品經理的直覺往往是南轅北轍的，如果上線後數據表現很差怎麼辦？你可以直接砍掉迅速否認，然後下一版重來一遍，但是一個産品的反複對于用戶是不小的傷害，而且單就數據表現差這一點，就有很多點可以挖掘。比如，是整個功能本身就不是用戶需要的？還是這個入口隐藏太深？或者是交互影響核心操作路徑？諸如此類，必須要結合數據和用戶反饋對需求進行校驗，然後再形成可靠的結論。

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!