编辑导读：产品经理日常工作中最常听到的词就是需求，而产品经理的核心工作也就是把需求变成可使用的产品。那当我们接到需求时，我们是如何把它转化成产品呢？本文将从七个方面进行分析，希望对你有帮助。

一、对“需求”这个词的理解

首先我们先了解一下，在产品开发过程中所沟通的“需求”到底指的是什么。我们先举几个我们工作中常常听到的需求：

• 老板：现在经营效率太低了，我们要上个系统，提高效率（目标需求）；
• 财务：每笔费用报销都要走审批，加强对费用支出的管理（业务需求）；
• 运营：日常经营数据需要支持导出功能，好进行加工分析（功能需求）。

我们可以将平常听到的需求都归为这三类，产品经理需要做的就是将目标需求和业务需要转化为产品方案，然后交付给开发团队。

接下来我们将以羽毛球馆订场地这个业务需求，来拆解一下整个过程，看它是一步步变成产品方案的。

二、定位业务问题

场馆运营部门提出一个需求，我们需要实现线上订场地。

业务需求的提出，肯定是为了解决某些业务问题。通过调研，现在纯线下订场的方式存在以下问题：

球友：

• 想运动，但不知道哪里有合适的场馆?
• 不知道场馆是如何收费的?
• 场馆有没有空闲的场地?
• 场馆的有哪些项目？有没有停车场、淋浴等设施？

场馆：

• 球友打电话过来，询问场地价格和空余等情况耗费时间;
• 新球友订场交定金麻烦，不交定金又可能爽约，造成场地未预定出去的损失;
• 人工登记场地预定情况，易产生失误，导致一场多订等情况，极大影响客户体验；
• 场地预定情况很难统计成分析数据，对运营决策无法提供帮助;

业务问题定位了，后面的设计就要围绕这些问题展开，设计完后要回过来看有没有解决这些问题，否则一切都是徒劳的。

三、梳理业务流程

流程是产品设计的关键，梳理流程能让你对整个过程更清晰。梳理过程前，先要明确下订场有几个场景，因为每个场景的流程可能不太一样。通过调研和分析得知，订场主要有以下几种场景：

• 线上订场—球友在微信或者APP上订场；
• 线下订场—球友直接到场馆前台临时订场；
• 电话订场—打电话给场馆前台，让前台预留场地；
• 长期球友固定订场—有些企业会固定在某个时段订场，比如周三的18:00~20:00，一次预订即可，定好有效期，不用每次临时预订；
• 包场—企业搞团建时会包下整个场馆；

这里就要思考一下，我们这次设计是否要满足这5个场景呢？我们回到定位业务问题这一步，问题都是在想要运动的球友在订场时存在的，而方式e在线下的处理暂时并没有多大问题，再深入一步调研可了解到，包场都是直接线下谈好价格，这个价格也是可浮动的，然后将钱线下转给场馆，放到线上反而不灵活，所以我们就先不考虑线上实现这个场景。

Tips：产品经理需要学会做减法，并不是把线下所有业务搬到线上来，开发出来后发现并没有什么用，又浪费这么多资源。

将待实现场景确定下来后，我们需梳理每个场景的业务流程，这样才能对整个过程清晰。因为我们这次只是讲方法，所以就只拿场景a来举例，继续下面的分析过程。

我们梳理出线上订场流程图后，这时我们需要分析一下，这些环节哪些需要做到线上？

入场前：订场、付款、锁场肯定是需要做到线上的，产品的目标就是为了解决订场效率低的问题；

前台接待：出示订场凭证、校验订场凭证、开灯、放行这些环节并没有太大的影响效率。出示订场凭证、校验订场凭证可通过报手机号的形式解决。开灯和放行涉及到智能灯控和智能闸机的对接，没有这些东西业务也能跑的通，也能正常营业，这期也先不考虑在线上实现；

入场后：到点提示也涉及到智能设备的对接，先可人工提示。

Tips：产品经理需要定义需求的优先级，先把影响业务正常运行的问题解决掉，再来迭代优化。

四、梳理业务规则

业务规则是运营部门为使业务正常运行而定义的，就算没有系统也是存在的。产品经理需要做的是把这些业务规则梳理出来，然后用产品的语言把它描述出来。还是以线上订场举例，场地什么时候可以订?订的时候有没有时间限制？价格会由哪些因素影响？可不可以退场？会员有没有什么特殊权限？这些规则听着是不是很乱，这就需要产品经理一条一条梳理清楚，梳理规则的同时还需要多问为什么要这样做呢，一来以后方便和开发等同事说清楚为什么这样设计，二来也能加深自己对业务的了解。

通过调研我们梳理出以下预订规则，但我们需注意以下两点：

• 这些规则都是比较容易通过调研得到的，还有一些隐性的规则，调研的时候很难得到，可能在产品上线一段时间后才能想到。例如订场后要在一定时间内支付，不支付就将场地变成空闲状态。产品上线后这种规则缺失一定会暴露出来的，但产品经理最好能提前考虑到这种规则，尽量避免损失。
• 这些规则仅仅为一个场馆的规则，为将产品的适用更多的场馆，也为防止以后场馆的业务规则变动，尽量做成可配置的。

以上只列举了线上订场的预订规则，还有退订规则、价格方案规则、会员权限等规则都需要一条一条梳理出来，这里就不一一列举出来了。

五、绘制原型

业务流程和业务规则都梳理出来后，就可以画原型了。这一步对产品经理来说，即简单又困难。简单是因为去想象具象的软件操作比思考抽样的业务逻辑更容易，难是因为画的原型最终要符合业务流程和业务规则，并且还要符合常规交互原则。

从业务流程分析，整个订场环节涉及到球友和场馆，那肯定要有球友订场端和场馆管理端。球友订场端刚开始也没必要做APP，做个H5放在微信公众号就可以了，还能引流到公众号。确定好用什么来实现后，我们要梳理一下线上订场有哪些页面，不要想到一个画一个，这样很容易漏页面。

Tips：刚开始设计原型时，尽量不要添加一些和主流程无关的页面，比如你觉得别人做了个VR查看场馆，你也要做一个，但是前期最重要的是把业务跑通，再来添加一些附加功能。

工具类产品原型设计多参考一下美团、淘宝等移动端产品，因为移动端产品发展到现在，已经培养了用户的操作认知，我们不用去发明轮子，让用户再重新去学习。

六、可用性测试

产品的原型出来了，可以给客户演示，让客户跑一遍整个流程，看先前提的业务问题有没有得到解决。如果有问题，再进行调整。其实让客户跑一遍流程也不能发现所有问题，只有在真正使用的时候才会暴露出问题来，但这一步也是不可少了。

七、撰写PRD

PRD全称为Product Requirement Document，中文名为“产品需求文档”。其核心目的是帮助开发、测试、运营、产品人员理解该需求的背景和具体要求，减少产品实现过程中诸多不必要的重复解答，从而提升整体项目推进效率。当业务规则、业务流程、原型图都出来后，我们需要把它交付给我们的开发团队去实现，交付的形式就是PRD。这里就不阐述PRD怎么写了。

八、总结

当接到业务需求时，变成产品的过程是：

• 定位业务问题；
• 梳理业务流程；
• 梳理业务规则；
• 绘制原型；
• 可用性测试；
• 撰写PRD。

以上只是个理想化的流程，产品经理并不是写完PRD扔给开发就没事了。包括后面的需求评审、跟进开发进度和问题、测试上线、迭代优化等，都需要产品经理主导。

写在最后：文中只讲了分析的方法，并没有把实际的过程细节描述出来。如果各位大佬有其他见解，也欢迎提出，产品路上我们一起成长。