编辑导语：B端产品具有非常强的业务属性，如果缺乏框架性思考，不仅单点设计功能将会让你精疲力尽，还可能会导致比较严重的问题。本文作者基于以往的经验，为我们梳理了符合业务的框架，希望能带给大家一些帮助。

缺乏框架性思考可能导致比较严重的问题：

• 对内：不断的堆砌功能，开发成本会越来越高。
• 对外：用户看到的信息繁杂，无法高效完成任务。

设计功能应前先厘清业务架构，以一种抽象的框架视角来全局思考。

一、业务架构

业务架构是一套将功能依据业务进行分类，整合形成的抽象化的业务模型。业务架构可以帮你厘清每个业务模块/功能间的边界，以及它们之间的关系。

先梳理架构，可以理解业务模块的边界，面对多个类似的需求时就可以基于场景迅速定位对应的模块；然后再设计功能，解决用户的需求。

架构有助于梳理一套标准化业务模型，搭建框架，让后端标准化，前端个性化，最终为了高效满足用户的不同需求。

我们要用发展的眼光看待架构，B端产品从大的层面分为四个阶段：

1. 基础产品完善期：这个阶段需要满足核心场景的需求。这个阶段要不断增加功能、稳定系统、完善服务；
2. 行业产品深入期：这一阶段需要满足重点行业的个性化需求，要有更深度的行业解决方案，更多的客户成功案例，更完善的客户服务体系；
3. 生态建设期：这个阶段要满足大多数的个性化需求，要有个性化定制，开放平台和开放的服务生态；
4. 再创新：让产品迈向更高阶段，探索新的卖点，挖掘用户的痛点，寻找市场的空白点。

业务架构也会随着产品的成长而成长。

二、通用架构

以B端SaaS软件举例子， SaaS不同的业务细分类型，存在一些通用的架构。

1. 商业活动模块核心有三个

1. 商品管理：让商品有更好的卖相，同时高效管理商品；
2. 订单管理：了解商品的销售情况，让自己产生最大化创收；
3. 客户管理：让熟客产生更高的复购和推荐，同时高效管理他。

管理活动主要是帮助企业把人和事（项目）梳理清楚。分解一下管理就是：

• 管人→HRM
• 管事（项目）→OA
• 管资源→ERP

基于不同的管理对象，管理活动架构存在较大的区别。人是管理活动的基石，所以管理活动主要讲述人的管理。

三、梳理业务架构三步走

1. 将场景需求清单拆解到功能，每一个功能需明确解决一个具体的业务问题，如何将需求翻译为功能，极其考验对于业务的理解；
2. 将功能按不同的维度进行分类整合，分类整合需要先考虑符合通用模块的功能，切忌重复造轮子；功能对应的复杂程度越高、业务越重要，越值得被拿出来单独做一个模块；
3. 梳理模块之间的逻辑关系。

以HRM软件举例说明：

小卢是一个创业公司的HR，随着公司不断发展，小卢也在不断调整关注点：

1.第一阶段：员工管理

由于公司人数很少，小卢每天最头疼的都是如何招聘到合适的人才，并且对员工信息进行初步的管理。

每天小卢花时间在各种渠道发布招聘需求，跟人口头约定工资，在招聘到人之后，简单记录一下员工的信息到花名册并分配到对应的岗位，就能基本符合企业的管理诉求了。

员工管理模块的主要业务：

2.第二阶段：考勤管理

随着公司人数不断变多，渐渐地，管理成了难题，老板让小卢想办法用制度约束。

于是小卢开始潜心研究考勤制度，并制定了一些复杂的考勤规则并执行下去，当员工考勤不符合规定时，就会扣工资，这也让老板感到满意。

考勤管理模块的主要任务：

3.第三阶段：薪酬管理

公司在持续发展壮大，小卢发现，负向激励无法让真正的人才留下，于是小卢开始设计一个更高效的薪酬体系，希望能够用正向激励的方式让员工更好地为公司创造价值，当员工为公司创造的价值越多，自然也会得到更多收入。

薪酬管理模块的主要任务：

员工管理模块基于考勤制度与薪酬制度产生活动数据，并最终通过工资反馈。这也是HRM软件的核心。

通过上述业务可以梳理对应的功能，先按照通用架构梳理。

通过分析，招聘业务相对复杂，同时价值比较高，可以考虑单独抽离出来。

申请审批比较通用，适合各个模块，为了避免各个模块重复造轮子，该模块也可以抽离出来。最终可以改成如下架构。

四、框架性思考

我们在做「完美工事」这款HRM产品时，从一开始就制定架构并虽然产品迭代而完善。

如上图，借助 Xmind 思维导图工具可以标识每个模块完成进度，添加优先级标签，更方便产品跟进业务模块，面对新的需求时也方便进行框架性思考。

一点经验分享给大家，欢迎关注交流。

作者：老于；公众号：老于的笔记

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

题图来自 Unsplash，基于CC0协议