決勝B端第2版(4):需求分析的十三要素五步法

決勝B端第2版(4):需求分析的十三要素五步法

本文由作者

楊堃

釋出於社群

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

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

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

舉例:一次並不成功的的需求分析

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

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

豌豆:“果凍果凍,又來麻煩你了,給你提個新需求!”

果凍:“好呀好呀,一起聊聊!”

豌豆(對著系統邊說邊比劃):“咱們現在的CRM系統,不是會有訊息提醒麼,裡邊會有很多提示,比如說如果線索還有1天就要掉庫,就會在訊息中心彈一條訊息,比如說你看現在這個,就是有三條未讀訊息,其中第一條就是掉庫提醒。”

決勝B端第2版(4):需求分析的十三要素五步法

目前訊息中心的樣子

果凍(不好意思的撓了撓頭):“呃,這個,是,小姐姐,我想請教下,掉庫是啥意思啊?”

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

果凍:“明白啦,小姐姐就是厲害,一說就透!咱們這次需求是什麼呢?”

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

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

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

豌豆:“太好了,那麻煩你了,果凍同學就是好,工作最高效了!”

兩週後,這個功能上線了!豌豆很開心,還給果凍和研發同學買了奶茶表示感謝。

不過,上線一週後,豌豆又來找到了果凍。

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

果凍:“嗯嗯,有道理!”(內心在懊惱的拍大腿,這麼簡單的問題我咋沒想到!)

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

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

決勝B端第2版(4):需求分析的十三要素五步法

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

決勝B端第2版(4):需求分析的十三要素五步法

訊息盒子(展示全部訊息的頁面)中增加了訊息分類

本以為訊息中心的最佳化到此就結束了,沒想到過了兩天豌豆又找來了。

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

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

決勝B端第2版(4):需求分析的十三要素五步法

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

豌豆:“對對對,就是這個意思,專業人員果然有效率!”(豌豆對果凍比了個大拇指)

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

決勝B端第2版(4):需求分析的十三要素五步法

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

豌豆(興奮地搓搓手):“太棒了,產品經理果然厲害!”

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

過了兩週,功能很快上線了!

這次果凍留心也查了後臺資料,發現訊息盒子根本沒有人訪問!果凍心很慌,難道做了這麼久最佳化的功能,完全沒人用?為此他專門去找了豌豆。

果凍:“豌豆小姐姐,咱們做的最佳化,從後臺看,好像沒人用啊,要不我們一起去找銷售同學做做宣傳!”

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

果凍聽完後,當初吐血倒地……

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

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

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

問題出在哪裡呢?

我們應該責怪豌豆,譴責她提需求不靠譜不負責麼?

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

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

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

在上邊的案例中,有幾個明顯的問題:

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

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

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

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

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

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

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

決勝B端第2版(4):需求分析的十三要素五步法

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

步驟一:分析相關角色

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

步驟一:分析相關角色

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

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

要素1:提出人

最終使用產品功能的人,是需求的使用人(或者叫做產品功能的使用人)。

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

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

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

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

要素1:提出人

最終受到產品功能影響的人,是需求的受影響人(或者叫做產品功能的受影響人)。

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

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

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

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

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

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

要素2:使用人

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

要素2:使用人

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

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

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

要素3:受影響人

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

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

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

果凍找到了最早給豌豆提需求的銷售,並且又聯絡了幾個願意和產研團隊多交流的新銷售和老銷售,聊了聊針對這個需求背後的場景,整理了下,寫下了這段文字:

要素3:受影響人

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

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

步驟二:瞭解基本場景

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

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

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

步驟二:瞭解基本場景

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

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

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

決勝B端第2版(4):需求分析的十三要素五步法

黃金思維圈

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

決勝B端第2版(4):需求分析的十三要素五步法

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

要素4:基本場景

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

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

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

為什麼要提前再多推送一次?

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

為什麼要提前到一小時?

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

為什麼提前到一小時也會忘記?

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

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

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

為什麼不能透過其他產品方案進行處理呢?

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

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

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

為什麼沒時間處理?

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

為什麼會給某些人分配大量的新分線索?

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

為什麼組長分配線索要憑感覺?

因為目前既沒有資料報表給他們參考,也沒有系統自動分配策略演算法給他們提建議,他們也不知道怎麼分配合理。

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

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

為什麼管理層會有這種感性上的認知?而不是理性上的基於資料的分析?

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

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

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

要素4:基本場景

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

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

—方法一:採用正反兩問的方法。

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

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

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

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

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

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

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

場景還原

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

要素5:發生頻率

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

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

要素5:發生頻率

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

步驟三:挖掘真實動機

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

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

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

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

a)最佳化新線索的分配規則

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

ii。保持人工分配,但給分配人員更多的資料支撐作為參考

iii。採取機器自動化+人工分配混合的模式

b)最佳化線索掉庫流轉規則

i。完善線索掉庫時間的規則(目前規則可能一刀切且過於嚴格)

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

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

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

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

步驟三:挖掘真實動機

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

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

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

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

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

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

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

決勝B端第2版(4):需求分析的十三要素五步法

銷售人員的使用者故事地圖

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

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

作為(誰),我想要(什麼),以便(為什麼);Aswho,I want what,so that why。

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

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

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

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

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

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

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

要素6:核心訴求

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

要素6:核心訴求

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

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

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

要素7:強烈程度

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

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

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

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

“今日需聯絡線索”是指之前設定了待辦提醒的當天待跟進線索;當線索被跟進並添加了拜訪小結後資料就會被清除;

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

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

決勝B端第2版(4):需求分析的十三要素五步法

全新設計的待辦事項面板

要素7:強烈程度

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

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

要素8:實際價值

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

要素8:實際價值

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

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

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

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

業務需求的價值

Notion:後office時代的新生產力平臺

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

騰訊分享:AB實驗,歸因和解讀才是王道!

技術需求的價值

步驟四:發散更多場景

頂部