作为一名初级产品，面对需求方提供的混乱资料、大量的需求信息以及复杂的系统逻辑，你是否不知从何入手？
笔者根据自身经历，摸索出“数据-模块-逻辑功能”的方法来梳理产品思路，解决这一难题。
方法
这种方法可以简单概括为：整理全部信息数据；数据分类，划分模块；梳理数据之间、模块之间的逻辑功能。
数据的来源包括但不限于：
（1）需求对接的文件资料；
（2）需求方口述；
（3）页面展示的信息。先把这些字段信息都列示到一个表格里，而我通常是用Xmind进行整理。除了这些看得见的数据，接着还要了解数据之间的逻辑处理；
（4）列出逻辑处理后的数据。
举个例子，下图是根据简化的进销存系统页面列出的信息：
其中，看得见的数据如商品的属性信息：名称、规格；订单信息：购买人昵称、联系方式、购买数量、下单时间等；而下单时长则是看不见的逻辑数据。当订单在30分钟还没付款，系统会主动取消订单，所以需要通过下单时间和系统当前时间计算出下单时长，提供给系统判断是否需要取消该笔订单。
难点：要确保数据的完整性，尽可能地发挥小宇宙，把所有逻辑数据都列出来。
2. 对每个数据按模块分类，且每个数据只能在唯一一个模块中进行维护
我一般会将模块分为两个大类：功能模块和公共模块，再根据实际项目功能划分子类。最终，所有子类的集合就是整个系统的功能模块。
功能模块指的是系统功能性质明显的分类，如商品管理模块、订单管理模块；而公共模块更偏向于收纳通用数据，如行政地区管理模块。
功能模块和公共模块只是个人叫法，用于区分，其本质都是一样的。
（1）广告管理：提取了商品管理中与广告相关的信息。
（2）商品上线管理：把商品管理中“商品组合”形成新商品的数据纳入其中；原来在分销商管理中“上线商品”和“销售价格”也分类到商品上线管理，令分销商管理的数据信息更加纯粹。
（3）用户管理：账户信息系统，管理与用户身份相关的信息，如性别、名称、联系电话等。
（4）行政地区管理：用于专门管理国家、省份、城市的行政地区划分。
按照我的划分方法，功能模块包括：商品管理、广告管理、分销商管理、商品上线管理、订单管理；公共模块包括：行政地区管理、用户管理。全部模块组合起来，就是一个完整的进销存系统。
商品管理模块中的商品名称、编号虽然会在商品上线管理模块展示，也会在订单管理模块中展示，但只可以在商品信息管理中进行维护；同样，行政地区管理中的国家、省份、城市数据在商品管理模块-商品属性-生产地展示，也在用户管理模块-联系地址中展示，但只可以在自己的模块中维护。
3. 对每个模块整理功能逻辑
3.1 内部的功能逻辑
举个例子：根据订单号查询订单，订单号是订单模块里的数据，而查询后的订单列表也是订单模块里的数据，因此查询就是内部的功能逻辑。
难点：在整理内部逻辑时，同样要发挥小宇宙，把所有内部逻辑列完整。
3.2 对外提供的功能逻辑
数据在A功能模块中维护，但B功能模块需要调用或展示；或者A功能模块的数据经过一定运算后得到的数据X，提供给B功能模块，而A功能模块本身可能并不需要数据X。
举个例子：
以订单管理模块的数据为例，从上图中可以看到订单里显示的商品编号、商品名称是由商品管理模块提供的，那么这属于是商品管理对外提供的功能逻辑（提供数据），而不属于订单管理模块的功能逻辑。
用稍微复杂的订单价格和企业的实际收益的流程来解释内部的功能逻辑：
首先，由商品上线管理提供的销售价格乘以购买的商品数量运算，得到订单价格；该运算过程是由订单管理模块进行，因此是订单管理模块内部的功能逻辑。
接着，再用订单价格乘以分销商管理模块提供的结算费率（计算企业分成后所得），算出该笔订单归属到企业的收益。这个运算过程也是订单管理模块内部的功能逻辑。
而对于订单管理模块来说，其中一个对外提供的功能逻辑就是向用户端提供其消费明细。
难点
（1）整理功能逻辑，实际就是分析每个数据的来源和归属模块。在这个过程中，可能会发现最初的数据分类有误，实际的逻辑运算应该在另一个模块里完成。不用觉得自己没考虑周全，多分析几次，积累实践经验后，就能迅速准确地判断每一个数据到底来自于哪个模块。
（2）其次，也可能会发现数据罗列不完整而需要后续进行补充。因为数据的完整性能一定程度保证功能逻辑的完整，而功能逻辑完整了，才能保证系统的业务流程形成闭环。这也是为什么一直强调要把数据列完整的原因。
结语
处理完上述的过程，得到的就是一份信息和功能架构图了。根据这图进行原型设计，有助于避免数据和功能的遗漏。
以上便是个人归纳的其中一种需求整理方法。后来在项目对接中也经常使用，对梳理项目思路起到了很好的辅助，希望能给刚入行不久的产品们一点点启发，同时欢迎各位前辈指导和分享。
