起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識面向BUG，聊聊需求優先級的判定方法
本文給大家介紹一個作者常用的優先級界定方法，作者把他理解成判斷優先級的三個階段性方法，分別對應不同階段的產品人，不同重要性的需求。一起來看看~
功能越多，BUG越多，互聯網是個缺少耐心的市場，往往上一個版本的BUG還未完全修復，就已經奔波在下一個版本的需求開發上，最終的結果便是產品的功能以極快的速度增長，而BUG的增長速度甚至比功能的增長速度還要更快，是以功能越多，BUG越多。
這也導致有一些BUG可以存續數年的時間，有的BUG在功能下架之前都未能修復，這就是真實的產品迭代路，并不是我們想象當中那般完美。
有時追求完美，強調質量產品人，或許顯得并不是那么正確。
人人的經典BUG，第一次關注到這個BUG 是在三年前，我剛開始寫文章的時候，實際上，這個BUG的存續時間或許遠超3年，在我寫文章之前，他可能就已經存在了。
連續兩篇相同的文章，除此之外，還有神奇的“-1”參數值，也存續了許久，至今任未修復。
即便是以底線，克制著稱的微信，也存在類似的壽命極長的BUG，這里就不列舉出來了。
換個視角，BUG也是需求
以前有朋友問我，產品經理是否需要對BUG進行決策，BUG是否修復是否由產品經理說的算。嚴格意義上來講，這并不是絕對性的問題，我只能告訴他，產品經理擁有解決BUG的能力，也擁有對BUG進行決策的決策權，但決策權并不等于你一定要這么做，這也的決策權只是一種補充，又或者是特殊情況的特殊處理方式。
因為BUG，也是需求的一種，我們可以將對某個BUG的處理，列入需求清單，只需要轉變一下我們看待BUG的視角，將BUG的現象定義為“當前正確”，將BUG的修復處理定義為“優化方案”。
當我們將內容重復出現理解為過去正確的需求時，我們便可以提出優化的需求，比如我們認為重復出現的設計并不是很好，因此將這里的產品設計方案進行了優化調整，這樣一來，BUG就成為了需求。
實際上，大部分BUG，都可以站在需求的視角進行處理。
某種意義上，產品和測試在面對開發時，有一些相同的成分存在，我們都能向研發提出技術性需求，只是這種需求的表現形式發生了變化，內容也不太一樣。
產品經理提出的需求是定義式的需求，我們定義要做什么，而測試提出的是糾正性需求，對錯誤的實現方式，按照產品經理的定義進行糾正，前者是后者的標準，后者是前者的邊界補充。
一旦將邊界放寬，BUG成為了正確的輸出結果時，我們便可以對輸出結果進行重定義，按照需求迭代的思路，將其優化調整為我們期望的結果，BUG也就不再是BUG，而是變成了產品的輸出需求。
是需求，就具備需求優先級
如果我們將BUG轉變成產品需求，也就具備了需求優先級的特點。我們要做的，其實就是需求優先級的界定；我們要做的，其實從未改變，未增加，也未減少。
需求優先級，對于產品人而言并不陌生，但掌握到精髓其實還是很難，多數情況，我們的優先級都是由領導決策，大概只有你成長為負責人以后，在無數的坑里自行領悟出優先級的判定方法。
我相信，大部分產品人的成長環境并不理想，也許你的leader都無法告知你準確的優先級判定方法，也許你正確的判。，在某些環境里，會被視為錯誤的，盡管結果上來講證明了你是正確的，也沒有意義。
這是由團隊環境決定的事物，所以如果你的團隊里，存在一位產品人，能有清晰的判斷思路，或者你的leader向你展現了一些專業手段。那么我建議你緊密跟隨，努力學習，即使收入低一點也沒關系，這些成熟的方法會讓我們少走很多彎路，并且這也的leader是可遇不可求的。
請傾聽一下，埋怨leader，埋怨環境的產品人心聲，太多的產品人渴望一位leader 而不可得了。
這里給大家介紹一個我常用的優先級界定方法，我把他理解成判斷優先級的三個階段性方法，分別對應不同階段的產品人，不同重要性的需求。
這三個階段性方法，分別是影響面積判定，性價比判定，以及目標匹配度判定。
1. 影響面積判定
這是最基礎的一個判斷方法，也是初期產品經理可以掌握的一個方法，他主要是面向功能性的需求進行優先級判定。
我將其定義為：影響面積大的優先于影響面積小的，影響面積極小的滯后觀察，影響面積極大的最優先處理。
大小的判定是相對概念的判定，并不是說影響100萬用戶，就是影響面積大，放到微信數億用戶的體量里，這100萬用戶也是影響面積極小的一個存在。
與影響面積類似的判斷方法還有嚴重度。
嚴重度大小判定：阻塞性業務優先于概率性錯誤，而概率性錯誤優先于使用體驗。
影響面積的判定，又或者是嚴重度大小的判定，均是針對功能的實現覆蓋面積的角度來判斷，對應的也是處于功能產品階段的產品人，此時我們更關注的是功能結果。
我將產品人的發展階段寬泛的定義為三個階段，從初往高，分別對應功能階段的產品經理，設計階段的產品經理以及需求階段的產品經理，每個階段的跨度大概都是2-3年的時間。
2. 性價比判定
性價比判定對應的是設計階段的產品經理，如果說影響面積是考慮的功能收益，影響越大，功能收益越大，那么性價比判定就是在收益的基礎上，增加了成本因素，將收益和成本進行綜合考慮的一種判定方式。
有的需求，能夠有極大的覆蓋面積，但卻需要付出極大的成本，這其實是不太推薦的，成本越高，風險也就越高，除非我們能找到一種低成本的實施方案，或許會讓效果有一些折扣，但卻是必要的。
性價比的判定，通常會引入多種成本維度，包括開發成本，運營成本，商業成本，資源成本等多個維度的成本進行綜合考慮。
最開始，我們或許只能考慮到開發成本，這得益于我們從業的前兩年時間，讓我們對功能的實施成本有了大致的經驗預判，而其他環節的成本也是我們和對應團隊的合作經驗得到，在缺少經驗時，往往需要多次溝通，多次交流，才能讓我們的判斷稍微準確一些。
作為一個綜合電商平臺而言，我們考慮增加一個自動秒殺模塊。
自動秒殺的設計，將會隨機從平臺的商品里生成秒殺隊列，這可以減少商戶的運作成本，他們基本不用運營維護，每天都會生成秒殺專區。
除此之外還會給予到秒殺商品大圖展示，如果能為每一款商品定制秒殺的專屬配圖，這對消費者會產生極大的吸引力，因為這些商品展示的大圖，都能帶上很吸引人的信息。
然而這個功能卻需要所有的商戶參與進來，每個商戶都需要對每個商品增加一張秒殺的活動配圖，這些配圖并不是每時每刻都在被使用，實際上相同周期里，大部分的圖片素材都是不會被使用的。
相對這個需求的價值而言，所需要付出的成本也是極大的，盡管這是一個很好的idea，但他依然不會進入到開發排期，除非我們有一些特殊的設計，能將成本降低下來。
我們在產品生涯的第二個階段，設計階段，會更多的考慮成本，價值衡量這樣的度量維度，產品于我們而言，不應該是有和無的關系，還會增加一層類似分數值的概念，滿分100分的設定里，我們也會越來越傾向于高分的方案。
3. 目標匹配度判定
當你成長為更專業的產品經理時，你會發現我們不僅僅不會修復一些BUG，甚至對于一些性價比高的事情也不會去做，即使他的成本并不高，即使他能為我們帶來可觀的數據，我們也會因為目標不匹配而放棄掉這個方案。
目標匹配度判定對應的是第三階段的產品人，我們開始深入思考需求，而這里的關鍵點在于匹配。
產品是一個較長周期持續存在的事物，每個階段都有不同的訴求，根據市場環境，根據公司策略等等許多因素，我們會得到某一個周期的核心目標，此時，我們的需求和決策都會圍繞目標展開。
你一定知道百度近期的一個事件，根據百度官方公告：由于系統維護原因，百度貼吧2017年以前的帖子將會無法訪問，修復事件將會另行通知。
隨后，微信在短時間內無法修改頭像和昵稱，各個內容平臺都無法分享內容至微信。
背后的原因是國家凈網行動的實施，而在這個時間點里，大家達成一致的目標均是圍繞內容處理展開，有的是清除歷史數據，有的是禁止外部不可控的數據進入。
相對于這個目標而言，其他事情的優先級都需要降低，否則，你可能贏了結果，輸了官司。
如果說影響面積判定，讓我們認識到了收益，而性價比判定讓我們認識到了成本，那么第三階段的目標匹配度判定則是會讓我們認識到“正確性”。
堅持做正確的事情，提出這款產品應該提出的需求，往他應該發展的方向去發展，是我們對正確性詮釋之一，同時也是中高端職場核心之一。
我們身處職場，對于產品經理而言，什么是職場呢？職場就是信息不透明，信息不對等的重災區，當上級做了決策，當公司決定了發展策略，定下了階段性目標時，其實沒有人會完整的告訴你為什么這么做，有些事情，背后的信息，并不是我們產品人所能接受的。
朋友告訴了我這樣一個故事，老板委托他做了一個功能，這個功能看上去與產品格格不入，并且對活躍，轉化都沒有什么幫助，唯一的作用就是一種理財的嘗試。他十分不能理解，直到最后偶然得知，當時公司的現狀幾乎接近資金斷裂，需要一筆資金作為周轉。如果不是這樣一個功能，可能當月就會面臨發不出工資的問題，盡管擁有成熟且健康的現金流。
在這樣一個信息不對稱，信息不透明的環境，我們唯有響應目標，并且以共同的目標建立什么是正確的衡量標準，才能保障項目的健康發展。
如果你發現了一個潛力極大的需求，并且有時效性，錯過了就失去了，那么你應該先和上層溝通，先改變目標，再落地方案，而不是表面執行A目標，背后實施B目標的方案，這很有可能帶來企業生存級的危機。
邏輯總結
本文我們通過BUG引入，輸出了我對需求優先級判定的三個方法，分別是：功能層面的影響面積判定，設計層面的性價比判定，以及需求層面的目標匹配度判定。
正文也聊到了這些內容：
- 大部分BUG都可以轉變成需求的視角，對于產品人而言，BUG也是需求的一個子集，或許有點特殊，但他依然是需求，依然遵循需求優先級的判定方法。
- 需求優先級的界定是一個相對的概念，而非絕對的概念，我們只能說A需求相對B需求優先級更高，而不能單獨的說A需求優先級高。
希望這篇文章，對你有所幫助 ，后續也會持續輸出邏輯案例性的文章。
#專欄作家#
枯葉，微信公眾號：產品經理充電站。人人都是產品經理專欄作家。近9年經驗的產品經理，擅長社交、社區、細分群體挖掘。
本文由 @枯葉 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
很有啟發