全栈工程师?
嗯.....目前并不是!

需求的優先級,如何評估?

需求的優先級是產品經理工作中常被提及的,那麼在產品工作中,要如何去評估需求的優先級呢?

在產品經理的工作中,需求優先級是經常被提及的事情。畢竟資源總是有限的,需求是無限的,想利用有限的資源來做無限的需求是不現實的,所以需要給需求排優先級。只是這個優先級怎麼定義,一直是個問題,下面我來講講我的理解。

  • 首先,需求來源於我們的目標用戶,我們的需求是用來解決用戶遇到的摩擦。所以,優先級定義的第一個維度就是摩擦的強烈程度。舉個例子:對溫飽的需求的強烈程度會遠遠高於文化生活的需求。
  • 其次,用戶的摩擦,存在一定的發生頻率,頻率可能從“時時刻刻”到“百年一見”,很明顯,如果頻率越高,那麼用戶這個需求就越迫切。
  • 最後,需求的滿足都是需要一定的成本的,產品經理需要對自己的投入產出比有一定的衡量。

所以總結一下,需求優先級可以暫時定義為:

一、重要程度

對於重要程度,需要時刻考慮兩個維度:用戶的維度和公司的維度

我們需要為用戶考慮,因為他是我們需求的直接來源;我們需要為公司考慮,是因為我們本質上是為了公司服務的。在產品生命周期的初始階段,我們需要多為用戶考慮多一點,這樣產品才能成長起來;在生命周期進入穩定期時,這時候就需要多為公司考慮,從而達到盈利的目的。

由於公司的維度和用戶維度大多時候都是衝突,所以我想先從用戶層面來剖析需求,最後引入到公司的維度。用戶的維度而言,有一種經典的模型:卡諾模型。它將需求分為以下幾種,我用統一的“如果有……就;如果沒有……就”這種句式做統一的解讀:

  1. 必備型需求:如果有這個功能,用戶滿意度不會提升;如果沒有,用戶滿意度會降低;
  2. 期望型需求:如果有這個功能,用戶滿意度會提升;如果沒有,用戶滿意度會降低;
  3. 魅力型需求:如果有這個功能,用戶滿意度會提升;如果沒有,用戶滿意度不會降低;
  4. 無差異需求:如果有這個功能,用戶滿意度不會變化;如果沒有,用戶滿意度也不會變化;
  5. 反向型需求:如果有這個功能,用戶滿意度會下降;如果沒有,用戶滿意度不會變化。

這五類可以用下面的圖來展示,為了方便理解,我把線條都畫成直線或者折線。

對於這5種需求的分類中,有些人會把發生頻率也納入到評估體系中,但是嚴格來講,這是不對,這5種需求劃分應該只跟產品的定位有關係。

舉個簡單的例子:

  1. 對於網盤,它的定位是一個“在線存儲”的產品。其最基礎的功能應該是:增、刪、改功能,所以這三個是作為必備型的需求。
  2. 接着,如果文件越來越多,那麼就會有管理的需求,這時候需要有文件夾分類、移動文件和複製文件等功能,所以這些會作為期望型的需求。
  3. 如果網盤能提供高達1T的存儲空間,那麼這個功能就作為一個魅力型需求。
  4. 如果網盤提供一個功能:用戶可以選擇讓文件大小顯示精確到小數點后10位的功能,這個對於大部分用戶來講是無感知的,那麼這就是一個無差異需求。
  5. 如果你在網盤裡插入廣告,那麼用戶會反感,這就是反向型需求。

這5種需求里在產品的生命周期的不同階段,優先級各不相同。初期是必備型需求佔優,第一個版本需要做出一個最小的可用產品,才能投入到市場里。在後續迭代里,需要穩步地加入期望型功能,然後每個迭代版本加入一兩個魅力型功能,也就是傳說中的“亮點”功能,用以配合產品的宣傳。大部分的無差異需求和反向型需求是不會被安排的,除非對於公司來講,這些需求有其他方面的價值。

比如:某手機廠商之前標榜的后蓋的弧度打磨經過了xx個版本。這種弧度的差異接近於無差異功能。但是為什麼還要做這個事情呢?因為這可以作為一個營銷的亮點,打造“匠心公司”的一種品牌形象。

再比如,反向型的需求常見於各種商業化的需求,不管是廣告、還是增值服務、道具收費等,這些都可能陰氣用戶反感,但是可以增加公司營收,所以這些需求在最後產品穩定期,都會作為重點去坐。

總結一下,需求重要程度的評估既需要考慮對於用戶的價值,還需要考慮對於公司的價值,以及考慮所在的產品周期。

二、頻率

頻率這個詞比較好理解,這是一個比較客觀的標準,大家對這個詞也很熟悉。只是,我有一個有趣的想法想跟大家分享一下:摩擦的發生頻率不僅僅是存在於實際遇到的時候,也存在於用戶自己的想象中。

舉個簡單的例子,對於鬧鐘,一開始大家都習慣於“周中”的鬧鐘,即周一到周五的鬧鐘。因為大多數的情況下,我們都是這5天需要上班上學。但是,大部分的國家都有一個叫做法定節假日的東西,所以就有可能出現周六或者周日上班的情況。

如果,只從“周中”和“周末”這兩個概念來說,是沒辦法滿足用戶的需求的。這時候,就需要引入一個“工作日鬧鐘”的概念。產品會自動判別今天是不是需要上班,從而智能地提醒。

這個現在基本都是鬧鐘產品的標配了,但是,我思考的是這個需求的發生頻率。理論上節假日都是少數,大部分情況下,只選“周中”也是可以滿足用戶的訴求的。但是,如果用戶在設置之後,都需要一直擔心“明天會不會響”這種事情,那麼我認為這個需求的摩擦就一直都存在的。

可能用戶設置完之後沒有感知,但是如果發生第一次、第二次調休遲到之後,這個擔心就會一直困擾着用戶。雖然實際上節假日是少數,但是在用戶的想象中,這確實是一個“每天擔心的事情”,所以從這一點而言,我覺得這個是一個“高頻”的場景,而不是“低頻”的場景。

三、成本

產品經理這個崗位,一直都有一種“管理”的屬性,因為產品經理需要協調好設計、開發和測試同學,共同地完成自己的設想。對於管理者而言,成本的評估一直都是不可繞過的一環。

最基礎的成本,也就是開發成本,開發成本是所有成本里最主要的成本,而開發成本最直接的指標就是開發時間。除此之外,如果涉及到比較複雜的場景,那麼交互設計的成本也是明顯增加。如果涉及到比較複雜的動畫,那麼視覺設計的成本也比較高。最後,還有測試的人力成本。

你以為這就完了嗎?

其實並不是,產品經理自身梳理邏輯以及撰寫文檔也是需要時間成本。這是最常規的成本。有些需求可能還會涉及到商務、法務甚至三方公司,涉及到方面越多,成本就越高。

最後這些零零總總加起來,才是總的成本。提出成本這個概念最重要的一條就是:希望產品經理在評估成本的時候,也要把自己考慮進去。

以上,就是我對於需求優先級評估這件事情上的心得,分享給大家。這種評估方法適用於大部分的需求,除了“老闆的需求”。老闆需求的存在不可以用常理來衡量,如果老闆比較講道理(理想情況下),你可以拿這套優先級評估的方法跟他溝通。如果不行,那麼老闆的需求優先級直接就提到最高了,而不需要經過任何評估。

#專欄作家#

妖葉秋,交互設計師,人人都是產品經理專欄作家。做過ToC產品的交互設計,現在在嘗試ToB的業務。主攻交互,也懂點用研、視覺和產品的知識。愛生活、愛設計、愛讀書、愛總結,頭像下方是我的聯繫方式,歡迎志同道合者與我交流。

本文原創發佈於人人都是產品經理,未經許可,不得轉載。

題圖來自Unsplash,基於CC0協議

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《需求的優先級,如何評估?》
文章链接:https://www.pmbear.com/%e9%9c%80%e6%b1%82%e7%9a%84%e5%84%aa%e5%85%88%e7%b4%9a%ef%bc%8c%e5%a6%82%e4%bd%95%e8%a9%95%e4%bc%b0%ef%bc%9f/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们