微信
手机版
网站地图

杨凌,产品架构图到底是怎样“画”出来的?,女人和狗

2019-04-14 15:07:10 投稿人 : admin 围观 : 228 次 0 评论

产品架构是对事务的笼统,但架构不是完美存在的效果,而是一个不断改进优化的进程。

此前咱们聊过“愿望国度事务架构、产品架构和信息架构的问题”在实践工作中咱们 能见到一些公司,产品都现已上线了,却找不到一份适宜的文档描绘整个产品的结构,前端和后台由哪些部分组成,各自之间有着怎样的相相联系,各个模块怎样协同支撑整个事务的开展。

更有甚者,乃至都找不到一份完好的文档,来明晰的界定产品的鸿沟,彻底是盲人摸象般柯恩认罪的走到哪算哪。

咱们还能见到不少挂着总监,乃至VP头衔的人,依然讲不清公司的产品的开展方向和未来规划,由于他们从来没有真实的规划过整个产品线的未来,渐渐的,整个公司只要各自一大堆的软件,或许不同的功用模块,有的是些微的改动,有的是重复规划和开发。

咱们的疑问是:为什么会出现这种状况?以及怎样处理这个问题呢?

以本次复盘的O2O渠道为例,咱们把整个渠道简化分拆为用户层、效劳层和接口层(裁剪掉整个渠道中的多租户等实践事务中的杂乱运用)。

如下图所示:

O2O产品架构示例

现在的疑问是,为什么要这么分层,又是经过什么方法得出每一层要有这些功用模块的规划呢?

本文为你详细解析杨凌,产品架构图到底是怎样“画”出来的?,女人和狗产品架构的规划进程。

01 产品架构是可视化4000328876东西

在前文咱们讨论产品的信息架构、产品架构与事务架构底子概念时,我用了一栋房子的比方来描绘“产品架构”的概念,“架构”决议整栋方法的方位、朝向、楼层,决议了地下几层,地上有几层,有多杨凌,产品架构图到底是怎样“画”出来的?,女人和狗少间房,层高多少米,这些东西是不论怎样装饰,都改动不了的实践。

对这栋房子而言,支柱、承重墙是再装饰的时分都不能动,要动就得大动手术,乃至爽性推到重来。

“客厅”、“餐厅”、“主卧”这些功用区域,则是咱们在运用某些某个产品的时分,所对应的功用模块。这个时分咱们就发现,假如等房子建好了,再想把本来的一房一厅改成两房一厅,就只能做间隔,比方导致每个房间的面积变小,或许没窗,或许采光缺乏等等。

从房子的比方,咱们能够得出一个定论:产品架构图是一种产品司理用来笼统表达一款产品的效劳和商业形式的可视化东西。

产品司理把产品所要完结的具象功用,笼统为一个一个互相独立又互为相关的模块(这种相关性也是模块的交互联系,包含信息和数据,通常以接口的方法完结),并把这些模块依据必定的事务或数据逻辑进行分层组合,来传递产品的事务流程、商业形式和规划思路。

所以,在产品正式进入开发曾经,制作一个完好的产品架构图就成为必定。

架构的底子意图便是为了整理产品思路,从全体上掌握产品的开展方向,把控产品的功用要点(卖点),它决议了产品必需求完结的功用,以及什么时分有必要完结的功用,也便是产品的架构决议三老头袭臀了产品的开展途径。

一起,为了满意咱们所设定的“架构”设想,还有必要装备相关的产品研制和商场运营资源以及详细的落沈明月地方案,包含技能选型和技能途径,商场营销规划等一系列的战略和方法。

产品架构是团队依据某一共同商场和用户痛点的一致交流言语,也是在产品迭代进程中的事务鸿沟。

02 分层是产品架构规划的底子方法

假如你满足仔细的话,会发现本文的事例“O2O产品架构示例”中,右侧有符号“接口层”、“效劳渠道”、“终端用户”等字眼,并做了一个符号,阐明他们说代表的意义和使命,比方“呼应终端的效劳恳求”,意味着这一层级的一切功用,都是为“用户”效劳的,是针对用户行为的一个信息承受和反应机制。

比方:在O2O的效劳进程中刘奕飞,用户有一个设备的修理恳求,他经过“用户界面”向渠道发送一个状况信息和恳求信息,渠道端经过一个有用的机制,及时的承受这一信息,并让用户了解到,“我现已知道你这边除了状况,我正在组织人选用一些方法来帮忙你处理问题”。

这便是一种呼应机制,这一进程便是整个渠道的效劳端开端处理用户恳求的起点,然后整个渠道依据这一个被“触发”的机制,去调集整个渠道的资源,包含各项数据的查阅、各种资源的调集,来协同处理这一个事务恳求的系列动作。

所以,整个产品的架构规划,也便是依据这一个连锁反应进行的事务层和逻辑层的解耦分拆,体系性的规划整个O2O渠道的前后端怎样高效的协同。

一起,依据这一个底子规矩,咱们再考虑渠道的未来事务开展,乃至咱们还需求考虑到未来三五年的事务容量会到达什么量级,由此需求选用怎样的技能规划和资源配置(云端效劳资源)。

由此可见,产品架构规划,首要便是一个分层规划的进程。

常来说,最简略完结的产品层级结构便是三层,即用户层、功用层和数据层,这种层级联系即可完好的完结前、后台联系的事务体系:

1. 一致的用户感知层

处理的是用户触达的问题,考虑在何种场景下经过何种方法触达用户,最表层的事务体会,也便是咱们常说的“用户体会”,包含界面,布局,配色等直观可见的每一个产品页面。

在这个层面,咱们考虑的是怎样更好的表达咱们想要表达的事务元素,怎样能够更招引用户的注意力和逗留决议计划,它在必定程度上决议了用户是否会当即卸载,或许是带着猎奇之心在有用的引导下探究产品。

这是产品司理的必修课,由于它能直观的让人直接评断产品,最常见的说辞便是“丑爆了”,并且是任何一个产品都会遭受到这一批判,哪怕你是微信也毫不破例。

但真实决议体会的,并不是这一层,但又百般无奈有必要面对的实践。所谓人靠衣装吧,一个装扮时尚的美人你乃至都会觉得她特别让你感觉密切,乃至你会直觉以为她底子便是一个好人,一个让你喜爱的人。

2. 解耦的事务功用层

多少产品司理实践在这个层级就开王杰的老婆始堕入模糊东北丈母娘状况,底子不知道乃至没有意识到“功用”的分化和层次规划,在他们眼里,任何产品都只需求一个界面+一个数据库,即可愉快的完结一切事务。

也是由于这种片面的判别,让多少人总是以为这个东西很简略,那个东西很简略,他人都能够做出来,你为什么明日还不能上线,以及谁谁谁又做了这么一个功用,咱们明日也要做一个。

诸如此类的底子原因便是只见树木不见森林。

这一种浅显的知道,也带来许多的产品被偷工减料,胡乱许诺,终究不得不草草了事,由于这些产品从一个开端就没有被真实的了解和规划,而是想当然的以为“咱们只差一个程序员,明日就能够上线”。

对这一层级的认知缺乏,会让咱们堕入一种古怪的局势。

一个妈妈生一个孩子要10个月,10个妈妈生一个孩子只需求一个月。

“事务功用”的解耦,实质是处理产品的中心功用的设六皇妹计问题,包含怎样高效的完结事务功用,怎样与用户层进行交互,怎样与外部体系进行数据通信等一系列杂乱的事务处理。

许多人无法了解,某个功用为什么要这么规划,为什么不能那样规划,便是无法跪趴真实了解这一层的规划,然后加重整个产品在最开端阶段就限制了它的或许性。

这是“重构”的原罪。

这儿再次用了解耦这个词,为什么会重复用到它,底子性原因便是考虑事务的扩展性,也是考虑整个渠道的伸缩性。不要把各个功用模块过于严密的耦合,导致任何些微的改动,都有必要大动干戈。

最糟糕的规划,便是一切功用只看到一个事务线,一切人都在忙活,但没有人搞得清楚鸿沟。

还有一种糟糕的局势便是,彻底的各自为营,没有协同,没有次第

这两种状况我都见过,带来的成果除了渠道的功率低以外,也是资源的糟蹋,更是堵塞了团队的上升空间。——堵塞整个团队获得效果的通道,也阻止团队才能的进步。

3. 会集的数据处理层

相比较于“用户层”,是一切人都直观可见的是,一切人都知道有一个“数据库”,别管知不知道数据是什么,有哪些,要怎样用,它就相当于咱们的钱袋子,装得有东西必定就比没东西更好。再要怎样耍弄耍弄,无法是钱票子装得多点,简略数一点的问题。

所以,这一层处理的问题便是,产品的数据从哪里,沉积到哪里去。实践上,略微深化一点的问题便是数据怎样高效的存储,怎样快速的被调用。

比方:今天头条的引荐算法,便是依据用户在运用(用户层的行为)进程中发作的数据,来制作这个用户的习气偏好,选用一种恰当的规矩来引荐相关的内容,然后使得这个用户更多的逗留在产品上。

然后在此根底上催生更多的商业或许性。

让咱们在回到事例中的O2O项目。

O2O产品架构示例

咱们用一个“用户故事”来描绘其时咱们需求处理的用户问题:

“张三新买的冰箱出现了毛病,他找到其时的回执单申报了一次售后效劳,要求在周六上午处理完冰箱的毛病”。

从这个描绘进程中,咱们就能知道3个要害信息:

(1)用户信息

要有一个便利的界面帮忙用户申报效劳,怎样能让用户在申报效劳的时分把材料问题录入正确,有没有方法在用户翻开这个界面就直接处理问题,有没有一个FAQ供用户查阅。

(2)事务信息

后台要处理用户的效劳恳求(申报的售后效劳),要组织一个拿手处理这个毛病的工程师上门效劳(事务技能要匹配,不能派一个不明白冰箱的工程师处理这个问题),时刻是周六(资源要分配,间隔太远不适宜,时刻抵触不适宜等)。

(3)数据信息

前次的订单是怎样找到的,这个用户是不是在效劳期内,是不是要额外收费,费用是多少。这次处理完的订单怎样和前次的订单相相关等等。

依照这种逻辑,就能明晰的勾勒出,在处理用户的效劳恳求所需求完结的系列动作,整个渠道钟沛枝的数据和信息是怎样进行流通,以及为了支撑整个渠道需求开发的产品功用有哪些。

当然,单凭这一个“用户故事”就能制作一个大约的事务概括。

这是一种最简略的分层机制,咱们能够快速的得到一个开始的产品结构,当然必定存在不少鸿沟不明晰,分层不明确的问题,咱们还需求依据不同信息层级的鸿沟、同一层级内模块和模块的鸿沟。

下一步,则是针对详细的事务打开规划。

03 笼统与解耦

在前述的”分层“逻辑中,在各个事务层级中,我用了许多“小豆腐块”表明详细的功用。我想你现在的疑问应该是,这些小豆腐块是怎样被界定,它们的依据又是什么呢?

比方:架构中有“接单”、“履约”、“回单”、“订单列表”,为什么没有登录,修正暗码这些根底功叶子笛能,是由于这个强制侵吞产品不需求这些功用吗?

这个问题的奥妙在于,产品架构处理的是事务问题,而非功用问题。意思便是,架构只框定这个产品要完结哪些事务,获得哪些效果杨凌,产品架构图到底是怎样“画”出来的?,女人和狗以及相关的支撑数据,而不处理为了完结这些事务,所需求进行的每一项详细的功用操作。

所以,在整个规划中,咱们只看到一些简练的、概括性的词汇,而没有任何的实践功用,并且这些词汇乃至或许自身便是整个渠道中的一个模块或许一个小产品,也新中国奇疑要案20例或许其间的词汇永久不会在产品中表现为详细的功用,比方:“履约”,它代表的便是完结效劳的一系列进程。

99000韩元

这种规划思路,便是笼统化,把具象的事务笼统为一种概念性的词汇,其意图不只是为了架构规划的简练性,更是为了整个渠道事务的完好性,并把离散的事务进程场景化。

经过这一层“笼统”今后,整个渠道的事务结构即可完好的出现只纸面上,咱们就能把用户建议恳求一直到后续的一切相关性事务完好的进行串联,也就能够发现整个进程的缺乏和缺点,去经过产品的优化来促进事务的优化。

这才是真实的产品价值,企业经过布置这一套渠道化体系,带来了整个事务流程的优化,进步了用户的体会。对2B的产品来说,它需求的是何朋娟体系性的进步整个组织的功率,进步全体的绩效,这其间也必定包含可见的体系布置本钱,保护本钱,以及相应的办理本钱的优化。

对用户来说,也只要这种全链路的触点优化,才是杨凌,产品架构图到底是怎样“画”出来的?,女人和狗真实的用户体会。

咱们再次回到O2O渠道的一个“辑组词用户故事”来反推怎样进行事务的笼统化:“坐席接到用户王五反应的问题,组织李四上门效劳处理用户的冰箱毛病”。

在这个描绘中实践包含的要害信息有:记载问题,组织资源,工程师承受使命,上门效劳。所以这个进程经过笼统处理后就变成如下方式:

咱们能够把这种笼统后的要害节点称之为“事务动作”,356mm他们将像一栋房子的支柱和承重墙相同,牢牢的支撑起整个渠道的工作。

经过这种高度笼统后,整个体系十分简练而又完好,各个环节只需求经过一个订单主线即可完结一系列的使命,不论这个进程即将发作多杂乱的事务交互,都一直能够环绕用户和订单来进行溯源办理和使命处理。

这种笼统后的事务动作即可作为咱们构建产品架构的中心信息,经过事务杨凌,产品架构图到底是怎样“画”出来的?,女人和狗分层和逻辑分层,谨慎进行分拆,构成终究的产品架构规划,并依据这一头绪进行恰当的打开和引申,则整个渠道雏形便显现在咱们眼前。

回到问题的起点,假定咱们没有能够进行这种笼统性的架构规划,咱们将面对怎样的局势呢?

04 架构,是一个渐进的进程

架构,是一个倾向微观的工作,而规划则是一个倾向细节的工作。这儿要区别的一件事便是技能架构和产品架构,技能架构是将产品需求转变为技能完结的进程,产品架构则是将用户需求转变为产品需求的进程。

咱们能够幻想一栋楼的地基问题所带来的影响,对任何产品而言,一旦架构定错,轻则楼盖不高,重则底子改不起楼。

所以,产品的架构规划,最检测PM的判别力和规划才能——体会是规划出来的,产品是规划出来的,简练的架构决议产品的调性。

可是,与“房子”的事例不同的是,产品的架构不只是“效果”,而是一种迭代的进程。它会跟着事务的开展而不断优化和调整,对一款产品来说,不存在一种一直静态的架构形式。

比方:电商渠道,在前期许多功用或许都不是要害性事务,在架构规划都或许不会考虑,而是跟着事务的开展而调整。所以,有必要确保产品架构具有必定的扩展性和生长性。比方:电商渠道的banner,跟着事务的开展,它能彻底生长为一个独立的强运营的事务模块。

#专栏作家#

杜松,大众号:产品微言,人人都是产品司理专栏作家。专心于人工智能方向,拿手产品规划和架构规划。

题图来自Unsplash ,依据 CC0 协议。

声明:该文观念仅代杨凌,产品架构图到底是怎样“画”出来的?,女人和狗表作者自己,搜狐号系信息发布渠道,搜狐仅供给信息存储空间服丁传红务。
杨凌,产品架构图到底是怎样“画”出来的?,女人和狗

相关文章

标签列表