起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求價值量化及優先級排序方法
編輯導語：需求處理能力是考察產品經理核心能力的重要指標之一，本文作者分享了有關需求管理的主要痛點問題、傳統需求管理方法論及其問題、需求量化方法以及相關建議，一起來學習一下，希望對你有幫助。
需求處理能力產品經理的核心能力模型的重要維度之一，作為產品經理每天要處理各種各樣的需求，如果說需求分析聚焦的是單個業務或單個功能的挖掘轉化，那么需求管理則更能體現一個PM運籌帷幄、有條不紊的大局觀和節奏感，既能業務滿意，也能研發認可，自己也不至于每天忙成小陀螺。
一、需求管理的主要痛點問題
需求源源不斷，資源是一直緊缺的。我經歷過的互聯網企業，都是需求等人，沒見過人等需求的。一旦出現人等需求的情況，那只能說崗位設置冗余，就可以考慮優化了。在此背景下，如何把好鋼用在刀刃上，就愈發重要。
1. 手心手背都是肉，先做誰的需求
需求多研發資源少的情況下，需求管理首先要解決就是需求優先級順序的問題，對口的業務多，每個人都說自己很重要，先做沒意見，后做都不滿意。
按照合作關系遠近親疏，還是按照提需求的時間，誰先提做誰的？對于產品、研發團隊的管理者，不同產品經理、不同產品模塊的需求放到一起搶占研發資源，該怎么安排，“會哭的孩子有奶吃”嗎？手心手背都是肉啊。最終績效考核的時候，總不能按照上線的需求數量來評判ABCD吧。
2. 臨時的、緊急的需求，該如何協調
不管是產品還是研發都不喜歡被插入需求，排隊就醫、買票，插隊的人總是讓人心生厭煩。
但臨時的需求、一些因為政策、戰略等緊急的需求又在所難免，不能每次來緊急需求都要求開發加人，或者周末加班吧？
當這些插入需求來了的時候，又該如何協調各方，達成一個“一團和氣”的局面呢？
3. 需求積壓很多，規劃卻不知從何下手
新人產品經理往往容易被堆積如山的需求搞得手忙腳亂，需求池里躺著上百個需求，做產品規劃時卻無從下手。
感覺每個都應該做，資源受限，卻好像哪個都可以不做。怎樣才能挑出大的西瓜，而不至于被一粒?！爸ヂ椤泵杀瘟穗p眼。
4. 產研團隊忙而無果，每天加班做需求卻沒成就感
研發人員像機器一樣，持續不斷地輸入需求，變現需求。但卻沒有成就感，甚至覺得自己就是個變現工具人。
二、傳統需求管理方法論及其問題
從“人人都是產品經理”開始，就有了各種各樣的需求管理的方法論。在過去10多年的產品工作及團隊管理工作中，發現很多方法論也就停留在方法論層面，實際操作時，還需要個人的“悟性”，悟性差的可能整個職業生涯中，都難以掌握到底什么樣的需求才算是重要且緊急的需求。
1. 四象限分析法判斷需求優先級
每個人都知道應該優先去做重要且緊急的需求，但問題是作為新人產品經理，重要程度和緊急程度的判斷依據是什么？每個人都說自己的需求非常重要，并且想越快上線越好。
2. Kano模型分析劃分需求類型
Kano模型按照用戶對于需求的期望程度劃分為基本需求、期望需求、興奮需求等五種類別，實際操作時，該怎樣客觀地描述不同用戶對于需求的期望程度？
3. ICE排序法定量確定需求優先級
ICE排序法按照需求影響范圍、完成需求的自信程度以及開發實現難易三個維度進行需求量化評分，最終按照得分值高低，確定需求優先級排序順序。
對于體驗優化類或者流程提效類的產品，用戶影響范圍的權重一樣是否合理呢？比如老板用的管理駕駛艙產品，就三五個高層使用，他的價值就不高了嗎？
三、需求價值量化方法實操
結合各方對于需求優先級排序的訴求以及現有需求分析模型存在的問題，結合數據產品的特點總結出一套用于量化數據產品需求價值的方法，可以為你提供一些新的思路和啟發。其核心思想：
- 量化：不同產品、不同類型需求最終按照相同的分數度量體系，按照得分進行價值排序；
- 分類：不同數據產品或同一產品的不同需求，總結下來主要分為體驗優化類、流程提效類、業務增收類幾個大的類別；
- 權重：不同類別的需求在量化維度上的權重理應不同，比如業務增收類的需求，更應該看重帶來的業務營收價值，相應的權重設置更高，在降本增效維度權重可以適當調低；
- 打分：每個維度按照產品的實際情況，進行打分區間的設置，例如采用10分制，用戶影響度，全部用戶，10分，60%以上8分，30%以下4分，以此類推。
1. 用戶影響度
任何產品需求都是為了解決用戶問題，所以需求涉及的用戶范圍是一個重要的評價維度，但這里需要細化不同類別的需求，比如做一個CDP精細化運營產品，主要的用戶就是運營部、營銷部的幾個人，即使每天都會使用，但是DAU終歸就那幾個人。對于用戶體驗類的需求該維度權重可以設置30%-50%，而流程提效類15%~25%，業務增收類的權重可以適當降低。
2. 戰略契合度
外部環境政策的變化或者公司新戰略的推行，產品迭代時，也要考慮這個維度。如果只是閉門造車，按照已有的優先級嚴防死守，那對于公司的影響可能是致命的，比如《數據安全法》《個人信息保護法》施行后，應對安全合規檢查的功能需求，會影響產品甚至公司的生死存亡。
此外，對于老板的需求第一時間去做或者不予重視都不可取，把戰略契合度加到評估維度中，則可以有效應對這一類需求。戰略契合度各類需求的權重設置控制在15以下。
3. 業務期望度
這一維度主要用于衡量用戶對于這一產品功能的期待程度，不做用戶感受是怎樣的，做了用戶是不是對產品滿意度大大提升。這一維度的評分區間劃分可以基于Kano模型進行，基礎需求10分，期望需求8分等
4. 效能提升
對于B端數據產品，多數還是幫助業務提升數據決策和應用的效率，通過產品功能的迭代，到底可以帶來多少降本增效的價值。
比如基于標簽的人群自動化圈選功能，沒有上線這個功能時，單個營銷場景耗時3小時（SQL取數、數據上傳等），每周至少2個場景應用，功能上線后業務自助圈選，30分鐘搞定，那么帶來的提效價值就是單次操作節約時長×操作頻次×統計周期，按照節約的時間成本換算成人力成本，按照價值區間進行得分。流程提效類需求，該維度權重適當增加。
5. 業務收益
數據賦能類的需求，比如算法推薦接口、API接口，其目標是基于數據為產品提供更加智能化的應用，按照接口調用量或者用戶請求UV去看，都不合理，而按照對應服務可以帶來的實際業務增量，換算成“錢”再去看，就更加合適。比如按照不同功能類別，劃分營收或訂單增量這一維度的得分區間。
6. 實現成本
從時間成本和人力成本兩個方面，如果用前面五個維度的正向得分除以成本，區間劃分時，成本越大，最終得到的結果就越小，總分值就越低。
成本兩個維度主要是輔助參考，這個具體操作時，需要不需要把成本作為分母，可以根據實際需求定，因為一旦相除，可能就意味著得分降低，價值度高但是開發耗時長資源投入多的需求就一直沒法做了。
把不同類型的需求在以上幾個維度的權重設定好，并且每個維度下的得分區間定義好后，用得分乘以權重，維度得分加和就可以得到每個需求的價值度得分，這樣不管是單個產品線還是不同PM的需求放到一起，都是相同的評分體系，涉及資源搶占和優先級判斷時，就更加有理有據。沒人？那就有多少人干多少事，挑最重要的做。初期操作時，可以用excel的公式設定自動化的得分計算。
四、需求價值量化實施建議
需求價值量化方法實施時，有一些點需要關注，也算是過去操作過程中的一些實操建議
1. 一定要結合產品實際情況進行吸收和轉化
在權重設置、每個維度的得分區間劃分時，要結合產品實際情況建立符合實際的標準，不能直接拿來主義。
2. 需求方、產品、研發形成需求價值量化的統一認知
需求價值量化需要業務方配合，通過宣講、需求流程優化等方式，讓各方對價值量化的意義有更加清楚的認知，而不是為了拒絕需求或者增加提需難度，作為產品經理把需要業務側提供的指標具象化，避免直接讓業務去操作需求量化的結果。
3. 量化計算過程自動化
如果對于每個需求都需要人肉計算得分，勢必會影響工作效率，當相關的權重、維度、得分區間溝通確認固定下來后，可以整合到需求管理系統，用戶提交需求加上產品經理審核、處理需求時，完成對應的得分賦值，系統自動化計算最終的得分，在一個需求池列表中，確定優先級順序。
五、總結
需求管理的好不僅是自身產品能力的體現，對于協同團隊也會認為你是一個靠譜的人。需求先做哪個后做哪個，建立一個清晰、明確的價值量化標準，優先做對的，有價值的需求，這樣才能在人力不夠的情況下有更高人效的產出。結合文中提到的需求價值量化的思路，看看如何與當前的需求管理工作結合起來吧。
#專欄作家#
數據干飯人，微信號公眾號：數據干飯人，人人都是產品經理專欄作家。專注數據中臺產品領域，覆蓋開發套件，數據資產與數據治理，BI與數據可視化，精準營銷平臺等數據產品。擅長大數據解決方案規劃與產品方案設計。
本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
怎么自動化，量表里面有些項是高管打分，是產品經理直接幫高管打分嗎
這個表格如何計算與搭建，跪求
需求管理的好不僅是自身產品能力的體現，對于協同團隊也會認為你是一個靠譜的人。