對於產品經理而言，日常工作中需要處理的需求複雜多樣，那麼該如何制定功能的優先順序呢？本文結合相關案例，談談如何制定優先順序，提升工作效率，一起來看看吧。

01 優先順序制定的方法

產品經理工作的常見內容之一就是要制定產品功能的優先順序。目前常見的優先順序排序主要是艾森豪威爾矩陣，今天我們深入來聊聊怎麼在日常優先順序排期中使用艾森豪威爾矩陣的思想。

艾森豪威爾矩陣是以美國總統德懷特-大衛-艾森豪威爾的名字命名，這個優先順序框架將幫助你按照重要性和緊急性來開展你的任務和行動。

這個工具通常也用在時間管理中，下表大家一定都很熟悉：

重要且緊急→馬上做

重要但不緊急 → 做好計劃

緊急但不重要 → 委託他人做

不緊急也不重要→不做

在產品優先順序制定中，如果使用這個矩陣，核心是如何區分（量化）重要和緊急。在我看來，重要度和緊急度，可以繼續細分為以下2個維度：

功能覆蓋面覆蓋面分為人群覆蓋和頻次深度，也就是功能上線後能夠解決多少使用者及使用頻次的問題。

功能可替代性：

現在使用者解決這個需求是否有可替代方案/功能，解決使用者痛不痛的問題。

產品經理是糾結論纏身者，對於新手來說，優先順序排序充滿了不確定性，大家疑惑“如何說服我自己這個排序是正確的嗎？”時，可以用評分卡來量化優先順序得分，解決不確定性。

我們來看一下功能優先順序評分卡：

說明：評分卡的權重均攤即可（畢竟是自己手頭的小工具，不必太認真）。現在大家可以看出來，這個卡片裡面主要是針對需求的問題域進行了細化分析。

不過如果是資料類/演算法類的功能點，只看問題域可能是不夠的。我們需要考慮技術可實現性，也就是這個功能點的研發成本如何，理論上來說，技術不成熟、資料準備不成熟的功能點，需要付出的成本也越高，甚至有可能是當前團隊能力是無法完成的。

針對資料/演算法的功能，還需要增加一些維度，我們來升級一下這個評分卡：

可以看到，能力滿足度是針對於問題的解決能力域的。

02 優先順序制定的案例

下面我們看一個例子，該案例是一個電商倉庫的資料看板需求。經過需求梳理，我們已經得到了2個功能點，現在需要使用這個功能評分卡來判斷優先順序：

功能點1：生產任務資料看板-上架積壓預警

上架主管每天時刻要關注積壓、時刻要關注上架效率，提供一個自動預警積壓功能。

分析評分維度：

（1）影響的業務範圍（使用者規模/頻次）

功能上線後，所有倉庫的上架主管使用，每天都會用，在高峰期會經常用。

（2）影響業務的程度

當發生大量上架積壓時，可能影響銷售（前臺使用者購買時顯示無貨）。

（3）替代方案

主管會安排專人盯或者自己隨時檢視從各個系統查資訊，手動估算上架速度，評估是否會積壓。

（4）替代方案的問題

主管可能對任務完成情況發生誤判，介入晚了。

（5）當前資料可滿足程度

已有現成資料了。

（6）當前演算法/技術可確定性

方案比較簡單：初版可使用【上架任務數量/上架效率】得到預計任務完成時間與任務要求完成時間進行比較，進行預警。

功能點2：人員工作量彙總日報統計

倉庫工作量沒有現成的報表，系統提供一個每日自動統計的資料報表，使用者可以每天直接在系統中看到工作量彙總。

功能上線後，每個倉庫每天出報表人員會使用（報表每天出1次）。

（2）影響業務的程度

沒有影響，不影響主業務流程。

（3）替代方案

去作業系統檢視訂單流水，然後人工每天計算彙總工作量。

（4）替代方案的問題

不夠直觀方便（製作報表耗費時間大概半小時）。

無需演算法。

分析完畢之後，我們進行量化：

量化之後可以看到，功能點1的綜合得分0。83是比功能點2高的，如果研發團隊只能做1個功能，那麼我們應該做功能點1。這個方法是我經常推薦產品新人用的，透過對功能點進行分析和量化，最後得到一個有邏輯性的排序結果。經常使用這個工具，逐漸就可以鍛煉出自己的手感。

你有什麼排優先順序的訣竅嗎？

作者：薄荷點點，“資料人創作者聯盟”成員。

本文由@一個數據人的自留地 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。