如何對TO B系統產品提出好的需求
本文深入探討了如何為TOB系統產品提出有效的需求,分享了在需求收集和分析過程中的關鍵步驟和注意事項,希望對你在產品管理和需求工程方面提供實用的指導。
在TO B的產品工作中,最重要的一個需求來源就是實施交付的項目。
實施交付項目上的需求是最能夠代表真實用戶心聲,最后能夠體現系統在業務中的價值。
但是,往往在需求收集和傳遞的過程中,最重要的、最有價值的信息被損失掉了,項目過多、客戶過多的時候,特別是SaaS系統,產品經理不可能每個項目都和客戶直接進行溝通,必須要面對二手需求。
為了避免在傳遞的過程中損失太多信息,特意編寫此文檔說明如何對提TO B系統產品提出好的需求。
一、需求模板規范
首先,給出一個需求模板:
二、什么是需求
2.1 需求的定義
在經濟學中對需求的定義:需求是人們在某一特定的時期內、在各種可能的價格下、為了達到某種目標,愿意并且能夠購買某個具體商品的需要。這里面涉及到四個關鍵詞:
- 人
- 場景(在某個特定的時期)
- 問題(為了達到目標)
- 購買能力(愿意并且能夠購買)
在To B系統的場景下,需要強調的兩個詞的差異,業務需求和功能需求,這是兩個完全不同的概念:
- 業務需求才是我們說的真正的需求,是需要解決的問題,是需求挖掘和需求分析的產出
- 功能需求是對系統某個具體能力的描述,一般是產品設計的產出
2.2 需求的構成是什么
需求的4個關鍵詞也就組成了需求的4個要素,缺一不可
2.2.1 人
人是需求的中心,全部都是圍繞人來說的,也就是用戶;在需求的語境下,用戶不是自然人,而是一種角色。例如:只有在爸爸的角色下,一位30誰的男士才會有尿不濕的需求,沒有角色的背景,這個爸爸就不會有需求。
PS.其實我們都是帶著角色的面具而生活。
2.2.2 場景
場景是為了更好的理解需求,同樣的需要,在不同的場景下就變成了不同的需求,脫離了實際場景的需求就是無源之水、無本之木。例如:一個人打車,在這個人要上班和要下班的場景下,需求將會有明顯的變化,上班的核心是時間,其他占比小,下班要綜合考慮事件、價格、舒適度、路線等等。因此,雖然有些需求看起來好像很相似,但是在不同的場景下需求的差異是非常大的。
2.2.3 問題
問題是對現狀和理想差距的刻畫,是需求的核心部分。問題的描述包括現狀是什么樣的,目前的解決方案是什么,和理想的差距是什么。這里尤為重要的現狀,現狀也就是目前的解決方案,不僅僅是狹義的解決方案,而是包括了對需求的深入洞察,解決方案是建立在對需求的深入理解后的產物,要多問幾個為什么,最終的目的是什么。
2.2.4 購買能力
需求是建立在交易的基礎上的,沒有交易需求就永遠無法被滿足,有交易就會有價值交換,也就是購買能力;客戶為了這個需求愿意付出的價值也側面體現了這個需求的重要程度。購買能力不僅僅指經濟成本,也包括時間成本、信用成本、機會成本等。例如客戶愿意直接支付的人天、是不是愿意等待、還是愿意拿這個來卡主驗收甚至是替換供應商(卡驗收和替換供應商其實客戶也要付出很多代價)。
2.3 需求洞察,揭開需求的面紗
在“問題”部分,提到了需求的洞察,這是非常有意思、非常開放且知易行難的一點,因此,我們在花一個小節對這一點再進行單獨的闡述。需求洞察是建立在對整體業務邏輯和業務結構的深刻理解之上的,對業務邏輯和業務結構不理解,就猶如盲人摸象、坐井觀天,永遠無法跳出到更高的高度解決問題,陷入解決問題的細枝末節,越陷越深,很可能會帶來無法解決的困難,最終也無法很好的解決問題。
什么是業務的邏輯和業務結構?舉一個新能源汽車行業的很簡單的例子來說明,如下圖:無論是什么需求其實都是在解決最終的整體經營利潤的問題,遇到的實際問題可能是某個分支上的問題,如果能解決高位的的問題,那么分支上的問題也就不是問題了。
明確需求洞察最重要的手段就是多問幾個為什么?一直問、一直問、一直問……業務的最終目標是什么?如何反映下指標上?為什么要這樣不是那樣?為什么數據不能多一點?…… 當然,如果一直問下去肯定會落在人性的“貪嗔癡慢疑”,這就問的太深,不是TOB系統語境下關注的。
因此,需要先了解業務結構,了解了業務結構就知道了業務邊界,討論范圍不能出了業務邊界。根據經驗,一般情況,根據問題所在的位置向上問2-3層即可,當然可能有時候向上求幾層也無法繞開問題,那就是確實只有一條路了,但是這個過程可以讓我們對需求的理解更加透徹。綜上,在理解業務框架的前提下多問幾個為什么,深刻理解真正目的,明確差距,切實為客戶帶來業務價值。
三、提需求的誤區
3.1 拒絕功能描述,拒絕不求甚解
汽車大王亨利·福特的名言:“如果當初我問客戶想要什么,他們一定會告訴我,想要一匹更快的馬”。一匹更快的馬就是功能描素,從A點到B點,更快的到達,更舒適的到達,更低成本的到達,才是需求。我們與客戶溝通時,大多數的情況,客戶不會把最真實的需求直接呈現給我們,而客戶往往喜歡直接給出一個方案或功能點的需求,特別是對于有產品或技術背景的客戶,這種情況尤甚。
這樣的需求非常具有迷惑性,看起來是非常明確、非常具體,各種邏輯也非常清楚,而實際上,這種需求大部分是功能描述(功能需求),并非業務需求。在這種情況下,加之人性的懶惰,很容易就把功能描述當成了需求進行處理,這會導致:
- 失去了對真實業務的理解,失去了從其他角度解決問題的可能性
- 長此以往只會被需求的提出者牽著鼻子走,失去了自己的節奏
- 需求的處理人、產品的設計者淪為功能點設計的機器人,喪失了全局的視角
之所以出現這種情況,是因為每個人的知識背景、邏輯結構、過往經歷、看過的書、見過的人都是不同的。
每個人對事物的認知存在一定的差異,客戶提出的解決方案是在他的認知下的解決方案。這種解決方案并不是經過論證分析的、最合適的、可落地的;大多數情況下都不是最佳解決方案,且很難實現。我們不能直接認為客戶的表述就是需求,然后就開始聚焦在這些語言上進行解決方案的探索如果這樣,那就是一葉障目,失去了發現語言背后隱藏的真實需求的機會。
總而言之,遇到這樣的情況,我們要多一層思考對方到底想解決什么問題,這也是本文一直強調的“需求洞察”,通過多輪有意義溝通,與客戶溝通需求,在溝通過程中不斷挖掘客戶的真正需求,揭開需求的面紗。
3.2 拒絕空對空,拒絕一句話的需求
一句話能說清楚需求嗎?能、也不能。之所以說能,是因為對話的雙方對某個具體的事物擁有相同的認知,這這種情況下,即使通過幾個簡單的詞匯也能相互理解具體的需求當時大多數情況,我們與客戶,我們內部的不同部門之間是很難建立高度相同的認知的,之所以無法建立:
- 我們與客戶的認知不同,這很好理解
- 內部的各個部門的信息很難在一開始就完全互通的,客戶的業務情況、項目的特點、客戶的調性……是非對客部門無法完全知曉的
在無法建立相同認知的前提下,貿然的通過一句話來完成需求的傳遞是有風險的,這會造成雞同鴨講的情況出現,客戶和項目說的不完全理解,項目和非對客部門說的也不理解,最終做出來的功能無法切實解決客戶問題,賠了夫人又折兵。
在這樣的情況下,一定要通過詳細的需求描述和分析文檔進行溝通。需求的提出方盡量按照需求的4個要素說清楚需求,非對客部門也要再編寫需求分析文檔,強化對需求的理解,和項目同學對齊。借用技術的語言來說,至少要做到三次握手,意思就是項目上的同事對需求描述一遍,其他部門的同事復述一遍,項目的同事再確認一遍。
總而言之,遇到這樣的情況,我們要多通過《需求文檔》和《需求分析文檔》確保對需求的理解深刻且一致。
3.3 拒絕經驗主義,拒絕先入為主
經驗是個好東西,經驗可以提升效率,少走彎路。但是如果犯了經驗主義錯誤,無意識地使用理性,卻拒斥理性的使用,那么就會增加失敗的風險。需求的傳遞和說明也是這樣,剛開始說就以為自以為自己理解了,不在進行深入了解了,或者簡單幾句話的說明,就以為其他人都應該明白了,這樣很有可能會造成需求理解的偏差,而且這種偏差一般都不小。
為了避免經驗注意,我們要時刻保持謙虛的態度,保持對需求的敬畏之心,不要有刻板印象,過早的下結論,該有的溝通和分析流程都應該有。
本文由@Seven 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!