产品经理方法论：如何进行需求定义？

项目从立项开始，需求定义就是把握项目整体的方向，宏观的需求。换句话说，就是业务的需求，明确项目的目标和范围。

那么在需求立项阶段，如何进行需求定义，根据笔者的经验需要结从下面三个方面来进行考虑和设计：

1. 需求定义的策略
2. 需求定义的理念
3. 需求定义的范围

一、需求定义的策略

在项目的立项阶段，都会输出一些立项项目书之类的产物，但是大多都比较空洞和混杂。从笔者的项目经历来说，从两个方面总结比较清晰：

1. 内部需求

B端的产品的职责是提高企业的内部运转效率，并为组织提供高效的协同管理，在市场上为企业经营创造机会。

大型企业中，当一个项目目标比较空的时候，找到项目的发起人，可能是部门领导，也可能是高管，进行深入沟通，了解战略规划上的第一步。

2. 外部工作

另外就是想做一个项目来实现业务需求或着商业盈利，当下又没有方向，那可以从外部参照物，包括实地考察，竞品分析等等

二、需求定义的理念

项目在立项阶段总结起来无非就四个字：问题、机会。

• 问题：当前项目要解决一个什么问题，为企业解决一个什么症结，难题；
• 机会：抓住一个什么机会，实现怎么样的商业价值；

三、需求定义的范围

需求范围的定义是一个很重要的工作，范围定义不清楚，容易做很多无用功与重复性操作，对需求的管理也会杂乱无章，新设计一个系统，怎么进行需求范围的梳理和定义，下面结合一个笔者做过的项目进行复盘。

四、案例说明

1. 背景说明

共享充电宝项目现在已在大街小巷普及，共享业务已经越来越普及到生活，包括共享单车，共享座椅，共享男友……

2. 需求定义策略

共享充电线项目，依托于扫码支付与单片机硬件技术，在网吧，酒店房间等场景直接铺设。

用户在上网，或者宾馆，茶楼，手机没有电时，可以直接扫码支付后充电，省去至前台扫码获取充电宝动作。

与移动充电宝相比，充电线不需要充电箱为充电宝充电，用户也不用到处找归还的场地。在酒店，网吧等场景，充电线的铺设与使用，比充电宝灵活，并且可获得大量C端用户数据进行会员运营

3. 需求范围定义

经过第一轮的调查，整理出其各部门总结：

• 用户：扫码支付，获得密码，在充电线单片机客户端输入密码，开机充电；
• 商家：网吧，酒店等业主，铺设设配，消费者扫码支付获得相应的分润；
• 代理商：拓展渠道，发展下级代理商及商家，管理设备，并获得分润；
• 平台：1）管理设备 2）管理代理及商家 3）定价 4）管理分润；
• 厂家：生产设备，进行发货。

这里首先给出一个定义：主题域

当面临一个新的系统的时候，可以将这个系统看成一个黑盒子，将其划分成不同的主题域，再通过一张构件图找到各主题域之间的关系。

什么是主题域？不就是子模块菜单吗？下面来做个对比

在笔者采用主体域划分系统前，是这样划分的

我想大部分产品经理都是这样划分的，这种传统的划分方式，按照逻辑，把这个系统按照不同的部门，划分成不同的模块。再对单独不同部门进行调研。

但是这样划分了以后发现，只是逻辑划分，并没有把业务流程串联起来，在分析的时候，会漏掉业务。为什么产生这样的结果？

传统的方法都是按照“业务名称+管理”来命名，业务名称实际就是业务实体，也就是“物”的线索。试想，我在设计商家管理，我就会想：商家要做什么事呢？设计库存管理，会想库存要怎么计划和显示？设计发货管理，会想发货要怎么走？

现在看来，这并不是最佳的方式，因为业务系统，会大量的业务流程的聚合，以及充斥着千丝万缕的层级关系。若单独去考虑商家和代理管理，是不是就把这两个业务实体割裂了？而这两个“物”其实是有关联关系的。

五、采用主题域划分

1. 节点梳理

但是，当我换了一种方式，以“事”为线索，顺着事务流程，业务脉络，划分成不同的节点。再把这些业务节点下梳理出的逻辑设计与功能设计聚合放入对应的应用端，形成主题域（类似于子系统），系统的一下就变得清晰起来。

我们按照业务流程，划分出三个节点：扫码，支付，获取密码

1）节点1：扫码

• 用户进行扫码，我们自然想到，这个码从哪里来，再倒推出生码，赋码管理
• 扫码以后，进行设备查询，那么就涉及到二维码和设备如何关联，设备的激活，禁用，上下架，倒推出需要进行设备管理

2）节点2：支付

• 接下来进行支付，在扫码查出设备以后，需要查询当前设备的价格，不同的设备肯定有不同的计费规则，并且满足调价需求，那么就需要一套灵活的计费配置来管理，可以把这个功能放入结算管理中
• 用户扫码可能会多个扫码入口，微信，支付宝，聚合支付，外置浏览器，这个时候需要对支付流程进行设计

3）节点3：获取密码

• 用户获取密码的方式，页面还是短信？若获取密码结果通过短信，则需要对接短信服务商，且需要用户填写手机号，拿到手机号又可以进行进行会员管理，进而推出会员管理。
• 密码规则：硬件如何记录使用过的密码？

以上从业务角色1（用户）的业务流，找到了三个节点，并沿着业务脉络梳理出了业务功能及设计逻辑。

现在再从业务角色2（代理商）的业务流梳理

4）节点4

分润规则：代理商，平台，商家的分润规则，分润是按照代理商层级来？还是地区来？还是设备来？再往上梳理，那代理商层级是怎么设计，代理商怎么授权商家？

进而进行代理商和商家的层级体系设计，授权流程设计。最后分润规则的灵活配置放在结算管理进行管理，代理商层级配置放在后台代理商管理进行管理。

5）节点5

现金提现：商家提现，代理商提现的限制，审核流等，属于结算的内容

2. 析出主题域

通过以上的梳理，以一个业务流程为基础，沿着节点梳理，每个节点会涉及到不同业务流程，再把这些业务分配到不同的应用范围里面，形成主题域，这样就理清了系统的脉络，给需求规格说明书提供了一最初的结构目录