大型 SaaS 平台产品架构设计思绪
发布时间：2022-04-25 08:59:44 所属栏目：云计算 来源：互联网
导读：当我们去搜索架构，可以得到很多的架构图片，比如组织架构、业务架构、数据架构、技术架构、安全架构、产品架构、部署架构等。 什么是架构，通常大家说架构一般指软件架构，架构是指软件的基础结构，创造这些基础结构的准则，以及对这些结构的描述。在这个定
|
当我们去搜索“架构”，可以得到很多的架构图片，比如组织架构、业务架构、数据架构、技术架构、安全架构、产品架构、部署架构等。 什么是架构，通常大家说架构一般指软件架构，架构是指软件的基础结构，创造这些基础结构的准则，以及对这些结构的描述。在这个定义基础上，我们可以简单理解为架构往往是对事物主体的结构性描述。 在公司整体战略之下，需要基于公司战略等多种因素设计组织架构，组织架构影响业务架构，业务架构影响产品架构，产品架构影响技术架构。 从这个链条可以看出产品架构基于业务架构。做产品架构前，需要对业务架构有清晰的了解。 一、业务架构对产品设计的5个影响 业务架构是基于组织架构设计的，业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织体系、资源分布等内容。 业务架构是一个比较专业的研究课题，技术人员一般对业务架构的关注度相对较低，更重视产品架构、技术架构。这里我们简单示例什么是业务架构，这些架构事实上影响我们的产品架构设计，如下图5-1就是其中一个业务架构设计的框架图。 业务架构对产品架构的影响，主要体现在以下几个方面： 1. 系统参与角色 业务架构一般会明确用户范围;营销端的参与人员，比如渠道商或代理商，大客户销售团队等;运营端的参与人员，如售后、客户成功等团队;合作伙伴的参与，如第三方合作平台等。每类角色按需设计对应的使用终端。 2. 核心价值 业务架构需要明确SaaS服务对客户带来的价值，这个价值往往需要通过产品端来呈现，业务架构的价值描述，很大程度上就是我们产品建设的侧重点。 3. 计费模式 业务架构一般会说明收入和成本模型。收入的处理过程影响运营产品的设计，如公司在线下收款，可以产品只需要控制用户账号的可用状态或有效期，如果是线上收款，就需要设计一套开通、续费的线上支付流程。有些SaaS产品还会涉及到收入和成本费用的摊销，以配合财务工作的处理，也可能需要在产品中完成此类计算。 假如所在公司没有清晰的业务架构，或者部分环节缺失怎么办?如果可以引导，我们尽量引导业务部门完善相关的环节，但有些客观情况是我们无法改变的，我们可以尝试按照现有架构，收集梳理信息，做好整体的结构设计，确保具备可扩充能力，能够满足后续需求，再根据业务各环节成熟度设计产品架构，分阶段去实现。 二、产品架构 SaaS产品架构的设计，可以考虑模块化、渐进式设计。 2.1 模块化设计 所谓模块化是指降低业务间的耦合。低耦合、高内聚是技术架构的重要设计原则，在产品端也非常值得借鉴。 模块式化设计对于系统建模、技术实现、升级迭代、业务推广都有很多帮助。模块化设计也是对最小化场景(MVP)的一种有效支撑。 SaaS产品随着公司的发展，业务范围、功能都会越来越大，而客户可能仅需要部分能力，如果功能间耦合太多，对客户的功能选择会增加限制;销售政策制定起也会受到掣肘，无法灵活组合产品进行销售，对业务推广产生一定影响。 如何做好模块化设计? 模块化设计针对有独立性、可复用的业务或功能进行抽取，包装功能集合构成产品进行推广使用，方便客户根据需要进行产品组合，模块化设计在传统软件中也非常重要。 2.2 渐进式设计 SaaS产品是逐步迭代的，产品设计也不是一蹴而就的，需要有一个不断前进的过程，渐进式设计非常契合SaaS产品。比如我们公司的产品，有企业客户、集团客户、代理商、平台运营人员、售后人员等参与，在设计系统的过程中，并不是一上来就把所有的工作全部做完， 这样周期太长，也不利于快速验证产品和市场的匹配，所以产品架构自然而然也变成了一种渐进的设计过程。 渐进式设计需要尽量考虑未来产品的全局，以满足后续产品扩展需要。 以我曾经做过的一个产品举例，产品的用户可以分为三大类，关系如下图： 在产品架构的搭建过程中，我们在清楚有这些基础结构以后，按照优先级顺序，逐步发展产品。如图： 首先搭建了企业版产品和简单的运营管理系统，让用户能够使用起来。后来随着代理商力量的不断计入，需要为代理商设计一套管理系统，代理商系统需要依赖于公司运营管理系统(公司运营早期就已经有了代理商加入，运营管理平台只有最简单的代理商管理功能，能够标记客户所属代理商，但并没有去开发一套代理商管理系统，只是预留了扩展能力)。 随着平台的发展，用户群体不断扩大，集团客户也在不断增加，公司又基于企业版产品开发了集团版产品，满足集团企业客户的需要。 整个代理商管理系统和公司运营管理系统也跟随迭代，从最初的企业注册审核，到用户工单管理、结算续费管理、再到增加集团版的开通管理流程及结算流程，历时用了几年时间。产品整体架构经历了多个版本的迭代，才逐步变成现在的体系，并且还在持续完善中。 产品架构的渐进式设计和最小化可用产品(MVP)并不是一回事，产品架构渐进式设计是为了产品稳步推进并可扩展，先集中精力解决当前的重要需求和问题，所积累的产品成果，会成为将来产品发展的基础，而不是MVP中表示的每一个过程都可能要重构。 MVP有一个非常生动的例子，用户需求是一辆车，那么车的MVP及产品演进过程应该如下图5-5的第二部分所示： MVP的演进 产品架构的渐进式设计和产品的MVP有什么关系，其实是两个维度的事情，产品架构渐进式设计是对现在业务的快速响应，以及对未来业务扩张的支撑。 MVP是在产品迭代过程中，在不同的阶段，可能需要进行重构，上图的例子，在一些产品论坛上都有阐述，这对MVP的解释是很准确的，最小化可行产品需要做到每次迭代都是完整可用的，可用场景闭环是MVP的核心指标，这是产品从0到1的一种有效验证方式，但我认为这种重构并不一定是必须的. 很多软件产品在迭代的过程中，都是在原有基础上的扩展，实际上产品架构具备弹性和扩展性，这是一名优秀产品经理需要具备的能力，毕竟任何历史投入都是有成本的，优秀的设计应该是在原有基础上的扩展，而不是推倒重来。 B端产品在发展过程中，也比较注重产品和服务的结合，这个服务并不是指产品即服务，而是在早期产品不够完善的情况下，部分环节通过线下服务来补充，这也是SaaS产品发展的一种形式。 产品架构大体能够说清楚了系统间的关系，但对于具体的产品流程，产品架构图是无法表达清楚的，还需要辅助系统流程图进行说明。 （编辑：开发网_开封站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330459号