作者從實際工作經驗出發，結合具體案例。分享了對B端定制化產品的需求進進行分析歸納的方法，供大家一起參考和學習。

寫本篇文章的目的：第一個目的是作者即將步入第一個三年，對以往的工作進行總結，準備進階突破；第二個目的就是與大家分享與討論。

我目前的工作有些像外包產品經理，給公司做一些定制化的B端產品。下面針對B端定制化產品的需求進行分析和歸納。

一、定制化B端產品的需求分類

首先我們先了解一下什么人會對產品提出需求：

第一種是直接負責這個項目的甲方負責人，他們一般會對產品整體有個需求概況，他們雖然是負責人，但并不一定有多了解具體業務；

第二種是管理人員，他們是直接對業務負責的管理人員，這類人員一般會提出一些偏管理的需求，他們更加注重如何通過一個工具系統性的去管理好這個團隊；

第三種屬于公司中高層，他們關心的是宏觀的數據希望能夠從大量數據中看到公司未來的走向，所以這類人更加會提出一些數據分析的需求，如駕駛艙；

最后一種是產品的直接使用者，或者說是使用頻次最高的人員，這類人員是業務的主要執行者，他們更關心其業務是否全面覆蓋，操作是否簡單等需求。

所以我總結B端定制化產品的需求一般分為四類：分析類需求、管理類需求、業務類需求、操作類需求。我們將需求分類之后，就能對癥下藥，找到需求的根本面目。

二、如何分析需求？

B端產品體術需求最頻繁的一類人群就是使用頻率最高的，涉及模塊最廣的業務人員，此類人員需要在系統中完成日常的工作，稍微遇到一些不好用或者操作操作繁瑣的功能，都會讓他們感到煩躁。他們一般會這樣提需求：“我要在XX頁面增加一個XX功能”“這個頁面太不好用了，XX功能用起來太麻煩了，能不能簡化一下”。

第一種需求屬于自認為我很了解這個系統了，我可以直接為產品設計需求，你只要照做就行了；但我要告訴你的是，如果你照做了，那么這個需求90%會進行變更，因為他根本不知道他要的是個什么樣的需求，這樣做出來之后他才意識到自己要的根本不是這樣的功能。面對這類人，我一般會問這幾個問題：這個需求能幫你解決什么問題？為什么會有這個想法？換一種形式可不可以？

舉個例子：在給某個公司的采購部門做系統的時候，他們有一個獨立的統計室來統計應付賬款，有個統計員和我說，我要把入賬列表改成默認展示當天入賬日期的入賬單；很顯然這個需求不是很合理，我問他我說為什么要這么做，他說你就改就行了，現在這樣很不方便。那我和他說，你問問其他同事愿意這么改嗎，如果你們都有這個需求那我可以考慮，然而最終結果是很大一部分不能接受這么改，我又問他我說你為什么要這么改，他和我說了，他想看今天入賬的供應商和總額，其他統計員也有相應的需求。

原來想看今日入賬的供應商和金額才是他最終的目的。需求明確之后我們完全可以有N個方式去滿足他，但絕對不是用他的這種形式，最后我們都很愉快的解決了這個問題。

第二種則屬于目的性強的選手，他不管你怎么去簡化這個流程，只是覺得這個流程太復雜，操作起來一點都不方便，最好有一個按鈕，一點這個按鈕系統就能把他所有的事情都做完才好。這類需求處理不好，他會一直吐槽你的產品不好用，嚴重的會對產品造成很不利的影響。

提出這類需求的人有兩種：第一種是對之前的操作流程固化了，不想去花時間學習新的流程（盡管你的流程很標準）。面對這類人，我建議直接告訴他設計如此，如果需要修改流程，可以找項目負責人或者你的領導，同意后可以修改。不要試圖和他解釋什么，要和他的領導去解釋這個流程有多標準。

第二種人屬于幫助你改善產品中不合理的地方，面對這類人， 要仔細和他溝通細節，讓他說明那些地方用起來不順手，然后詢問他有什么好的建議和想法嗎，記下但不要照做，回去后好好梳理現有流程和他提出的建議，如果覺得確實有改的必要，務必想好所有關聯性流程后進行修改。

例如我在給采購部門做線上詢價時，一個業務員對我說，每次我做詢價的時候需要在采購單頁面確認好我要詢價的物料，然后再去詢價頁面增加一個詢價函，這樣操作太繁瑣了，能不能直接在采購單頁面直接詢價呢。他這個想法不錯，但是采購單頁面的單據是主從表的關系，不能在這個頁面加詢價功能，這就是蘇杰老師提起的，認真聽但不要照著做。最后我用一種方式完美解決了這個問題。

另外這類使用者還會提出一些系統上沒有涉及到的業務，這類業務可能是他們公司特有的業務，再權衡利弊后可視情況選擇做與不做。大致可以從資金、開發難度以及業務占比等方面進行考慮。

例如我在做某個公司的檢化驗系統，一個化驗員對我說，對于新物料的檢驗不應該由我們部門發起，因為我們不知道什么時候來新物料，供應商把物料送到公司時，會第一時間到庫房去提交到貨單，所以應該由庫房接收到貨單的同時發起對物料的化驗請求。

以上我列舉了操作類需求和業務類需求如何去分析，接下來介紹管理類需求如何去做，因為分析類需求不屬于我的專業，所以我不能給你們提供更好的建議。

以上我們說到了管理人員一般會根據他所管理的職能去提一些管理類的需求，這類需求是很有意思的，管理類需求做的好，可以把你的產品提升一個很高的等級，使你的產品在同類產品中脫穎而出。

管理類需求思考的出發點和操作類、業務類是不同的，需要你站在管理者的角度去考慮問題，但有一點是不變的，就是目的。管理者提這個需求一定是想達到某個管理的目的，記住在管理者眼中，系統就是個管理工具，他希望系統能幫助他去約束員工，為他提供管理數據，所以管理者提出的需求一般圍繞這兩點展開。

還是以上述采購部門的例子舉例，他們的采購部長找我說，希望我能做一個采購計劃的限制，每個月只能申報兩次采購計劃，分別在月初和月末，我說為什么啊，這個直接讓你手下就能辦到啊，告訴你的小弟讓他們限制申報部門不就完事了。他說他的小弟由于各種原因會不好意思拒絕申報部門的計劃，這樣我就很煩惱，我希望通過系統去做這件事。然后我就答應他了，但是我給他留了個最高權限，因為真的有申報部門有極特殊情況下，不能不給人家報不是，但是這次你面對的是采購部長，如果沒有正當理由，那你就想想怎么混過去吧，這樣就形成了一個閉環管理。

當然管理者的需求也不是不可以拒絕的，這個采購經理跟我提另一個需求的時候我就給拒絕了，他說采購員經常把計劃處理了，但是他并不在系統上做完成標記，希望我能做一個彈窗提醒，每隔一段時間就去提醒他一次，我告訴他在其他公司不是沒有這么做過，但是沒有效果，業采購員會直接關閉這個窗口。建議你把這個計劃處理效率放到采購員的KPI中，對他有了直接利益加持就有了動力。然后沒過多久他又找我做了一個采購員KPI的模塊，因為這招太好用了。

三、總結

我們在做需求分析時，首先要給需求歸類，然后再想想自己面對的是什么樣的人，他基于什么目的提出的需求，然后根據這個目的對癥下藥才能達到需求人想要的目的。

以上的分類是我自己用著最熟練的分類，但不一定適合你們，我在這里講的是方法，不是讓你們照著做，你要根據我的想法找到適合你自己的分析方法才是最重要的。

本文由 @墨紫衣 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議