B端产品，如何梳理符合业务的架构
缺乏框架性思考可能导致比较严重的问题：
- 对内：不断的堆砌功能，开发成本会越来越高。
- 对外：用户看到的信息繁杂，无法高效完成任务。
设计功能应前先厘清业务架构，以一种抽象的框架视角来全局思考。
一、业务架构
业务架构是一套将功能依据业务进行分类，整合形成的抽象化的业务模型。业务架构可以帮你厘清每个业务模块/功能间的边界，以及它们之间的关系。
先梳理架构，可以理解业务模块的边界，面对多个类似的需求时就可以基于场景迅速定位对应的模块；然后再设计功能，解决用户的需求。
架构有助于梳理一套标准化业务模型，搭建框架，让后端标准化，前端个性化，最终为了高效满足用户的不同需求。
我们要用发展的眼光看待架构，B端产品从大的层面分为四个阶段：
- 基础产品完善期：这个阶段需要满足核心场景的需求。这个阶段要不断增加功能、稳定系统、完善服务；
- 行业产品深入期：这一阶段需要满足重点行业的个性化需求，要有更深度的行业解决方案，更多的客户成功案例，更完善的客户服务体系；
- 生态建设期：这个阶段要满足大多数的个性化需求，要有个性化定制，开放平台和开放的服务生态；
- 再创新：让产品迈向更高阶段，探索新的卖点，挖掘用户的痛点，寻找市场的空白点。
业务架构也会随着产品的成长而成长。
二、通用架构
以B端SaaS软件举例子， SaaS不同的业务细分类型，存在一些通用的架构。
1. 商业活动模块核心有三个
- 商品管理：让商品有更好的卖相，同时高效管理商品；
- 订单管理：了解商品的销售情况，让自己产生最大化创收；
- 客户管理：让熟客产生更高的复购和推荐，同时高效管理他。
管理活动主要是帮助企业把人和事（项目）梳理清楚。分解一下管理就是：
- 管人→HRM
- 管事（项目）→OA
- 管资源→ERP
基于不同的管理对象，管理活动架构存在较大的区别。人是管理活动的基石，所以管理活动主要讲述人的管理。
三、梳理业务架构三步走
- 将场景需求清单拆解到功能，每一个功能需明确解决一个具体的业务问题，如何将需求翻译为功能，极其考验对于业务的理解；
- 将功能按不同的维度进行分类整合，分类整合需要先考虑符合通用模块的功能，切忌重复造轮子；功能对应的复杂程度越高、业务越重要，越值得被拿出来单独做一个模块；
- 梳理模块之间的逻辑关系。
以HRM软件举例说明：
小卢是一个创业公司的HR，随着公司不断发展，小卢也在不断调整关注点：
1.第一阶段：员工管理
由于公司人数很少，小卢每天最头疼的都是如何招聘到合适的人才，并且对员工信息进行初步的管理。
每天小卢花时间在各种渠道发布招聘需求，跟人口头约定工资，在招聘到人之后，简单记录一下员工的信息到花名册并分配到对应的岗位，就能基本符合企业的管理诉求了。
员工管理模块的主要业务：
2.第二阶段：考勤管理
随着公司人数不断变多，渐渐地，管理成了难题，老板让小卢想办法用制度约束。
于是小卢开始潜心研究考勤制度，并制定了一些复杂的考勤规则并执行下去，当员工考勤不符合规定时，就会扣工资，这也让老板感到满意。
考勤管理模块的主要任务：
3.第三阶段：薪酬管理
公司在持续发展壮大，小卢发现，负向激励无法让真正的人才留下，于是小卢开始设计一个更高效的薪酬体系，希望能够用正向激励的方式让员工更好地为公司创造价值，当员工为公司创造的价值越多，自然也会得到更多收入。
薪酬管理模块的主要任务：
员工管理模块基于考勤制度与薪酬制度产生活动数据，并最终通过工资反馈。这也是HRM软件的核心。
通过上述业务可以梳理对应的功能，先按照通用架构梳理。
通过分析，招聘业务相对复杂，同时价值比较高，可以考虑单独抽离出来。
申请审批比较通用，适合各个模块，为了避免各个模块重复造轮子，该模块也可以抽离出来。最终可以改成如下架构。
四、框架性思考
我们在做「完美工事」这款HRM产品时，从一开始就制定架构并虽然产品迭代而完善。
如上图，借助 Xmind 思维导图工具可以标识每个模块完成进度，添加优先级标签，更方便产品跟进业务模块，面对新的需求时也方便进行框架性思考。
一点经验分享给大家，欢迎关注交流。
作者：老于；公众号：老于的笔记
本文作者 @老于
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
