Ｂ端產品如何做好需求管理？
作為一個產品經(jīng)理，
從開始接手產品工作的那一刻起，就在和各種各樣的需求打交道。
打交道的過程中會遇到如下各種問題：
1.需求應該要從哪里去收集？
2.各種渠道，各個相關角色會反饋給你一堆需求，這時應該如何去落地？
3.當需求越來越多時，需要一個需求庫來進行相關需求的管理，這時需求庫如何做，需求庫里應該要包含哪些要素會比較好？
4.接到的需求到底該不該做，什么時間做，應該如何去判斷？
5.等等。
這一系列的問題，
通過做好需求管理的一套方法，將會一一得到解決。
這一套方法是什么？
我將從以下3點展開來講：
1.需求全生命周期管理；
2.需求庫管理；
3.需求取舍、優(yōu)先級判斷原則。
01
需求全生命周期管理
關于“需求”相關的問題，
我們首先要建立一個基本的認知，那就是：
需求全生命周期管理。
需求不是一個零碎、單一環(huán)節(jié)的存在，它有相應的一套完整管理過程。
這一套完整的全生命周期管理，大概可以分為以下6個關鍵點：
1.需求收集；
2.需求分析；
3.需求確定；
4.需求評審；
5.需求推進；
6.需求變更。
以上6個關鍵點，這里我將一一拆開來詳細講講。
第一個關鍵點，需求收集。
需求管理的第一步就是收集需求，沒有收集到需求，何來后面的全生命周期管理。
收集需求的方法有很多，
比如：
1.可以通過用戶訪談的形式收集需求；
2.可以通過用戶調查的方式收集需求；
3.可以通過深入一線，觀察、學習的方式收集需求；
4.可以通過會議溝通的方式來收集需求；
5.可以通過競品分析的方式來收集需求；
6.等等。
關于收集需求具體更詳細的理解，可以參考我之前的一篇文章：
第二個關鍵點，需求分析。
通過第一階段收集到的需求，可能會來自于不同部門、不同角色、不同顆粒度且零散的需求。這時就需要對需求進行分析。
需求分析的目的就是業(yè)務分析，也就是：
選擇一種以業(yè)務為導向的方式將零散的、不同顆粒度的需求串起來，形成一個完整的、內容清晰的框架，指導后續(xù)相關的產品設計 、產品開發(fā)工作。
做需求分析時，我們可以用業(yè)務流程圖，業(yè)務場景，領域建模，狀態(tài)圖等思考模型來進行需求分析。
具體如何用這些模型來做需求分析，可以參考我之前寫過的兩篇文章：
第三個關鍵點，需求確定。
對分析完成的需求，接下來就要和需求發(fā)起者進行確定，這是不是他們想要的需求。
第四個關鍵點，需求評審。
需求確定以后，接下來需要與技術團隊評審需求，需要開發(fā)的周期、投入的人力需要多少進行溝通。
第五個關鍵點，需求推進。
對已經(jīng)完成確定、完成評審的需求，需要進一步往下進行原型設計、UI設計、技術開發(fā)等工作的推進。
如何推進？
需求推進的過程中有哪些關鍵點需要注意，可以參考我之前的一篇文章：
第六個關鍵點，需求變更。
已評審完成的需求，在往后推進落地的過程中，可能會遇到需求變化的情況。
可能是業(yè)務方提出的需求變化，
也可能是技術在開發(fā)過程中遇到了技術挑戰(zhàn)，提出了需求變更的請求。
這時通過再次溝通、評估新的產品方案、評估新的技術方案，選擇合適方案，往下進行需求落地的推進。
從需求收集到需求變更是一個完整、閉環(huán)的需求管理過程。
只有認清需求管理的全生命周期，才能管理好全生命周期中動態(tài)的變化，管理好每一個“需求管理”的節(jié)點。
02
需求庫管理
一家初創(chuàng)的企業(yè)級Saas公司，
或者是一家傳統(tǒng)企業(yè)開始開發(fā)軟件來解決企業(yè)數(shù)字化轉型問題的公司，
剛開始需求沒有多少，收集到的需求可能找個文檔簡單記錄一下需求就可以。
隨著業(yè)務的發(fā)展，需求越來越多，
面對龐大的需求，這時就需要找一個合適的工具來進行需求管理。
這個工具叫做“需求庫”，也有人把它稱為“需求池”。
通過需求庫的使用，
可以把需求按照標準的方式匯集在一起，方便后面對需求的統(tǒng)一管理（可以在需求庫里增加需求、修改需求、查看需求，對需求進行歸類、優(yōu)先級排序等等）。
需求庫里包含的要素主要有5大類：
1.需求，包括
需求描述，提出人，提出職級，提出時間。
2.優(yōu)先級
P0,P1,P2。
3.評估
產品可行性、技術可行性、投入資源、開發(fā)周期預估。
4.狀態(tài)
需求確認、需求評審、產品設計、技術設計、技術開發(fā)、測試、部署上線。
5.變更情況
變更提出人、是否有技術瓶頸、產品方案是否變更，技術方案是否變更。
知道需求庫里需要哪些要素之后，接下來，就要進行需求庫的繪制，
需求庫的繪制，可以使用Excel表格或者石墨文檔來完成。
03
需求取舍、優(yōu)先級判斷原則
文章一開始，我就提到，
日常工作中，各種渠道，各個相關角色會反饋給產品經(jīng)理一堆需求。
面對一堆需求，需求該不該做，需求的優(yōu)先級該怎么去排列，
這時，就我們就需要有一些方法或者是原則來支撐我們對需求取舍、需求優(yōu)先級判斷。
先聊第一個問題，需求取舍。
需求到底該不該做？
根據(jù)我的經(jīng)驗來看，可以有幾個標準來綜合判斷：
1.戰(zhàn)略方針
也可以叫產品的價值主張，知道了產品的價值主張，就能大概的知道產品的邊界在哪？
屬于價值主張范圍內的需求，可以考慮做；不屬于價值主張范圍內的需求，則不應該做。
2.用戶價值、商業(yè)價值組合思考
如果需求對用戶價值，對公司也有商業(yè)價值，那就該做；
如果對用戶有價值，對公司沒有商業(yè)價值，那也可以考慮做，可能需求優(yōu)先級就要排在后面；
如果對用戶沒有價值，不管對公司是否有商業(yè)價值，都不應該做。
3.若無必要，則不需要過度設計
我們開發(fā)軟件是為了支持業(yè)務的需要，支持業(yè)務需要時可以是線上+線下來完成，如果是及其低頻、線下處理比線上處理還要方便的業(yè)務需求，這時可以化繁為簡，沒必要線上來做。
接著聊第二個問題，需求優(yōu)先級排序。
首先，對需求類型進行分類，我對所有的Ｂ端需求分為3大類:
1.業(yè)務閉環(huán)型需求；
2.便利性需求；
3.個性化需求。
這3類需求，
第一個最重要，排第一；
第二個，第二重要，排第二；
第三個，第三重要，排第三。
我之前在哈佛商業(yè)評論期刊上看到一篇文章，具體文章標題我已經(jīng)忘了，文章中給出了Ｂ端企業(yè)顧客需求的幾個維度，如下圖：
這張圖里面的基本價值和功能價值就是我說的業(yè)務閉環(huán)型需求；
便利價值就是我說的便利性需求；
個性價值和理想性價值就是我說的個性化需求。
這里我舉個實際的例子，
比如，小明是某個給景區(qū)提供營銷推廣、SCRM的Saas服務商的一個產品經(jīng)理，這家公司是一家初創(chuàng)企業(yè)，在做門票系統(tǒng)時，有以下幾個需求：
1.添加門票
2.編輯門票
3.查看門票
4.刪除門票
5.分組批量管理門票
6.面向用戶的詳情頁，需要有多種樣式可以選擇
這6個需求中的1、2、3、4對應著我上面講的閉環(huán)型需求，優(yōu)先級是排第一的；
第5個需求對應著我上面提出的便利性需求，優(yōu)先級排第二；
第6個需求對應著我上面提出的個性化需求，優(yōu)先級排第三。
這三類需求中，
不同類別中，也會存在很多需求，如何進行前后排列？
可以從以下幾個維度來綜合考慮：
1.需求強烈程度；
2.功能的使用頻次；
3.實現(xiàn)成本；
4.團隊情況；
5.企業(yè)生命周期階段。
這里還是接著舉例，
比如，
文章中提到的，給景區(qū)提供營銷推廣、SCRM的Saas系統(tǒng)，其中有一個需求是：
掃碼授權系統(tǒng)可以和景區(qū)服務號綁定，這個需求首先肯定屬于閉環(huán)型需求，排在第一位的，沒有這個需求功能，產品閉環(huán)不了。
在第一個類別中，這個需求優(yōu)先級應該如何排列呢？
我們來綜合考慮一下：
1.需求強烈程度，程度是比較高的；
2.功能的使用頻次，頻次是比較低的，一次授權，終身使用；
3.實現(xiàn)成本，產品設計、技術開發(fā)上比較耗時；
4.團隊情況，初創(chuàng)團隊，產品、技術人員較少；
5.企業(yè)生命周期階段，屬于初期，主要要進行產品價值的驗證階段。
綜合評估完，短期來講，每增加一個景區(qū)，技術手動操作，授權服務號綁定系統(tǒng)（這個比較簡單，耗時較?。?，只要能解決系統(tǒng)綁定服務號問題就行，不一定要完整的解決方案。
完整的解決方案排在后期再去做，
因此這個需求的優(yōu)先級是排在后面的。
以上講了一些方法來支撐我們對需求取舍、需求優(yōu)先級判斷，
不過老實來講，需求優(yōu)先級判斷這事其實是沒有標準答案的，
沒有一種方法可以將需求劃分到足夠小的顆粒度來進行需求優(yōu)先級判斷，只要能夠大概的區(qū)分出來就好。
最后，
關于Ｂ端產品如何做好需求管理的問題就講到這里了。
愿你有所收獲，知道如何動態(tài)、系統(tǒng)的管理需求。