如何定義需求的優先順序？

01-14

當遇見多個需求時，怎麼進行排序呢？雖然現在有自己的一些想法，可是感覺不是很完善，希望各位達人幫助解惑。謝謝！

在互聯網公司很常見的問題，無論是不是產品都需要了解，這個問題我和螞蟻金服的產品小夥伴討論過 @張宇航：

一般產品經理比較在乎用戶體驗，金融背景的人在乎商業價值。技術對規劃匹配度要求較高，比如擴展性，架構，系統複雜度。傑出的老闆會綜合幾點，排出優先順序。提高投入產出比。

最後治標的方法是團隊要認同同一個邏輯，統一站在一起，考慮未來產品規劃時，各類需求的據測標準，比如：

1. 用戶體驗（用戶確實需要，且有數據支撐）

2. 商業價值（能帶來收入，有理論依據）

3. 構架規劃（可擴展性強，系統不會在早期過於複雜，未來能夠靈活可配）

4. 優先順序（商業層面的優先順序，技術層面的優先順序）

這樣把標準制定好，再具體去分析某一個問題，就容易一些。比如發現XX提的要求，雖然很好，但是容易過早的造成系統複雜度大大提高。不建議做。

你們帶著這套達成一致的決策框架體系，去分析具體的問題，就可以了。這樣就是老闆和你們一起推進，而不是和老闆對著干。

至於排期，應該是技術來排期，而不是老闆倒逼說要X日完成。

說到底是個價值評估問題，當然是高價值的在前低價值的在後。這麼個排序原則，傻子都明白。

但如何評估價值，卻是個價值觀的問題。

道理或標準到處都有，但為何真正執行起來操作指導意義有限？

於是我們開始懷疑我們掌握的道理和標準是不是普世真理，於是問了這麼個問題。。。其實恰恰搞錯了方向。

首先，這些都是對的。

其次，因為那都是對的，而不是有用的。

因為價值觀這事兒，每個團隊、甚至團隊內每個人的理解都不一樣！

===================================================

其他的我覺得沒必要再說下去了，正確的方法未必可以推導出成功的結果。

如果只是想要方法，我還是那句——道理無比樸素：先做重要的，後做不重要的。

產品經理小技巧丨利用波士頓矩陣分析需求這篇文章或許可以幫到你

我試著用層次樹來拆解優先順序，同層級的指標相互比較列出重要性矩陣來判斷指標權重。

其實就是層次分析法的變種。

比如，

一層放重要性和可實現性

二層分別對重要性和可實現性進行拆解，重要性分用戶體驗、商業價值、緊急程度等，可實現性分外部資源、時間、程序員數等

三層可以對上層再細分

需要的話可以再精確分四層五層...

同層指標打分的時候可以邀請相關人員來幫忙，市場、技術、銷售、老闆都參與進來。

其實需求分級完全可以做一個決策系統出來，按產品進度時期的不同給系統不同的模型，讓系統去搜集不同部門的信息給非主觀型指標自動打分，產品人員輔助決策就可以。

這學期的DSS論文就是這方面的，然而只是想想罷了

我覺得這不是一個單純的需求優先順序的問題，而是如何混跡職場的問題，所以還是需要根據你自身的公司情況自己來考慮。

如果你負責過整個產品團隊，你就知道需求不僅是產品需求，業務需求也會鋪天蓋地的提過來，客服、財務、運營、老闆，這些需求不是在同一個價值體系可以評估的，每個職位和部門都有自己的KPI，你很難評估出他們之間的重要性關係，就算你可以評估客服的需求在幾個月內都一直沒有其他部門的價值高（只是舉個例子），你也不太可能好幾個月不給他的需求排上期…

其實如果僅僅是產品需求你都很難定義優先順序，就算整體上大家都一個固定的指標：訂單量、收益等等，落到具體的case上也不能完全按照這個來劃分，難道新的產品線因為單量或收益暫時不高就一直排不上期，一直需要給成熟的業務讓路嘛，那麼它可能永遠也發展不起來…

大的原則是每個需求的目標和工作量都要可量化，可具體要怎麼解，還要根據公司自身的情況，以及人際關係來平衡，畢竟資源永遠是有限的.

一、確定需求優先順序考慮的四個因素

1，獲得這些功能帶來的經濟或業務價值（客戶角度）

由參與的客戶來提議；

2，開發新功能所需的成本；

3、開發新功能所產生的學習和知識的量及重要性

4、開發這些所減少的風險；

進度風險、成本風險、功能風險，或者分為技術風險、商業風險；

二、風險-價值關係四象限

【風險】

高高風險低價值（避免）高風險高價值（首先處理）

低低風險低價值（最後處理）低風險高價值（其次處理）

低高【價值】

三、確定合意性優先順序

Kano模型：按用戶合意性分為三個等級：必需的、線性功能、興奮點和驚喜點功能

哪個惹不起哪個先，其它都是扯淡。

不得不說這是一個PM在定Roadmap時會遇到的永恆問題。先來定義問題，優先順序是個先後問題，是關於資源如何沿著時間線分布的問題。題目中說了如何排定功能需求優先順序，如果直接對功能需求進行討論，勢必會犯「妄圖在下游去根治上游帶來的污染」的思維錯誤，功能來自需求，需求來自目標，產品經理通常會在三個層面思考問題：目標、問題、解決方案，真實的問題來自於和目標/預期不一樣的現象，下面來說下我的思考框架：

明確目標：基於影響最終目標的因果關係鏈、產品策略、競爭策略來制定目標實現路徑、產品路線，從而明確子目標。
確定目標優先順序：同時關注的目標最好不要超過3個，目標一多，其實就沒有目標了，例如在增長黑客的AAARR模型中，如果如果活躍度高但是留存低，那麼需要階段性的專註於提升留存。
目標內的問題優先順序確定：實現目標要解決的問題？解決方案？解決問題需要的資源？對於目標完成度？回答好這些問題來預估問題的ROI，實際中一個目標往往需要解決多個問題才能達成，此時再制定目標內的問題優先順序，優先解決ROI高的問題。實際過程中應該注意的是如果要解決的問題之間無邏輯/因果/從屬關係，並且消耗資源也不同，那麼二者在時間上是即無內在也無外在關係，可以並行。
Roadmap迭代：「好的解決方案是基於Context對於問題的最優解」，高ROI、高優先順序的項目做完後，由於內部環境、產品自身的改變、競爭對手的動作等原因，有可能Context已經發生了很大的改變，所以適時回顧目標是必要的，基於新的Context來調整Roadmap。

這個方法能的好處：

基於目標、問題去思考，不會在一些和目標不相關的創意上浪費時間，在開放和剋制、發散和收斂之間做好平衡，思維收放自如。
不會在不同目標帶來的問題之間糾結：是應該提高這個頁面的載入速度，還是要獲取1W個用戶？因為這兩個問題就不會被拿來做比較。

PS：實際工作中遇到的項目從自己參與的角度可以範圍三類：有決策權、參與決策、執行。上面是自己有決策權的情況；如果是參與決策，除此之外還要成功的影響決策，這就是一個團隊內溝通的問題了；如果自己只是執行，那往往已經到了解決方案層面了，通過對目標、問題的ROI分析確定重要性，然後用下圖做選擇，並且實際中，往往卵用沒有的事，拖一拖大部分就自然消失了。

誠惶誠恐的瀉藥

在日常生活中，處理任務的優先順序有四種情況：重要且緊急；重要不緊急；緊急不重要；不緊急不重要。這四種情況也是我們處理需求優先順序的原則，即重要性+緊急性。把需求的重要性+緊急性統稱為商業價值原則。

需求那麼多，一些理論的東西百度里有很多。說說我自己的理解

當然是根據用戶的需要啊！你做這個產品之前你肯定想過你這個產品的定位，人群是哪些。根據你產品的功能，需求是跟著產品的使用情況來不斷更改。（當然，產品做很久沒人用自然也談不到需求增加的情況）比如微信定位就是移動社交，那最主要的需求肯定是聊天。當聊天做的多了發現用戶有分享的需求，於是接著做了朋友圈。需求和功能是相輔相成不斷成長的。

而且你只是說「你有自己的想法」，需求需要調研和做畫像的。但像上面說的，不同產品需求不同你的策略也要不同。比如猿題庫，他的定位人群很準確也很好定。而且功能也相對簡單。所以在用戶體驗上下功夫就好~再如陌陌，定位是社交。市面上已經有微信他如何競爭和定位？於是抓住了隱私性降低的陌生人距離社交，這也是需求啊。

所以我的結論是，不同產品不同策略方式。這種問題沒有最優解，所以需要PM非常強的市場敏銳度和策略方案。想一想用戶為什麼用你的產品，粘度從哪而來，解決了用戶的什麼問題。

嗯嗯嗯以上~

按需求重要性，核心需求，次要需求，一般需求

按緊急程度，非常緊急，緊急，一般

按需求實現成本，容易，一般，難

按獲得收益，少，一般，多

1）核心功能（你做的優化對核心功能的影響程度，如果你不做，會影響核心功能的體驗，就必須得做；如果做了是優化，而這個優化能被用戶感知的程度如何呢？）；

2）你的投入產出比；

3）最後補充一點，所有判定的有一個原則，就是公司或者老大對這個業務的定位和戰略，這是遇到矛盾時候的解決依據。

需求優先順序評估時，不可忽視對風險的把握。對於那些低頻的需求，在做決策時更要善用User Story，為特殊情景準備好Plan B，以避免極端情況下的不可挽回的巨大損失。

取決於定需求優先順序的人是誰

乙方的話：是客戶還是項目經理？

甲方的話：是業務部門還是IT部門？

競品調研

需求文檔撰寫

不斷地和技術，UE，市場溝通，一般不停地開會

分析產品數據，找出問題，將問題變成需求，再迭代

跟進開發過程