what:
产品架构的目的:
梳理产品思路,从整体上把握产品的发展方向,把控产品的功能重点(卖点)。它决定了产品必须要实现的功能,以及什么时间必须完成的功能。即决定了产品的发展路径。
产品架构解决的是业务问题,而非功能问题。即该架构只会框定该产品要解决哪些业务问题,取得哪些成果,以及需要哪些数据支撑;而不解决为了完成业务,所需要的具体每一项功能操作。
产品架构图:
是用来抽象表达一款产品服务或者商业模式的可视化工具。
demo图:
how:
1、基本方法“分层”:
最基本的产品层级结构就是三层,即用户层、功能层和数据层。
产品架构是对业务分层设计的过程。
统一用户体验层:
解决的是用户触达的问题,考虑在何种场景下通过何种方式触达用户,最表层的业务体验,也就是我们常说的“用户体验”,包括界面,布局,配色等直观可见的每一个产品页面。
解耦的业务功能层:
“业务功能”的解耦,本质是解决产品的核心功能的设计问题,包括:如何高效的完成业务功能,如何与用户层进行交互,如何与外部系统进行数据通信等一系列复杂的业务处理。
解藕的根本性原因就是:考虑业务的扩展性,也是考虑整个平台的伸缩性。不要把各个功能模块过于紧密的耦合,导致任何些微的改动,都必须大动干戈。
集中的数据处理层:
这一层处理的问题就是,产品的数据从哪里,沉淀到哪里去。实际上,稍微深入一点的问题就是数据如何高效的存储,如何快速的被调用。
分层栗子:
“张三新买的冰箱出现了故障,他找到当时的回执单申报了一次售后服务,要求在周六上午处理完冰箱的故障”。
用户信息:一个方便的界面协助用户申报服务。例如:怎么能让用户在申报服务的时候把资料问题录入正确,有没有办法在用户打开这个界面就直接解决问题,有没有一个FAQ供用户查阅。
业务信息:后台要处理用户的服务请求(申报的售后服务)。例如:要安排一个擅长处理这个故障的工程师上门服务(业务技能要匹配,不能派一个不懂冰箱的工程师处理这个问题),时间是周六(资源要调配,距离太远不合适,时间冲突不合适等);
数据信息:在处理用户的服务请求时,所需要的一系列动作,以及整个平台的数据和信息是如何进行流转。例如:上次的订单是怎么找到的,这个用户是不是在服务期内,是不是要额外收费,费用是多少。
2、抽象与解藕:
抽象化,就是把具象的业务抽象为一种概念性的词汇。其目的:不仅是为了架构设计的简洁性,更是为了整个平台业务的完整性,并把离散的业务过程场景化。
通过这一层“抽象”以后,就能把用户发起请求,到后续的所有关联性业务,完整的串联起来。从而发现整个过程的不足和缺陷,去通过产品的优化来促进业务的优化。
对用户来说,也只有这种全链路的触点优化,才是真正的用户体验。
业务抽象化的demo:“坐席接到用户王五反馈的问题,安排李四上门服务解决用户的冰箱故障”。
关键信息有:记录问题,安排资源,工程师接受任务,上门服务。则经过抽象后就变为:
受理:坐席把用户反馈的问题记录在案,并形成一个单据
调度:坐席根据用户信息,安排恰当的工程师
接单:工程师接受坐席安排的任务
履约:工程师上门处理用户反馈的问题
这种抽象后的关键节点称之为“业务动作”。“业务动作”即可作为我们构建产品架构的核心信息
今天的文章产品架构设计基本方法有哪些_数据架构设计分享到此就结束了,感谢您的阅读,如果确实帮到您,您可以动动手指转发给其他人。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/50830.html