为了账号安全,请及时绑定邮箱和手机立即绑定

论如何培养产品感觉——需求倒推

标签:
产品

吴军在《见识》里讲过,凡事做到50分靠常识,从50分做到90分靠技术,从90分做到100分靠艺术。“产品感觉”我觉得是产品经理这一职业中“艺术”的一部分,暂时我还不太好用言语完美地描述,就先意会吧。

产品经理产品感觉的培养一部分是来自自身的实战经验,一部分是来自别人做过的产品,做自己的产品的过程可以理解为需求正推,而看别人做过的产品我称之为需求倒推。

先讲讲需求正推 —— 需求分析

讲需求倒推之前先讲讲需求正推,即我们耳熟能详的“需求分析”,产品经理们每天做的最多的事是需求分析,可以理解为分析问题到解决问题的过程,或者说是从用户需求到产品功能转化的过程。

苏杰的《人人都是产品经理2.0》中提到过关于需求分析的Y模型,可以帮助大家很好地理解这一过程,这里借鉴一下:

webp

通常的需求分析是指从123的过程,即通过用户需求场景发现用户需求背后的目标和动机,最终得出产品的解决方案;优秀的产品经理需求分析时会经历从1243的过程,4即价值观,需求的本质(文中举了很多需求分析的例子,比如乔布斯讲过的段子“福特与马”,感兴趣的可以详细看下)。

这套方法论听起来简单,实际应用过程中却没这么容易,我们很多人身上的“学生思维”很重,即一看到问题马上就想答案,直接从13,这是典型的方法中心的思维方式,这会导致我们做出来的方案抓不住重点,可能很快被推翻重来。所以我们很多人身上缺乏的是问题中心思维,即通过用户需求思考用户需求背后真正的问题,那如何锻炼我们的问题中心思维呢,我觉得可以从需求倒推入手。

什么是需求倒推?

理解了什么是需求分析之后,就很容易理解什么是“需求倒推”了,所谓的需求倒推,就是从已有的产品推导出背后的用户需求,这中间需要把自己转化为新手,不断地追问产品背后的为什么,从而去真正理解产品现在设计的目的,推导的过程会让你有恍然大悟的感觉。反向推导后再做正向验证,就会有真正需求分析的感觉了,我也是最近好奇一个产品的某个功能设计,才发现需求倒推可以培养产品感觉,所以想写这篇分享。

举个例子

最近跟进某个项目上线,在测试同学处逗留时,发现测试同学在用一个专门测试工具记录自己的测试过程,这个测试工具我之前没见测试同学用过(后来问过测试同学,说是今年刚启用的),于是产品经理的好奇心激发我去用了一下这个产品,想挖掘一下人家的设计理念。

我们知道测试同学测试一个项目通常过程如下:

webp

如果不了解测试工作,或者没有多加思考就将以上过程工具化的话,可能做出来的产品是这样的(只是粗略地把想表达的东西画了一下,众多细节未考虑在内):

webp

拍脑袋的原型

而我看到的测试工具是这样的:

webp

用例库

webp

测试计划

可以看到,我们原想的一个菜单可以搞定的功能,人家分了两个菜单,所以疑问来了,人家为什么这么做?这么做满足了什么用户需求场景?下面是对我挖掘过程的还原:

一、首先搞清楚产品功能

我亲身体验了一下,得出来的结论是这样的:用例库 —— 测试用来创建并管理所有测试用例的地方;测试计划管理 —— 测试根据具体项目创建测试计划并跟踪测试过程的地方(测试用例来自于“用例库”)。至此,还是可能没明白分两个菜单的原因,于是有了进一步的挖掘。

二、看用户的真实使用场景

我看了下测试同学在里面创建的真实用例,发现有几个计划中会包含相同的用例,并且计划名称中包含如“购物车测试(本地环境)、购物车测试(测试环境)、购物车测试(线上环境)”类的字样,我立马结合工作中的实际场景明白了这个产品这样设计的原因。

三、总结产品满足的用户需求场景

比如测试同学在测同一个项目(如“购物车”)的时候,可能会经历几个发布环境,每个发布环境都要测一遍,而每个发布环境测的场景可能是相同的,这种情况下,测试同学就可以从用例库中选中所有的购物车测试用例创建不同的测试计划,用来跟踪每次测试的过程。

再比如不同的项目可能会涉及同一个产品,还拿“购物车”举例,上个月我们做购物车推荐,这个月我们做购物车展示促销活动,都会同时涉及对购物车的测试,但是覆盖的测试用例可能不同,这时候测试同学可能需要做的是在“用例库”创建不同的测试用例,测试的时候选择部分测试用例创建测试计划进行测试即可,如果下次购物车重构之类的,则可以选择所有购物车测试用例进行测试。

四、复盘自己拍脑袋的设计

想清楚别人设计的原因之后,可以照着真实的使用场景复盘自己拍脑袋的设计,就可以发现如下问题:

1、测试用例无法灵活复用

如果我想对一些测试用例反复测试的话,是实现不了的,你可能想到“复制”功能,“复制”功能带来的问题是:测试用例如果需要新增无处安放、复制出来的一份测试用例如果需要跟之前的作区分就要另取一个名字以跟现有的名字区分,这样多次之后,整个用例库重复又混乱。

2、无法实现对用例库的管理

用例库如果跟测试计划合二为一带来的问题是,测试同学无法清楚知道某个项目的所有用例,如果测试同学想基于历史用例补充新的用例,没有一个地方能汇总给到这个项目的所有历史用例,没有根据,就不知道自己有没有补充重复,或者遗漏。

五、正向验证

试想,如果测试同学向你提出做一个测试工具,你能否根据这些使用场景抽象做出来这么一个工具?这中间需要产品同学抽象总结的能力,在足够多的需求收集之后能抽象出背后涉及的元素,及元素之间的关系。

怎么样是不是有一些产品感觉,我也是自己照这个流程走了一遍,才发现自己好像多了点产品感觉,你也可以试试哦,毕竟任何技能都是要靠练习的。



作者:我真是青柠
链接:https://www.jianshu.com/p/606937cce91f


点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
JAVA开发工程师
手记
粉丝
50
获赞与收藏
175

关注作者,订阅最新文章

阅读免费教程

  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消