作為產品經理或者交互設計師,亦或者 UI 設計師,每天都會遇到各式各樣的需求。有的一句話,有的一個簡單的文檔,有的只是一個線框圖,各種程度的資料,不一而足。特別是如果在一個 ued 部門內的時候,處理的需求更為繁雜。如果沒有一個比較好的處理排序優先級的方法,很容易將需求層級搞混亂,從而導致整體研發進度受影響。

當前在需求分析階段,比較受歡迎的主要是 KANO 模型分析法、BCGmatrix 分析法、MoSCoW 分析法,這三個又被稱為「需求分析三劍客」。還有一個最近也比較受歡迎的分析方法,就是 RICE 法則,又稱為大米法則。在一個團隊中,不會過于去依賴某一個分析法,綜合的運用和考慮才能夠更高效和快速的處理當前的需求池。

這四個方法,難不成在我們日常處理工作需求的時候,一個一個的去嘗試?顯然,這是一種依葫蘆畫瓢的行為。在比較長的工作項目中,我們多少有了一些運用的經驗和理解。希望接下來的講述,也可以對你解決多而復雜的需求分級有一定的幫助。

簡略思路

BCGmatrix 分析法、RICE 分析法,這兩個的針對對象層級都含有產品層,或者說用戶體驗要素中的戰略層考慮。而 KANO 模型分析法和MoSCoW 分析法,偏向針對的是具體的產品功能層級,所以,在我們考慮需求優先級初步判斷的過程中,可以優先使用 BCGmatrix 和 RICE分析法進行判斷。這其中 RICE 分析法,也可以針對產品功能層級進行分析(后文會詳細闡述)。BCGmatrix 從對用戶價值和對公司價值維度,也可以涉及到功能層級。但這并不妨礙優先使用此兩個方法。

通過前兩個方法,就可以優先排除一部分偽需求存在,但是下沉到產品功能層級的時候,就不可以再接著運用 RICE 方法了??梢詮腂CGmatrix 分析法角度,篩選出需求的維度(對用戶價值高還是對公司價值高)偏向。再結合接下來的兩個分析法,以團隊實際和公司業務實際,來判斷需求處理的策略和優先級。

介紹具體方法的日常思考運用

1. BCGmatrix分析法

波士頓矩陣是由波士頓咨詢公司創始人布魯斯·亨德森于 20 世紀 60 年代首創,被視為企業戰略策劃時代的一個節點。作為分析企業成長(企業實力)與市場份額(市場引力)之間的關系的工具,它高度概括了企業戰略決策的一般方法,最早用于分析企業的市場增長率和市場份額(市場占有率),又稱為「市場增長率-相對市場份額矩陣分析、產品系列結構管理法等」。

雖然波士頓矩陣方法最初并非應用于互聯網領域,但是后來經過變化升級,漸漸的開始在互聯網領域應用。特別是在產品需求優先級的判斷上。

?產品層篩選

依據當前公司或者團隊產品偏向,或者新的業務場景需求對于當前公司產品的增長率或者市場占有率影響性,初步區分需求池中真偽需求存在。此時,有些內容需求恐怕需要進行完整的報告文檔,比較偏向戰略層的決策,都是上層推動的。你的意見建議,必須拿出有力的證據,才可以讓管理層認識到你的建議是對的。

例如在「易出行」(已隱去真實項目名稱)中,當時涉及到幾個新的業務場景接入的問題,涵蓋掃碼、維保、充電等,那么到底優先接入哪個場景的業務?關于戰略層的決策,一般做為產品經理或者交互設計師,是沒有權限參與的,除非你已經達到總監級別了。當時,比較看好的是維保和充電,主要是結合市場層熱度以及結合我們內部項目主營業務來決定的。但是,卻忽略了團隊的資源配置以及所處階段的更為重要的任務是搶占垂直市場,而不是去和其他已有實力的人搶份額。

當然,關于最終的建議和討論是我們 UED 部分大佬去和老板說明的。但是關鍵點你是可以和老大去表明的。

產品功能層篩選

正如上圖所示,對用戶有價值的需求,一般屬于用戶需求;對公司有價值的需求,一般偏向產品需求。這個時候,就看一下,其需求的本質是偏向哪一種類型了。

明星功能需求

即對用戶有價值,同時對公司也有價值的產品功能需求??梢约葷M足用戶的部分需求,又可以實現產品的部分目標需求。和在企業規劃中一樣,處于雙高級別,是優先級最高的需求。例如,在我們某一個場景的門店列表中是否增加導航入口這一功能,一方面,用戶購買之后,可以快速方便的去到附近門店消費,一方面門店提升了營業額,對我們平臺的信任度增加,這個功能就可以劃歸明星類產品需求。

問題功能需求,問題類需求雖然表面對公司沒有直接的商業價值,但是從對用戶價值角度而言,可以提升用戶的滿意度和忠誠度,所,綜合來說,這類需求從本質上來說也是對公司有價值,只是不直接。之所以是問題需求,因為會隨著時間或者業務變化,會變成明星需求或者現金牛需求,甚至會變為瘋狗需求。最終走向,存在不確定性,有很大的風險。

例如,掃碼挪車這個需求,這個是一個不高也不低的需求,但是對于用戶而言,很多時候,又是一個非常必要的存在。特別是一二三線城市,因為各種原因,總有需要聯系車主挪車的情況。它短期內,對于公司產品來說,其實算是一個雞肋的功能,和主營業務沒有強相關。但是對用戶的確有價值的,所以,我們在前期推廣的時候,很多人還是比較樂意注冊,但是出現了一個小失誤,就是沒有處理好注冊使用的流程限制門檻,比較繁瑣。結果可想而知。

現金牛類需求,這類需求比較明顯的自然就是對公司有明顯的價值,但是從用戶角度而言,多少會有一些負面影響。從理論上來說,應該盡量避免對用戶體驗造成不良的影響。但是,需要看公司產品的情況的。

例如,當前各種游戲非?;馃?,當然,似乎游戲一直都是比較熱的。但是在你玩游戲的過程中,會常常引導你去看直播,這種體驗,你應該不陌生。那么像是某易或 TX 為啥這么做呢?之前公眾號也有文章說明,這種就屬于現金牛類需求,公司的目的就是希望引流賺錢以盈利。

瘋狗類需求,最后這種需求,就是和第一類需求相反的「雙低」需求,也就是我們常說的偽需求。需要你判斷出,并盡量去排除掉。

其實從以上幾個需求類型的分類闡述,就可以看出對于問題類需求和現金牛需求,考慮的時候,需要多考慮一步。在產品成長初期,例如我們之前的「易出行」,獲取用戶增長和提升用戶的留存率是第一要考慮的,那個時候,我們并沒有去考慮如何去盈利。所以,問題類需求優先級高于現金牛需求。

但是如果產品處于穩定成熟期,例如,現在的很多超級 APP,公司的目標自然都是以提升盈利水平為第一要務,像是「拼多多、瑞幸」等。

除此之外,我們在考慮需求的時候,涉及的因素是非常多的。上述的波士頓矩陣也只是提供我們一個分析的思路和處理的方向。自然還有其他的方法,可以幫我們進一步的去驗證其合理性,例如:RICE 法則。

2. RICE分析法

一個好的優先級排序框架可以幫助你用清晰的思考去理清項目里面的每個因素,并以嚴謹、一致的方式將這些因素結合起來。但是你可能很難找到一個能讓你以一致的方法去對比不同思路的系統。所以,我們需求掌握不止一種分析思考的方法,才可以有效的管理我們的工作和生活。

RICE 是用來評估各項目需求的四大因素的首字母縮寫:觸達(Reach),影響力(Impact),信心度(Confidence)和努力(Effort)。

REACH觸達

為了避免出現主觀需求的偏差,我們應該評估每個項目在既定時間內會影響多少人。對于我的團隊來說,就是「在一個季度內,這一個項目將會影響到多少客戶?」

觸達范圍是衡量每個時間段內產生的用戶數或活躍數。也許會是「每季度客戶數」或者「每月交易額」。盡可能使用產品指標中真實的測試數據而非虛構的數據。最終,我們選取的是 DAU 和 MAU。

舉例:

  • 每個月,目前有 10W 個客戶(總部支持,有推廣位,且每月都有營銷活動),能夠進入到注冊漏斗的階段,有 30% 的人選擇這個選項,那觸達的結果就是每月 100,000 x 30% = 30,000個客戶。
  • 每個季度,每個使用該功能的客戶都能看到這個改變。那觸達的結果就是每季度 60,000 個客戶。
  • 這個改變將會對 50W 個現有客戶造成一次性影響,但并沒有持續的影響。那觸達的結果就是每季度 60,000 個客戶。

IMPACT影響力

關注項目中直接影響結果的數據,評估獨立個體的影響程度。對于團隊來說,就是「當有客戶接觸這個項目,它能夠提供多少轉化率?」 你的團隊也許會用其他的指標來取代,比如「提高使用率」或者「最大化用戶滿意度」。

影響力很難精確的衡量,所以可以設定幾個加權選項:3 代表「重大影響」,2 代表「高度影響」,1 代表「中度影響」,0.5 代表「低度影響」,以及最小的 0.25 代表「輕微影響」。這些數字將作為權重值與各項評分相乘,加權得出評估結果。

選擇影響力的權重值看起來似乎不太準確,另外的一種方法就是依靠個人的經驗直覺。

舉例:

  • 對所有看見它的客戶而言,它都能產生巨大的影響。則影響分數為 3。
  • 這對每個客戶而言將有比較少的影響。則影響分數為 1。
  • 產生的影響程度適中,則影響權重為 2。

CONFIDENCE信心

為了遏制對于鼓動性強但概念不明的想法的熱情,需要把評估的信心水平也考慮進來。如果你認為一個項目本可以有巨大的影響力,但是并沒有足夠的數據來支撐這樣的看法,這時,你對該項目的掌控度源于你的「自信度」。

自信度是一個百分數,可以采用一個有多項選擇的量表來輔助避免決策失誤的可能性。100% 是「信心程度高」,80% 是「中等」,50% 是「低」。任何時候,如果信心程度低于 50%,那根本就是天方夜譚。坦白告訴自己,你的評估,到底有多少事實和數據支持?

舉例:

  • 我們有影響范圍的量化指標、影響力的用戶研究、努力程度的工程評估。那么這個項目有 100% 的信心度分數。
  • 我有數據支撐影響范圍和努力程度,但是對影響力不是很確定。這個項目有 80% 的信心度分數。
  • 影響范圍和影響力可能比評估的還要低,努力程度可能比評估的還要高。這個項目有 50% 的信心度分數。

EFFORT努力(這里我們理解的是工時)

為了能夠快速發展并用最少的努力獲得影響力,從團隊的所有成員出發,去評估一個項目需要的時間總量,包括產品、設計和開發。

努力程度的評估是以「人-月」(一個團隊成員一個月的工作)為單位對努力程度進行評估(我們團隊的日常評估是「人-天」,這里我們采用他們的單位)。這里會出現許多未知情況,所以為了讓評估留有余地,在這里我采用整數,或者用 0.5 來代表任何小于一個月的工作。不像其他的正向因素,更多的努力程度是一件壞事,因此我把它放在了分母,來除總的影響力。

舉例:

  • 該項目將需要 1 周的規劃,1-2 周的設計,以及 2-4 周的工程時間。我給它的 1「人-月」的努力程度分。
  • 該項目將需要幾周時間來規劃,非常多的設計時間,一個工程師來做至少需要兩個月。我給它的 2「人-月」的努力程度得分。
  • 該項目只需要 1 周時間來規劃,沒有新的設計,而工程時間需要半月開發。我給它0.5「人-月」的努力程度得分。

RICE分析法公式得分算法

一旦你完成了這些因素的預估,把它們合并成一個單一的得分,這樣你就能一目了然的比較不同項目的分數了,如下方公式:

一旦最初的評分完成,排序你的項目表單,并重新評估。有沒有哪些項目的分數似乎太高或太低?如果是的話,重新考慮你的估算并做出調整,或者接受你的直覺可能是錯誤的。在決定難以比較的項目想法時,RICE 可以提供極大的幫助。它迫使你思考為什么一個項目會產生影響力,并且誠實地預估為達到目標所需的努力程度付出。

多數時候,我們只需要評估一個大概就會比較明顯的可以得出,哪些需求是優先級比較高的,哪些是偽需求的。

怎么說呢,這個 RICE 法則分析,和后面的 KANO 模型分析在量化指標這塊,比較好明晰的。但是回歸產品業務場景來說,比較難以一時間可以看出,先做哪個的力證。所以,關于 RICE 法則,產品可以多考慮一下,因為在我們看來,這個更多的是偏戰略層的。交互或者用戶體驗設計師,可以做到了解其分析原理即可。

參考資料:

https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/

3. MoSCoW法則分析(莫斯科法則分析法)

在 PRINCE2 中有一種叫 MoSCoW 的排序法。其名稱是 4 個級別的首字母縮寫。這 4 個級別分別是:Must:必須做的/必須有的;Shoud:應該做的/應該有的;Could:可以做的/可以有的;Wouldnot:現在不可做/現在沒有的。

以之前易出行后臺服務系統為例,在定制化開發軟件產品前,項目組和產品經理通常會開展用戶調研。在調研中,不同用戶會從自身場景提出許多需求。當期項目的產品功能應該滿足哪些用戶的哪些需求就成了一個待回答的問題。MoSCoW 排序法提供了一種思考方式,引導大家圍繞交付物展開思考:

哪些需求是必須有的、對應的功能是必須做的,如果缺失則產品不可行、或者會嚴重影響用戶最終的使用目的;哪些需求對應的功能如果可能的話是應該有的,即便用戶可能沒有想到或意識到;哪些需求對應的功能是可以有的,即便本期項目沒有也無傷大雅,或者有其他替代方案;哪些是不能有的,是一些不合理的需求。

使用 MoSCoW 排序法的優點是:

體現了PRINCE2關注產品(最終交付物)的原則。

在使用 MoSCoW 為需求排優先級的時候,實際上是圍繞交付物思考,在排序的同時劃定了產品的功能范圍以及當期項目范圍,一舉多得。避免了盲目響應需求、輕重緩急拎不清,導致的范圍蔓延。

明確了產品(交付物)的定位和演進方向。

這一點在 PRINCE2 中沒有明確提到,但在工作中卻能實實在在感受到的。我們仍以易出行車主服務系統為例:用戶提出的需求實際上是從自己角度出發的,往往方向差異很大。對需求響應的排序,實際上影響了產品定位——到底要解決誰的什么問題。

系統上線后,用戶在使用中還會不斷提出新需求,一些需求如果不仔細斟酌就盲目響應,會導致系統被改成「四不像」,淪為功能模塊的堆砌,背離系統設計之初的定位,這個時候,特別是內部孵化項目或者中小型團隊公司的項目,還容易受直接管理層的意見左右,雖然這種情況,難以避免,但是希望我們可以明確一個立場「這個公司不是你的,但是這個項目在由你負責的時候,就是屬于你的」所以,它的好壞也是你職業生涯中的重要一筆,希望可以必要的時候,力爭一下。此時,運用 MoSCoW 方法,能協助項目組或產品經理理清思路,明確產品演進的方向。

但同樣的,這個分析方法也有其一定的缺陷,比較明顯的就是:must 和 should 兩個層級的需求輸出的時候,會產生一定的迷惑。因為這兩個層級,比較難以區分。所以,這個時候,kano 模型分析法也許就該走上前臺了。不同的優先級排序方法背后是不同的思想和視角,但是我們可以從自身需要出發,去結合合適的方法,而不是按本文的順序去一一試驗哈。

歡迎關注作者微信公眾號:「PGDWORKS」

點贊 1
收藏 7
繼續閱讀相關文章

發表評論 已發布 1

還可以輸入 800 個字
 
 
載入中....
1 收藏