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

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

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

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

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

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

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个需求已经验证过一次，还要再验证一次，因为用户可能发送了验证码之后，又将手机号改了，因此绑定前，一定要再次验证新手机号的合格性再绑定上去。

写在最后

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

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

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

以上便是本文的全部内容，感谢阅读！