带解决方案的需求如何接?只需这3步

带解决方案的需求如何接?只需这3步

时间:2020-4-26 作者:抖音代运营

最近工作中总是接到一种需求:我要 XX功能,这么做就行!

也就是需求提出者直接带着解决方案找过来,这种需求在产品的工作中十分常见,如果处理不好,很可能给自己挖一个大坑,这篇文章聊一下可以如何接这种需求。本文的描述是基于自己的 C端经历。

从业务部门的一个需求说起

在家办公期间突然接到业务线老大的一个语音,开门见山的和我说:现在我们做的直播,想要在直播过程中和用户增加互动,需要在直播中加上答题功能。

具体方案:一次最多 5道题,主持人发起,(此处省略 500字),甚至后台怎么配合都给我说了,然后紧接着问我:什么时候能做完上线?

这种直接带解决方案的需求在产品的工作中,经常会碰到,尤其是业务主导,业务方比较强势的公司中更为常见。如果我们直接执行会怎样呢?

七十九度直接从解决方案出发会碰到的问题

对于这种需求,有时可能习惯性的就跟着提出者的解决方案走,直接讨论解决方案的逻辑及细节。

趟了几次坑之后,我发现直接跟着解决方案走,很可能会遇到如下两种情况:

(1)需求是合理的,但是提出者给的解决方案并不好,只是就问题解决问题

这种情况下,提出者的需求是合理的,但由于提出者可能并不具备产品的专业技能,导致方案有缺陷,无法解决问题。

比如,产品的活跃度很低,不健康,于是负责的同事 A找过来:我们产品的活跃太低了,要提升,我们要多给用户增加推送,每天推送 10条,让用户想起我们,打开我们!

用户活跃度低需要提升,这个没问题,但是不分析原因,强行 push,打扰用户,可能初期有一点点效果,但长期下来,只会让产品的卸载率上升。

(2)需求是不合理的,是提出者想当然的结果

这种情况,提出者提出的需求是“错误”的,是自己想当然的,给出的解决方案必然也是错误的。

常见于不考虑产品的目标用户,以及用户的实际使用场景,只是单纯的就功能自嗨。

以上两种情况,无论是哪种,如果产品直接跟着解决方案走,最终的效果都不会很理想,甚至会导致项目反复,临时变更,越做越复杂的情况。

对于这种“你就这么做”的需求如何接

首先我们要知道,解决方案并不等于需求!对于这种情况,我们要回到需求本身,从需求入手。

很重要的一点是:讨论问题,以问题代替方案来和提出者讨论。

可以分为以下几个步骤:

1. 拒绝传递需求,尽可能找到“需求当事人”

在工作中,可能有很多时候,需求是由老大或者业务部门的老大直接提给七十九度的,也就是需求经过了其他人的传递,这种情况下,信息内容可能会失真,和开始的需求不一致,甚至可能“面目全非”。

我们在接收信息的时候会经过两步:理解与加工;理解中可能会出现偏差,在不自主的加工后信息的失真会更严重。

在传递中,他人对信息的理解与加工,可能会影响我们的判断,如果直接按照传递者的说法做,很有可能方向是错的。

因此,在实际工作中,还是建议允许的情况下,尽可能的和“需求当事人”直接接触,了解一线需求。

比如,笔者曾经负责的一个小程序,中间有一个步骤需要用户授权昵称以及手机号,但在开发的时候发现已经不允许同时获取昵称和手机号了,本来打算调整方案,分开获取。结果一个同事说正好他需要找一下业务,可以帮忙沟通一下,给我返回的结果是他们不要昵称了,但给到业务测试的时候,发现人家原本的意思是:可以在这一步不要昵称授权,而不是可以完全不要昵称。

2. 明确是业务需求还是用户需求

对于提过来的需求,我们先大致分为两个类型:业务需求和从用户角度提出的需求。

之所以要先区分,是因为,这两种需求的出发点是不一样的。

对于 C端产品,业务需求通常来自于运营和市场同学,出发的角度是如何更好的运营用户,是从“KPI”角度出发的;而从用户视角出发的需求,则是认为用户是有这个需求的,这么做是更好的帮助用户。

因此,我们对接这两种需求的方法也会有所不同。

(1)业务需求

这类需求是业务部门内部的,比如业务部门需要做个活动,或者要提升某个指标,需要产品端配合。

文章开头的例子中,运营人员提的直播中答题的功能,就属于这种。

配合业务方,更好的进行产品的推广、运营,是十分重要的,但我们不能完全“听从”于业务方,否则业务方不断的来找配合各种活动,整个项目组的人员都会疲于应付。

对于这种需求,我们要明确两个事情:

1)业务方的目的

对于业务方的需求,我们首先要和他们明确:这么做的目的是什么?

提出业务需求很合理,但在做之前,需要先沟通清楚业务方的目的,明确目的可以让我们了解更多的信息,从产品的角度给出思考与建议,更好的配合业务方,也让我们自己处于主动而非被动的位置。

2)要达到什么样的目标?如何衡量?

对于需求,必然要有能够衡量的标准。如果没有衡量标准,各个业务团队不断的做活动、提需求,会让产品和开发疲于应付运营需求,影响产品的正常进度。

因此,在沟通中,我们需要和业务方明确目标以及如何衡量,要能够有明确的数据指标来衡量。

明确这两点:

  • 一方面可以让我们了解更多信息,并从产品的角度进行思考与建议,掌握一部分的主动权;
  • 一方面,长此以往,也会让业务方在每次提出解决方案前,先明确好目的以及衡量标准,这样可以提前在他们内部就筛选掉不靠谱的需求。

注:目的和目标是两个不同的词。目的更抽象一些,是我们的期望或终极的宗旨,目标则更具体一些,是阶段性的追求。比如,运营同学提的红包活动,目的是想要引导新用户快速下单,具体的目标则是让新用户的下单率提升 10%。

(2)从用户角度提出的需求

这种类型的需求,提出者通常是因为觉得用户是需要的,能更好的满足用户需求,通常也会带着“合理”的理由,但我们还是要谨慎。

对于这种需求,我们要明确:

1)需求是为了哪些用户?

随着产品不断的发展,用户不断的增加,需求会越来越多,越来越多样化,产品中不同的用户,对功能的使用和需要程度都会存在不同,因此,我们需要明确:这个需求,是为了满足哪一部分用户?

2)这部分用户在什么场景下因为什么而会用到它?

需求依附于某一个场景,以及这个场景下遇到的问题。

在明确了为了哪些用户而做之后,我们还需要明确:这些用户在什么情况下,会因为什么而需要它。

比如:人人都是七十九度上传文章的时候,有一个功能:通过链接导入其他平台的文章。这个功能就能够减轻作者人群,在上传文章时排版的工作量。3)目标用户真的“需要解决”这个问题吗?

有时候,确实有需求,但用户真的“需要解决”吗?是否已经有其他的解决方案且广为人知?

比如笔者的一个朋友,曾经想要做一个大学校园的二手交易平台。大学生二手交易这个需求和场景都是存在的,但目标用户真的会有很强的意愿用一个新的方式来解决吗?即使没有这个平台,大学的贴吧、BBS、朋友圈都是他们可以用来出售二手物品的地方。

3. 判断需求的价值

明确需求后,我们要判断需求的价值。

对于业务类的需求,可以通过面向的用户、是否合理、预期投入产出比、是否会造成用户的反感四个方面来考虑。

用户角度的需求则可以从以下几个方面来判断:

(1)需求的覆盖度

这个需求所能覆盖到的用户是多是少?能够覆盖的用户是产品的核心用户还是普通用户?

(2)需求的类型

对于目标用户来说,这个需求是基本型、期待型还是兴奋型?

(3)需求与产品的规划是否一致

需求对产品本身来讲,是否与产品规划一致,是否能够帮助产品更好的服务目标用户?

判断不同需求的价值,主要是为了明确:

  1. 是否要做?
  2. 优先级如何?

资源总是有限的,我们无法满足所有用户的所有需求,因此,我们需要通过对需求价值的判断,决定哪些需求是需要做的,哪些需求是我们放弃的,以及做的需求中,应该优先做哪些?

注:这里的放弃指的是当前阶段,而不是完全舍弃,随着产品和业务的不断发展,有一些某个阶段不做的需求,可能会在下一阶段就值得去做了。

总结

对于带解决方案的“需求”,核心的一点是:不要跟着解决方案走,解决方案不等于需求!我们要通过对需求类型的区分,用不同的方法来明确真正的需求,并通过对需求价值的判断,明确是否要做。

 

作者:海先生,公众号:慢言录

028-84360888 13608068886(推销勿扰) 发送短信