admin 管理员组

文章数量: 887019


2024年2月6日发(作者:c语言指针赋值方式)

规划TOB产品架构图,用这6步搞定,错过就要再等(1)

导语:软件工程是一项复杂的项目投资工程,架构设计的好坏往往决定着项目的成功或失败。ToB的产品人在设计一款产品时,学会充分利用产品架构是一项必备构架的能力。这里我们来聊聊ToB的产品架构如何去搭设,能让你的产品菌丝体更长,更稳定。

“产品架构犹如屋宇地基、人体骨骼、车辆核心部件。”

“架构”一词最早来源于建筑,其核心是通过一系列构件的组合来承载上层传递的压力。经过漫长的演变,架构设计的已经深入多个行业和场景,有望成为了必不可少的活动。

1. 架构的含义

架构一词,从韦伯词典中定义为“一种意识过程结果的形态或框架;一种统一或有条理的形式或结构”。其余部分这里的关键部分是具有特殊结构的,有条理的,这个定义很抽象,很不好理解,说人话核心我们要把握住“框架”、“结构”、“有条理”这几个网页内容就好了。

我们来看一个例子:

车的骨架由车身、车架、发动机、制动设备、轮胎和机械设备等构成,这些组件构成了一款完整的车,提供驾驶服务,这些组件的好坏着车的使用寿命和服务体验;组件数量的多少决定着车所能提供服务的服务边界在哪,不是越多功能这样一来好,也绝非只有一个车身就行,组件的最低数量是保证一款车能够正常使用。

同理,软件产品是不是也需要具备同样的逻辑,保证一款必须软件产品能够正常使用,满足用户诉求,解决用户的问题。

我们有一个不容忽视的结构性问题,软件领域发展到从那时起,延伸出了企业软件系统、业务架构、应用架构、数据架构、产品架构、技术架构等一堆的词语。是不是有点晕了,这些架构都是用来干什么,它们二者之间有什么区别?不搞清楚它们之间的关系,产品架构从何谈起。

2. 架构之间的区别和联系

这么多名词,它们是如何定义的?相互之间如何区分和联系?这里做一些简单的说明,详细的解释和案例还望各位童鞋翻阅架构相关书籍。我们来看下面这张图。

1)业务架构

架构是指企业通过分析自身所处的外界环境,自身面临的美好未来和挑战,同时剖析自身的内部结构特点和资源情况,明确自身优劣势,从而目标选择和制定企业推进目标,制定具体的实施方案和计划。

核心要素主要包括主要包括业务着力点、资源能力、业务流程和组织机构结构;放在企业层面是企业金融业务层面目标,放在部门层面是部门业务目标。

内核对业务架构我们要思考一下的问题:

举例来说:企业采购业务的业务架构

2)数据架构

数据架构是基于数据管理领域知识数据资料经验的总结,提炼操作过程指导未来数据管理的过程。

主要主要包括数据治理和计有数据管理,数据治理包括数据管理政策,原则,规范和标准等;数据管理包括数据总体视图和数据结构,数据库设计等。

下图是一张整体视图:

3)技术架构

技术架构是将数据架构和应用架构落实下去,通过技术的手段构建出来。主要包括架构规划和技术选型等事项。架构规划包括网络、平台、语言、中台、微提供服务等概念规划;技术选型主要是具体到某个产品时技术方案的选型,包括开源框架、语言、架构风格、数据库、中间件等。

我们来一个单个产品的技术架构方案,如下图:

4)应用架构

应用架构是描述一个企业各个丁公藤相互之间独立的应用系统的部署以及核心业务流程之间的婚姻关系,目的是建立业务架构与数据架构和交集其他架构之间的关联;它能连接业务架构的程序,功能,人员,也能够连接数据架构中的数据管理和使用,还能提出对关键技术技术架构的要求。主要分为表现层、应用层和数据层来直言

产品架构是产品的整体,是对某抽象概念一块具体业务的进行抽象,截叶可视化的方式呈现出来,它划分了功能模块、数据流向,包括现有的,以及未来规划的。其目的不仅是为了架构设计的简洁性,更是为了整条业务的完整性,把离散的业务过程场景化。

产品设计架构和应用架构的设计产品关系?

产品架构是应用架构的一部分,当架构设计应用架构只有一个产品时,也就是产品架构。多个产品组合一起形成了企业应用架构全景图。

这里主要阐述如何规划产品架构图。

画产品架构图目的是为了将业务层次结构拆解并梳理出产品思路,整体上推进把握产品的发展方向,把控产品的核心功能,重新考虑决定了产品功能的实现路径和大体规划。当然,架构本身也是需要随业务的发展的演进,具备一定的扩展性。这里阐述几条做架构的好处:

1)梳理产品方向和规划路径

系列产品这种图本身就体现了整个产品的结构,包括已实现的和未实现的,为产品的插值指明方向,判断产品之间的局限关系和关系。

2)为团队提供明确的目标

团队成员,包括,研发、测试、运营、市场和销售,能够根据这张图了解产品的规划,相应的团队可采取对应的策略。比如,研发可思考技术设计方案,市场和销售可制定品类的推销策略等。

3)建立业务全景图

产品规划是从业务架构中抽象构架出来的,反过来,可以帮助业务部门完善投资业务制度、和管理标准化,实现整个链条上才的闭环。

构建产品架构图是需要产品人具备较高的综合能力,包括不限于:

这里提供更多一个方法:6步构建ToB产品架构图

1. 梳理用户故事,全面认识业务需求,形成业务闭环

不管是从0到1构建一款产品,还是1到N迭代一款产品,当新的管理业务场景进来时,我们资金需求先要进行用户分析和需求实地调查,全面的认识需求,从组织级,用户级,开发级三个层面考虑不同类型的功能需求、质量需求和约束条件。比如,我们看一个企业采购签订需求到签订合同签订的场景。

这里用户提交需求,中间经过招投标,最后才签订合同,涉及多个角色,多个业务场景,我们在分析的时候,就要全面的调研整个业务环节的用户,并记录其相应的业务诉求和现状。

2. 识别业务链条的业务领域以及问题域

用户的需求陈述可能是模糊,可能是清晰的,我们在获取用户需求后,先要判断业务领域,再识别该领域内的问题。

1)业务领域,是一个组织所做的案子以及其中所包含的一切。狭义上,如采购领域、生产领域、销售领域等。这里领域是采购领域,子顶上领域是采购边上的细分领域。

我们将上头的例子进行领域划分后,分为需求领域、招投标领域和融资协议领域,如下:

2)问题域,是指产品能够解决的可所有问题的集合。架构设计是没有时间对所有人所有需求进行深入分析,不想也没必要对所有的需求进行深入分析,只要抓住关键需求即可。

关键需求下定决心架构,将核心需求当前要逐步解决的,以及未来要解决的问题归集起来,作为问题域。

比如,上面的例子不必包括不限于下表问题:

建立问题值域是需要的人具备一定产品业务知识和结构化思维,可阅读相关投资业务书籍,比如采购,财务书籍等,提问投资过程可基于实际业务操作流来积累每个环节可能会出现的问题。

3. 画出业务闭环流程图,并拆分出初步的解决方案域

通过前面的调研和领域划分,基本上能够确定业务场景集中式的或将来的业务普诺省流程图。管理业务流程图的画法,可参考相应的书籍或文章会单独进行分享如何画好业务流程图。

基于业务流程图和需求,我们需要抽象和归纳同类型事物,用更外国专家来表达;比如,微软和梨子都是水果。

上述推算出案例我们基本可以得出整个流程上的初步解决方案功能。

4. 明确产品定位,划分好范围

回到定位,不要走错了路。可参考:《战略(4):TOB产品定位,千万不要忽略这两层!》。

梳理完需求和业务流程以及初步的解决方案域,我们能够评估那些是当前产品或待规划产品的,不是当前产品定位内的需求,要果断的让另一个产品承接;比如,审批流的需求,当前产品内只能是部门内审批,涉及到外部门负责人的审批,审核审批流的功能必须放在企业OA系统完成。

5. 架构分层

清晰的直观产品架构图至少包含这三层:

在进行产品架构分层时,我们可以采用的方法分别对展示层、业务逻辑层和数据层图表进行信息分类和排版。在信息分类时可以使用金字塔将每层核心信息尽量完全穷尽,相互独立。

分层以前需注意以下几项:

1)表现层

主要就是用户的接触渠道,用户通过这个登录使用产品功能,获取相应的服务,一般可分为PC端和APP端。

2)应用层

这个层将功能模块具体的功能进行分类组合成模块单元,先将有大的模块填充,再将大模块下的功能点填充。

模块和功能的颗粒度如何界定?

颗粒度大小没有明确标准,只要能表述一项工作任务即可。

另外,一些主数据,用户,组织架构,消息组件,日志管理、接口服务等服务能力可单独放在支撑层或者作为应用层的一些基础数据也是可以。

3)数据层

这里主要是描述产品主要的存储数据库和存储方式。比如,涉及储存到结构化数据一般存储在Mysql,sqlserver等关系型数据库;涉及到文件,可能将一般存储在对象存储。

图中的1、2、3对应的是表现层,应用层和数据层的功能和逻辑逻辑系统划分,大家可以参考;这里就没有把技术架构相关的内容放上来了,特别是涉及到中台、微服务划分,均没有体现,比如,IAAS层,PASS层,SaaS层等。

5. 信息流转和产品规划

产品架构图除了表达核心功用之外,还需需将信息穗序的路径标识清楚,比如图中的标识4;

另外,我们需将产品功能的实现情况通过不同颜色标识出来,比如,绿色代表功能也已上线,黄色代表功能需优化,灰色代表功能是发展规划中。

如果你的产品是0到1,那么也可以标识出1.0版本做那些功能,2.0版本做那些功能,3.0版本做那些功能,有一个相对清晰的展示,这才是最终的产品架构图。

如下图:

最后,构建产品架构图是产品经理一项必备的能力,ToB的产品结构整体而言较为复杂,除了考虑机能品牌本身功能场景外,还需考虑集成系统之间的数据交互和接口交互。

这里给大家分享了架构设计是什么,为什么要做产品架构,以及6步法构建一款B端产品架构图,接下来我们就是要找机会去打听练习,去感悟。

知道的是知识,做到的是能力,能够构建自己的体系才是大咖!

你认为好的产品架构图是什么样的?


本文标签: 架构 产品 业务 功能 需求