做网站和软件的团队,织梦系统怎么做网站,北京seo收费,给别人做网站别人经营违法产品架构是基于业务架构的#xff0c;那么做产品架构前#xff0c;需要对业务架构有哪些清晰的了解呢#xff1f; 当我们去搜索“架构”#xff0c;可以得到很多的架构图片#xff0c;比如组织架构、业务架构、数据架构、技术架构、安全架构、产品架构、部署架构等。
什么… 产品架构是基于业务架构的那么做产品架构前需要对业务架构有哪些清晰的了解呢 当我们去搜索“架构”可以得到很多的架构图片比如组织架构、业务架构、数据架构、技术架构、安全架构、产品架构、部署架构等。
什么是架构通常大家说架构一般指软件架构架构是指软件的基础结构创造这些基础结构的准则以及对这些结构的描述。在这个定义基础上我们可以简单理解为架构往往是对事物主体的结构性描述。
产品架构是对产品的一种结构性描述。一般可以包括前端系统、业务管理、运营管理、基础支撑等子产品或子系统并描述各个子产品或子系统之间的关联关系。
在公司整体战略之下需要基于公司战略等多种因素设计组织架构组织架构影响业务架构业务架构影响产品架构产品架构影响技术架构。
从这个链条可以看出产品架构基于业务架构。做产品架构前需要对业务架构有清晰的了解。
一、业务架构对产品设计的5个影响
业务架构是基于组织架构设计的业务架构是把企业的业务战略转化为日常运作的渠道业务战略决定业务架构它包括业务的运营模式、流程体系、组织体系、资源分布等内容。
业务架构是一个比较专业的研究课题技术人员一般对业务架构的关注度相对较低更重视产品架构、技术架构。这里我们简单示例什么是业务架构这些架构事实上影响我们的产品架构设计如下图5-1就是其中一个业务架构设计的框架图。 业务架构对企业的收入模式、支出成本、客户群体、客户关系、需要的资源、关键活动以及合作伙伴等进行设计说明。
业务架构对产品架构的影响主要体现在以下几个方面
1. 系统参与角色
业务架构一般会明确用户范围营销端的参与人员比如渠道商或代理商大客户销售团队等运营端的参与人员如售后、客户成功等团队合作伙伴的参与如第三方合作平台等。每类角色按需设计对应的使用终端。
2. 系统运营流程
业务架构对运营流程有较明确的定义如开户、续费、注销、变更、售前售后工单处理、库存入库出库处理、合同流程、发票流程等。这些构成SaaS平台的运营流程是产品实现商业价值的重要手段产品环节一般需要有相应的处理。
3. 核心价值
业务架构需要明确SaaS服务对客户带来的价值这个价值往往需要通过产品端来呈现业务架构的价值描述很大程度上就是我们产品建设的侧重点。
4. 周边系统
业务架构中的合作伙伴、资源一定程度上体现出需要与产品交互的其他系统这些“其他系统”可能是产品需要的一些基础能力如文字识别、计算能力等、数据权限数据、业务数据、流程管理流程、运营流程等 而这些能力需要合伙伙伴或者公司的现有资源中提供。这些周边系统会以各种各样的作用支撑着产品的运转。
5. 计费模式
业务架构一般会说明收入和成本模型。收入的处理过程影响运营产品的设计如公司在线下收款可以产品只需要控制用户账号的可用状态或有效期如果是线上收款就需要设计一套开通、续费的线上支付流程。有些SaaS产品还会涉及到收入和成本费用的摊销以配合财务工作的处理也可能需要在产品中完成此类计算。
假如所在公司没有清晰的业务架构或者部分环节缺失怎么办如果可以引导我们尽量引导业务部门完善相关的环节但有些客观情况是我们无法改变的我们可以尝试按照现有架构收集梳理信息做好整体的结构设计确保具备可扩充能力能够满足后续需求再根据业务各环节成熟度设计产品架构分阶段去实现。
二、产品架构
SaaS产品架构的设计可以考虑模块化、渐进式设计。
1. 模块化设计
所谓模块化是指降低业务间的耦合。低耦合、高内聚是技术架构的重要设计原则在产品端也非常值得借鉴。
模块式化设计对于系统建模、技术实现、升级迭代、业务推广都有很多帮助。模块化设计也是对最小化场景MVP的一种有效支撑。
SaaS产品随着公司的发展业务范围、功能都会越来越大而客户可能仅需要部分能力如果功能间耦合太多对客户的功能选择会增加限制销售政策制定起也会受到掣肘无法灵活组合产品进行销售对业务推广产生一定影响。
如何做好模块化设计
模块化设计针对有独立性、可复用的业务或功能进行抽取包装功能集合构成产品进行推广使用方便客户根据需要进行产品组合模块化设计在传统软件中也非常重要。
1归类与抽象
需要对相似的功能或者场景进行归类然后抽象出来进行设计。在软件设计领域越是底层的东西越容易复用越是偏向应用端的东西越难以复用。比如构成一套软件服务可以有服务器硬件、应用服务中间件比如数据库等、各种微服务、业务流程、外部入口等这套软件架构中服务器硬件是处于架构底层比较基础且通用性很强应用入口处于架构高层级形式相对灵活复用性较低。在产品端也是同理基础信息如人员、机构等属于基础信息同一组织在不同系统中的结构大体一样复用性强其次是各类业务流程再其次是业务表单。
我们要做的产品模块化设计是针对不同用户的需求将完成某项业务的场景进行分析、归类、抽象抽取共性部分做成可实现多种组合的产品形态。
2数据接口
系统一般由逻辑算法和信息两部分构成信息又分为内容和数据逻辑是构建软件功能的骨架内容和数据是血肉其中以数据尤为重要。
假如要实现软件模块化且模块之间相互独立必须要先抛弃逻辑实现方法因为有逻辑就代表这两个模块谁也离不开谁就不能称之为独立。
如果这两个模块必须要关联在一起但又不允许它们在逻辑上互相干涉那么最好的办法就是为它们内部包含的数据进行抽象化形成标准化接口以数据调用的形式实现两个模块间的互相协作。
模块化的一个特征是复用在产品设计上复用意味着需要多种场景的结合如果只有一个场景就不是复用在多个场景都需要使用的情况下会有数据交互的需要模块化设计就是要把共性的东西抽取出来后提供标准接口进行数据交互这个共性的东西可以是字段也可以是规则。
大家通常理解的SDK也是模块化设计的一种体现。模块化的产品可以是一个界面、也可以是一个功能还可以是一个子系统。
2. 渐进式设计
SaaS产品是逐步迭代的产品设计也不是一蹴而就的需要有一个不断前进的过程渐进式设计非常契合SaaS产品。比如我们公司的产品有企业客户、集团客户、代理商、平台运营人员、售后人员等参与在设计系统的过程中并不是一上来就把所有的工作全部做完 这样周期太长也不利于快速验证产品和市场的匹配所以产品架构自然而然也变成了一种渐进的设计过程。
渐进式设计需要尽量考虑未来产品的全局以满足后续产品扩展需要。
以我曾经做过的一个产品举例产品的用户可以分为三大类关系如下图 在产品架构的搭建过程中我们在清楚有这些基础结构以后按照优先级顺序逐步发展产品。如图 首先搭建了企业版产品和简单的运营管理系统让用户能够使用起来。后来随着代理商力量的不断计入需要为代理商设计一套管理系统代理商系统需要依赖于公司运营管理系统公司运营早期就已经有了代理商加入运营管理平台只有最简单的代理商管理功能能够标记客户所属代理商但并没有去开发一套代理商管理系统只是预留了扩展能力。
随着平台的发展用户群体不断扩大集团客户也在不断增加公司又基于企业版产品开发了集团版产品满足集团企业客户的需要。
整个代理商管理系统和公司运营管理系统也跟随迭代从最初的企业注册审核到用户工单管理、结算续费管理、再到增加集团版的开通管理流程及结算流程历时用了几年时间。产品整体架构经历了多个版本的迭代才逐步变成现在的体系并且还在持续完善中。
产品架构的渐进式设计和最小化可用产品MVP并不是一回事产品架构渐进式设计是为了产品稳步推进并可扩展先集中精力解决当前的重要需求和问题所积累的产品成果会成为将来产品发展的基础而不是MVP中表示的每一个过程都可能要重构。
MVP有一个非常生动的例子用户需求是一辆车那么车的MVP及产品演进过程应该如下图5-5的第二部分所示 产品架构的渐进式设计和产品的MVP有什么关系其实是两个维度的事情产品架构渐进式设计是对现在业务的快速响应以及对未来业务扩张的支撑。
MVP是在产品迭代过程中在不同的阶段可能需要进行重构上图的例子在一些产品论坛上都有阐述这对MVP的解释是很准确的最小化可行产品需要做到每次迭代都是完整可用的可用场景闭环是MVP的核心指标这是产品从0到1的一种有效验证方式但我认为这种重构并不一定是必须的.
很多软件产品在迭代的过程中都是在原有基础上的扩展实际上产品架构具备弹性和扩展性这是一名优秀产品经理需要具备的能力毕竟任何历史投入都是有成本的优秀的设计应该是在原有基础上的扩展而不是推倒重来。
B端产品在发展过程中也比较注重产品和服务的结合这个服务并不是指产品即服务而是在早期产品不够完善的情况下部分环节通过线下服务来补充这也是SaaS产品发展的一种形式。
产品架构大体能够说清楚了系统间的关系但对于具体的产品流程产品架构图是无法表达清楚的还需要辅助系统流程图进行说明。
