需求的优先级

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

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

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

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

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注