本文认为，产品经理需要基于场景分析业务，基于需求设计产品，业务、场景、需求是产品发展道路上不可缺少的三大要素。

以一个电商平台为背景：

业务：实际要做的事。

管理商品订单，根据订单进行发货，对退款订单进行处理。

场景：这个事是如何完成的，过程中有什么人参与。

用户在网站上选购了商品，进行下单，下单后会生成一条待支付的订单。用户进行支付成功后，订单状态转为支付成功-等待发货的状态。卖家安排配货员在下午4-6点会统一对支付完成的订单进行的配货、贴面单、叫快递、发货。

需求：做这个事的过程中遇到了什么问题？

由于订单量不断提升，快递单已经抄不过来了，导致很多货物延迟发货，用户经常催单或者干脆退单。招人也不是长久之计，所以希望后台的订单处理效率能提升。

基于场景分析业务，基于需求设计产品

刚入行的时候，接到一个需求，上手就是干。要管理订单，做『订单管理』；要发货，做『在线发货』功能。

我做错了吗？并没有。我很好的完成了每一个功能，不过，那是以前的眼界。

产品设计时，由于人手、时间等原因，经常会以最小成本去实现一个功能，然后后续再排期迭代，新增功能，修改功能。而眼界，正把我们坑在迭代的过程中。

早期阶段的迭代思路：

商户：可以提供在线发货上传快递单号吗？

我：好，发货需要填写快递单号。

商户：订单越来越多了，能不能把订单导出来，我们复制填写订单好，然后统一发货啊？

我：好的，增加统一发货功能，订单需要导出。

商户：我们接入了快递公司，他们给我们提供了一个单号段，你们这边有接入快递公司的功能吗？

我：我们需要研究一下。

所以，早期一般是，遇到什么问题，解决什么问题。这么做虽然没什么错，但是很是被动。也容易留坑，因为在设计时，脑子里只有当下的需求。比如：提供了订单，我们并没有接入快递100的快递跟踪，用户还是需要复制订单号自己去搜索。

后来做的东西多了，接到需求就会多考虑一些，这个考虑：

• 基于经验，做过这些功能，知道坑在哪里；
• 充分了解业务场景后的需求分析，提前设计。

商户：可以提供在线发货上传快递单号吗？

我：恩？为什么需要上传快递单号呢？

商户：这边有些用户进行打电话问我们快递信息，所以我们希望把快递单号上传上去，让他们可以自己去查快递信息。

我：好的，这个可以做到的，对了，顺便问一下你们这边目前都是怎么发货的？

商户：我们这边会把每天下午4点会把订单导出来，然后抄到快递面单上，让配货的人根据面单去配货，然后打包。等快递来收，快递员走了以后我们这边会统一对订单进行发货操作。

我：额，所以你们这还是人工抄面单的是吗？

商户：对的。

我：你们这边需求我大概清楚了，我们这边会安排下去。

商户：好的。

分析需求：商户目前需要上传快递单号功能，用户这边需要查到自己的快递信息。恩~如果仅上传快递单号的话，还要复制到别的平台再搜索快递信息。看下能不能做到就在我们的平台就能根据快递单号查询物流信息。

另外商户这边目前都是手抄面单，订单少还好，多的话，工作量也不少，这也是个需求点，先记下，排期解决一下（在线打印面单功能）。

订单管理页面已经有太多功能了，发货这个场景看下能不能拆出来，尽量一个功能下只解决一个场景下的问题，让用户做事更专注、快速一些。

以上例子并非真实案例，仅提供一个思路。

基于场景去了解业务：可以让你更清楚，用户为什么要提出这些功能，他们想利用这些功能去解决什么问题。当你充分了解场景之后，你才能改变流程。

『改变流程』：用户很多时候有路径依赖，他们经常会基于原来的流程去跟你讲业务，你的产品只是替代了他们过程中的某个工具，或者修复了原来的某个bug。但是不一定要按照原来的流程设计，而你提出新的流程之前，你必须要充分了解他们做事的场景，才能指出他们的不足，然后说服他们。

基于需求设计产品：用户不一定会明确的跟你说『我要什么』，或者说他们其实也不知道他们要什么，他们就是觉得现在不爽。所以，在了解了场景、业务之后，要深究他们在这个场景下的目标是什么？

提供在线发货功能，是为了提升发货效率。所以，需要围绕『提升发货效率』这个需求点去进行产品设计，在线发货、批量发货、在线打印面单、接第三方快递单号等，这些需求或许无法一次性实现，但是你考虑到了，就可以安排一个迭代计划，走在用户前面，化被动为主动。

以上是我的一个思路转化过程，实际上除了以上思路以外，有时候还会兼顾公司的战略、产品定位等去思考。

发现问题的本质，才能更好的解决问题。主动思考，才能更有计划的做产品设计。

最后说句我自己的工作态度：以主人翁的心态去做产品工作。

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

题图来自 Unsplash ，基于 CC0 协议