项目需求需要把握项目整体的方向和宏观的需求，本文作者从自己的实战经验出发，结合实际案例，对项目需求进行分析梳理，并记录了自己的相关思考，与大家分享。

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

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

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. 析出主题域

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

3. 使用构件图

什么是构件图？为什么要画构建图？

构件图就是划分主体域之后，对梳理出来的脉络进行进一步整理，找到各主题域之间的接口关系之后的关系图。

如果单独采用之前的层次结构，只是体现了分解结构，就会隔离各个业务，忽略了各个主题域之间的关系。构件图就是为了明确各主题域之间的关系，明确主题域之间接口关系的另外一个作用也是作为需求变更的防火墙。创建构建图后，如下：

当然，接口的定义很广泛，有技术上各个类之间的接口，构件之间的接口，对于需求而言，这里是从业务的角度来说，各个主题域之间的接口。

关于主题域的思考

在以上案例，由于项目案例的业务很简单，按照一两个业务流程就能确定主题域，并且只通过一级就确定了主题域。

我们的目的在于如何通过主题域的设计思想，来为需求范围定义提供系统建设的分类参考，而对于B端复杂的业务系统，业务流程众多，怎么样能理清主题域？还有几种方法：

1. 以组织结构为线索：在组织复杂聚合的情况下，组织部门的边界可能就是主题域的边界；
2. 以分管领导为线索：按照领导权力边界划分；
3. 以典型的业务职责区分：例如很多企业/组织都有自己的产品生产，销售，供应等环节。

结语

以上便是笔者根据实战项目，对项目需求定义的一些思考，作为个人的复盘和记录，希望对你有帮助，欢迎指正和评论。

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

题图来自 Unsplash，基于 CC0 协议