今儿这篇博客记录下三个问题，主要还是围绕用户需求来说的：1）某个调研中值得注意的2个问题；2）如何确定优先级；3）解决问题的思路。
这个调研的另外一个背景是说大boss提出的某个bug，另一boss就提出说是不是假如大boss没发现这个问题，那么我们就没法去注意到这个问题。而实际的情况是，类似这样的小问题，我们一直都是有关注，只不过此前一直都是以整体的方式进行评估调研，而没有从更微观的角度来看这些问题——若是要关注的那么细节的话，就会失去对产品方向整体的把控。我这里提到的这个背景其实是想记录下ziwei老师说的两点需要注意的地方：1）并不是说大boss提出的需求就一定要以更优先级来推动，从根本来说，还是需要我们自己通过调研评估来把这个问题的严重程度搞清楚，综合考虑成本和收益来确定这个问题解决的优先级别。2）这个事情也大概暴露了此前我们的评估标准，或者评估的细则有可能还不够完善，在前一阶段，我们重点关注的是大的地方，而随着产品的进一步推动，我们的标准以及注意力也需要慢慢的集中在某些小问题上。
那么该如何确定优先级呢——具体点的？我们常喜欢在工作中用中优先级、高优先级来说明一个事情需要去做的紧迫程度。但事实上，所谓的中优先级或者高优先级，如果不作额外的说明，作为需求的受理方其实是很难做出准确的判断。因为他们手头上攒着的事情实在是太多了，如果他们看到结论说是中优先级去推动这个事情，即便是结了明确提到了需要高优先级推动的，他们事实上也可能会忽略——对他们来说，总有更紧急重要的事情是去处理的。以上是最近刚做完的某个调研的时候，我在给结论的时候没注意到的问题。ziwei老师说，其实，在这种情况下，我们需要具体的说清楚为啥要做这样的事情，具体到我做的这个调研，从面上来看，影响范围还是比较大，从点上来看，也没有说出现特别严重的恶劣case。那么，在这个时候，我需要指出的是希望rd可以先分析下做这个事情所需花费的代价是多少，然后再综合考虑排期。
其实还有个问题想顺带提下——解决问题的方式。对于se来说，大部分的问题可能都需要通过rank来解决，但脑子里必须清晰，rank并不是解决问题的唯一方式。而要采取什么样的方式来解决问题，从根本上来说还是取决于你的问题是什么，问题产生的原因是什么。如果不搞清楚这些问题，提出解决方案有可能是吃力不讨好。以此调研为例，要看通过调研反应了反映了什么问题，我们对用户的什么需求没有满足好，我们有什么样的资源，这样一步步下来，解决问题的思路就会慢慢清晰了。
接下来的一篇blog将会继续探讨下如何分析用户需求的问题。