需求調研的前置思考
編輯導讀:產品經理每天都會接觸很多需求,當有多個待處理的需求堆積在一起時,如何安排調研工作呢?本文作者從自己的工作經驗出發,對此進行了分析,希望對你有幫助。
不知道大家拿到多個待設計的需求時,是如何安排調研工作的,像我之前就會先將同一模塊的需求整理到一起,再將有聯系的需求整理到一起,將這些需求打包分成好幾份,一般一份需求是與同一個功能相關的,業務負責人也是差不多的角色,在調研的時候可以聯系1-2名對象,一次調研多個相關需求,這樣比較有整體性,還節省時間。
舉一個調研的小例子:
以培訓評論功能為例,當時收集了好幾個培訓評論相關的需求,比如評論人匿名改為非匿名,評論人和培訓管理者都能刪除不合適的評論信息,培訓管理者可以控制評論信息是否公開展示等等;我們聯系了不同品牌的培訓負責人溝通這個問題,在這個過程中還收集了新的需求,導致這個需求變得非常龐大。
一開始我們是不太想做這個功能的,覺得控評的話會讓參加培訓的店員不愿意持續發表言論,培訓組織者就聽不到真實的聲音,便失去了評論功能的意義,于是與多個品牌方進行調研溝通,并希望改變他們想法。
在調研過程中,我們去了解需要控制評論的場景,目前的處理方式,以及希望實現的效果,同時還會給到對方一些我們的建議,雖然大部分都被對方否決了,表示仍舊希望實現控評的效果;
調研完后仍舊不死心,還去找老板咨詢了此需求的處理方案,并舉例有贊商城,淘寶,美團等平臺都不允許商家刪除評論,當然最后的結局仍舊是實現這個需求,但是因為聯系了多個品牌調研,又自己糾結了很久,導致在業務調研方面花費了3天的時間,后續的行業分析又花費2-3天的時間,等到確定要實現該需求已經過了一周,剩下的設計時間就不多了。
原本簡單了解現狀和預期效果就可以直接設計的需求,花費了一周的時間進行調研,導致沒有給其他需求預留時間,直接影響產品工作的產出,長時間的低產還會影響客戶對產品的信任度。
一、需求調研現狀
在設計需求前,我們一般會先去需求池里挑選符合近期目標的需求,但需求池大部分的需求都是客戶直接提出的,只能說明客戶認為這件事對他們自己來說是有價值的,但我們不能直接判斷出是否真的有價值,甚至是需求價值的高低,所以我們必須要對這些需求進行調研,了解需求提出的背景,及要解決的問題,和我們能解決的問題,才能對需求價值進行判斷。
就以上面培訓評論功能中需要控評的需求為例,在收到這個需求的時候,我們只知道客戶想要管控評價內容是否公開,以及能主動刪除評論,至于他為什么提出這個需求,到底要解決什么問題,我們是不清楚的,所以必須先與需求提出人做一個簡單的溝通;
在初步溝通中了解到,部分門店員工在培訓課程的評論區發表了不文明、以及詆毀品牌的內容,品牌方認為這些不良情緒會傳播給那些正常工作的門店員工,從而影響他們的工作情緒,給品牌帶來不穩定的因素,但當時我們產品認為這是收集門店真實想法的渠道,阻塞的話會讓門店對品牌失去信任,就不太愿意接受這個需求。
之后就有了各種證明這個需求是錯誤需求的過程,但現在回想起來,我們其實是在需求信息了解還不夠充分的時候做判斷,如果我們了解到在培訓課程下進行評論的員工只有兩百分之一,而發布不良言論的門店員工只有發布評論員工中的五百分之一,還會不會覺得這是收集門店真實想法的渠道呢?而且在培訓評論功能里收集門店真實想法是一個正確的方式嗎?
二、調研的前置思考
重新處理這個需求的話,我會在需求初步溝通前,獨立的分析一下這個需求,如該需求是否為主流程業務,當前活躍用戶數有多少,活躍客戶數又有多少,提需求的幾個客戶在該功能上的使用情況是怎樣的等,作為后續調研的前置思考。
像這個需求所涉及的評論功能,屬于非主流程業務,可以判斷價值不高,同時活躍用戶數很低,而發表不良言論的用戶數就更低了,說明需求調整后影響范圍非常小,并且需求場景和需求目標都已經很清晰了,那么我們可以直接安排設計,而不是花大量時間去證明需求是否正確。
如果在開始調研前,通過一些信息可以初步判斷需求的價值,如影響范圍、需求場景和需求目標是否清晰,就能初步判斷這個需求是需要花較長時間調研,還是簡單了解場景和目標即可的話,便能減少一些簡單需求卻花費大量時間進行調研的浪費。
1. 調研評估
在正式調研需求前,可以收集一些信息,作為需求調研前的輔助評估,就稱為調研評估吧,方法是在正式調研前先對需求進行評估,根據評估結果安排合適的調研方案,目的是合理分配資源,針對不同的需求,采取不同的調研策略;
調研最容易遇到的問題就是時間不夠,需求永遠調研不完,但時間有限,如何將有限的時間合理的安排給每一個需求是讓產品經理頭疼的問題。
在調研前可以對需求先進行一個評估,評估的維度有很多,根據各團隊的實際情況約定即可,可以是本次迭代需要達成的目標,如提升用戶APP端體驗,或提升某個功能模塊的日活數據,或就是要完成某個客戶的定制需求,也可以是需求的影響范圍,但一定是個可以衡量的指標,評估完成后才能對需求調研優先級進行判斷。
評估完成后會有一個調研優先級的排行,這時就可以根據優先級安排調研工作了,優先級高的需求,一般需要深度調研,可能需要聯系多個品牌,分別與其業務部門深度溝通;優先級低的需求,可以只做嘗試性調研,明確需求后再做下一步計劃;還有一些完全不符合產品規劃的需求,可以直接拒絕需求,不做調研;這就是根據調研評估結果決定調研方式。
2. 影響范圍評估
需求的影響范圍可以幫助我們初步判斷需求的優先級,影響范圍即使用該功能的客戶數據和用戶數;有的功能所有客戶都使用,有的功能只有部分需要的客戶才會使用,有的功能所有用戶都使用,但有的功能每個客戶只有少數幾個用戶在使用;一般來說,用戶數越多的功能價值越高,對應的需求價值也會越高,調研優先級也會靠前。
每個迭代一般給到產品的設計時間是固定且不多的,假設本次迭代只有4個工作日的時間可以進行調研和設計,產品經理應該怎么安排調研工作呢?
某產品經理需要的調研時間和設計時間比例為1:1,那么調研時間可以安排2個工作日,留下2個工作日進行設計,假設迭代目標是優先實現需求影響范圍大的需求,那么產品經理就可以根據影響范圍去需求池撈需求了,優先挑選影響范圍大的需求,直到已挑選出來的需求足夠兩天的調研量就可以結束了。
通過需求范圍評估可以初步判定需求價值,從而決定需求的調研優先級,在調研時可以將有限的時間分配給優先級高的需求,以實現調研價值最大化。
3. 需求場景清晰度評估
除需求影響范圍之外,需求場景是否清晰也可以在調研前幫助我們初步判斷需求的優先級,每個需求背后都會有一個真實發生的業務場景,但用戶提需求的時候往往只說他以后想要的,而目前如何發生的不會主動告訴你,不告訴你可能是因為沒有真實的業務場景,也可能是提出人不了解真實的業務場景,但真實場景一定是我們設計前需要了解的信息,否則設計的功能很大概率與真實場景不匹配,功能上線用戶卻無法使用,造成設計、開發資源的浪費,所以需求背后的真實業務場景非常重要;
需求業務場景一般包含以下五個要素,人物、時間(頻率)、地點、起因、經過,缺少任何一個環節都會導致設計遺漏,那么在調研前先分析需求是否缺失以上要素,缺失越多對設計的影響越大,調研的優先級也就越高,這種需求就要花費更多的時間去調研;
當手上有多個影響范圍相同的需求待調研時,如何判斷先調研哪個需求呢?我的建議是先調研缺失業務要素最多的需求,因為這種需求在調研前是無法進行設計的,你不知道這個功能做給誰用,他習慣如何使用,想要達到的效果也不知道,只能先去調研再設計;而只缺失一個要素時,你至少可以先考慮操作端口,或主要操作流程,或最終展示的結果,帶著已有的部分設計去找客戶調研確認;
通過需求場景清晰度評估可以初步判定需求缺失的要素數,從而決定直接調研還是帶設計稿調研,并清晰的了解本次調研的內容,以實現選擇最優調研方式。
三、總結
需求調研可以幫助我們了解需求,通過一定的了解從而識別需求是否正確,或者是否有價值,如果說需求調研是砍柴,那需求的前置思考就是選刀和磨刀,選一把合適的刀并打磨鋒利,一定可以讓砍柴的工作事半功倍,為了提升調研工作的效率,我們需要構建一套需求調研的前置思考內容,先對需求進行合適的分類,針對不同分類的需求執行不同的調研方式。
產品經理為公司創造價值,公司為產品提供資源,但資源一定是有限的,產品經理永遠都要思考的問題是如何對資源進行合理分配,調研前置思考可以幫助產品經理對調研資源進行合理分配,首先定義價值衡量指標,然后在調研前根據價值指標衡量需求的價值,將更多的調研資源分配給高價值的需求。
前置思考可以幫助產品經理合理分配需求調研的時間和方式,以達到需求調研工作的價值最大化,從他人角度看來工作效率是提升了,但對產品經理自己而言,每一次需求評估都可以離公司目標更近一步,也能離自己的目標更進一步。
本文由 @小小周 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
老板的需求優先級最高,老板認為對就對
老板的需求是例外
細節見真章!
什么場景中會需要?能帶來多少價值?用戶的真實需求是什么?是否有更合適的解決方案?
這些是調研的過程中去考慮的哦~
有用!感謝作者分享,這就用起來!