編輯導語：在産品設計過程中，了解需求是産品落地的基礎之一，而在B端産品中，需求可能會涉及到業務需求、用戶需求及管理需求三個方面，具體該如何保障B端需求的快速洞察、快速實現呢？不妨看看作者的總結和梳理。

一、需求的定義

需求是産品存在的基礎，貫穿整個産品的整個生命周期。本文聊聊需求的管理方法論。需求管理方法論概念包含了，需求調研和挖掘、需求分析、需求管理（輸出需求文檔），也可以用一句話來說明，就是收集客戶想要什麼，最終确定實際做什麼。

本文會涉及到面試過程中問到的需求相關内容，可以先收藏後細品。

二、B端需求的分類

在我看來，B端需求主要分為業務需求、用戶需求和管理需求。

• 業務需求，就是B端行業的業務流程中産生的需求，業務流程是行業知識體系的一部分。
• 管理需求，在B端行業為實現業務目标而進行的決策、計劃、控制等的過程産生的需求。
• 用戶需求，用戶在系統使用過程中産生的其他需求。

在下文中會用這三類需求進行詳細說明。

三、需求的調研和挖掘，需求收集

1）調研的8大科學方法已經前面寫過，這邊介紹一下調研時的幾個小技巧。

① 用圖形作為調研助手

用圖形會引導大家的讨論方向一緻，收斂，不易跑題。圖形會引起參與者的視覺共鳴，從而加速、加深理解的程度。圖形的邏輯清晰，可以避免讨論結果似是而非的現象，為後續需求變動提供證據（甩鍋）。

② 找到調研的合适顆粒度

對于顆粒度的把握，是沒有一個定數，但如果調研結束後，不需要再向客戶進行咨詢就可以進行設計工作了，那麼這個調研就做到位了。第一次調研現場，顆粒度盡量越細越好，因為後續的調研會增加更多成本。

2）業務流程優化的一個方法-ESEIA方法ESEIA流程優化方法是由五個首字母組成，包括E（Eliminate）清除、S（Simplify）簡化、E（Establish）增加、I（Integrate）整合和A（Automate）自動化，用來減少流程中的非增值活動，增加流程中的增值活動，然後進行整合和自動化，如圖所示。

• E：清除，找出并清除不增值的活動；
• S：簡化，清除不必要的活動後，對必要的活動進行簡化；
• E：增加，根據需要增加增值的活動；
• I：整合，對簡化後的活動進行整合，使流程連貫；
• A：自動化，充分利用信息技術自動化功能，提高流程處理速度和質量。

案例：藍湖SaaS，是一款針對産品設計到開發階段的流程優化工具，從産品原型設計——原型上傳——UI設計師打開——根據原型設計——設計稿切圖——打包上傳——程序員下載——打開設計稿并查找相應切圖——開發時不定時查詢，一系列流程中找到可清除的不增值的活動，簡化相應活動，增加增值的活動（在線編輯和設計），整合後使流程連貫，數據上雲，讓整個上傳下載自動化，提高流程處理速度和質量。

四、篩選，如何對需求的判斷

1. 擺正需求方的位置

需求的來源會有各種不同的渠道，有内部同事、領導、自己産生的需求。也有外部市場、用戶、競品分析、行業規範等産生的需求。我們需要先把他們産生的需求分類，擺正位置，才能對症下藥。不管是哪個渠道來的需求，在上文有說到，可分為三類，業務需求、管理需求、用戶需求。業務需求和管理需求分别來自于業務流程優化和管理流程方面，如圖（房産營銷部分業務流程）。

1）業務需求，那需要從直接相關方和上下遊的間接相關方來看，比如房産營銷中的客戶鎖定期和解鎖期，就會可能影響到銷售、财務、采購、管理者等各個相關方，需要每個相關方都接觸了解後才能設計。

2）管理需求，主要在上層管理的需求，一般隻需要針對相關領導的需求就行，但需要知道需求方真實的需求，和該需求是否能夠實現。由于管理流程是附加于業務流程之上的，所以如果業務流程沒有能夠産生這個管理需求的能力，那就需要從業務流程中去重新審視這個管理需求的真實性和可行性。

3）用戶需求，這個就比較簡單了，主要就是使用習慣，交互等事宜。可以從同一層級的直接相關方了解後進行分析。

2. 判斷真實的需求

1）方法一：邏輯演繹

當産品經理不清楚客戶的業務但又感到有問題時，可以用邏輯推演來判斷，通過邏輯推演可判斷客戶的需求是不是合理的、正确的。

例如：為什麼需要做這個功能？缺少這個功能會如何？這個功能與其上遊的工作流的關系，與下遊的工作流的關系？思考新需求對現有業務邏輯的影響，會不會影響現有業務功能，當然也同樣要考慮到一些潛在的影響，這同樣是你對需求評估的一個重要标準。

2）多維度觀察

産品經理與客戶在專業知識方面是不對等的，客戶并不知道他提的需求将來在系統中會帶來什麼後果，産品經理也未必聽懂了客戶的真實需求，因此對客戶提的“表面需求”要經過側面的判斷才能确定為“真實需求”。為了解決這個問題，可以參考使用5W1H分析法幫助做好判斷工作：

• 對象（what）：什麼事情。
• 場所（where）：什麼地點&場景。
• 時間（when）：什麼時候、順序。
• 人員（who）：相關方、責任人。
• 為什麼（why）：原因。
• 方式（how）：如何。

在需求調研中使用5W1H方法，首先要理解的是What、How，而作為判斷的重要依據的是Why，其他Where、When、Who是附屬信息，沒有經驗的産品經理隻會從正面進行調研，即詢問“做什麼”“怎麼做”，但是最為重要的“為什麼做（Why）”卻往往不問，這樣就會失去多維度觀察需求的機會，也同時失去了識别需求的虛實的機會。

3）價值判斷

對于複雜的、規模較大的需求，用簡單的、操作層面的能夠做評估的依據難以确定是否是真實的需求，可以用“目的、價值和功能”三要素來分析和判斷。目标，客戶的需求目标是什麼？價值，确認該目标達成後，客戶可以獲得什麼價值？功能，做什麼功能可支持該價值的實現？

如果針對某個需求的判斷符合下述條件，那麼它就可能不是真實的需求。

• 确定不了這個需求的目标是什麼？
• 雖然知道目标，但是看不出目标達成後會給客戶帶來什麼價值（回報）。
• 提出的功能需求實現後，并不能給客戶帶來預期的價值等。

五、搭建需求池&需求的優先級

從各個渠道來的需求，經過上述的分析後，可以放入到需求池中。需求池裡的需求主要有：

1. 真實的需求，還未進行過價值評估；
2. 可能轉化為需求的一些思考、想法、靈感。也可能是從競品那分析所得。

過濾了一些僞需求，通過挖掘知道了用戶的真實目的，确定了需求方意願度，明确了需求價值點，根據需求價值來提供解決方案，整理出了需求池，接下來就是對需求的優先級排序：

1）從需求分類的層級來排序，在B端産品中，因為業務需求是所有需求的底層，所有業務需求是第一位的，然後才是管理需求，最後才是用戶需求。這就是為什麼很多B端産品不講究交互設計，而在業務流程上做了很大的投入。

2）可以從兩個緯度四個象限進行劃分，一個是緊急程度，一個是重要程度。按照優先級劃分為重要緊急、不重要緊急、重要不緊急、不重要不緊急。

如果産品在0-1階段，那根據KANO模型的基本型需求>期望型需求>興奮型需求來判斷，如果産品在1-N的叠代期，根據，産品價值大實現成本低>産品價值大實現成本高>産品價值小實現成本低>産品價值小實現成本高來判斷（圖來自網絡）。

六、需求文檔的輸出

功能需求整理輸出産品方案，做需求文檔輸出時，為了全面考慮産品方案的邏輯完整性和流程的完整性，可用以下三個點來自查自檢。

1. 功能觸發的前提

1）前置條件：觸發該流程的前提條件，如領取優惠券的前置條件為“注冊且登錄賬号”，甚至還有其他比如是否是新用戶等等。

2）數據來源：流程中數據來源，如審核功能中：審核人員審批下級發起的審核單。審核人員的操作流程中，下部發起審核産生審批單就是審核人員的操作流程中的數據來源；數據來源通常是在發生數據流轉的場景下需要進行說明。

3）角色及權限：即用戶在系統中承擔的作用的抽象，是否已經把功能抽象到權限中去，這樣可針對權限的設置來分配某些角色可以用，某些角色不可以用。

2. 操作流程

1）事件：主要是指功能的交互規則及邏輯判斷。

這個模塊用來說明用戶和系統之間發生的交互。交互規則是泛指的交互規則，包含功能的頁面布局、觸發功能的動作及觸發後的交互效果；邏輯判斷則是指當用戶在前端發生行為，系統對用戶行為進行識别、判斷并返回相應的動作的過程。

2）觸發反饋：指用戶與系統完成交互後，用戶和系統會得到什麼樣的反饋及産生什麼樣的數據和結果。

3）異常處理：是對主流程補充，我們盡可能全的羅列并寫清楚異常流程時，可以有效避免在産品設計時的場景遺漏。異常流程的梳理建議是參考測試同事的正反例原則。

3. 通用說明

1）數據埋點：埋點就不多進行贅述，但不管是采用第三方系統還是自己的埋點體系，都要做好數據分類，後續提取數據時能減少很多功夫。

2）數據需求：主要為業務方和産品經理在使用和運營提供決策依據，在設計産品方案時一定要規劃相對的監控數據指标，以便于後續運營和叠代時有數據進行支撐。

3）數據字典：不要出現這個數據在這是姓名，到另外一個頁面成為了用戶名這樣的事情。以上，是我對B端産品（項目）的理解，後續會對業務需求、管理需求、用戶需求分别分析一下。

本文由 @pm老潘 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議

,

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

查看全部