作者：imwaco

本文主要是卖下瓜，说下自己对如何分析用户需求的一点看法。

用户需求这个被用滥说滥的词语，我还是想来再插上几句话。从何说起呢？我不知道，想到哪里就说哪里吧。

刚洗澡的时候也在思考这个问题，首先我想到的是产品的定位。 作为一个产品来说，它有其自身定位，它解决的用户需求一定要符合产品定位的。否则，产品就有可能出现无限延展的情况。 而用户需求本身也是纷繁复杂的，加上产品定位这个限制条件之后，应该可以过滤掉相当的一部分。

剩下的呢，需求的主次，把次需求过一下。 然后就剩下主需求了。

除了需求的主次，还有需求的紧迫程度。 从主需求里挑最紧急的来做。 然后这个时候剩下的需求应该是不多的了。 还能再过滤掉一些么？

仔细想下，解决需求的难易程度，即成本，又可以过滤掉一部分。

也就是说获取核心需求，可以经过以下几个步骤来过滤： 1）在产品的定位思考用户的需求； 2）辨别清楚用户需求的主次； 3）区分用户需求的紧迫程度； 4）考虑解决用户需求的难易程度。 类似一个倒金字塔的结果，一层一层的往下过滤，然后最后就可以得出你眼下最需要解决的问题了。 这个一个大原则大道理，这样的道理应该是每个人都会明白的。 大多数人讨论问题其实也就是在这个层面。

应该结合case讨论的更深入些的，担心泄露机密什么的，所以还是算了吧。

今儿就谈点主义。

今儿这篇博客记录下三个问题，主要还是围绕用户需求来说的：1）某个调研中值得注意的2个问题；2）如何确定优先级；3）解决问题的思路。

这个调研的另外一个背景是说大boss提出的某个bug，另一boss就提出说是不是假如大boss没发现这个问题，那么我们就没法去注意到这个问题。而实际的情况是，类似这样的小问题，我们一直都是有关注，只不过此前一直都是以整体的方式进行评估调研，而没有从更微观的角度来看这些问题——若是要关注的那么细节的话，就会失去对产品方向整体的把控。我这里提到的这个背景其实是想记录下ziwei老师说的两点需要注意的地方：1）并不是说大boss提出的需求就一定要以更优先级来推动，从根本来说，还是需要我们自己通过调研评估来把这个问题的严重程度搞清楚，综合考虑成本和收益来确定这个问题解决的优先级别。2）这个事情也大概暴露了此前我们的评估标准，或者评估的细则有可能还不够完善，在前一阶段，我们重点关注的是大的地方，而随着产品的进一步推动，我们的标准以及注意力也需要慢慢的集中在某些小问题上。

那么该如何确定优先级呢——具体点的？我们常喜欢在工作中用中优先级、高优先级来说明一个事情需要去做的紧迫程度。但事实上，所谓的中优先级或者高优先级，如果不作额外的说明，作为需求的受理方其实是很难做出准确的判断。因为他们手头上攒着的事情实在是太多了，如果他们看到结论说是中优先级去推动这个事情，即便是结了明确提到了需要高优先级推动的，他们事实上也可能会忽略——对他们来说，总有更紧急重要的事情是去处理的。以上是最近刚做完的某个调研的时候，我在给结论的时候没注意到的问题。ziwei老师说，其实，在这种情况下，我们需要具体的说清楚为啥要做这样的事情，具体到我做的这个调研，从面上来看，影响范围还是比较大，从点上来看，也没有说出现特别严重的恶劣case。那么，在这个时候，我需要指出的是希望rd可以先分析下做这个事情所需花费的代价是多少，然后再综合考虑排期。

其实还有个问题想顺带提下——解决问题的方式。对于se来说，大部分的问题可能都需要通过rank来解决，但脑子里必须清晰，rank并不是解决问题的唯一方式。而要采取什么样的方式来解决问题，从根本上来说还是取决于你的问题是什么，问题产生的原因是什么。如果不搞清楚这些问题，提出解决方案有可能是吃力不讨好。以此调研为例，要看通过调研反应了反映了什么问题，我们对用户的什么需求没有满足好，我们有什么样的资源，这样一步步下来，解决问题的思路就会慢慢清晰了。

接下来的一篇blog将会继续探讨下如何分析用户需求的问题。