需求优先级
上一篇文章中说到由一个需求挖掘出更多的需求点，需求那么多不可能一下全都做的（开发资源有限），那么这个时候我们就要对需求进行优先级的排序，得出结论哪些需求优先做，哪些需求后续做。
主要从三个维度对需求优先级进行排序
- 用户量和使用频率
- 开发难度和效果
- 产品价值
用户量和使用频率
使用频率/用户量
下面以网易云音乐为例，对次进行进一步的解释。
例子
（1）音乐列表和音乐播放是基础体验，用户量大使用频率高，有大量需求的时候要优先做这部分需求，一般这类需求大量存在于产品初期。
（2）个人设置例如个人基本资料、清理缓存等使用的用户量也很大，不过使用频率没那么高，相对于音乐播放这个需求优先级就相对低一些。
（3）歌手的后台管理，歌手是平台的一类用户，他们使用后台管理的频率很高，但是这类用户基数比较小，所以这部分的需求优先级相对来说会更低一些。
（4）歌曲的私人定制，这个部分用户量和使用频率都不是很高，如果满足这部分用户的需求，他们会对产品好感度大大提升，不过在优先级排序上这部分就要最靠后了。
开发难度和产生的效果
开发难度/产生的效果
（1）优先做开发难度低，产生效果快的需求，一般这样的需求在产品早期，这个阶段需要快速迭代，快速试错。
（2）在产品成长期，产品功能相对稳定，要做开发难度相对较大，产生的效果较快的需求。
（3）一些开发难度低，产生效果也不是很明显的创新。
（4）开发难度大，产生效果慢的需求优先级最低，这种可能是某个设计机会点。
产品价值
这个维度排列需求优先级从两个方向去考虑
（1）用户是否愿意为了解决问题而付费。
（2）如果做出来，用户愿意为之付出多少费用。
总结
通过上面几个维度对所有的需求进行综合的排序，排列出先做哪些需求后做哪些需求，到这里还没有完，上篇文章我们通过思维导图把所有的需求挖掘出并展示出来（如果忘记了可回看上篇文章），通过这篇文章我们以不同的维度对产品需求优先级进行了排序（思维导图的每一项都可以移动，也可以用表格把需求按优先级整理出来），之后我们把解决方案带入到上篇文章的需求挖掘中
会员功能需求.png
- 用户：即会员需求这个功能第一批核心用户是谁？
- 场景： 用户在什么场景下会用到这个功能？
- 问题 ：解决这个用户的最大痛点是什么？
- 对比 ：和用户现在的解决方案对比，体验提升有多大？
把这些结论列出来，和领导去谈这些需求的落地问题，就能站在同一个维度去探讨问题了。一般比较重要的需求都会开个需求审核会议，小的需求只需要快速迭代。需求审核通过后有些需求会砍掉有些会走入下个流程，即业务流程图和原型的制作了。这个在以后的文章中写。
