價值的優(yōu)先級

我們已經(jīng)學(xué)習(xí)過了從財務(wù)的角度來說，一個產(chǎn)品的價值是如何體現(xiàn)在金錢利潤上的。這件事本無可厚非，但是，在價值驅(qū)動交付的開篇，我們又說過，一個產(chǎn)品的價值也并不是完全的體現(xiàn)在錢這件事上。因此，矛盾也就產(chǎn)生了，那么除了財務(wù)維度外，我們還應(yīng)該怎樣衡量一個產(chǎn)品中各項任務(wù)的價值優(yōu)先級呢？

這也是我們今天要解決的問題，所幸的是，在敏捷的工具中，也有一些方法是專門用于處理這些問題的。

基于客戶價值的優(yōu)先級排序

這些技術(shù)就是為了能夠讓客戶也參與到排序過程中，目的是盡快地為客戶產(chǎn)生最高價值的工作。團隊可以識別到一些具有高價值的特性，并且將一些低價值的特性后移。優(yōu)先級排序整體來說就是讓團隊能夠保留有用的功能的前提下調(diào)整范圍以滿足預(yù)算或時間目標(biāo)的基礎(chǔ)。

團隊?wèi)?yīng)該基于項目的需要和如何做對組織更為有利來選擇優(yōu)先級排序的方案。比如有下面將要說的這些。

主觀判斷

通過個人經(jīng)驗的主觀判斷來決定 待辦事項列表 的優(yōu)先級。這個其實對于具有豐富經(jīng)驗的 PO 和 SM 來說并不是什么特別大的問題。因為如果是長期從事同一個行業(yè)的產(chǎn)品開發(fā)，并且有過長時間合作經(jīng)歷的 PO 和 SM 來說，確實有可能會通過他們的主觀經(jīng)驗來獲得一個非常合理的優(yōu)先級排序。但是，凡事總有兩面，有些東西確實僅憑經(jīng)驗是不夠的，畢竟我們所處的是一個不斷變化的時代。這一點在 互聯(lián)網(wǎng) 行業(yè)體現(xiàn)得尤其明顯。

MoSCoW 優(yōu)先級排序

這個單詞不好記，那就記住 莫斯科方法 。它是在 DSDM 中使用的一種優(yōu)先級排序的方案，這個縮寫代表的是：

• Must：必須做的。

• Should：應(yīng)該做的。

• Could：可以做的。

• Would Not：不要做的。

怎么應(yīng)用它呢？很明顯，將 待辦事項 和這四個方向一一對應(yīng)。Must 就是不管怎么樣都一定要做的東西，如果沒有這個功能，那么這個產(chǎn)品就沒法用；Should 是應(yīng)該會有的功能，有了這些功能產(chǎn)品就可以正常運作，如果沒有它們，產(chǎn)品用起來會非常麻煩或者很耗費資源；Could 就是錦上添花的功能，有了可能會讓用戶更開心，沒有的話也并不會對我們的核心功能造成什么影響；Would Not 則是至少在目前階段下，我們確定不會有的功能。

還是拿電商的項目來舉例。

Must 當(dāng)然是用戶、商家和訂單流程。要讓用戶能買到東西，商定能賣東西，中間有一個訂單流程可以讓產(chǎn)品到用戶手中。注意，這個一定是必須的，貨物送不到用戶手中，其它的一切都無法讓他成為一個電商項目。繼續(xù)分析，用戶模塊（登錄注冊、瀏覽商品、下訂單）、商家模塊（登錄注冊、上下架商品、訂單處理）、訂單流轉(zhuǎn)模塊，請先至少完成這三個模塊。這里我們不用考慮得太細，先確保這個流程能夠走通就可以了。

經(jīng)過 Must 開發(fā)之后的產(chǎn)品可以用嗎？當(dāng)然可以，但是，我們需要快遞員貨到付款，為什么呢？因為上面并沒有提到支付模塊，所以支付模塊是一個 Should ，它可以讓產(chǎn)品更好用。另外，商品的評價模塊也能夠提升用戶的滿意度和商家的競爭意識，也是一個可以考慮的 Should 模塊。其它還有什么呢？大家可以自己想想然后在評論區(qū)留言討論哦！

Could 的話，運營玩法，優(yōu)惠團購都是可以考慮的模塊。另外，現(xiàn)在火爆的電商直播也是可以考慮的方向。當(dāng)然，它們并不影響你的整個下單購買流程，但是卻會讓你的購物過程更開心。這個地方其實是很考驗 PO 和 運營 團隊的。

Would Not：這個看過之前文章的同學(xué)一定馬上就想到了，早期的分成分利。訂單功能剛開發(fā)好你就準(zhǔn)備一鍵代發(fā)了，剛有幾個人下單你就考慮各地分公司如何提成分潤了。訂單量剛過 10 就馬上要去開發(fā)一個 花唄（金融工具） 想讓用戶更多地下單了。這種事情好好想想，可能嗎？還是盡量 No No No 吧！

Kano 分析

莫斯科方法好玩嗎？還有一個跟他非常類似的，Kano 分析，中文可以叫做 卡諾分析 。先看一張圖。

在我們繼續(xù)之前，先自己看看這張圖，看看能不能看懂它所表達的含義。

在 Kano 中，有三個重要的評價維度，沒錯，比 莫斯科方法 少了一個。不過這三個維度我覺得比 莫斯科方法 更好用。它們分別是：

• Must be：必須具備的，這個和 莫斯科方法 的 Must 是一樣的，沒什么多說的。

• More is better：期望的，從英文翻譯可以看出來，有了會更好，類似于 莫斯科方法 中的 Could 和 Should 。

• Delighters：超出預(yù)期的，做出了客戶都沒想到的驚喜功能。

注意，在這里，沒有了 Would Not ，這是因為 Kano 方法認為沒必要為不需要做的東西單獨準(zhǔn)備一個維度。Kano 分析面對的是真實的可用型的需求。所以這三個維度其實也是對應(yīng)了三種需求：

• 基本型需求（Must be）：這是一個門檻，也是產(chǎn)品必須要實現(xiàn)的功能，沒有這些功能的產(chǎn)品不能認為是一個可用的產(chǎn)品。當(dāng)這個需求無法滿足時，客戶會很不滿意，但是它也是有局限性的，就像最下面紅色的箭頭。這一部分的功能你做得再好，對客戶或者用戶來說也是理所應(yīng)當(dāng)，無法沖破那條滿意度的橫軸。但是，目前的環(huán)境下，過硬的產(chǎn)品質(zhì)量和口碑是有可能沖破的。

• 期望型需求（More is better）：這種需求被滿足后，用戶會感覺到很滿意，但這些并不是必須的需求。這種需求越多越好，因為從圖中我們可以看到，它是呈線性上升的，也就是說，滿足的需求越多，用戶的滿意度越高。產(chǎn)品的價格通常和這個期望型需求相關(guān)，但也并不是絕對的。比如蘋果產(chǎn)品就是出了名的功能少。

• 興奮型需求（Delighters）：它和期望型需求被滿足的不同點是，這部分需求很大一部分是用戶自己都不知道的，但是卻能帶給用戶極大的愉悅感，所以在上圖中我們會發(fā)現(xiàn)它的曲線會呈現(xiàn)優(yōu)于線性增長的趨勢。反過來說，這一部分也就是最需要創(chuàng)意的部分。往往一個產(chǎn)品的創(chuàng)新就是從這里體現(xiàn)的，比如說抖音和快手的橫空出世。當(dāng)然，這一部分需求如果沒有，也是不影響整個產(chǎn)品的。比如騰訊一直想做電商，但是一直失敗，卻并不影響他的微信和QQ，反而是微信支付這個金融產(chǎn)品成為了一個讓用戶非常興奮的功能點。

雖說在上面的這幾個需求的解釋中我都講了一些反例，但是這些反例其實很極端，因為沒有第二家蘋果。而大部分情況下，遵循 Kano 的分析總是會讓你少走一些彎路的。

相對優(yōu)先級排序

相對優(yōu)先級排序就是要和一些屬性進行比較，獲得的是一個相對值，其實就是根據(jù)成本、風(fēng)險和處罰后能提供最大益處的特征（功能）給予最高的優(yōu)先級。比如說，我們的特征（功能）要和它所提供的價值成正比，但要和它的成本及風(fēng)險成反比。然后使用一些數(shù)值來表示這種關(guān)系，最后根據(jù)獲得的值來確定排序順序。

它的好處是反映功能如何體現(xiàn)價值，并且同時反映功能缺失時，客戶體檢到的消極程度有多少。其中，風(fēng)險也會反映功能所帶來的挑戰(zhàn)有哪些，而成本則會反映 實現(xiàn)功能的實際成本要花費多少。

綜上所述，相對優(yōu)先級排序需要的數(shù)據(jù)、維度更加廣泛，是一種理性的純數(shù)據(jù)方式做出的優(yōu)先級排序。

總結(jié)

又是一堆概念和工具，不過相比上篇文章偏計算的那些內(nèi)容來說，這一部分還是好理解的多。有沒有發(fā)現(xiàn)，這些東西其實和 產(chǎn)品經(jīng)理 職責(zé)中的 可行性研究分析 的內(nèi)容非常相似。在 產(chǎn)品經(jīng)理 相關(guān)的課程及文章中，也會經(jīng)常見到這些內(nèi)容。其實說白了，價值驅(qū)動交付本身就是 PO 的核心職責(zé)。所以我們一直在講產(chǎn)品經(jīng)理的東西也就不奇怪了。

參考文檔：

《某培訓(xùn)機構(gòu)教材》

《用戶故事與敏捷方法》

《高效通過PMI-ACP考試（第2版）》

《敏捷項目管理與PMI-ACP應(yīng)試指南》