我在文章《需求优先级分析方法论-波士顿矩阵和KANO模型》中提到了两个需求分析的方法论。事实上，在实际应用过程中，我们会遇到更多更复杂的情况。今天我们从实际情况出发，来探讨一下，实际开发过程中如何进行需求的优先级排序。
需求分析的准则
日常我们常见的需求分析准则有：“有利于提升用户体验的需求优先”、“更多用户使用的需求优先”、“有利于公司营收的需求优先”……等等。除了这些，今天来看一下其他的一些非常见的准则：
痛点优先于痒点
什么是痛点？就是那些得不到满足时会痛苦、抓狂的需求点。口渴时要喝水、生病时要吃药，这些都是痛点。
什么是痒点？就是那些得到满足时会很满意、愉悦的需求点。无聊时想听音乐、想吃好吃的东西，这些是痒点。
虽然解决了用户的痛点和痒点后，都能提升用户的满意度。痛点和痒点的核心区分点是得不到满足时，会不会感到痛苦、抓狂。
痛点优先于痒点是很好理解的。如果头痛都解决不了，你给我挠痒痒有什么用？
在工作中，难就难在怎么区分痛点和痒点。也有很多时候，我们将痒点误认为是痛点了。所以市面上经常能看到某些产品，具备了令人尖叫的功能，但是火不起来。
防止恶劣影响优先于满足用户需求
什么是会对用户造成恶劣影响的事情？比如严重的Bug、比如破坏产品氛围的用户行为等。
一旦产品的功能对用户产生了较为恶劣的影响，往往会导致用户大规模的流失。要知道每一名流失的用户，其实都是我们费尽千辛万苦的从引流、转化、存留等环节留下来的。
记住一句话，要用户使用你的产品的理由需要千千万万，但是要用户离开你的产品的理由，只要一个就够了。
核心功能点优先
核心功能要优先，这个都知道。但是将一个大的功能细分成多个功能点后，我们可能会发现一个功能并非所有功能点都要实现。
比如，一个完整的IM功能可能包括文字、语言、图片、视频、表情，甚至包括文件传输等。但是，并不是说，所有产品的IM功能都要囊括这么多的功能点。我们想一下，一个电商平台的IM功能需不需要自定义表情这个功能？
根据二八原则，正常情况下20%的功能足以满足80%的用户需求。优先开发能够满足多数用户的功能点。
有依赖关系的功能优先
产品的功能和功能之间是有相互依赖关系的。作为被依赖的需求优先于其他需求。
如产品常见的账号功能，用户能否注册进入产品是其他一切功能的基础。如内容社区，必须先有信息发布和展示的功能，才能做信息互动的功能。
整理出需求之间的依赖关系，将有依赖关系的功能优先开发。
需求性价比
在继续进行需求优先级排序讨论之前，我们先来看一个概念：需求的性价比。
借用性价比的概念，这里简单的将需求性价做如下定义：需求的性价比 = 价值 / 成本。
价值
什么样的需求价值比较大？
- 使用人数多
- 使用频率高
- 核心用户的需求
- 有利于提升用户体验
- 有利于达成运营目标
- 能让产品赚钱（这是很重要的标准啊）
对于需求的价值已经是老生常谈了，在这里不展开。
成本
所有需求的实现都是有成本的，除了我们投入的真金白银的人力成本等显性成本外，还包括可能带来的损害和风险等隐性成本。
实现成本
实现需求的成本，指那些投入需求开发的人力成本和必要的其他资源的成本。开发成本可以说是一个需求开发最最直观的一项成本了，毕竟是真金白银的投入。
损害
有时候发布新的需求会对用户和产品产生损害。
- 降低用户体验。这个容易理解。
- 损害产品价值。如一些违反产品定位的需求。最著名的有某宝团队开发了“圈子”功能，被用来发布黄色图片。功能一上线就被下线了。
风险
风险是一项隐含的成本，经常会被忽略，但又是确确实实存在。
- 是否涉及核心流程或核心算法的变更。如果是的话，是否做了周全的评估。
- 是否会产生大量的不能回滚的数据。大量的临时数据，对后续的开发来说是一个沉重的包袱。
用户的使用成本
用户的投入成本也是经常被忽略的一项成本。用户对产品的使用，需要投入一定的时间、金钱或者其他资源。这些都是用户在使用产品时的成本。
排除伪需求
在需求优先级排序之前，还有一件事情要做，那就是将伪需求剔除掉。
网上对伪需求的讨论已经比较多了。但是我比较赞成的一个观点是：严格来说，并没有什么需求是真正的伪需求。伪需求的产生其中一个主要的原因是需求分析人员对需求挖掘得不够深导致的。关于需求的挖掘，这里不展开。
本文从需求性价比的角度来讨论伪需求。也就是说，伪需求就是性价比不高的需求。
- 价值小投入大
投入了大量的人力物力去开发的功能，结果几乎没人点开。这种情况下更多出现在某些大功能的小功能点上。做了个大而全的功能，结果只有少数功能点被使用。
- 损失比收益大
经常是为了满足某一群用户的需求损害了另一群用户的利益。或者为了满足公司的利益，损害了用户的利益。比如产品过度的商业化损害了用户体验。
- 用户得到的价值小于付出成本
如近年来一直很火的O2O的各种项目，用户付出的成本大于用户得到的价值。这种需求只能靠着补贴来降低用户付出的成本，一旦补贴停止，项目也就进行不下去了。
- 有简单的替代方案
有时候并非你的功能不够好，而是别的功能比你好。举个例子：你要上屋顶拿个东西，你需要的可能不是去造个梯子，你需要的可能只是一根竹竿。
需求排序
综上所述，下面讲所有原则整合起来，看一下在实际的使用过程中怎么来进行需求排序。
【极高】系统重大的Bug
重大的Bug和漏洞必须第一时间解决。有可能一个Bug就会导致大规模的用户流失。【高】投入小、价值高
开发难度简单的，但是有利于运营目标达成。例如有利于引流、提升转化率的需求。【高】投入大，价值高
开发难度较大，但是有利于提升产品营收的需求。【中】投入小，关联度高的功能
很多时候，我们会顺带着把一些关联度高的小需求优先开发了。硬是把那些工作量很小的功能拆分出来反而不利于开发和测试。【中】基础功能
有依赖关系的基础功能需要先行开发。【中】内部运营需求
主要是提供给内部运营人员使用的需求。如某些活动工具、数据分析等需求。倒不是说，运营需求不重要，而是经常运营需求在前期是可以手工的方式去解决的。【低】探索型需求
功能的价值还不是特别明确的功能。常见的如某些战略型的创新功能。【低】优化型需求
对当前功能进行优化的需求。并不增加功能本身的价值，但是用户体验的提升有一定的帮助。【极低】测试型需求
指那种市场和用户尚未被培养起来需求，而且团队对预期效果也没有一个明确的判断。这种需求先做市场分析先。
意外情况
制定了计划，就应该按照计划执行。但是，并没有什么绝对的事情。总是有一些情况逼着我们对计划做改变。
重大Bug
重大Bug或者漏洞绝对是第一优先级处理的。这是不吃饭不睡觉都要搞定的事情。老板要求
某一天老板出现工位后面，告诉你有个功能很紧急必须马上开发。竞品迭代
突然你的发现了直接竞品发布了一个很好的功能，有可能抢走你的大批用户。政策性风险
相关部门的一纸文书，很多功能都必须停下了。预估错误
市场的预估错误，比如，用户没那么喜欢你的功能。技术的预估错误，比如，某个技术上存在漏洞达不到应用标准。
还有一些重要但不紧急的意外情况，也是需要我们持续关注的：
技术发展
技术的发展会让一些需求的假设前提不存在了，或者产生了新的前提。比如某智能手机的重大技术升级。市场变化
重大的技术升级或者杀手级应用的出现，总会带来市场的变化。比如智能手机的出现，带来了移动互联网的市场。再比如微博、微信的出现，各自带来了一个超级大的市场。
遇到这些情况的时候，就不要抱着以前的优先级不放了，灵活地考虑问题。
写在最后
产品的需求排序，正是印证了那句话：我懂得所有道理，却无法对需求进行排序。
道理很简单，要执行起来没那么容易。最后还是得回归到团队和项目里面去。非黑即白型需求排序很容易就做出来了，最难的在于那种“差不多”的需求上。
最后，放出两个问题作为结尾吧，各位同学想想如何排序。
第一个问题来源于互联网，相信很多同学都见到过了。QQ发布第一个版本的时候，有以下需求：
- 卡通头像
- QQ表情
- 很小的.exe文件
- 聊天记录管理器
- 聊天室
- 看谁在线
- 语言
- 安全性
- 使用流畅
- 传文件
第二个问题来源于微信6.6.6版本更新后用户的反馈：
- 未读消息一键已读
- 好友互删
- 进群验证
- 朋友圈支持Gif格式
- 订阅号分组
- 禁止被拉进群
- 朋友圈分组
- 检查被删除好友
- 朋友圈评论带图片