产品经理如何将用户需求转化为研发需求?

0 评论 3524 浏览 80 收藏 13 分钟

每当接到一个用户需求,产品经理头疼的事情之一,可能就是如何把用户需求转化成研发需求。怎么理解二者的区别,并成功地将需求转化呢?这篇文章里,作者做了分享与总结,一起来看一下。

产品经理与研发人员的博弈是产品界永恒的话题,产品经理说研发人员不懂业务,研发人员说产品经理不懂技术,但矛盾的是,每一次接到一个用户需求的时候,产品经理都需要绞尽脑汁把它转成研发需求,以便于研发人员能够知道如何将该需求正确实现出来。

一、用户需求和研发需求的区别

用户需求是研发需求的结果,研发需求是用户需求的过程;用户需求的本质是“做什么”,研发需求的本质是“怎么做”。然而有时候“做什么”和“怎么做”之间是没有必然联系的。

比如,用户需求是:设计一个功能,使用户可以将当前账号绑定的手机号更换成新的手机号。

在未经过细致分析的情况下,我们大致可以将该需求转化为以下研发需求:

  1. 对旧手机号通过验证码形式进行验证,验证通过后输入新手机号
  2. 验证新手机号与旧手机号不同且未被其他账号绑定后,向新手机号发送验证码
  3. 对新手机号通过验证码形式进行验证,验证通过后将账号绑定的旧手机号更改为新手机号

在以上研发需求中可以发现,如果你不看到最后一步,根本不知道这些需求是为了实现什么功能,而这只是一个很简单的功能,对于复杂的业务功能,尤其是多人分工研发的功能,很多研发人员做完了也不知道这个功能是干什么用的,因为在研发需求中,有时会牵涉一些功能需求;

比如上文提到的对新旧手机号进行验证,或者涉及一些设计约束,比如上文提到的判断新手机号是否绑定其他账号,防止重复绑定,而这些功能需求和设计约束,都是为了最终能够正确实现“更换手机号”的用户需求,但其本质跟用户需求是没有直接关系的。

关于功能需求和设计约束的定义,感兴趣的读者可参考之前的文章《从10大管理看产品经理的日常工作——产品整体管理》。

二、为什么需要转化需求

之所以需要将用户需求转化成研发需求,是因为产品经理和研发人员的思维有着相当大的差别。

产品经理由于经常接触业务,因此在产品经理脑海中,每次想到的都是需求的解决方案;而研发人员,在日常研发工作中,很多只是负责某几个接口或某几个页面的编写,大多数的研发人员对业务形态没有一个完整的概念,所以他们更关注的是需要他们做什么东西,只要研发需求写得足够详细,他们就能在不完全清楚业务形态的情况下将功能开发出来。

还是以上文“变更手机号”的需求为例,如果产品经理给开发的需求这样描述:由于在实际业务中,用户有可能需要更换绑定的手机号,因此需要开发一个这样的功能。那么从开发的角度,他会认为这个功能是这样实现的:给已登陆的用户提供一个页面,用户输入手机号,点击确定后,将该用户账号绑定的手机号修改为新手机号。

如果你问他,为什么不做手机号验证,为什么没有判断手机号重复绑定,他们会说:“产品就是这么设计的。”

这就是产品思维和研发思维的区别,经过多年与研发打交道,我对他们的工作方式总结了一句话,就是:尽量不少做,绝对不多做,不保证不做错,出错就是产品经理的锅。

之所以会形成这样的工作方式,是因为有可能产品经理需求描述中简单的一句话,研发就需要好几个人干好几天才能做完,在这样的工作环境中,他们没有太多的时间去考虑业务层面的东西,因此要求产品经理将需要做的事情写得非常详细,以减少研发人员在研发过程中的思考时间。

三、如何转化需求

将一个用户需求拆解成多个研发需求时,每个需求都可以从用户、权限、验证中的一个或多个维度去考虑,接下来我还是以上文的“变更手机号”需求为例,简单分析一下如何将这个用户需求转化为研发需求。

所谓“用户”,即是“人”,我们可以分析一下什么人有变更手机号的诉求以及原因:

  1. 账号所有人,变更原因:更换手机号
  2. 非账号所有人,如盗号的人,变更原因:通过变更手机号,将账号据为己有

从以上分析可以看到,这个需求的真正的用户应该是前者,而非后者,因此这里就涉及到“权限”的问题,如果不做权限的限制,让后者可以很轻松地变更手机号,那么将可能对前者造成不可估量的损失,关键的问题是,如何明确用户有权限进行手机号变更呢,这就需要通过“验证”来确认权限,我们可以再来分析一下,哪些验证可以用来明确用户的权限:

  1. 账号密码验证
  2. 手机号验证
  3. 人脸识别验证

以上3种验证方式都可以在某种程度上验证用户的身份,在这样的情况下,应该选择哪一种验证方式呢,这就需要做取舍了,我们可以这样分析:

通过以上对比表格,我们可以发现,“账号密码验证”是最先排除掉的,剩下的两种验证方式中,我们可以发现“人脸识别验证”的结果是最准确的,造假成本也是最高的,但同时操作门槛也是最高的,且只能在手机上操作,而相对而言,手机号更加方便快捷,因此大多数的产品会选择通过手机号来进行验证。

但我们会发现,无论是哪一种验证方式,都存在造假的可能,没法百分百保证验证结果的准确性,因此在这个需求中,也可以考虑双重验证,比如通过手机号+人脸识别来验证用户身份,但这未免太过繁琐,那么就可以考虑用户进行手机号验证时,判断用户当前的 IP 属地与经常登录的 IP 属地是否一致,如果不一致,再考虑让用户进行人脸识别,如果属地一致,则验证手机号即可。

当然,无论怎么防范,无非是提高了造假的成本,并不能完全杜绝作假的行为,因此,针对一些安全性更高的信息和操作,应该再上一把“锁”,比如支付应用会要求用户单独设置一个支付密码,用来区分登录操作和支付操作,以此来增加安全性。

除了对“权限”的验证,即将绑定的新手机号也需要“验证”,主要验证几点:

  1. 新手机号与旧手机号不同
  2. 新手机号未被其他账号绑定
  3. 新手机号是正确的

因此,通过以上分析,我们可以尝试将这个用户需求转换成以下研发需求:

  1. 用户点击“修改手机号”时,进入“验证旧手机号”页面,用户发送验证码并进行验证码验证
  2. 旧手机号验证不通过时,通过系统向用户展示错误提示;验证通过时,判断当前操作的 IP 属地与用户经常登录的 IP 属地是否相同,如果相同,则进入“验证新手机号”页面;如果不相同,需判断用户当前访问页面的设备,如为 PC 设备,则展示二维码,用户通过手机扫码进入“人脸识别页面”,如为移动设备,则直接进入“人脸识别页面”
  3. 如需进行人脸识别,在人脸识别验证通过后,进入“验证新手机号”页面
  4. 用户在“验证新手机号”页面输入新手机号,验证新手机号与旧手机号不同且新手机号未绑定其他账号后,向新手机号发送验证码
  5. 用户输入新手机号验证码点击提交,同时验证新旧手机号不同、新手机号未绑定其他账号、新手机号验证码正确通过后,将该账号的绑定手机号更新为新手机号

第5个需求你可能会觉得很奇怪,为什么第4个需求已经验证过一次,还要再验证一次,因为用户可能发送了验证码之后,又将手机号改了,因此绑定前,一定要再次验证新手机号的合格性再绑定上去。

写在最后

讲到这里,本文的核心内容已经讲完了,最后我想讲的是,很多时候产品经理志得意满,觉得自己已经把一个用户需求的研发需求梳理得清清楚楚,但是到了评审的时候还是容易挨怼,一方面,太多的文字容易让人觉得找不到重点,另外,中国文化博大精深,同一时间不同的人对同一句话可能有不同的理解,甚至同一个人在不同时间对同一句话都有可能产生不同的理解。

在这样的情况下,除了尽可能精简一些不必要的文字之外,有时候一个简单的流程图就能够把一个看似复杂的逻辑讲清楚,比如你不妨试试把上面的研发需求换成一个流程图,你会发现比上面那堆文字直观得多,对于研发而言,他们希望产品经理能够直击重点,而不是把需求写得跟小说一样。

如果你对绘制流程图的要点感兴趣,可参考之前的文章《为什么你画的流程图开发总说看不懂?》

以上便是本文的全部内容,感谢阅读!

专栏作家

产品锦李,公众号:产品锦李(ID:IMPM996),人人都是产品经理专栏作家。不务正业的产品经理和他的产品设计。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!