根據bug與新需求對當前主要業務的影響程度排期

比如社群產品，關於內容生產與內容消費的bug與需求就提升優先順序，其他模組的bug和需求就降低優先順序。

如果在同一個模組中，對體驗影響最大的bug優先解決，其次是痛點/癢點的需求，然後是次級bug，興奮點需求。

也可以根據使用者對問題的反饋頻率來排期，反饋頻率越高，也就說明對使用者影響越大，影響的人數越多。而且一般如果不是影響較大的問題，使用者也懶得去反饋，所以使用者反饋是值得參考的。

以上也只是理想情況下的排期情況，技術老大一聲吼，所有的文件理論全是狗。

一般來說是要評估一個線上BUG的嚴重程度，若是致命的會導致系統無法正常執行，那自然是優先順序最高，應該要立馬處理。若不影響現有程式的執行，可歸為下一期版本最佳化中的需求。

那產品經理要如何去評估和權衡需求優先順序，這也反映了一個產品經理的專業水平和能力，每天要面對不同需求進行權衡優先順序是每一個產品經理一天的常態。簡單分享一下個人評估需求優先順序的一套評判標準。

首先優先順序等級劃分為：1、2、3、4、5，隨數值變大而等級變高進行定義。

具體定義如下：

它規定了我們想象的且未來肯定能做起來，能解決未來使用者痛點，但目前使用者暫時還不能很好接受，需要投入很多的時間和資金去培養使用者習慣，這種在短時間內不在計劃之內的，只是先記錄備用。

它規定了那些有了會更好，但目前沒有也沒有什麼關係的需求，如一些提高效率的小功能，例如微信在某個版本推出的收藏的這個功能，一開始收藏這個功能並沒有細化只是簡單的收藏操作，也不影響使用者可以在收藏列表中找到自己收藏的內容；但如果在收藏列表中加了搜尋以及標籤以後使用者根據每次收藏的內容附加一個標籤，在某些時候要急用某一內容只需透過標籤搜尋內容就馬上出來了，微信在後續版本中也添加了給收藏內容加標籤以及搜尋標籤的功能。

它規定了當前版本可以不做，但必須在未來版本中實現的需求。此種需求對產品的體系結構影響可能較大，因此必須在系統設計時予以考慮。

它規定了那些競爭對手已經實現且使用者感覺很好的需求、本產品區別於其它同類產品的獨特需求及其它一些需求。只有完成這些需求，才能使本產品有市場競爭力

它規定了產品的必備需求。沒有這些需求，產品將不能完成使用者的工作，從而也就無法達到市場的准入條件。

本文是自己日常工作中需求優先順序排序的一個常用方法的總結。需求優先順序排序還有很多種方法，比如利用RICE工具來判斷優先順序，卡諾模型，四象限管理法等等，各位可以對每一種方法都稍作了解後選擇最適合自己的一種。