本文由作者?楊堃?發布于社區

需求挖掘和分析是產品設計中挑戰最大的工作之一，如何洞察需求的本質，識別出真實的意圖，并通過優雅的產品設計，解決需求背后的痛點，是所有產品經理都應該持續提升的核心能力。

需求分析的偏差和錯誤，不僅會浪費寶貴的研發資源，在錯誤的功能上投入精力和代價，更加會給業務帶來損傷和傷害，甚至導致錯失市場時機。

本章，我們將聊一聊B端產品的需求分析工作，包括如何基于場景洞察需求本質，如何利用UML進行復雜需求的抽象設計。

舉例：一次并不成功的的需求分析?

關于需求分析失敗的經歷，果凍有著切身的刻骨體會。在剛畢業沒多久時，果凍負責一款企業自研，給電銷團隊銷售人員使用的銷售型CRM產品設計，主管會將一些比較簡單的需求和設計任務交給果凍。

有一次，電銷部門銷售運營部的小姐姐豌豆找打了果凍，提了一個需求。

豌豆：“果凍果凍，又來麻煩你了，給你提個新需求！”

果凍：“好呀好呀，一起聊聊！”

豌豆（對著系統邊說邊比劃）：“咱們現在的CRM系統，不是會有消息提醒么，里邊會有很多提示，比如說如果線索還有1天就要掉庫，就會在消息中心彈一條消息，比如說你看現在這個，就是有三條未讀消息，其中第一條就是掉庫提醒。”

目前消息中心的樣子

果凍（不好意思的撓了撓頭）：“呃，這個，是，小姐姐，我想請教下，掉庫是啥意思啊？”

豌豆：“哦對了，你剛接手這塊工作，還不太了解業務。在我們銷售管理業務中，如果給銷售分配的銷售線索，銷售7天沒跟進，或者14天沒成單，這條線索就要強制被收回到公共資源池中，由其他銷售撈取跟進，這個就叫掉庫。”

果凍：“明白啦，小姐姐就是厲害，一說就透！咱們這次需求是什么呢？”

豌豆：“是這樣的，目前線索的掉庫提醒是提前一天，銷售同學看到后很容易就忘了，大家找我反饋說希望提醒能夠更及時一些，比如說掉庫前一小時再提醒一次；我想一小時哪兒夠啊，還得忘，前1小時和前10分鐘，得提醒兩次，這樣大家就不會忘記處理了。”

果凍聽完后心中有一些疑惑，提醒了就能及時處理么，而且掉庫前10分鐘提醒，就能保證銷售同學馬上放下手頭工作，去跟進這個線索么？不過雖然有諸多疑問，但是果凍對業務并不了解，剛剛已經請教過問題覺得怪不好意思，不好再追問太多，于是。。。

果凍：“好的，這個需求聽起來很合理，估計也不難，我讓研發大哥評估下，盡快排期去做！”

豌豆：“太好了，那麻煩你了，果凍同學就是好，工作最高效了！”

兩周后，這個功能上線了！豌豆很開心，還給果凍和研發同學買了奶茶表示感謝。

不過，上線一周后，豌豆又來找到了果凍。

豌豆：“果凍同學，還得麻煩你。上次提的需求上線后，我問了下銷售同學，他們提了個意見，我覺得很合理，就是在消息文案中，能說清楚還有多久掉庫，之前是沒寫的，但是大家都知道是提前1天推消息，可是現在掉庫前要推三次消息，大家就不知道到底還需要多久掉庫了。”

果凍：“嗯嗯，有道理！”（內心在懊惱的拍大腿，這么簡單的問題我咋沒想到！）

豌豆：“還有個問題，這個提醒功能，銷售同學非常喜歡，但是大家還反饋說提醒的內容太多了，如果能分個組，比如說能把掉庫提醒的消息，在點擊‘查看更多’后進入的消息盒子頁面中，都能分類展示，那這樣大家就能一目了然，知道今天有哪些新分線索，掉庫線索啦，安排自己的工作計劃就更方便啦！”

果凍聽起來感覺怪怪的，為啥要通過消息中心來管理自己的工作計劃呢，不過他也想不出其他更好的主意，也找不到反駁的理由，于是就按照下邊這樣做了設計，過了些日子就又安排上線了！

掉庫提醒消息增加了時間說明

消息盒子（展示全部消息的頁面）中增加了消息分類

本以為消息中心的優化到此就結束了，沒想到過了兩天豌豆又找來了。

豌豆：“果凍果凍，又得麻煩你！上次做的功能非常棒，銷售同學很喜歡！我最近又想到了個好點子，現在的消息只是提示了掉庫預警，但是銷售是不是有處理跟進，其實銷售是記不住的，如果我們能在消息提醒后邊加一個按鈕，讓銷售同學來標記這條消息是不是做了處理，這樣咱們的消息盒子功能就更強大啦！”

“你說的是不是這樣？”果凍拿著工具很快改了一版原型給小姐姐演示。

消息盒子中增加了消息待辦標記

豌豆：“對對對，就是這個意思，專業人員果然有效率！”（豌豆對果凍比了個大拇指）

果凍（思考片刻）：“我想到個好主意，我們將處理、未處理的消息再做一次分類，這樣如果消息特別多，銷售同學就能一下子找到所有沒處理過得掉庫提醒消息了！，就像這樣：”

消息盒子中增加了根據待辦的分類

豌豆（興奮地搓搓手）：“太棒了，產品經理果然厲害！”

雖然前兩次研發同學已經對這個項目有抱怨，因為據研發同學講，看了后臺數據，通過“查看更多”按鈕進入到消息盒子的頁面訪問量基本為0，說明消息盒子根本沒人用，在里邊加功能沒意義。但是，果凍這次依然硬著頭皮找了研發，拍胸部保證了需求的合理性，并說之前沒人用是因為宣傳不到位，最終艱難的說服研發排期實現。

過了兩周，功能很快上線了！

這次果凍留心也查了后臺數據，發現消息盒子根本沒有人訪問！果凍心很慌，難道做了這么久優化的功能，完全沒人用？為此他專門去找了豌豆。

果凍：“豌豆小姐姐，咱們做的優化，從后臺看，好像沒人用啊，要不我們一起去找銷售同學做做宣傳！”

豌豆（懊惱的）：“哎，不用去了，我已經做過好幾輪宣傳了，也和很多銷售同學聊過，他們說這個功能想法是挺好的，不過不是特別實用，銷售同學希望在展現即將掉庫線索的同時提供更多線索信息。所以，我正想找你提個新需求，能不能把新分線索、掉庫線索這些不同類型的線索，都在線索列表頁加一個新的篩選條件給篩出來啊，這樣大家就不用通過消息盒子來管理自己每天的待辦工作了，畢竟消息盒子只負責通知嘛！”

果凍聽完后，當初吐血倒地……

通過十三要素五步法進行需求分析?

相信閱讀完上一節的案例，大家都會會心一笑。

耗費了這么多時間和資源，做出來的功能卻沒能幫助到業務人員，甚至沒有人愿意使用，恐怕這是最讓產品經理傷心的事情了。

問題出在哪里呢？

我們應該責怪豌豆，譴責她提需求不靠譜不負責么？

還是應該責怪果凍，譴責他不去挖掘需求背后的真實性和痛點，只是做了一個原型工人么？

還是認為他們兩人都有責任？

我認為，在任何產品設計工作中，產品經理要對需求的分析、判斷、方案的設計負全責！產品經理的工作職責之一，就是幫助用戶、引導用戶分析他們的真實訴求，找到背后真正的問題點，而不是用戶提了什么就做什么。我們不能苛求讓用戶來提出合理、嚴謹的需求，這不是用戶的責任和義務，而應該通過自己的專業能力，來完成這項工作。

在上邊的案例中，有幾個明顯的問題：

• 果凍不熟悉業務，沒法和需求方在同一個頻道上對話交流
  

• 豌豆只是需求的二傳手，并不是需求的真正來源，而且夾雜了很多自己的想法
  

• 果凍沒有認真地去分析需求、理解需求
  

• 果凍在產品設計常識和原則上需要繼續積累（例如個人待辦管理是不應該在消息中心實現的，這是個基本產品設計常識）
  

當然，果凍畢竟是一個當時才畢業沒多久的新人，需要學習和歷練。那么，有沒有什么方法，能幫助果凍盡量做到全面的需求分析呢？其實，在需求分析中，是存在一些套路和技巧的，如果嘗試通過這些方法進行需求分析，至少保證你在一些關鍵點上沒有遺漏。

接下來，我將介紹需求分析的十三要素五步法，這是我結合工作經驗以及一些理論，總結的一套方法論，幫助大家做好需求分析工作。

十三要素五步法，即在需求分析過程中，通過五個核心步驟，涉及十三個關鍵要素，幫助設計人員盡量全面的梳理需求，挖掘需求背后的本質問題，找到所有可能的解決思路，從而做出正確的產品設計方案；這五個步驟分別是分析相關角色、了解基本場景、挖掘真實動機、發散更多場景、設計產品方案，具體見下表。

我將以果凍遇到的CRM消息中心線索掉庫提醒的需求為例，給大家講解并演示十三要素五步法的實際應用。

步驟一：分析相關角色

當我們接手需求后，第一件要做的事情，是先識別需求背后的各個角色；這和我們在從無到有構建產品的調研前期，需要先識別關鍵利益方，道理是一樣的。理不清楚人，就理不清楚事，也就無法設計合適的產品方案。

要素1：提出人

給產品經理提出需求的人，是需求的提出人。

在公司中，任何人都可能是需求的提出人，比如客戶、銷售、售前顧問、實施人員、客戶成功、業務運營、老板等等。需要注意的是，需求的提出人，并不一定是產品功能的使用人！而需求背后要解決的痛點，也并不一定是需求提出人的痛點！

要素2：使用人

最終使用產品功能的人，是需求的使用人（或者叫做產品功能的使用人）。

需求的使用人，不一定是需求的提出人。反而我們在工作中收到的很多需求，都是需求提出人，代表需求使用人提出的需求；例如，在甲方公司，業務運營團隊總是代表業務一線提出需求；在乙方公司，銷售或者客戶成功經理（CSM，Customer Success Manager，SaaS公司特有的崗位，負責對付費客戶進行持續跟蹤服務）總是代表客戶提出需求。

對于產品經理來講，如果想準確且深入的分析需求背后的場景和痛點，必須對預期產品的使用人進行調研，了解他們真正面臨的問題，而不要把精力都花在和需求提出人的溝通上。大多數時候，產品經理要解決的是產品的使用人遇到的問題和痛點，但有些時候，解決的也可能是需求提出人的痛點。在本節結束會有一個案例演示這種情況。

誠然，很多時候，需求提出人可能和產品用戶的接觸更加頻繁密切，對用戶的整體訴求有更直接的了解，產品經理應該悉心聽取需求提出人的建議，但是產品經理必須和產品的使用人取得直接聯系，要面向終端用戶進行訪談和溝通，需求提出人所描述的需求，畢竟是經過自己消化理解后二次轉化的內容，是二手的素材，產品經理只能作為參考，但不能作為決策的依據！

在某些甲方公司，存在一些很不好的現象，某些業務部門或人員，總是攔在業務一線和產品經理之間，不允許產品經理直接接觸一線用戶，希望產品經理只是一個原型工具，希望自己能“把握大權”。這樣做，對公司利益來講是不利的：研發資源本身就是公司的高價值稀缺資源，好鋼應該刀刃上，做出來的功能應該能夠真正解決問題。既然公司設計了產品經理這個崗位，就不應該只是作為工具人而存在，而應該能夠深入一線，融合技術，賦能業務。

要素3：受影響人

最終受到產品功能影響的人，是需求的受影響人（或者叫做產品功能的受影響人）。

需求的受影響人，不一定是產品的使用人。產品經理在需求分析時，一定要留意對受影響人的分析，有必要時也要進行調研和訪談，從而更全面的理解問題，并做出決策。

在果凍面對的CRM需求案例中，需求的提出人，就是銷售運營部的豌豆，她代表自己部門的銷售人員提出了需求，這也是她的本職工作，然而在過程中她同時加入了自己的理解和判斷（通過增加提前1小時和5分鐘的掉庫提醒消息，來提示銷售同學跟進即將掉庫的線索）。

需求的使用人，是銷售一線人員，因為實現的功能最終是給他們使用的，并不是給銷售運營部使用的。

在這個案例中，需求的受影響人同樣是銷售一線人員，并不涉及其他角色。

我們可以再舉一個例子，來展示提出人、使用人、受影響人不一樣的情況。假設銷售部門的老板提出了一個線索分配的需求，希望新的銷售線索由系統根據配置規則分配給不同銷售，而不再由人手工分配；針對這個需求，提出人是銷售部門的老板，使用人是銷售運營（配置功能是給銷售運營人員使用的），受影響人則是銷售一線（配置的規則會影響到銷售一線人員獲取新分線索的方式）。注意，在這個案例中，產品經理要解決的是需求提出人的痛點（銷售部門的老板，針對新分線索人工分配不合理導致線索資源被浪費的痛點）。

大家可以看出，在B端的業務場景下，僅僅是需求背后的相關方，就需要先花一些功夫作分析。

步驟二：了解基本場景

當我們理清了需求的相關角色后，下一步要著手分析需求背后的基本場景。基本場景的分析，要圍繞著存在痛點的那一方來進行，如果多方都有痛點，則要分析多個場景。

要素4：基本場景

在互聯網公司做產品設計，不論是C端還是B端，在探討產品的功能設計時，大家最喜歡提出的挑戰就是，你這個設計背后的場景是什么？具體情況是怎樣的？一切脫離了場景的功能設計，都是脫離了實際的空中樓閣，是難以落地并發揮真正價值的。

一旦我們把枯燥的功能設計，融入了具體的場景，就會發現事情變得鮮活、生動、有趣。

如何了解需求背后的基本場景呢？方法非常簡單，我們小學時就學過了，按照寫敘事作文的方法，來進行場景分析，即：

基本場景?=?人物?+?時間?+?地點?+?起因?+?經過?+?結果

我們將需求盡量按照按照這六個要點進行場景還原，就會發現一句話需求馬上鮮活了起來。

現在，果凍試著將原始需求，通過這六個要點進行拆解還原。首先回憶下原始需求是這句話：

“目前線索的掉庫提醒是提前一天，銷售同學看到后很容易就忘了，大家反饋說希望提醒能夠更及時一些，比如說掉庫前一小時再提醒一次”

果凍找到了最早給豌豆提需求的銷售，并且又聯系了幾個愿意和產研團隊多交流的新銷售和老銷售，聊了聊針對這個需求背后的場景，整理了下，寫下了這段文字：

場景還原：銷售同學栗子（人物），來公司半年了，每天勤勤懇懇辛辛苦苦，手里有不少老線索，每天也會分到很多新線索。在每個工作日的早上、下午和晚上（時間），坐在格子間的工位（地點），開著CRM系統，都要忙碌的聯系不同的客戶，可以說，不是在打電話，就是在撥號的路上。然而，今天下午，栗子同學又暴躁的生氣了，又有一個優質線索，因為不小心忘了跟進掉庫了（起因）！“這個系統一點都不好用！”栗子抱怨著，系統中這條線索的掉庫提醒只在昨天發了一條消息，一閃而過，一點意義都沒有，根本記不住，也不方便統一查看管理（經過），就是因為這個系統不好用，導致我經常丟掉一些線索，損失掉很多優質客戶，業績不達標，還影響心情士氣！（結果），不僅我如此，所有伙伴都有同樣的經歷和感受！

當果凍還原了這個需求背后的場景后，發現銷售同學遇到的問題一下變得生動了，而且在場景中更多體現了問題和現象，并不用描述解決方案，這讓果凍對問題的把握一下子有信心了！

要素5：發生頻率

需求背后事情或問題發生的頻率，是我們需要一開始就了解清楚的重要問題，有必要作為一個要素列出來，引起大家重視。

在大多數情況下，一般我們會有一個一般認識，對于非常低頻的需求和操作，可以將優先級調低，因為有些功能，可能做出來一年只會用到一次，如此還不如提供線下支持投入產出比高。例如某些配置功能，可能開發需要10人天，但是一年只用兩次，如果讓研發手工在后臺幫忙設置，只需要10分鐘，在資源緊張的情況下，這個需求還不如就讓研發手工支持了。

但是，有些特殊情況，即便需求的頻率很低，也要考慮支持，例如財務的月結工作，每個月只進行一次，對于企業來講是非常重要的業務動作，如果有相關的處理邏輯調整，應該提前開發，做好充分測試，保證月結工作順利進行，而不能讓研發同學在月結當天手工處理，影響月結工作，問題就非常嚴重了。

步驟三：挖掘真實動機

掌握了需求的基本情況后，下一步，我們要嘗試盡可能的挖掘需求背后的真實動機。

絕大多數情況下，用戶提出的需求，都是自以為正確的解決方案。這是人之常情，即便作為產品經理，我們靜下心來自我反思，很多時候我們給別人提需求時，是不是也會習慣性的把自己以為正確的解決思路一起提給對方？而且希望對方能按照自己的想法和意圖去執行？

暢銷書作者Simon Sinek，在TED演講中提出了黃金思維圈（Golden Circle）理論：如果將思維模式分為三層，即Why、How、What，通常情況，我們思考問題時，往往喜歡從外層開始，在表層上探索，很少深入到核心的Why層面；如果我們在思考時能夠從最里邊的Why層出發，展開到How，再到What，更容易洞悉問題的本質并做出正確決策。

黃金思維圈

在產品設計需求分析工作中，用戶提交的需求往往是在What層面的思考，我們應該幫助用戶，從思考的外層逐步深入到內層，找到核心訴求后，再往外延伸展開，尋找更多的解法，如下圖。

需求分析和產品設計的思維方向

要素6：核心訴求

在尋找需求背后的核心訴求時，我們可以采用豐田公司大野耐一提出的5W法，連問五個為什么，層層遞進，通過打破砂鍋問到底的方法，窮究問題的本質。當然，5Why只是一個參考，實踐中并不一定必須問五次為什么。

果凍嘗試用5Why法對需求進行分析。

原始需求是銷售同學希望在線索掉庫前1小時也能推送一次提醒。

為什么要提前再多推送一次？

因為目前提前一天的消息提醒銷售同學認為時間隔得太久很容易忘記。

為什么要提前到一小時？

因為這也只是一個拍腦袋的決定，其實估計提前一小時推送也會忘記。

為什么提前到一小時也會忘記？

因為目前系統只是推送通知，推送完就不見了，不是刻意記憶，根本想不起來，也很難找到。

為什么推送完就不見了？不能持續的提示或不消失么？

因為目前采用的是消息通知的組件來進行通知，如果希望將即將掉庫的線索提醒變成一個持續存在的待跟進任務，需要采用其他產品設計方案更佳。

為什么不能通過其他產品方案進行處理呢？

當然可以，銷售遇到的問題并不是推送消息的時機問題，而是有沒有更好的方法，時刻提醒他們有一條很重要的待辦工作存在。

設計一個一直存在的明顯提示的待辦任務，銷售同學就肯定能夠及時跟進么？

不一定，他們可能還是沒時間處理。

為什么沒時間處理？

因為銷售同學目前線索分配不合理，有些銷售會收到大量的新分線索，根本處理不完。

為什么會給某些人分配大量的新分線索？

因為目前系統采用的是銷售組長人工分配的策略，銷售組長分配時純粹憑感覺，并不知道目前誰工作量飽和，誰比較清閑，從而分配的更合理。

為什么組長分配線索要憑感覺？

因為目前既沒有數據報表給他們參考，也沒有系統自動分配策略算法給他們提建議，他們也不知道怎么分配合理。

為什么一直沒有在系統上實現這種功能，幫助他們決策？或者代替他們決策？

這實際上是個敏感話題，某種程度上講，組長能夠手工分配線索，代表著一定的“特權”，銷售管理層認為每個銷售小組都有自己的管理模式，把分配策略留給一線管理者，感覺更高效。

為什么管理層會有這種感性上的認知？而不是理性上的基于數據的分析？

問的對，這是存在了很久的，大家一直知道但卻沒有深入分析的問題，我們應該借此機會深入分析下目前的人工分配策略到底是否合理，是否應該從本質上解決新分線索的分配模式，讓每個銷售的工作量都變的公平、合理。

你看，通過對需求不停的問為什么，其實我們可以發現很多問題點和改進的機會點。當然，問題挖掘的深度和方向，需要產品經理自己做好把握和判斷。比如說，果凍在分析完后，發現問題的原因之一是線索分配規則不合理，不能簡單粗暴的直接跑去質疑銷售負責人。我們分析的目的，應該是洞悉本質，在合理的范圍內找到更多更優的解法。

同時，我們也要意識到，對需求做深層次的洞察，不是沒完沒了問為什么就足夠的，一方面，需要有靈活的思路和探究到底的勇氣以及決心，另一方面，更需要對業務有著深刻地理解和認識；尤其是后者，對于B端產品設計來講，如果你對業務理解不夠深刻，是很難洞察需求本質的。

要素7：強烈程度

需求的強烈程度，代表了用戶對痛點的忍耐程度。如果需求強度大，說明用戶痛點顯著，需求真實性高；如果需求強度低，說明用戶痛點不顯著，甚至可能是一個偽需求。

判斷需求的強弱程度，或者說判斷需求的真實性，推薦兩個方法。

—方法一：采用正反兩問的方法。

我們總是習慣詢問用戶，如果我做了某某功能，你是否喜歡，或是否會用。請相信我，多數情況下，用戶都會回答“我喜歡”，“我會用”，但上線后用戶卻不會像之前承諾的那樣熱心使用新功能。除了正向詢問，你應該還要采取逆向詢問，即：如果我不做某某功能，你的感受是“我很喜歡”？“理應如此”？“無所謂”？“勉強接受”？“我很不喜歡”？這也是C端產品設計、用戶研究分析時經常采用的KANO模型背后的設計思路（關于KANO模型，我們在第12章B端產品的迭代管理中還會進一步探討）。

—方法二：詢問目前痛點的解決方法。

判斷需求強度的另一個辦法，是詢問用戶目前是如何解決痛點的。如果用戶說需求很緊急，但當你問他，目前問題是如何解決的，而他回復你說目前問題并沒有著手解決，那么你一定要留心，這個需求，對用戶可能并不像他所說的那么緊急。如果真的是很著急的痛點問題，請你放心，即便你沒有實現相關功能，用戶也一定會自己想辦法解決。

同樣的方法也適用于產品初期市場分析時，當你定義了目標客群，在分析客戶的痛點或遇到的問題時，如果客戶當前并沒有采取措施解決這些痛點，那么很可能他也不會為了解決這些痛點付費購買你的產品。

要素8：實際價值

需求的實際價值，是需求優先級管理中重要的排序依據。在需求分析前期，我們也需要明確需求價值，如果價值有限，或者不符合公司當前階段產品規劃的重點，甚至可以不用投入太多精力，而直接將原始需求的優先級降低。

B端產品需求整體可分為兩大類，一類是解決客戶、用戶痛點的業務需求，一類是針對產品或技術本身持續優化的技術需求。

業務需求的價值

我們在第一章提到過，B端產品對企業來講承擔著提升收入、降低成本、提高效率、保證品質、控制風險的重任。每一條業務需求都服務于業務，背后的價值也在以上五點以內。還有一類需求是為了改善用戶體驗，我們暫且將這類需求也歸于業務需求范圍，因此，除了以上五點，還可以再加一點，即改善體驗（軟件產品的交互體驗，而非企業對于終端消費者的服務體驗）。

技術需求的價值

軟件產品在構建過程中，自身也存在很多非業務相關的優化點，比如說，我們要將列表頁進行支持自定義設置的改造，從而解決為不同客戶三天兩頭硬編碼修改列表頁的煩人工作，這類需求是為了降低研發成本，或提升產品化能力而存在；再比如說，為了解決企業客戶重復的問題，我們需要將產品背后的應用架構，進行主數據改造，這類需求，是為了改善架構合理性而存在；這些都是技術需求背后可能的價值。（關于主數據架構改造的話題，我們將在第四篇“進階篇”進一步探討。）

我們應該盡量保證每條需求只對應一個價值點，如果一個原始需求對應了多個價值點，產品經理可以考慮（并非絕對）該將其打散、拆解成多個需求，分別對待分析。這樣做的目的，是讓工作的顆粒度更加合理，并且可以和產品規劃相呼應，也可以需求對應的功能設計更加聚焦。

步驟四：發散更多場景

用戶提交的原始需求，往往是針對背后的痛點自以為正確的解決方案。當我們已經洞察了需求背后的核心訴求后，應該跳出需求本身的范圍，從更多的角度、場景切入，思考如何解決問題。

要素9：橫向替代場景

橫向替代場景，是指圍繞核心訴求，找到所有可能的解決思路或者場景，這些場景彼此之間在某種程度上是可替代關系。

原始需求所描述的場景，只是所有可選方案中的一種，而且不一定是最優解。通過5W法分析問題本質時，我們對問題有著不同層面的理解，可以選擇對其中某一層面或某幾個層面，展開分析所有可能的解法。

果凍分析需求后，發現背后的核心問題是銷售同學新線索分配不合理，導致來不及跟進線索，造成掉庫現象頻繁發生。雖然需求希望的是加強即將掉庫線索的提醒頻率，但這并不是唯一的解決思路。果凍思考后，針對提高銷售人員線索跟進效率問題，梳理出了以下解決問題的思路和場景。

1、讓線索分配流轉更加合理公平高效

a)優化新線索的分配規則

???i.實現系統自動化分配策略

?? ii.保持人工分配，但給分配人員更多的數據支撐作為參考

?? iii.采取機器自動化+人工分配混合的模式

b)優化線索掉庫流轉規則

???i.完善線索掉庫時間的規則（目前規則可能一刀切且過于嚴格）

2、讓銷售人員對每日工作計劃的安排和執行更加合理且高效

c)讓銷售人員及時掌握當前任務待辦情況

d)系統幫助銷售人員根據優先級和價值安排每日工作計劃

果凍的分析相對全面的覆蓋了可能的問題解決方向，而且果凍再次深刻地認識到，需求分析的難點在于對業務理解的深度。豌豆提交的需求，只是上邊提到的方案c）中的一個小功能點而已，除了c），我們還有a）、b）、d），都是可以選擇的優化方向，而且他們彼此獨立，在某種程度上是互相可替代的選擇。果凍通過追本溯源，找到了問題的本質，再通過橫向擴展，采用結構化思維，窮舉了解決的思路，一切從業務場景出發！下一步，就可以選擇一個確定的解決方向和場景，繼續深入的分析！

要素10：縱向互補場景

縱向互補場景，是對選定的解決方案及場景，進一步思考在需求點的上下游和整體的用戶操作動線上，是否存在考慮不夠全面的機會點和優化空間，找到圍繞需求點的互補場景，讓方案更佳全面、透徹。

用戶提交的需求，往往只是一個點，但是背后的場景，實際上是一條線，或者一個面。如果我們在設計時只是實現了一個點，那么接下來總會有接二連三的補充需求出現。作為產品經理，需要提前將這些可能的優化點、相關的補充場景都思考周全，進行統一的規劃和設計，避免局部和片面性的思考。

分析縱向互補場景，可以將場景中用戶行為或動作的事前、事后環節，或者在系統上完整的操作動線全部梳理出來，找到其中可優化的遺漏點。想做到這一點，最有效的方法，就是深入到業務一線，要么輪崗體驗業務的實際場景，要么通過觀察用戶操作并訪談了解用戶的行為。

在C端產品設計中，用戶故事地圖（User Story Mapping）是一個非常經典的用戶體驗分析工具，可以幫助產品經理和體驗專家分析用戶為了達成某個目的，在使用產品中的關鍵步驟和動線，并依據此，從場景的角度出發去拆解設計軟件的功能點。

在B端產品設計中，我們可以借鑒用戶故事地圖，來分析某類用戶角色，在某些場景下的完整環節，以及相關的需求點或功能點。

結合目前領導對產品的規劃，當前階段CRM建設的重點在于賦能銷售，幫助銷售人員提升工作效率，因此暫不考慮線索分配策略這些涉及到業務規則調整的功能設計，果凍將注意力集中在如何幫助銷售人員及時掌握當前待辦任務這個方向上，從原始需求“提高掉庫消息提醒頻率”切入，思考更加全面的設計方案。

通過在銷售部門實際輪崗工作三天，以及大量的訪談工作，果凍嘗試使用用戶故事地圖這個工具，將自己了解到的電話銷售核心場景（部分）的故事地圖繪制出來，虛線部分是目前銷售人員通過線下手工完成，系統還不支持。

銷售人員的用戶故事地圖

用戶故事地圖的繪制并不復雜，難點在于場景的梳理拆解。為了達到某個業務目標或目的，用戶的操作動線首先在第一個層面進行拆解，得到了不同的一級場景，即Activity，將一級場景可以進一步拆解出二級場景，即Back Bone，這就像一個敘述故事的骨架，也叫作Walking Skeleton；在二級場景下，我們可以進一步更加細致的列示出所有相關的功能點，即用戶任務UserTask。

用戶故事地圖中最小顆粒度的用戶任務，也就是敏捷開發中的用戶故事User Story，用戶故事是一種從用戶場景切入去描述最小功能點的軟件設計方法論，每一條用戶故事按照如下結構來描述：

作為（誰），我想要（什么），以便（為什么）；Aswho，I want what，so that why。

在傳統的軟件設計工作中，尤其是針對復雜的業務型軟件產品，我們往往從業務流程和功能結構切入去進行軟件設計，但很少考慮用戶體驗和場景。而敏捷軟件設計中，更重視從單一用戶和場景的視角切入去進行軟件設計。兩者設計思路和出發點完全不同，產生的效果也不一樣！

B端產品有一個很常見的體驗問題，就是功能都有，單獨用起來也沒問題，但在實際業務場景下，把這些功能連起來，就非常難用，體驗差。這正是因為很多設計人員習慣于從功能結構的角度思考設計問題，而很少從場景的角度思考體驗問題。

作為B端產品經理，一定要認識到，現代軟件設計，既要求有抽象設計和結構化思維，又要有場景設計和用戶體驗思維，這兩者缺一不可，是每一名B端產品經理都應該重視并掌握的能力。

用戶故事地圖，以及User Story的產品設計方式，對B端產品經理來講，值得學習借鑒。當然，User Story在B端產品設計上也存在缺陷和不足，這個話題在本章最后一節還會深入探討。在梳理縱向互補場景時，用戶故事地圖是一個可選的工具，并非必須，梳理縱向互補場景的要點是將某個解決思路下所有的操作鏈條以及相關場景的功能點都能思考全面，避免需求上線后重復返工修補。

基于自己的輪崗調研，并結合用戶故事地圖的呈現，果凍發現，在銷售的日常線索跟進作業場景中，首先每天會拿一個小本子把待辦任務整理好，并標記優先級；在收到消息通知后，銷售還會把新分線索、即將掉庫線索記錄下來，更新到小本子中；每天工作結束前會回顧當天的跟進情況，并計劃第二天的工作安排。

可見，系統已經無法很好地支持銷售人員的當日工作管理，銷售人員反而通過記事本自己管理工作。針對線索掉庫提醒的功能優化，單純的提高通知頻率是不夠的，還需要從銷售的完整工作場景入手，在各個環節都進行優化。

經過思考，在“幫助銷售人員及時掌握任務代辦情況”這個思路下，除了提升消息通知頻率，我們還考慮增加當日待辦清單任務聚合的能力，增強銷售同學對當天工作的管理，讓銷售同學和小本本說拜拜！

步驟五：設計產品方案

產品經理通過對原始需求進行充分分析后，確定了整體的解決思路，接下來，要設計具體的產品方案，來幫助用戶解決痛點，實現業務訴求。

要素11：已有方案

有些需求，其實并不一定要開發新的產品功能來解決問題，現有功能可能也許就可以一定程度的直接或間接滿足訴求，產品經理首先要對此進行判斷，不要盲目的、匆忙的著手功能設計。如果需求優先級并不高，客戶又很著急，那么通過一些已有功能，部分、間接的解決問題，也不失為一個盡量幫助到客戶的好選擇。

尤其是對于甲方自研自用系統的情況，研發資源有限，如果可以用一些變通的方式解決問題，并不一定必須開發功能，而且在甲方工作的軟件設計人員必須嚴肅的意識到，解決業務問題才是核心目標，軟件產品只是為了解決業務問題采用的手段之一，有些時候通過軟件產品解決問題投入產出比反而較低。

我們可以舉一個小例子，來解釋下如何通過已有方案間接地滿足用戶訴求。相信大家在使用微信中都會有一些煩惱，有一些群總是不停地彈消息，占據聊天記錄前排位置，對自己沒有任何意義，但因為某些原因自己無法退群，因此只能忍受（大家可以想象生活中是不是有這種群），假如你是微信的產品經理，用戶提交了一個對群“置底”的功能，這樣就能既不退群，又不會受到打擾。假設這個功能暫無法開發，有沒有其他妙招能夠幫助用戶間接地解決這個問題呢？當然有啊，你可以讓用戶挑十幾個經常聊天的對象都“置頂”，這樣那些讓人煩惱的群被靜音后就不會再看到他們啦！

要素12：功能需求

產品經理在分析原始需求后進行軟件產品設計，編寫PRD（Product Requirement Document，產品需求文檔），也即功能需求文檔，提交給研發人員，進入下一步開發工作。

在B端產品設計中，很多時候僅僅繪制線框圖編寫邏輯說明是遠遠不夠的，還需要進行需求建模等工作，將軟件功能進行高度抽象化的設計，具備靈活性和擴展性，支持不同客戶和業務場景，這是一個相當復雜且具有挑戰的過程。

除了增加掉庫線索的提醒頻率，果凍還設計了一個全新的待辦事項面板，將銷售每日工作幾個關鍵場景的待辦事項聚合在一起展示出來，如下圖。用戶可以通過點擊數字超鏈接，進入到線索列表頁，呈現出符合條件的線索記錄。

“今日新分線索”展現的是當日新分的所有線索；

“今日需聯系線索”是指之前設置了待辦提醒的當天待跟進線索；當線索被跟進并添加了拜訪小結后數據就會被清除；

“即將掉庫的線索”是指1天內即將掉庫的線索；當針對線索做了某些相應的動作后，數據就會被清除；如果新增了一條即將掉庫線索，則消息中心進行首次提醒，且“即將掉庫的線索”數字加1。

有了下邊這個小面板，以及點擊數字后進入到統一的線索列表頁，實際上已經實現了先前豌豆需求中對消息盒子的各種改造需求。在典型的B端產品設計中，消息中心只負責主動式消息提醒，待辦管理應該通過其他的組件設計實現。

全新設計的待辦事項面板

要素13：非功能需求

在需求分析工程中，非功能需求（NFR，non-functional requirement）是指軟件產品為了滿足業務需要必須具有且除了功能需求之外的特性。在軟件質量評估國際標準 ISO/IEC 25010:2011對非功能需求做了非常詳盡的定義。

簡而言之，類似于訪問時間、并發量、安全性這類非功能訴求，但是在軟件設計和使用中非常重要的要素，都是非功能需求涵蓋的范圍。對于產品經理來講，需要留意這類需求，在某些場景中，如果有需要，應該明確的指出軟件產品的非功能性訴求，例如某些同步查詢功能，要求最長響應時間不應超過30秒，并發量要至少支持30個并行查詢。

【資源推薦】

關于非功能需求詳細的說明，有興趣可查閱ISO官網https://www.iso.org/standard/35733.html。

?小結?

至此，我們已經完整探討了需求挖掘分析的十三要素五步法，通過這五個步驟和十三個要素進行充分的需求分析，相信會幫助您洞察、探索需求的全貌。

作為產品經理，一定要分析需求背后深層次的原因，而不是馬上上手進行功能設計。只有理清了背后的問題，才能做出合理的方案決策，確定優先級，并與產品規劃結合起來考慮。

當然，這套方法分析起來也略顯復雜，更重要的是，我希望大家能夠通過學習這套方法，培養自己場景化的思維意識，以及全面、縝密的思考邏輯。當你經過方法論多次的訓練后，思維模式和思考習慣會形成肌肉記憶，一旦形成了肌肉記憶，在以后的工作中，即便你不會刻意的采用這套方法，依然會潛移默化的把握需求分析的關鍵要點。

同時，我也想再次強調，B端產品成功需求分析的前提永遠都是理解業務為第一要務，如果自身業務知識底子不夠厚實，學習再多的需求分析技巧也是枉然。

↘好文推薦：

Notion：后office時代的新生產力平臺

張小龍力薦的貝索斯演講：善良比聰明更重要

騰訊分享：AB實驗，歸因和解讀才是王道！

👇歡迎關注：

點個“在看”吧

總結

以上是生活随笔為你收集整理的决胜B端第2版（4）：需求分析的十三要素五步法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。