如何科学地做好需求评估?

释放双眼,带上耳机,听听看~!

接需求,是产品经理最常见的工作职责了。无论是业务方提需求、领导下达任务、还是需求评审,总会有很多需求扑面而来。比如要加个功能,或者改个流程…

如何科学地做好需求评估?
但是,并非所有需求都经过了深思熟虑,考虑周全。也有些需求,做完了没有任何价值。

那么,你怎么判断这个需求是值得做的?不至于被一些无脑需求牵着鼻子走呢?

拍脑袋,比职级,做实验?

有没有一些系统的判断依据、方法论?

当然有。

一般来说,可以从这四块分析:找出用户和场景,看性价比分析收益,评估方案合理性,最后定优先级和排期。

下面详细说。

一、找出用户和场景

理解需求,第一要务是理解用户和场景,理解谁想解决什么问题。

脱离了这一点,需求极易走偏。

举个例子,一个数据平台产品。领导某天突然提了个想法,觉得现在分析师做了很多报表,但是好多用户没有开通查看权限,不知道这些报表的存在,所以这些报表没有充分用起来。

希望增加一个报表检索和预览的功能,让用户能预览这些报表有哪些字段,然后决定是否申请看数权限。

如何科学地做好需求评估?

听起来很make sense。

因为用户不知道有哪些报表,所以需要通过预览去了解,然后申请权限。你看,有用户,有场景,看起来解决了一个真实的问题。

如果你不假所思的去做了,可能不一定达成所愿。

为什么?

如果你再仔细想想,这个需求里的用户和场景是你想的那样吗?

用户和场景,说的是真正存在痛点的人。

在这个需求里,真正存在痛点的,是领导和数据分析师。而不是用户。

真正的需求和场景是,他们做了很多报表,但是不知道如何让用户使用起来。他们希望用户能更好的利用这些报表,让他们有更多价值贡献。

如果你按照之前的逻辑去做,你就会做一个报表预览和权限申请功能。

而用户却不见得买单。

用户看不看得懂这个预览功能,还是其次。更重要的是,一个普通用户能清晰分辨自己需要什么数据吗?他自己会隔三差五的去搜索看看有没有新增看板吗?他自己会不怕麻烦的发邮件申请权限吗?

显然,他们没有这个诉求。

用户不关心你有多少报表,不理解为什么要预览,不希望申请权限。

他们的诉求,是希望看到更多有用的报表,更方便的使用报表,更简单的开启权限。

更好的方案,可能是把报表直接分配给需要的用户,并且增加“new”等字样提示,或者发消息通知,附带报表字段说明,让用户更容易理解,更方便使用,更愉快的接受。

这种情况下,用户和分析师之间才能取得一个良性共赢。

所以你看,用户和场景的不同,会带来完全不同的推导逻辑。

用户和场景,就像是需求的方向。他们一旦出现偏差了,后面的努力就容易白费功夫。

二、分析性价比

理解了用户和场景后,就需要具体分析这个需求的投入产出了。

我们做项目,当然是期望用最低的成本,实现最大的价值,这样才能收益最大化。

相反,如果做的事情非常难,最后收效甚微,谁都会担心自己这么做是否值得。

所以,性价比是我们首先要考虑的事情。

性价比包括价值和成本,我们先说价值。

评估价值,有几个简单的办法:

  • 看影响面大不大:正常来说,一个人的个性化需求,显然是没有一群人的共性需求来得有价值。一个用户的产品功能出现了BUG,不必着急。但是如果所有用户,都遇到了BUG,那么就得赶紧处理下了。此外,使用频率也有类似的效果,简单来说,高频需求,就比低频需求更值得投入。
  • 看影响程度深不深:同样是BUG,一个是让用户无法付款的BUG,另一个是让用户启动APP的时候多等待了2秒钟。显然是前一个的影响程度更深,更值得做。同样的,如果一个功能的上线,能帮每个用户每天节约1分钟,那就不如另外一个能帮用户节约半小时的产品功能有价值。
  • 看有没有附加价值:可能某些功能,只有少数人用,并且对他的帮助也有限。但如果这个用户是你的上级领导,那么好好做这个功能,就具备了附加价值。你好好表现,领导也许看在眼里,将来给你升职加薪。否则,如果你不重视,那么领导将来有可能对你不待见。

如何科学地做好需求评估?

有了价值,再看成本。

最好的项目,往往都是那些价值高,但成本相对较低的内容。

如果帮每个用户每天节约半小时的那个功能,需要重构整个系统,整体完成要半年,而节约1分钟的那个功能,只需要1小时,那显然节约一分钟的那个功能性价比更高,短期产生的收益会更明显。

当你需要用巨大的成本,换取微小的收益时。这个需求就不再值得做了。

常见的成本问题,还有开发资源不足、当前技术架构不支持、预算不够等等…

除了时间和金钱成本以外,还有一类潜在成本,是风险带来的。

当我们做的事情,有巨大的风险时,此时项目的性价比也会调低。

比如你爬取了其他媒体有独家版权的视频素材,然后在自家平台上播放。这样即便成本很低,将来也有被告上法庭的风险,一夜回到解放前。因此,这种潜在风险也需要考虑到成本里。

如果经过我们的分析之后,我们判断需求的性价比很高,很值得做。这个时候就进入了下一步,方案评估。

三、评估产品方案

对产品来说,业务方一般都习惯带着方案找过来。

但由于业务方的视角具有局限性,这些方案通常都不是一个好的全局解决方案,反而更像是一个吐槽建议。

产品经理的价值,就体现在对这些需求进行评估和转化上。

一般来说,有这么几个部分需要评估:

  • 方案是否最简单最有效
  • 方案是否带来负面体验
  • 方案是否足够有扩展性

1.方案是否最简单有效

一些方案你听起来很绕、很复杂,最终的效果却差不多,这种时候,很可能是方案不够简单高效。

举个例子,当你希望禁止用户填写某个表单时,你可以把表单里的每一个控件都做成不可编辑,或者提交的时候在后端做校验,不允许保存。

如何科学地做好需求评估?

看起来方案很完善,但是成本也不低。

或者你也可以简单直白的把表单填写的入口按钮置灰了,这样的方案就远比前面几种简洁。

2.方案是否带来负面体验

拿前面数据平台的案例来说,如果我们强行给用户加了一个预览功能,把相关的不相关的报表都给用户展现出来,这个时候用户的报表就会特别多,甚至因此找不到自己原来常看的报表了,用户也会因此懵圈吐槽。这就是带来了明显的负面体验。

一般来说,负面体验在可接受范围内,都是可以的。但如果过于难用,就需要想别的方案替代。借用俞军的公式来说,产品价值=(新体验-旧体验)-换用成本。

我们需要确保新功能的价值,要远大于用户付出的代价。

3.方案是否足够有扩展性

有时候我们做项目图简单快捷,喜欢把文案、数据都写死了,或者把页面交互框架、数据层级结构定死了。那么等到未来再想改的时候,几乎是不可能的。

对于一些持续迭代维护的产品而言,还需要考虑长远,留出一定的扩展性。

对产品经理来说,提前考虑未来版本的可能走向,提前将这些信息告诉下游开发,这样未来才能愉快的和技术交流迭代。

甚至对一些通用组件,要提前考虑解耦的事情。比如搭建通用的SDK、前后端分离开发、模块组件化等等。这样未来的维护成本会低很多。

四、确定优先级和排期

经过前面的分析,我们就明白了需求的方向、价值、方案,剩下的就是排期实现了。

这个时候,主要工作就是跟相关同事同步信息,协调资源和时间,让他们开始落地实现。

性价比的分析,会告诉我们需求的优先级,用于权衡不同需求之间的先后关系。

有了这个先后关系和对应原因,我们就能够妥善回复业务方大致排期了。至于具体的完成时间,一般都是需求评审后才能知晓。

实现阶段主要难在资源协调和项目管理,项目负责人要确保大家认可这个事情的价值和目的,并且对齐各方的认知,让大家对具体方案有明确统一的认识。

对于项目里每个任务要拆分足够细,单独评估工时。确保大家每周过进度,解决遗留问题等等…

当然,这也是项目管理领域的知识范畴。

给TA买糖
共{{data.count}}人
人已赞赏
产品经理

高质量的数据需求文档怎么写,看这篇就够了

2020-7-20 12:28:29

产品经理

需求太多优先级怎么排?完爆KANO模型的WSJF模型

2020-7-20 13:24:13

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索