产品结构设计
来源：网络
阅读量：次
产品结构设计
包含多层维度的设计。主要有如下5层维度
系统层面的结构——如何分平台／系统
版本层面的结构——如何分版本／权限
模块层面的结构——如何分模块／二、三、四、五级模块
页面层面的结构——如何分页面／页面信息
产品内在逻辑结构——如何用逻辑串联
产品结构的在用户端的展现就是信息结构。这点相信大家都懂，无非是页面层级、页面内部信息层级的划分、信息内容的分类和展示。
其次就是产品内在的逻辑结构：
比如某个配置项应该放在功能模块内还是基础模块内？
比如在连锁系统中，会员是放在连锁维度还是单店维度？
比如直接在营销活动中创建电子券，还是先在电子券模块中创建，然后营销活动进行引用？
这些其实都属于产品功能层面的架构。
内在逻辑架构设计的核心原则及案例
（1）、易用性——从用户使用体验层面考虑
（2）、可扩展性——迭代、修改的成本最小化
（3）、技术实现性价比——技术实现成本是否过高不匹配功能价值，按性价比高的去设计
（4）、普适性——每个单元模块是否可以被其他单元无限重用
（5）、熟悉业务——违反业务习惯的逻辑设计不能出现
（6）、掌握产品发展方向——预见产品在中短期内的发展方向，提前考虑进去
（7）、从简单到复杂——任何一个产品都是从最小MVP开始的，千万不要在开始就架构一套复杂的系统
关于一些结构设计上，我给大家列一些比较高频出现，比较常见的B端产品（不同纬度的产品架构思路）小例子：
1）、比如我们有一套面向商家的门店经营管理系统，这时需要一个有一个卡券平台，跟门店管理系统中的业务有着密切的关系，这个时候你该定义这是一套系统还是两套系统？他们的关系是什么？边界在哪里？
2）、比如我们做了一套诊所管理系统，后续要垂直化专科式发展，那么到底是通过拆分版本，完全一个科室一个独立的版本？还是做在一套系统里，然后通过权限划分 更合理呢？这其实就是产品架构的一部分
3）、比如对于电商类的saas，很多是非协作型的，也就是说模块之间并没有严格的强联系，相对比较独立，独立作为一个B端业务闭环，可单独使用。但是像诊所saas，则是协作型的，即业务流程涉及到多模块多角色，每个角色都需要在流程中承担一部分工作职能。非协作型和协作型的系统设计的思路也是不同的
4）、比如我们在设计电子券的时候，我们是通过一个步骤完成创建+投放，还是通过创建一个步骤+投放一个步骤完成流程？背后的考虑因素是什么？
5）、对于一些业务流程的设置项，是放在后台该业务模块维度，还是基础设置模块的维度？
6）、比如原先要设计商品管理模块，考虑的主要是单店模式，跨店的商品管理是隔离的，但是当跨店客户提出想要统一管理商品，并可以支持总分店和分店之间的商品调拨的时候，单店商品管理的设计方案就无法支撑这样的业务模式，需要做大规模的底层改动
7）、确定维度，比如哪些指标是单店维度，哪些是机构维度，比如预约是放在后台“诊所管理”里面，还是单独放在后台“预约管理”中？放在哪个维度又是基于哪些原因考虑的？
8）、业务的不满足性，比如我们在做一款电子券的时候，考虑了线上场景，但是还要考虑线下场景，这就需要电子券模块下需要投放到线上（多个渠道）、线下（二维码、短信等），那么渠道后续可能会进行变更，那么假如我们把创建+投放一步完成，那么未来我们要改动渠道，就会影响整个卡券流程，如果我们能分2步，那么只需要对第二步投放进行修改就行，这样系统的可扩展性就会强很多
9）、比如对于订单模块的架构设计，是否能够支持各种营销活动：满减、卡券、积分抵扣等，具备足够强的业务包容性
10）、重复被使用的模块，如何避免重复造轮子！比如电子券模块，在很多营销活动中都会用到，比如短信消息模块，在很多业务中都会用到，那么这些被高频用到模块就应该抽离出来，而不是每个业务环节中都去做一遍。
产品结构
内容版权声明：除非注明，否则皆为本站原创文章。
