那些年我走過的彎路之——項目價值。

從業幾年來，火山一直擔任to B類產品經理。to B類產品有一個非常顯著的特征：那就是業務部門對于產品形態往往都具有非常強的話語權，有時甚至是可以主導產品的走向，這一點我在上一篇文章《產品經理大忌：脫離用戶》中已經做過一些闡述。大多數時候，業務部門的需求就像是連珠炮，一個接一個，讓產品經理應接不暇，我們每天都能夠聽到這樣的一些話語：

這個xx需求抓緊做，要不然客戶就丟了！

那個xx功能什么時候可以做好呀？客戶每天都在抱怨！

我有一個大客戶，需要xxx功能，我們能做客戶可以簽得下來。

……

互聯網公司的資源永遠都是緊張的，創業型互聯網公司尤其如此。這些漫天的需求撲面而來，為了盡可能地滿足業務需求，那個時候我們可以說已經是把一個資源掰成兩份來用。相當長的一段時間，我們整個產品、技術團隊都保持著“996”的工作強度。但即便如此，業務方還是會抱怨我們速度慢，效率低，提了好多需求都沒做。

面對這些接踵而至的一些需求，實際上火山當時已經自己總結摸索出了一套用Excel設計的一套需求管理工具，利用這套工具，我們可以隨時根據實際需要，按照多種維度進行靈活的優先級排序。但工具再好它也只是個工具，最終執行的時候還是靠人、靠團隊來決策的。

以往需求決策邏輯

對于堆積如山需求，我們決定先做哪個后做哪個的時候，決策邏輯大致會有如下幾種：

1、誰強勢誰優先。

當技術部門與業務部門的需求發生碰撞時，往往業務部門取勝，因為業務部門比技術部門更強勢；當銷售部門和客服部門的需求碰撞時，往往是銷售部門取勝，因為銷售部們比客服部門更強勢。

2、誰是領導誰優先。

即領導提的需求，基本都是優先執行的，多個領導同時提，那就是那個領導官大，那個領導的優先級就更高。當然，這里需要特別說明的是，這里的領導不包括我們的CEO，我們的CEO是一個情商比較高的人，他經常都是一副我只是提需求，優先級你們排的態度，我們即便不把它的需求往前排他也不會放在心上，因此這條原則對CEO無效。

3、誰催的急誰優先。

差不多的兩個需求，A盯得緊，天天催，B偶爾催一下，那基本就是A的需求先做。

4、誰實現快誰優先。

兩個需求都很著急，A需要2周才能開發完成，B只需要2天，那基本就是B先做。

5、誰在外部誰優先。

經常聽到的措辭就是：這個功能自己人用的，克服一下，先把這個客戶的做了吧，這個需求不做客戶簽不進來啊……所以，幾年來很多內部需求大多都是一拖再拖。

現在回想起來，這些原則不見得都錯，但是你是否已經發現，我們決策先做什么后做什么的時候，我們缺了一根弦，一根很重要的弦——項目價值。

項目價值

跳槽到現在這家新公司之后，我發現即便是在這樣一家技術團隊資源10倍于上一家公司規模的公司，依然面臨著資源不足的窘境，每天都有來自各方的源源不斷的需求，永遠都做不完。公司給我分配了一位非常優秀的前輩導師，雖然年紀只比我大1歲，但是工作能力卻比我強太多。

我觀察到，我的導師面對各方提過來的需求時，一般都是在耐心聽完對方提的需求之后，反問對方一句話：你覺得做這個項目能產生多少價值？這個問題很關鍵，除去一些影響流程的緊急修復優化類的bug或項目之外，大多數常規的需求在經過這個問題的“洗禮”過后，都可以更加“輪廓分明”地展現在我們面前，比如：

銷售：這個xx需求一定抓緊做，這個月底做不出來，客戶就丟了！

產品：你的心情我非常理解，不過我能先了解一下做這個項目能帶來多少價值你們有評估過嗎？

銷售：能為我爭取回來一個實實在在的客戶，這就是價值??！

產品：這個描述太抽象，能否通過一定的方式把價值量化一下，比如我們評估一下這個客戶一個月能給平臺帶來多少銷量。

銷售：前期量不是很大，大概5萬/月。

產品：也就是說大概一年60萬，假設后期量有增長，一年100萬銷量差不多吧。假設我們做了這個項目幫你簽下來這個客戶，按照現在毛利3%計算，做這個項目大概可以給我們帶來的利潤價值是3萬/年，對吧？

銷售：差不多吧。

產品：我們做好這個需求需要2個開發+1個產品+1個測試，工期大概兩個月，按照人均12k計算，人力成本差不多需要9.6萬，換句話說，我們至少需要3年才能收回我們的投入的人力成本……

銷售：額……那好吧，那你們按照你們的計劃排把，盡量給我往前排就好……

這就是繃緊一根“項目價值”的弦之后的效果！就像這個案例一樣，我就經常發現，有些一開始提需求提得很火急火燎、理直氣壯的人，在經過這個問題的“拷問”之后，慢慢就不那么言之鑿鑿了，開始接受暫緩需求，甚至于有些最后自己主動放棄了。

產品經理核心工作——需求管理

如果要用一個詞來總結產品經理崗位工作的核心內容，那火山的答案一定是——需求管理。

每家公司，每個產品經理手里都積攢著堆積如山的需求，這些需求可能來自用戶、銷售、客服、老板甚至是競品，每個需求的提出都自有他們的合理性，那么哪些需求要做哪些需求不要做，哪些需要現在就做，哪些可以以后再做，哪些需求需要一次性做完，哪些需求需要分階段實現，這中間的取舍考驗著產品經理的智慧。

我們都知道，一個需求的優先級是由它的重要程度、緊急程度、工作量、需求來源等等各個方面綜合確定的，而在我的需求管理工具里面，實際上也有考慮一個需求帶來的價值，即“重要程度”的評判維度。但在很長一段時間里，我們都在疲于應付一些所謂的緊急需求，對重要程度這個維度根本就沒有做深入地思考，重要程度指數基本都是產品經理憑感覺確定。也就是說，在我們的決策邏輯里面，實際上是缺少了項目價值這根弦。而這種狀態直接導致的結果就是，我們看似做了很多的努力，到最后卻依舊發現我們的產品并沒有質的變化。

如何繃緊“項目價值”這根弦？

那么有沒有什么辦法，可以讓我們在做產品決策的時候繃緊項目價值這根弦，保證它不被遺忘或忽視呢？

對于這個問題，在成熟的互聯網公司實際上基本是不太存在的，因為一個項目在立項的時候，它的項目價值是必須要寫明的，如果沒有寫清楚項目價值，或者項目價值評估得不切實際，那根本立項就是通不過的。也就是說，在成熟的互聯網公司當中，這根弦已經通過比較規范的需求管理的流程來保證了。那么，如果你身在一家尚未形成規范流程的創業公司當中，如何才能讓自己繃緊這根弦呢？實際上，弦能否繃緊是意識問題，終究得靠自己，我也無法回答，但當我們拿到一個需求，對于要不要做以及什么時候做的問題，火山可以分享一點心得。

想清楚這個問題說難也不難，依據個人經驗來看，90%以上的需求，對于“要不要做以及什么時候做的問題”，如果能想清楚兩個問題，基本就能解決一大半了，這兩個問題就是：

1.做完之后，這個項目能帶來什么價值？

銷量提升、成本節省、用戶增長等維度，盡可能量化。

2.如果不做，會有多大的影響？

人工成本、客戶丟失、用戶抱怨等維度，看看這個影響是否可控可接受。

以上就是今天分享的內容，希望對各位在產品路上不斷前行的PM門能夠有所啟發。

本文由 @ 火山 原創發布于人人都是產品經理。未經許可，禁止轉載。