需求系列(一)——需求處理流程

產品經理日常的主要工作都是圍繞需求展開的，每天為它摳破腦袋，只為開發哥哥們少點煩惱，用户爸爸們多點快樂。想清楚了，皆大歡喜；沒想清楚，詠春葉問。

在後面的這段時間裏，我將以一個系列的文章來分享一些自己對需求的認識，希望能幫助到還未能系統認識需求的同學。

作為本系列的第一篇，我們先聊聊常見的需求處理流程，後續文章將以此流程為框架，逐條展開。

一、需求獲取階段

在需求獲取階段，需要做好收集和管理兩件事。

這些需求既有產品經理主動挖掘的，也有從用户、運營、業務方、領導等渠道被動獲取的，無論哪個渠道來的需求，都需要有一個正式的地方進行管理，也就是我們通常所説的需求池。

不過，對於多方關注的重點需求，通過需求池來向各方同步就不太合適了：

• 一是因為需求池內容太多、太雜，向業務方、領導彙報的時候會有很多幹擾信息，難以快速抓住重點；
• 二是因為需求池裏面可能有些需求不適合完全公開。

這時我們就需要使用《事項跟蹤表》來單獨跟進，形式上用Excel、PPT都可以。

而放在《事項跟蹤表》裏的需求，也要在需求池裏記錄下來，即需求池是做全量需求管理的，《事項跟蹤表》是做重點需求跟進、彙報的。

二、需求分析階段1. 分析內容

需求分析主要從需求要素、定位、分解、優先級四個方面進行。

1）需求要素分析

需求要素分析是從需求本身出發，不考慮其他因素。

這些要素包括：內容、用户/角色、頻次、價值、場景-動機、強度六個方面，這些要素的含義大家應該都比較清楚了，這裏説一下分析各個要素的目的是什麼：

• 分析需求內容，是為了弄清楚需求是什麼；
• 分析需求用户/角色，是為了弄清楚需求為誰服務；
• 分析需求頻次、強度，是為了弄清楚需求對用户的重要性、緊迫程度；
• 分析需求場景-動機，是為了弄清楚需求真偽、用户目的，更深入的理解需求；
• 分析需求價值，是為了弄清楚需求值不值得做。

2）定位分析

需求的定位分析是分析需求對產品當前階段目標的意義。

分析需求的定位，有以下兩個目的：

1. 一是作為優先級排期的判斷條件之一，如果需求與產品當前階段的目標密切相關，則需要作為高優先級上線；
2. 二是為了框定需求範圍。每個需求的實現程度都有深有淺，可以很簡單，也可以很複雜，瞭解了需求之於產品的定位，就能判斷需求要做到什麼程度。如果一個需求對產品很重要，那就需要做得很豐富，如果只是輔助需求，則需要適當輕量。

3）需求分解

原始需求的顆粒度往往較粗，不利於後續的分析、設計、開發等工作，所以我們需要對這些顆粒度較粗的原始需求進行分解，分解為一個個完整、獨立、可實現的子需求。

4）優先級分析

優先級分析是以拆解後的子需求為單位進行的，根據各類優先級的判斷方法、原則，初步評估各個子需求的上線順序及時間。

2. 常見問題

需求分析應該是大家從入行那天就知道要做的事，但大多數同學在做需求分析時會犯以下三個比較常見的錯誤。

1）缺乏系統性

這是在分析中最常見的問題，即很多同學在分析需求時沒有系統性的框架，導致很多方面沒有分析到、考慮到，從而對需求認識不全面。

2）缺乏深度

對需求某些要素認識比較淺，不夠細緻深入，例如在分析需求的用户時，沒有對用户分層、切片，對各個分層的用户也缺乏足夠的瞭解，導致對用户只有一個籠統、模糊的認識，最後自然無法深入進去。

不過分析是否有深度的定義其實很難把握，也缺乏明確的判斷標準，需要隨着分析者思維能力的提升、信息量的提升來加強。

3）忽略順序

在上文列舉分析內容時，其實是有分析順序的，即需要有前面環節的分析結論，才會有後面環節的分析基礎。

當需求分析清楚後，我們就可以針對高優先級的需求設計產品方案了。

三、方案設計與分析1. 方案設計

設計需求方案既可以自力更生、獨自設計，也可以借鑑其他產品同類需求的方案，兩者本沒有好壞對錯、也沒有所謂的創新與抄襲之爭。

產品經理最重要的職責之一，是分析清楚需求後，找出最適合這個需求的滿足方案，而不是糾結這個方案出自何處。

2. 方案對比

任何一個需求的滿足方案都不會只有一種，至於選擇哪一個，則要考慮很多因素，所以我們需要從多維度對比這些方案的投入產出比，以此來儘可能的選出所謂最優解。

評估方案投入相對比較簡單，也容易量化，主要包括時間成本、人力成本、資金成本、機會成本，但方案的產出則難評估得多，一個方案：

最終產出=價值-負面影響

結合這個公式，評估方案產出的難點主要有以下幾個：

1）價值標準難選取

哪個方案帶來的價值更大，取決於我們以什麼標準去衡量它，但這個標準有時候並不好找。

2）部分標準難量化

在選取的評判標準中，有些是無法量化的指標，這些指標所體現的價值就無法客觀判斷。

3）部分標準主觀影響大

對於無法量化的指標，就需要由人主觀判斷，這樣結論就與評判人的主觀想法密切相關了，有時候也會屁股決定腦袋。

4）需要逆向評估

方案大多都是有利有弊的，除了正向評估方案價值，還要逆向評估其所帶來的負面影響。這個方案對某些用户可能是有價值的，對另外一部分用户可能是種打擾。

5）價值、負面影響不確定性大

相比於成本的預估，價值的預估則要困難很多，因為不確定性太大，影響因素更多，且大多沒有可借鑑類比的經驗，説得好聽叫預測，説得不好聽就是“聽天由命”。

所以，所謂的最優解是一個美好的願望，我們真正能做的是在當時條件下，基於自己有限認知做出的自認為最合理的決策。

3. 依賴分析

有些方案看起來很美好，但如果沒有必要條件的支持，那也只能停留在紙面上。

所以我們需要將備選方案的內部、外部依賴條件分析清楚，以判斷這些方案需要哪些支持、誰能提供、提供數據能否滿足要求、提供時間、提供方式等，進而提前做好準備。

以上的對比、分析，並非全由我們獨自完成，而是需要作為牽頭人，找到相關方，如技術負責人、依賴方，合力解決，從而選出一個最終方案來滿足我們的需求。

4. 方案初評

選擇方案後，需要就下個迭代的內容與前後端的技術負責人做初步評審，解決明顯的障礙和問題，節約後面正式評審的時間。

四、需求上線階段1. 方案評審

需求上線前，先要進行我們常説的需求評審，不過從產品經理的視角來看，這個應該叫做產品方案的評審，所謂需求評審，是從開發視角來講的。

在方案評審時，需要做好四件事：原始需求説明、方案講解、方案評估以及工作量評估。

1. 原始需求説明是指向開發團隊介紹經過分析後的需求要素，目的是為了讓開發小哥們更好的理解需求，更有代入感，以免實現歪了；
2. 方案講解即介紹滿足需求的方案，這是開發同學最關心的事情。有時候開發小哥們在理解了需求的情況下，可能會提出更好的方式；
3. 方案評估是從實際開發人員角度評估方案的可行性、風險、成本，在方案設計階段，我們雖然與前後端技術負責人做了初步評審，但粒度比較粗，且評估人不一定是一線開發人員，所以可能有些細節沒有注意到，此時我們就要更深入、全面的進行評估；
4. 工作量的評估是通過量化的方式評估迭代需求總量，有利於開發團隊合理規劃迭代的開發時間。

2. 確定迭代內容

根據需求優先級、需求工作量、迭代容量（開發團隊一個迭代最多可負擔的工作量），我們要把超出迭代容量且優先級較低的需求往後排，以保證已有需求的開發質量。

3. 測試驗收

方案上線前，對應方案的產品經理需要在上線前兩天在測試環境驗收，以保證方案的正確實施。

方案上線後，還需要第一時間在正式環境再次驗證，以確保不會因測試環境與正式環境差異而出現的幺蛾子。

五、需求優化階段

需求方案上線還只是開始，要想知道這個需求是否真正達到了預期效果，發揮出了真正價值，還需要持續跟蹤監測。

通過埋點，統計用户行為，並根據需求預期價值，確定分析指標，通過對比指標實際數據與預期數據，找出差距，探究差距原因，並制定相應優化策略。

以上就是我們日常處理需求的完整流程，上述的每個小環節都可以引申出大量的知識點、方法論，在後續的文章中，我將挑選重點環節進行介紹。

作者：周翔；公眾號：周翔Fly；個人微信：zhouxiangxgg

本文由 @周翔 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議。