『产品架构图』的画法拆解!

唧唧歪歪PM

共 3830字,需浏览 8分钟

 ·

2022-08-16 13:43

结构化思维,是产品架构设计的底层驱动力。

上篇文章讲了一个观点:产品同学职场发展的关键在于战略性的制造不平衡,文章中分享了一个关于“架构设计”的案例,不少产品同学看后在微信群内反馈,说很想系统学习下架构设计。

坦白说,产品架构设计需要很多的经验积累,尤其依赖对业务场景的深度理解、体系化的产品思维、较强的抽象能力等等,偏向于水到渠成,很难读完一篇文章就能学会,但掌握了设计方法,再通过反复练习就能逐渐掌握。

因此,镜同学想通过本文系统性的分享下产品架构设计的入门方法,我会通过一个产品案例帮你更好的理解产品架构设计。

当然,能力有限,本文并非适合每个产品同学,欢迎批评指正,主要是想帮助入行不久的产品同学建立对架构设计的一些认知,重点是分享一些方法论。

等你看完,你一定会有这个认知

产品架构设计对外集中体现的是你的专家效应,尤其是对你的产品视野和格局都有很大的提升,而这对你的职场发展也极为重要,绝不是撑面子的花架子。

你知道的,在“产品大峡谷”,镜同学一贯愿意并擅长做这样的辅助。

↑- 敏捷版的产品架构图示例

先介绍下该产品案例的背景:

我们团队目前主要在做HSE安全信息化平台,该平台的产品矩阵主要解决企业安全生产管理的需求,诸如“双重预防机制”等等,目前平台积累了近十万企业用户。

同时,为了提高集团各事业部的业务推进效率,我们同时也在做CRM系统,上周我们设计了一个“客户档案”的产品需求。

这个需求属于客户关系管理系统中的一个一级功能,主要是把CRM系统收集到的客户信息,尤其是安全信息平台所拥有的该企业的安全信息进行集中展示,用户可以免费或付费查询,多少有点类似于“企查查”。

这个需求是让一个产品经理负责设计的,评审时我发现他对产品设计的深度还远不够,只是被动的罗列企业的信息,缺少深入的产品设计思考。

归根结底,主要在于没有产品架构的意识,因此,借这个案例,分享一些经验,希望能给你带来一些启发。

1、回归业务场景,找准产品定位。
不仅仅是产品架构设计,任何产品设计都应该围绕业务场景所展开,让需求深度契合业务场景是最基础的产品能力
很多产品初学者,最容易犯的错误往往就是忽略了业务场景,反而在乎某个功能的界面交互、用户体验等,这是本末倒置。
产品定位清楚后,才会有具象化的北极星目标,才可被拆解量化出详细的需求任务
要想搞清楚产品定位,可以从业务场景和功能定义来着手。
比如,我们这个“客户档案”这个业务场景:
首先,安全行业的上下游企业在开展业务时,很多时候客户都需要掌握某个企业的基本信息,尤其是关于安全管理的相关信息,借以评估该企业的安全管理水平如何等等。
其次,我们刚好沉淀的有客户数据和安全数据,完成这个需求之后,用户就可以通过该“客户档案”功能查看,可以查询某个企业的基本信息,尤其是安全信息。
比如,保险机构在推安责险前就需要了解企业的安全管理水平,安全管理水平高保费就可以低一些,反之就高一些,他就可以通过“客户档案”功能查询。
因此,客户档案的功能定义便是如此:为安全行业的上下游企业,提供以安全数据为核心的一站式查询服务,助力其业务高效发展
2、提炼本质需求,拆解核心要点。
通过业务场景和功能定义基本确定了产品的定位,接下来最重要的其实就需要提炼本质需求,拆解出来核心的需求要点。
这个阶段需要完成先从具象到抽象,再从抽象到具象的两轮转变
还以“客户档案”为例:
①从具象到抽象
根据业务场景和功能定义,我们对客户档案已经有了初步具象化的认知,那么下一步就是要将需求抽象提炼,客户档案本质上是什么呢?
重新审视需求:基于现有的客户系统和安全平台各个系统的基础数据,目的是为了向用户提供企业的基本信息查询服务,进而设计付费查询等增值服务。
显然,该需求是一个数据应用服务
②从抽象到具象
明确了这是一个数据应用服务,接下来就需要结合业务场景,向下拆解,再次具象化产品需求,拆解出高层级的核心功能点。
比如,数据来源设计、数据查询设计、增值服务设计(套餐配置、线上支付、订单管理等等),这些都属于核心的功能要点。
需要说明的是,在这个阶段只需梳理出核心的功能要点,不需要太深入到细节里面,只需要高层级的核心功能就行,这样更利于全局把控或敏捷调整设计方向。

3、对照需求方法论,场景化详细需求。
首先,数据应用类需求有哪些需求方法论呢?
严格来说,这依赖于你的产品知识积累,当然你也可以边学边应用,比如,我们就可以参考“数字化转型”,一般来说,数据应用服务都需要经历数据收集、数据治理、数据分析、数据融合几个阶段。
事实上,数据应用类的产品设计绝非一朝一夕,它在客观上需要长期的数据沉淀,可能是数年甚至数十年,并且经过数月的打磨和驯化,再通过数小时的数据准备,最后实现秒级的数据结果。
对用户而言,他们看到的结果往往都是可视化的统计数据,这些易读性和便捷的交互设计,都是为了能帮用户最大限度地提高决策效率,这背后其实是一系列的数据处理逻辑。
上周我去北京参加了IBM的产品交流会,中间也有提到数字化转型,我当时也在峡谷微信群里分享了一些现场图片,其中就有关于数据应用的方法模型。
其次,找到了方法论,就要场景化详细需求,我们还以“客户档案”这个需求为例:
第一,数据收集:
数据收集也就意味着要确定数据来源,客户档案我们初步设定有三个数据来源:①客户系统的企业数据;②对接企查查的基础数据;③我们其他安全系统的企业安全数据。
在这里,镜同学还特别想说一句,产品经理要牢记“数据来源”这四个字,在产品设计时反复询问自己,这对业务逻辑的充分理解很有帮助。
第二,数据治理:
数据治理意味着设置适用于收集、存储、处理和处置数据的内部标准,即数据策略,它规定了谁可以访问哪些数据以及哪些数据应受治理。
数据治理其实很重要,比如,有些数据是没有价值或者价值很低的,这些数据就不必要展示;有些数据涉及隐私或安全,不能够展示;
这就对我们提出了要求,我们一定要对数据进行筛选和过滤,剔除无意义的数据,保留最有价值的高效数据
事实上,我们这个产品同学在最初设计时,直接展示了企业的生产数据,诸如“风险四色图”、“隐患排查”的现场数据,这些数据均没有经过治理,都是最初的原材料堆砌。
所以我说,他的第一次产品设计丰富度很高,但设计的深度很浅,更多是被动的罗列数据,并没有对数据进行充分治理,产品自主思考与设计不足。
第三,数据分析

在数据治理之后要进行数据分析,这些分析要立足于当下的业务场景,说白了,治理后的生产数据是原料,是最初的生产资料,我们要想办法加工成半成品。

那么,这个案例中“客户档案”的企业安全数据,我们应该如何有效分析呢?

我们首先要进行分维度的权重设计,其次要进行统计分析,诸如,哪些数据是对业务需求意义大,应该分配什么样的权重;这些一定不是单纯的罗列原始数据,因为你展示的是依托数据的客户档案,应该是报告性的、统计性的,一定要让用户最直观的看到你的数据分析结果。

比如,通过数据分析,产品应该可以告诉用户某个企业的安全评分是90分,统计数据大概有哪些,等等,均是直观表达,而不应该是众多的列表、详情,等待用户自己再去计算分析。

第四,数据融合

在我看来,数据融合应该围绕着产品价值来实现
比如,增值服务应该包括付费查询、报告下载、导出文件、在线支付等等,这些都是具体的功能点;
再比如,针对体验性或口碑的提升,通过“客户档案”来提高数据变现能力,进一步提升公司的品牌影响力。
当然,镜同学这里只是提供一个产品思路供你参考,所以也只是一部分细化的需求,像数据查询、付费查看等等需求功能,都可以对照产品方法论,依托业务场景,从底层去构建基础的需求功能点。

4、梳理成思维导图

通过以上的功能梳理,我们对于需求功能点应该拆解的比较清晰了,那么下一步我们应该就是着手画产品架构图了。

不过,我还是建议你先梳理成思维导图,这样结构化更加清晰,也方便查漏补缺,这对于接下来的产品架构设计更能具象化,理解起来也更加高效。

这里思维导图的关键在于结构化的拆解,要通过需求方法论、场景化的需求分类,将该产品设计分解成对应的结构层次中,这些维度是架构图的关键。

比如,客户档案需求设计时,我们就可以把需求方法论“数据收集”、“数据治理”、“数据分析”、“数据融合”作为设计底座,从这些维度方向去进行功能详细设计,细化成哪些功能点,这就自然而然形成了产品架构。

5、产品架构设计

接下来就要画产品架构图了,这里对照“思维导图”即可快速梳理,当然,如果你可以使用VISIO、PPT或者Axure等工具设计。

最后,我觉得产品架构的颗粒度应该大一些,重点在于方向把控和核心功能点的设计,是核心业务逻辑的集中表现,不必过于细化。

架构设计的前提在于高度契合产品定位,设计的核心在于多维度的结构化分层,从不同的维度去拆解原始需求,不断修正,反复训练,熟能生巧。

比如,客户档案的产品定位一定不是做企查查,而是依赖业务系统的差异性数据,提供垂直领域的数据服务,随之带来的数据权重将会在架构设计上充分体现,这也是架构设计的核心理念。

当然,本文只是一个小的产品案例拆解,方法也未必适合每个产品同学,只是希望这些敏捷的设计方法能带给你启发,尤其是能对初学者对产品架构的认知能提供一些浅薄的经验参考。

另外,偷偷告诉你,在公众号“产品大峡谷”内回复“架构设计”,即可无套路获得镜同学使用的架构设计源文件(Axure版哦),这个模板应该能提高你的工作效率。

最后,真的希望对你有产品启发。

浏览 143
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报