首页 > 名字大全 > 微信名字 正文
【微信连体字名字】深长文本(a):什么是产品体系结构?

时间:2023-03-08 06:39:44 阅读: 评论: 作者:佚名

业务偏离的所有结构都是流氓,产品更是如此。本文首先对产品体系结构的基本概念和方法~enjoy做一个整体说一下。

我们经常可以看到“产品架构”这个词,甚至可以看到一些公司有“产品设计师”这个职业。

说到结构,很多人会感到虚无缥缈,到底什么是产品结构?

我们知道,有技术设计师、自我推进、人、技术设计师这种专业工作岗位。首先,让我们看看技术建筑师在做什么。(约翰肯尼迪,技术设计师、技术设计师、技术设计师、技术设计师)

建筑师可以采取相关的高可用性措施,使在线业务模块化、重新配置系统分区、确保系统稳定性和安全高效地运行。简而言之,这是一个团队领导,需要同时控制总体和区域瓶颈,并根据特定的业务场景提供解决方案。

首先,我们来看一下技术设计师的几个关键关键词。

由于平衡抽象、建模和设计可预测性、主动简化的美模型和重用质量、效率和资源敏捷性、迭代和进化前结构和重构的特点,技术体系结构的关键词也适用于产品体系结构。

技术架构上有一句比较流行的话。业务偏离的所有结构都是流氓,产品更是如此。

让我们考虑把“产品体系结构”写成文章系列。这篇文章首先从整体上说明产品体系结构的基本概念和方法,然后对以上关键词进行深入分析。

首先,什么是产品结构?

1. 先来看看“人”的构成

(1)原子水平60多种重要的东西,例如氧气约占65%,碳约占18%,氢约占10%,氮约占3%,这四种元素约占人体的96%。其他因素很少,但很重要。

(2)在分子水平上,水约占人体的60%,碳水化合物和脂肪约占人体的14%,蛋白质约占人体的17%,其他维生素、矿物质、纤维素等。这些是人体的七种营养素,这七种营养素在人体中各有非常重要的作用,不可或缺,不能太多。

(3)在细胞水平分析中,人体由细胞、细胞外液和细胞外固体组成,细胞是构成人体的基本单位。

(4)组织水平分析中,人体由上皮组织、结缔组织、肌肉组织、神经组织等四个主要组织组成。

(5)长期水平分析中,多个组织以不同的编制形成器官。人体有很多器官,包括胃、肺、心脏、肾脏、脾脏、胰腺、肝脏、膀胱、尿道、子宫等。

(6)系统一级共有九大系统。消化系统、呼吸系统、脉管系统、内分泌系统、神经系统等。

我们用消化系统打一个比喻就很清楚了。让我们看一下消化系统的示意图。

我们将发现人类的消化系统:

它由许多器官组成。它由消化道和消化腺两部分组成。食物分布在口腔、咽、食道、胃、小肠(十二指肠、工厂、回肠)、大肠(阑尾、盲肠、结肠、直肠、肛门)中,消化道壁附近,有助于将消化液排出消化道内消化食物。有必要的功能作用:食物的消化和吸收为机体提供必要的物质和能量。

2. B端业务体系的构成

“人体消化系统”与“B端业务体系”非常相似。例如,一个病人来诊所看病。顾客必须先在网上预约,然后在约定时间到诊所登记诊疗,接受诊疗,付钱,接受药物,最后离开诊所。

整个业务流程包括预约、注册、诊疗、支付、吃药等“软机构”模块、“硬机构”等医生、护士、药剂师、相应药品、材料、电话号码硬件、打印机等。

这些柔软而坚硬的“器官”在整个过程系统中发挥着不同的作用,使患者能够顺利进行到过程的结束。约翰f肯尼迪,Northern Exposure)这个工作体系发挥的作用是有秩序地诊治患者。

结束人的消化系统,回顾B端业务,会发现很多相似之处。

消化系统——业务流程系统组织——基本模块机构——第一业务模块细胞——第二业务模块分子3354页内的标签(第三业务模块)原子——字段此处出现的“基本基本基本模块”、“第一业务模块”、“第二业务模块”等本质上是对业务的分层

(1)层定义

一般来说,B端产品的分层基本上是根据上面的(2)-(6)维度划分的,根据业务复杂性相应增加。

或减少层级。

(2)完成分层

将同一平台下、同一职能下、同一角色下具有高度关联的子模块分到同一层母模块中,这就需要你作出判断哪些模块是业务相似度和关联度都非常高的。

事实上(2)-(6)构成了业务的结构,每个维度模块们的任意一个模块都是结构中的节点,他们之间相互独立,但又相互关联、相互影响。

类似计算机网络的结构:

所以我们看到:B端业务的核心在于业务流程+结构,且业务塑造的结构是为业务流程而服务,什么样的业务流程决定什么样的业务结构。

3. B端产品架构的构成

产品架构就是对业务的结构化抽象!根据业务体系的分析,我们看到其实TO B产品最后就是要抽象出准确的流程+结构。

我们常常说一个功能,或者一个业务场景的解决方案,本质其实就是一个小系统。

在这个小系统中,上面那些“底层基础模块”、“一二三级业务模块”、“字段”等各种节点支撑了这套业务流程,从而使得这个功能(解决方案)能够形成闭环,并顺利的运转起来。而众多功能/解决方案又构成了一个产品整体,就像这些众多的相互独立、相互作用、相互依赖的小系统组成了一个大系统。

再强调下:大家要记住TO B业务中,流程是核心,结构都是围绕业务流程进行划分和设计的。所以流程的优先级是大于结构的。

二、如何绘制业务流程图?

一款产品的主要核心业务流程的脉络一定是非常清晰的。比如:这是一款自助开票软件,那么核心流程一定是用户扫码自助填写开票信息,并由系统完成开票,并发送到用户手机/邮箱。比如:这是一个电商平台,那么核心流程一定是选购商品,添加购物车,下单完成支付。

当然B端复杂的业务场景往往会有多条主业务流程,并且附带了很多分支流程。

我们在画流程的时候,首先要定义横纵向维度,其次就是划分模块。

一般来说,流程图的纵向维度可以做成职能部门/角色/平台层;流程的横向维度可以进行平台层/模块层的划分。

以下图“拼团功能”为例,横向是平台层,纵向是模块层,这是一个跨平台跨模块的产品需求。可以看到在这个业务流中,一级模块划分出了营销、商品、订单、统计模块。本质上划分模块就是对业务流的解耦。

三、模块划分的基本原则?

根据上述流程构建的一个非常简单的产品结构图:

(这个结构图略去了很多,只是想做个示意)

这其中我们看到划分出来了“商品”、“活动”、‘订单“、”统计“,加上“商家管理”、“消息推送模块”共6个模块。

那么在划分模块的时候我们要关注哪些原则呢?

1. 关注低耦合

(1)什么叫解耦?

藕断丝连,这个词语非常形象,业务体系就像一个藕,业务内部的模块之间的相互关系就像藕丝一样错综复杂,又互相依赖、联系紧密(耦合),解耦就是把藕折断,分成独立的两部分。

本质上它是把场景不同、业务属性不同的模块进行拆分,归为不同的两类,但是因为两者都为业务流程服务,这其中难免会有相互协同的地方,于是就会有丝连的情况,这种丝连体现在流程中。

(2)解耦的作用?

解耦能够让场景更聚焦,让功能模块更聚焦垂直业务。比如积分模块,凡是跟积分相关的一切业务需求,如无特殊情况,都可以被归集到积分模块中。对于需要用到积分的其他业务,则可以通过开放一些标准接口供其他业务调用。

最忌讳的是把另一个业务(随便举个例子比如活动模块:抽奖活动,抽中就送积分)和积分模块聚合在一起,这会导致,任何一个模块要做修改和迭代时,都会最大程度的影响另一个模块,导致无论产品还是技术的迭代成本都异常之高。

2. 关注角色场景

对于不同职能/角色不同的使用者,他们的业务场景,工作内容必然会有区别,我们不能把他们各自使用的功能权限放在一个模块内,这会带来很多问题:

  1. A和B的模块发展方向完全不同,导致模块的发展南辕北辙;
  2. A和B的模块关联度很低,产品功能上两者聚合在一起显得毫无意义;
  3. 用户不希望A的模块可以被B看到和使用,两者的权限不同,但是由于同属一个模块而导致权限非常难划清边界。

所以对于不同职能/角色的使用者,尽量将他们各自所要用到的产品模块拆分开来,保持各自的独立性,是模块划分的一个重要依据。

3. 关注数据流

业务流程可能会以一个人、或一个主体为中心进行流转。而数据流是隐藏在表象之下的另一个流程,他是以数据为中心进行流转的。

一般来说,C端产品的数据流,基本只需要考虑前后台的数据流转情况即可。但是B端就会复杂一些,B端saas产品数据往往贯穿C端功能,还会出现跨平台、跨模块的数据流传。

数据流的作用,能帮助你更清晰的划分模块。

四、如何设计产品结构?

1. 产品结构设计的范围

产品结构设计包含多层维度的设计,主要有如下5层维度:

  1. 系统层面的结构——如何分平台/系统;
  2. 版本层面的结构——如何分版本/权限;
  3. 模块层面的结构——如何分模块/二、三、四、五级模块;
  4. 页面层面的结构——如何分页面/页面信息;
  5. 产品内在逻辑结构——如何用逻辑串联。

产品结构的在用户端的展现就是信息结构。这点相信大家都懂,无非是页面层级、页面内部信息层级的划分、信息内容的分类和展示。

其次就是产品内在的逻辑结构:

  • 比如某个配置项应该放在功能模块内还是基础模块内?
  • 比如在连锁系统中,会员是放在连锁维度还是单店维度?
  • 比如直接在营销活动中创建电子券,还是先在电子券模块中创建,然后营销活动进行引用?

这些其实都属于产品功能层面的架构。

2. 产品内在逻辑架构设计的7个核心原则及10个案例

  1. 易用性——从用户使用体验层面考虑;
  2. 可扩展性——迭代、修改的成本最小化;
  3. 技术实现性价比——技术实现成本是否过高不匹配功能价值,按性价比高的去设计;
  4. 普适性——每个单元模块是否可以被其他单元无限重用;
  5. 熟悉业务——违反业务习惯的逻辑设计不能出现;
  6. 掌握产品发展方向——预见产品在中短期内的发展方向,提前考虑进去;
  7. 从简单到复杂——任何一个产品都是从最小MVP开始的,千万不要在开始就架构一套复杂的系统。

关于一些结构设计上,我给大家列一些比较高频出现,比较常见的B端产品(不同纬度的产品架构思路)小例子:

(1)比如我们有一套面向商家的门店经营管理系统,这时需要一个有一个卡券平台,跟门店管理系统中的业务有着密切的关系,这个时候你该定义这是一套系统还是两套系统?他们的关系是什么?边界在哪里?

(2)比如我们做了一套诊所管理系统,后续要垂直化专科式发展,那么到底是通过拆分版本,完全一个科室一个独立的版本?还是做在一套系统里,然后通过权限划分 更合理呢?这其实就是产品架构的一部分

(3)比如对于电商类的saas,很多是非协作型的,也就是说模块之间并没有严格的强联系,相对比较独立,独立作为一个B端业务闭环,可单独使用。但是像诊所saas,则是协作型的,即业务流程涉及到多模块多角色,每个角色都需要在流程中承担一部分工作职能。非协作型和协作型的系统设计的思路也是不同的

(4)比如我们在设计电子券的时候,我们是通过一个步骤完成创建+投放,还是通过创建一个步骤+投放一个步骤完成流程?背后的考虑因素是什么?

(5)对于一些业务流程的设置项,是放在后台该业务模块维度,还是基础设置模块的维度?

(6)比如原先要设计商品管理模块,考虑的主要是单店模式,跨店的商品管理是隔离的,但是当跨店客户提出想要统一管理商品,并可以支持总分店和分店之间的商品调拨的时候,单店商品管理的设计方案就无法支撑这样的业务模式,需要做大规模的底层改动

(7)确定维度,比如哪些指标是单店维度,哪些是机构维度,比如预约是放在后台“诊所管理”里面,还是单独放在后台“预约管理”中?放在哪个维度又是基于哪些原因考虑的?

(8)业务的不满足性,比如我们在做一款电子券的时候,考虑了线上场景,但是还要考虑线下场景,这就需要电子券模块下需要投放到线上(多个渠道)、线下(二维码、短信等),那么渠道后续可能会进行变更,那么假如我们把创建+投放一步完成,那么未来我们要改动渠道,就会影响整个卡券流程,如果我们能分2步,那么只需要对第二步投放进行修改就行,这样系统的可扩展性就会强很多

(9)比如对于订单模块的架构设计,是否能够支持各种营销活动:满减、卡券、积分抵扣等,具备足够强的业务包容性

(10)重复被使用的模块,如何避免重复造轮子!比如电子券模块,在很多营销活动中都会用到,比如短信消息模块,在很多业务中都会用到,那么这些被高频用到模块就应该抽离出来,而不是每个业务环节中都去做一遍。

3. 产品架构必备能力

当然作为一个产品架构师,要完成这些事情,对于能力的要求也是非常高的,最主要的4点:

  1. 懂业务;
  2. 预见能力,预见未来业务流程、业务模式的变化趋势;
  3. 成熟的B端产品结构化思维;
  4. 懂技术原理,懂技术原理最大的好处就是能大概评估这个设计方案的技术成本,并推动自己选择更合适,投入产出比更低的设计方案。

总结

产品架构其实是一个非常复杂而宏大的话题,这篇将近5000字的文章也只是起了个头。

我想说的是,产品架构不只是给产品搭个框架,他出现在产品设计的方方面面中。

通过这样的架构思维帮助产品最均衡的匹配用户的多样性需求,匹配公司的大研发资源,匹配合适的时机把产品做到合适的程度等等。

这是一个系统性的工程,好的架构能够支撑业务发展多年而不重构,更能让用户啧啧称赞。

我想这就是产品架构的魅力吧!

作者:司马特小队,丁香园高级产品经理。微信公众号:司马特小分队

本文由 @司马特小队 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

  • 评论列表

发表评论: