我在文章《需求優先級分析方法論-波士頓矩陣和KANO模型》中提到了兩個需求分析的方法論。事實上，在實際應用過程中，我們會遇到更多更復雜的情況。今天我們從實際情況出發，來探討一下，實際開發過程中如何進行需求的優先級排序。
需求分析的準則
日常我們常見的需求分析準則有：“有利于提升用戶體驗的需求優先”、“更多用戶使用的需求優先”、“有利于公司營收的需求優先”……等等。除了這些，今天來看一下其他的一些非常見的準則：
痛點優先于癢點
什么是痛點？就是那些得不到滿足時會痛苦、抓狂的需求點。口渴時要喝水、生病時要吃藥，這些都是痛點。
什么是癢點？就是那些得到滿足時會很滿意、愉悅的需求點。無聊時想聽音樂、想吃好吃的東西，這些是癢點。
雖然解決了用戶的痛點和癢點后，都能提升用戶的滿意度。痛點和癢點的核心區分點是得不到滿足時，會不會感到痛苦、抓狂。
痛點優先于癢點是很好理解的。如果頭痛都解決不了，你給我撓癢癢有什么用？
在工作中，難就難在怎么區分痛點和癢點。也有很多時候，我們將癢點誤認為是痛點了。所以市面上經常能看到某些產品，具備了令人尖叫的功能，但是火不起來。
防止惡劣影響優先于滿足用戶需求
什么是會對用戶造成惡劣影響的事情？比如嚴重的Bug、比如破壞產品氛圍的用戶行為等。
一旦產品的功能對用戶產生了較為惡劣的影響，往往會導致用戶大規模的流失。要知道每一名流失的用戶，其實都是我們費盡千辛萬苦的從引流、轉化、存留等環節留下來的。
記住一句話，要用戶使用你的產品的理由需要千千萬萬，但是要用戶離開你的產品的理由，只要一個就夠了。
核心功能點優先
核心功能要優先，這個都知道。但是將一個大的功能細分成多個功能點后，我們可能會發現一個功能并非所有功能點都要實現。
比如，一個完整的IM功能可能包括文字、語言、圖片、視頻、表情，甚至包括文件傳輸等。但是，并不是說，所有產品的IM功能都要囊括這么多的功能點。我們想一下，一個電商平臺的IM功能需不需要自定義表情這個功能？
根據二八原則，正常情況下20%的功能足以滿足80%的用戶需求。優先開發能夠滿足多數用戶的功能點。
有依賴關系的功能優先
產品的功能和功能之間是有相互依賴關系的。作為被依賴的需求優先于其他需求。
如產品常見的賬號功能，用戶能否注冊進入產品是其他一切功能的基礎。如內容社區，必須先有信息發布和展示的功能，才能做信息互動的功能。
整理出需求之間的依賴關系，將有依賴關系的功能優先開發。
需求性價比
在繼續進行需求優先級排序討論之前，我們先來看一個概念：需求的性價比。
借用性價比的概念，這里簡單的將需求性價做如下定義：需求的性價比 = 價值 / 成本。
價值
什么樣的需求價值比較大？
- 使用人數多
- 使用頻率高
- 核心用戶的需求
- 有利于提升用戶體驗
- 有利于達成運營目標
- 能讓產品賺錢（這是很重要的標準啊）
對于需求的價值已經是老生常談了，在這里不展開。
成本
所有需求的實現都是有成本的，除了我們投入的真金白銀的人力成本等顯性成本外，還包括可能帶來的損害和風險等隱性成本。
實現成本
實現需求的成本，指那些投入需求開發的人力成本和必要的其他資源的成本。開發成本可以說是一個需求開發最最直觀的一項成本了，畢竟是真金白銀的投入。
損害
有時候發布新的需求會對用戶和產品產生損害。
- 降低用戶體驗。這個容易理解。
- 損害產品價值。如一些違反產品定位的需求。最著名的有某寶團隊開發了“圈子”功能，被用來發布黃色圖片。功能一上線就被下線了。
風險
風險是一項隱含的成本，經常會被忽略，但又是確確實實存在。
- 是否涉及核心流程或核心算法的變更。如果是的話，是否做了周全的評估。
- 是否會產生大量的不能回滾的數據。大量的臨時數據，對后續的開發來說是一個沉重的包袱。
用戶的使用成本
用戶的投入成本也是經常被忽略的一項成本。用戶對產品的使用，需要投入一定的時間、金錢或者其他資源。這些都是用戶在使用產品時的成本。
排除偽需求
在需求優先級排序之前，還有一件事情要做，那就是將偽需求剔除掉。
網上對偽需求的討論已經比較多了。但是我比較贊成的一個觀點是：嚴格來說，并沒有什么需求是真正的偽需求。偽需求的產生其中一個主要的原因是需求分析人員對需求挖掘得不夠深導致的。關于需求的挖掘，這里不展開。
本文從需求性價比的角度來討論偽需求。也就是說，偽需求就是性價比不高的需求。
- 價值小投入大
投入了大量的人力物力去開發的功能，結果幾乎沒人點開。這種情況下更多出現在某些大功能的小功能點上。做了個大而全的功能，結果只有少數功能點被使用。
- 損失比收益大
經常是為了滿足某一群用戶的需求損害了另一群用戶的利益。或者為了滿足公司的利益，損害了用戶的利益。比如產品過度的商業化損害了用戶體驗。
- 用戶得到的價值小于付出成本
如近年來一直很火的O2O的各種項目，用戶付出的成本大于用戶得到的價值。這種需求只能靠著補貼來降低用戶付出的成本，一旦補貼停止，項目也就進行不下去了。
- 有簡單的替代方案
有時候并非你的功能不夠好，而是別的功能比你好。舉個例子：你要上屋頂拿個東西，你需要的可能不是去造個梯子，你需要的可能只是一根竹竿。
需求排序
綜上所述，下面講所有原則整合起來，看一下在實際的使用過程中怎么來進行需求排序。
【極高】系統重大的Bug
重大的Bug和漏洞必須第一時間解決。有可能一個Bug就會導致大規模的用戶流失。【高】投入小、價值高
開發難度簡單的，但是有利于運營目標達成。例如有利于引流、提升轉化率的需求。【高】投入大，價值高
開發難度較大，但是有利于提升產品營收的需求。【中】投入小，關聯度高的功能
很多時候，我們會順帶著把一些關聯度高的小需求優先開發了。硬是把那些工作量很小的功能拆分出來反而不利于開發和測試。【中】基礎功能
有依賴關系的基礎功能需要先行開發。【中】內部運營需求
主要是提供給內部運營人員使用的需求。如某些活動工具、數據分析等需求。倒不是說，運營需求不重要，而是經常運營需求在前期是可以手工的方式去解決的。【低】探索型需求
功能的價值還不是特別明確的功能。常見的如某些戰略型的創新功能。【低】優化型需求
對當前功能進行優化的需求。并不增加功能本身的價值，但是用戶體驗的提升有一定的幫助。【極低】測試型需求
指那種市場和用戶尚未被培養起來需求，而且團隊對預期效果也沒有一個明確的判斷。這種需求先做市場分析先。
意外情況
制定了計劃，就應該按照計劃執行。但是，并沒有什么絕對的事情。總是有一些情況逼著我們對計劃做改變。
重大Bug
重大Bug或者漏洞絕對是第一優先級處理的。這是不吃飯不睡覺都要搞定的事情。老板要求
某一天老板出現工位后面，告訴你有個功能很緊急必須馬上開發。競品迭代
突然你的發現了直接競品發布了一個很好的功能，有可能搶走你的大批用戶。政策性風險
相關部門的一紙文書，很多功能都必須停下了。預估錯誤
市場的預估錯誤，比如，用戶沒那么喜歡你的功能。技術的預估錯誤，比如，某個技術上存在漏洞達不到應用標準。
還有一些重要但不緊急的意外情況，也是需要我們持續關注的：
技術發展
技術的發展會讓一些需求的假設前提不存在了，或者產生了新的前提。比如某智能手機的重大技術升級。市場變化
重大的技術升級或者殺手級應用的出現，總會帶來市場的變化。比如智能手機的出現，帶來了移動互聯網的市場。再比如微博、微信的出現，各自帶來了一個超級大的市場。
遇到這些情況的時候，就不要抱著以前的優先級不放了，靈活地考慮問題。
寫在最后
產品的需求排序，正是印證了那句話：我懂得所有道理，卻無法對需求進行排序。
道理很簡單，要執行起來沒那么容易。最后還是得回歸到團隊和項目里面去。非黑即白型需求排序很容易就做出來了，最難的在于那種“差不多”的需求上。
最后，放出兩個問題作為結尾吧，各位同學想想如何排序。
第一個問題來源于互聯網，相信很多同學都見到過了。QQ發布第一個版本的時候，有以下需求：
- 卡通頭像
- QQ表情
- 很小的.exe文件
- 聊天記錄管理器
- 聊天室
- 看誰在線
- 語言
- 安全性
- 使用流暢
- 傳文件
第二個問題來源于微信6.6.6版本更新后用戶的反饋：
- 未讀消息一鍵已讀
- 好友互刪
- 進群驗證
- 朋友圈支持Gif格式
- 訂閱號分組
- 禁止被拉進群
- 朋友圈分組
- 檢查被刪除好友
- 朋友圈評論帶圖片
