搭建产品架构,不能忽略这4个原则

0 评论 6218 浏览 18 收藏 10 分钟

编辑导读:产品架构,就是对产品主要功能的一种提前规划和架构。企业在搭建系统布局的时候,就应该先做好架构规划,避免后期出现问题来不及补救的情况。本文作者分享了搭建产品架构的几个重要原则,与大家分享~

前几天突然接到一个朋友的电话,说最近公司交易系统频繁的出问题,造成了近千万的损失,看有没有办法解决。

几年前有和他简单聊过一下那个公司构建系统的情况,我说了一句话:这么搞迟早得崩。最近真的严重到打补丁的方式没有效果,他想到了我们当时的聊天,以为我有什么办法,我想了一下,告诉他没什么办法,只能一边救火,一边安排人认真梳理,重构一个系统。

这不是个案,很多公司的系统规划都是简单粗暴,今天给我做个CRM,明天给我做个ERP,出了问题临时找方法打补丁,解决当前的问题,最后写系统的开发小哥自己都说:太冗余太恶心了,这玩意我自己都不知道啥逻辑。

企业在做自己的系统布局时候,很多时候需求及规划是不清晰的,只能看到眼前的需求,后期业务怎么发展还没有具体规划。产品规划不能以业务的视角去看,要以产品架构的全局视角去思考。清晰的业务需求排高优先级,不清晰的需求可以作为构建产品架构的方向指导,每个分支可以单独规划,统一思考整体架构。

01 产品架构路线演变

产品的架构路线是一个逐步演化的过程,信息化早期阶段,企业基本不谈产品架构,或者说产品架构只存在于单独系统中,产品部门的管理是严格区分业务线,业务线间相对封闭,各自发展。

随着各公司内产品线越来越多,产品开发人员会发现各产品线做了很多重复的内容,明明可以共用的内容做了好几遍,为什么不能共用一部分?业务人员也慢慢体会到,一个业务流要切换好几个系统,越来越麻烦,为什么不能共用一个系统?这就催生了产品需要统一架构,全局思考。

演变路径还有一个基础,那就是产品架构的思路逐渐成熟,在最初的产品规划期就有一个相对详细的路线参照。比如说最近很热的中台化架构,利弊已经很明显,如果企业的规划中是多产品线,有共用的能力或组件,就可以朝着中台化架构的方向去构思规划。再比如流量池式的架构方式,把多个产品的流量用多种产品方式做连接联合,建立流量闭环。

02 产品架构原则

在公司内提出产品架构的时候,一定会有不同的声音,产品经理不可能用一张图或者几份文件,就能满足各部门的需求,但这里想说的是,一定要勇于提出整体产品架构,哪怕是错的,也给了大家讨论的方向,给了产品架构逐渐清晰的可能性,或许还能给各部门间的连接提供机会。产品架构是逐渐清晰的,是不断修改才会逐渐逐渐准确,所以大胆的画一画产品架构图,大胆的拿着蓝图PPT去找领导聊一聊。

在大公司,比如前公司内八大事业群,公司五六万人的时候,做全公司整体产品架构基本不可能,除非你是CXO。对大部分不是CXO的产品人员来说,可以构想本事业部或者本产品线的整体架构。如果只负责一个产品模块的化,可以先构建单模块架构,对规划产品也是有帮助。

(1)确保产品架构的可延展性

产品架构一定是可延展,可迭代的。随着业务推进,可以说只有企业愿景、核心价值观、总目标是基本不变的,其余的都可变,更何况本来就是蓝图属性的产品架构。

(2)产品架构需高度抽象化,标准化

产品架构是高度抽象,先不考虑具体内容,重点是建立一套系统矩阵,功能或信息模型。产品架构规定标准化产品规则,后期所有的新增产品都需要遵守同一套标准,甚至可以是产品红线,维护整体机构的健康。通过标准化的规则建立产品,是个捷径。

这里做一个类比,产品架构就是一个书架,产品就是每个隔间的书,有大小不同规格,根据时间或者阅读的需求,逐步把书放到该放的隔间中,这就是产品的增量。

(3)产品架构内需要限定清晰的边界

产品架构中需要有明确的分割边界,明确规定每一个产品或模块的属性、范围、职能。尤其是对于有多产品间信息流转的业务,更要注意这一点。

站在业务人员的角度,当然希望一个系统大而全,或者用一个流程涵盖一切,这样最方便。但产品角度去考虑,完全不是这样,系统有明确的细分逻辑,规划阶段需要明确各细分属性。

(4)产品架构需考虑产品矩阵关系网

产品架构可以抽象为产品+关系,就是多产品构成的矩阵,结合产品间的关系,够成的网络。

关系可以是业务属性,比如流程、业务流转等;关系可以是流量属性,比如流量流转路径、流量分发方式;关系也可以是产品属性,比如增量关系、迭代关系等。

考虑产品关系的时候,绕不开项目角度的思考,比如放在项目集中思考,在项目组合中思考,结合运营一起思考等等方式,作为产品关系网的辅助。

03 产品架构方式

一般是以企业愿景为基础,以现有产品作为起点,绘制产品架构图。

把企业目标愿景落地成系统布局,再分步规划达到目标系统的步骤、过程,这就构成了产品架构的主线。辅助业务线架构,由主业务线延伸,往往作为分支存在。把支持型产品和外部对接产品并入架构,如OA、财务等。同步构建关系网,业务流转等。

企业都会关心“四流”,信息流、商流、物流,还有资金流,对应到产品层面,是我们常说的两个模型:

  1. 信息流对应信息模型,模型涉及信息的进入、流转、分析、转出,信息的完整度、有效性等方面。
  2. 商流、资金流、物流对应功能模型,或者说是交易模型。企业可以说是建立在交易模型的基础之上的,交易主体、交易方向、交易过程等,是商流需要考虑的问题;具体到业务层面,货物的运输也就是物流、收付款也就是资金流,都可以是交易模型的子功能集。

借助信息模型和交易模型,基本可以构建完整的产品架构。可同时思考流量模型和用户模型,流量模型的核心的流量闭环,是增量和存量的处理,可以作为产品架构前置部分的逻辑参考。用户模型的核心就是用户建模,单用户模型、用户群模型,结合流量、交易一起思考的流量属性、业务属性等等,都可以作为产品架构底层部分的思考。

最后,还是回到开头那个问题,试想,如果在做公司第一个产品的时候,就构建产品架构,后期产品布局都是“架构射程范围内的事情”,可能就不会出现那么多意料之外棘手的情况。

一个产品不可能是单独的存在,开始规划的时候,就先有产品架构的意识,提前踩坑,后面产品的增速会越来越快。

 

本文由 @谢宇 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!