三、需求怎么评估
需求的评估细分下来还可以分为两个问题，需求做不做和需求的优先级问题。
To do or not to do，这永远是摆在产品面前的一道难题。咋看来是无从下手，但还是有一些明确的方法可以借鉴。
**1、逻辑分析法
**
正如上文需求分类和来源中提到的，我们发现的需求并不一定是毫无问题的。数据分析可能会有偏差，用户研究可能会有人为因素，但综合多个来源产生的需求，互相印证，综合分析，走歪的可能性就大为降低了。很多需求，产品是可以通过经验和逻辑判断能力直接去除的。这也是为什么很多产品经理招聘的要求里有逻辑分析能力强的一个原因。
从一个需求是否需要满足，可以砍掉一些价值不大的，没有什么使用场景的，和无法实现的需求。
对需求进行进一步深挖，把一些表面/伪需求/需求解决方法转化为真实的需求。
2、产品定位法
产品定位主要包括三方面，目标用户，主要功能，产品特色。对需求按照这三方面来检验，是否是目标用户的需求，是否和主要功能紧密相关，是否符合产品特色。
就像网易云音乐，分享听音乐时的感受这个需求，符合云音乐的目标用户（大众音乐爱好者），跟主要功能（找歌听歌）比较相关，也符合云音乐的社交音乐app的产品特色，所以这个需求是可以做的（音乐评论）。（《【聚焦产品核心能力系列】价值链导向的产品决策》这篇文章也是类似的角度，讲的也挺精彩的，推荐下）
对于产品定位的探讨，可以再另外写一篇文章来探讨。
3、KANO模型法
KANO模型把需求分为如图三类：
需求记录
二、需求背景
介绍市场情况，产品定位，竞品分析，用户研究，需求来源，需求分析等，这些工作都要做的扎实，可以参考前面的内容。要让文档面向的对象明白为什么要做，做的大致方向，起到统一思想的作用。这里的功夫更多的是在文档外。
三、总体介绍
对需求总体进行介绍，在这我一般采用思维导图的形式，对需求进行介绍，涉及的模块，功能范围。让大家对需求有个总体的认识。
不要过早的进入细节，这点还是很有好处的。只有大家的思维站在了同一高度，才不会在后续的需求讨论时局限于细节，而这点也是在各个评审会上最令人头疼的一点。
四、需求描述
需求描述
关于流程图，很多产品不怎么画，但对我来说，在需求的完善阶段，一个好的流程图，能起到查缺补漏的作用，而且可以让你不要过早的进入到交互，界面，导航的考虑上。这里想得越清楚，后面的需求变更会少很多。
用这个和开发进行沟通其实挺有帮助的，测试也不需要追在后面不停的问，这里有个情况怎么处理。
五、相关原型
原型的做法往细了讲，太占篇幅，主要分为低保真，中保真，高保真。在工作中，我一般做到中保真的程度，足够传递界面，交互细节。
这里还有个特点就是为了便于讨论，最好把需要讨论的页面都做出来。
具体一些细节，因为是讨论需求的，就不过多讨论了。有机会在原型篇章再做讨论吧。
网友评论