我在之前的文章提到过需求排序的基本方法，不过没有提到怎么严谨地判断需求的价值，也就是需求的重要性。
需求分析有两种核心的方法：定性分析和定量分析。我就从这个维度来解释下怎样对需求做判断。
1. 定性分析
1.1 KANO 模型
KANO 模型是现在大家都比较认可的方法。实际上，这个模型即使你没有系统学习过，也肯定对其理念有一定体会。
那具体怎么区分这些需求呢？KANO 模型就是提供了这样的方法。
我这里用的是飞哥简化版，大概是这样的：
解释下这个图。
作为一个功能， 每行对应的是如果有的话，用户会开心、无所谓还是不开心，每列则是如果没有的情况。具体说：
矛盾：如果用户觉得功能存在和不存在都很开心，或者都不开心，显然是有问题的，所以说是矛盾的情况，是存在逻辑问题的，不予考虑。
错误：如果功能不存在让用户很开心，或者功能存在让用户不开心，那这个功能显然是错误的功能，不予考虑。
无关：如果功能存在和不存在，用户都觉得无所谓，那功能也就无关紧要了，同样不予考虑。
最重要的就是剩下的三类了：
必要：如果功能存在用户并没有特别的感觉，但不存在会不开心，说明这个功能是要满足基本需求的，也就是大家常说的『痛点』。
期待：如果功能存在用户很开心，功能不存在用户很不开心，这就是满足用户最直接、最明显的需求了，是用户内心已有期待的。
惊喜：如果功能不存在的时候用户并没有感觉，说明这个功能用户之前没有预期，但功能存在用户很开心，也就是说达到了惊喜的效果。这就是小米常说的『惊喜点』，所谓让用户尖叫的功能。
任何需求都可以分为『惊喜型』、『期待型』和『必要型』。大家考虑需求的价值，就要基于这三种来做判断了。
很多公司和产品利用的产品运营手法就是在满足后两种需求的同时，不断用第一种需求激活用户的热情、促使用户传播。
1.2 用户访谈
除了通过常识对需求做以上提到的判断，深度访谈可以作为配合，来验证之前的考虑。
访谈的时候尽量用开放性的问题来沟通，不要直接问『如果有这样的功能你会不会用？』、『你到底想要什么样的功能？』，而是了解用户背后的需求、TA 使用的场景以及 TA 过去满足相同需求的方法，这些信息能提供关键的证据，来辅助验证你的判断。
沟通时，对同样的功能，也可以用多种问法来试探用户，以防用户不够理解；同时，也要反复对同一个功能做深入的探讨：『这样不好的话，那如果是那样呢？』『你觉得它不符合你要求的原因是什么呢？』再即时地做出反应，能获得更有价值的信息。
2. 定量分析
如果定性分析不能保证效果，那定量分析就可以获得更准确的信息，相应地，成本会偏高一些。
2.1 数据获取
数据获取有两种，一种是功能设计前获取一些能辅助做判断的信息，一种是功能上线后观察一些用户使用的行为数据。
对于前者，具体方法很多，公开渠道、咨询公司或者调研都可以，就不展开说了。对于后者，关键就是观察用户是不是在用某个功能和在用这个功能时的具体行为。
很重要的还是：数据只是提供信息，做判断一定要经过逻辑分析。之前某老板说从大数据判断出去洗脚店和去医院看病的因果关系，让人跌眼镜，就是滥用数据做判断的典型例子。用户数据是最有价值的信息，但怎么用，是很讲究的。
2.2 快速验证
访谈的结果有时候不会特别可靠，快速验证是最重要的方式。具体方法有很多，包括大家常提到的 Demo 或者 MVP（最简化可实行产品） 或者灰度发布或者 A/B 测试都可以作为验证手段。
其实大部分手段只适用于功能已经比较完善的情况下，也就是做事后判断，而不是事前的预测。
折衷的方案是：用最简陋的方式做一个满足需求的功能出来，投入到市场中观察用户的反馈，来确定功能的重要程度。如果用户反馈良好，就做得更完善、优化得更好用，反馈糟糕就砍掉。
不过这样的验证可靠，但显然成本很高，要酌情使用，对于特别拿捏不定的可以用这方法，但如果每个需求或功能都用这套方法，其实意义就不大了。还是要通过更准确的判断来对需求和功能定性，从而节省成本。
最近我看过一个最有趣的快速验证方法，特别鸡贼，是国外的，可以参考。
他们在想检验用户是不是对他们的服务有兴趣时，并没有考虑做个简陋的 MVP，因为他们认为没有良好体验的功能版本并不能很好地检验，所以他们就做了个精美的官网、列举了他们要提供的所有的功能和服务、甚至支持真实支付成为会员。但是，他们没有做任何功能和服务。
这是他们官网首页。
这是询问用户是不是要使用他们的服务。（做得跟真的似的……）
最后再告诉用户：都是假的，还没做好那。
虽然都是假的，但用户真正来到了哪个页面、有多少关注这个服务、有哪些有付费意愿，这些数据是都拿到了。觉得靠谱接着做完，不靠谱就退款给用户，成本极小。
是不是很牛逼的方法？
希望能帮到你。
评论(0)