三、需求怎么评估
需求的评估细分下来还可以分为两个问题，需求做不做和需求的优先级问题。
To do or not to do，这永远是摆在产品面前的一道难题。咋看来是无从下手，但还是有一些明确的方法可以借鉴。
**1、逻辑分析法
**
正如上文需求分类和来源中提到的，我们发现的需求并不一定是毫无问题的。数据分析可能会有偏差，用户研究可能会有人为因素，但综合多个来源产生的需求，互相印证，综合分析，走歪的可能性就大为降低了。很多需求，产品是可以通过经验和逻辑判断能力直接去除的。这也是为什么很多产品经理招聘的要求里有逻辑分析能力强的一个原因。
从一个需求是否需要满足，可以砍掉一些价值不大的，没有什么使用场景的，和无法实现的需求。
对需求进行进一步深挖，把一些表面/伪需求/需求解决方法转化为真实的需求。
2、产品定位法
产品定位主要包括三方面，目标用户，主要功能，产品特色。对需求按照这三方面来检验，是否是目标用户的需求，是否和主要功能紧密相关，是否符合产品特色。
就像网易云音乐，分享听音乐时的感受这个需求，符合云音乐的目标用户（大众音乐爱好者），跟主要功能（找歌听歌）比较相关，也符合云音乐的社交音乐app的产品特色，所以这个需求是可以做的（音乐评论）。（《【聚焦产品核心能力系列】价值链导向的产品决策》这篇文章也是类似的角度，讲的也挺精彩的，推荐下）
对于产品定位的探讨，可以再另外写一篇文章来探讨。
3、KANO模型法
KANO模型把需求分为如图三类：
基本型需求：
如果此类需求没有得到满足或表现欠佳，用户的不满情绪会急剧增加，并且此类需求得到满足后，可以消除用户的不满，但并不能带来用户满意度的增加。产品的基本需求往往属于此类。对于这类需求，产品的做法应该是注重不要在这方面失分。
期望型需求：
此类需求得到满足或表现良好的话，用户满意度会显著增加，当此类需求得不到满足或表现不好的话，用户的不满也会显著增加。这是处于成长期的需求，用户、竞争对手和产品自身都关注的需求，也是体现竞争能力的需求。对于这类需求，产品的做法应该是注重提高这方面的质量，要力争超过竞争对手。
魅力型需求：
此类需求一经满足，即使表现并不完善，也能到来用户满意度急剧提高，同时此类需求如果得不到满足，往往不会带来用户的不满。这类需求往往是代表用户的潜在需求，产品的做法就是去寻找发掘这样的需求，领先对手。（定义来自于百度，略改）
这表可以通过用户思考功能实现和不实现时感觉获得，一共25种可能分类。
字母代表对此功能，实现和不实现情况下的情绪反应对应的人数比例。
同时，E表示兴奋型需求，L表示期望型需求，M表示基本型需求；R表示相反的需求，I表示无关紧要的需求，Q表示存疑的需求。
公式中字母代表该需求，选择这个类型的人数总和。
A=（E+L)/(E+L+M+I)越接近于1，说明增加这功能用户得到的满意度提升
B=（L+M）/（E+L+M+I),越接近于1，说明不增加这功能导致的不满意度上升
A低B高说明是基本型需求，A高B低说明是兴奋型需求，A高B高说明是期望型需求，A低B低说明这个需求无关紧要，不需要做。
评估要不要做后，接下来就应该考虑的是，哪个先做，就是需求优先级排序。
经过上述的一步步，你手里可能已经有了一堆的需求列表，那什么该先做，什么该后做，也许这就决定了你这个产品的生死。如果你是神级产品，按照你的经验直觉来就好，不过估计也不需要来看我这篇文章了。作为菜鸟产品，就老实按照方法来，积累经验。
首先，要考虑产品是否已上线，如已上线，需要考虑几个点：
1、用户属性：是哪一类用户的需求，核心用户，次要核心，非核心用户等；需求用户数量，来源后台的数据统计，或者用户反馈的频次等。我们优先满足的最大数量的核心用户的需求。
2、需求频率：这个需求（可能）被使用的次数，次数越高，优先级越高。
3、需求价值：在12的基础上结合现阶段的产品目标评估需求对用户价值和商业价值的作用，获得一个五点评分。
4、需求成本：考虑需求实现的资源成本（UI，技术，测试等等）
在1234的基础上得出每个需求的大致性价比，如有些小需求价值不高但实现成本也低，每个版本顺手也就做点。
5、需求类型：这个要看产品对需求的判断，来源于对用户的了解，场景的思考。可以考虑采用KANO模型分析，基本需求优先做，期望型需求次之挑选着做，兴奋型需求要有一两个，作为亮点和差异化竞争的点，但产品迭代前期可以先不做。
6、需求依赖：考虑下需求的依赖关系，前置后置等。产品是一个整体，一个需求也不会是独立存在的，所以要从一个完整的角度去考虑。像朋友圈，用的人多，频率高，类型也算兴奋型需求，但是要建立在有一定的朋友关系基础沉淀上。那就需要前置的需求如通讯录，聊天，还有摇一摇（建立朋友关系)。
考虑了种种要求后，可以得出一个需求优先级排序列表。
如果产品还未上线，12数据的获得都是需要产品主动的去获取，各种竞品，分析报告。5中需求类型也优先做基本需求。但整体的步骤相差不大，对产品的要求也更高。
做产品有一个体会就是，越在上游做的多，下游就越轻松，宁愿在这一步多花一些功夫也不要在产品上线后才发现功能不如预期。
以前待过一家公司，那时候刚去，每周五会进行一次产品演示，把已经开发好的app功能通过大屏幕展现出来，然后让几个合伙人看产品是否符合需求。如果有问题就要从头开始设计，这样导致的问题就是项目进度非常慢，在我去之前，已经花了两个多月的时间来反复修改。这样做了两个星期我就忍不住了，这样的返工效率实在太低，就加入了需求评审和交互稿评审的环节。到了界面开发这个阶段，就不再做大的改动，才大大提高了项目进度。
四、需求文档该怎么写
产品要写的需求文档不少，但我们一般说起来的，用的最多的，应该还是prd文档。
prd该怎么写呢？
要回答这个问题，首先要考虑的是，这是给谁看的。
同级的产品，交互，UI，技术，测试，运营看的，需要够详细，够清楚，才能让他们知道怎么按照需求文档做。是的，这一大帮子人，都是要依赖这份文档来下一步工作，这份文档的基础性，重要性不言而喻。
那这份文档应该包含什么呢，有什么规范和注意事项。
下面的文字主要来自于我自己工作学习中的感悟，只能说适合我的需要，而且也还在不断的摸索改进中，大家可以看看作为参考。文后也贴了些一些其他人的文章，大家可以对照的看，以找到合适自己的需求文档写作方式。
1、需求记录
对我来说，这个文档是我与其他相关人员（老板，产品组，交互，视觉，技术，测试，运营）沟通和pk的主要工具。每一次的沟通结果都要在这有一定的体现和记录，只有如此，后续的工作才能有效的展开。而需求记录在这起到的作用就是对这个过程有个记录，并且每个看到这个记录的人都能知道这个文档的进展，不会做无用功，重复功。可以想象，如果不做详尽的记录，文档的每一次变化，相关人员看到的时候都会不知从何下手，不知道哪里有变化，上次讨论的结果最后如何做等等。需求文档是一个统一思想，同步进度的工具，而需求记录就在其中起着至关重要的作用。
做好了这个记录，需求变更，需求追踪都会变得轻而易举，是我们产品与其他人员“撕逼”一大利器。
二、需求背景
介绍市场情况，产品定位，竞品分析，用户研究，需求来源，需求分析等，这些工作都要做的扎实，可以参考前面的内容。要让文档面向的对象明白为什么要做，做的大致方向，起到统一思想的作用。这里的功夫更多的是在文档外。
三、总体介绍
对需求总体进行介绍，在这我一般采用思维导图的形式，对需求进行介绍，涉及的模块，功能范围。让大家对需求有个总体的认识。
不要过早的进入细节，这点还是很有好处的。只有大家的思维站在了同一高度，才不会在后续的需求讨论时局限于细节，而这点也是在各个评审会上最令人头疼的一点。
四、需求描述
关于流程图，很多产品不怎么画，但对我来说，在需求的完善阶段，一个好的流程图，能起到查缺补漏的作用，而且可以让你不要过早的进入到交互，界面，导航的考虑上。这里想得越清楚，后面的需求变更会少很多。
用这个和开发进行沟通其实挺有帮助的，测试也不需要追在后面不停的问，这里有个情况怎么处理。
五、相关原型
原型的做法往细了讲，太占篇幅，主要分为低保真，中保真，高保真。在工作中，我一般做到中保真的程度，足够传递界面，交互细节。
这里还有个特点就是为了便于讨论，最好把需要讨论的页面都做出来。
具体一些细节，因为是讨论需求的，就不过多讨论了。有机会在原型篇章再做讨论吧。