搭建产品架构，不能忽略这4个原则
前几天突然接到一个朋友的电话，说最近公司交易系统频繁的出问题，造成了近千万的损失，看有没有办法解决。
几年前有和他简单聊过一下那个公司构建系统的情况，我说了一句话：这么搞迟早得崩。最近真的严重到打补丁的方式没有效果，他想到了我们当时的聊天，以为我有什么办法，我想了一下，告诉他没什么办法，只能一边救火，一边安排人认真梳理，重构一个系统。
这不是个案，很多公司的系统规划都是简单粗暴，今天给我做个CRM，明天给我做个ERP，出了问题临时找方法打补丁，解决当前的问题，最后写系统的开发小哥自己都说：太冗余太恶心了，这玩意我自己都不知道啥逻辑。
企业在做自己的系统布局时候，很多时候需求及规划是不清晰的，只能看到眼前的需求，后期业务怎么发展还没有具体规划。产品规划不能以业务的视角去看，要以产品架构的全局视角去思考。清晰的业务需求排高优先级，不清晰的需求可以作为构建产品架构的方向指导，每个分支可以单独规划，统一思考整体架构。
01 产品架构路线演变
产品的架构路线是一个逐步演化的过程，信息化早期阶段，企业基本不谈产品架构，或者说产品架构只存在于单独系统中，产品部门的管理是严格区分业务线，业务线间相对封闭，各自发展。
随着各公司内产品线越来越多，产品开发人员会发现各产品线做了很多重复的内容，明明可以共用的内容做了好几遍，为什么不能共用一部分？业务人员也慢慢体会到，一个业务流要切换好几个系统，越来越麻烦，为什么不能共用一个系统？这就催生了产品需要统一架构，全局思考。
演变路径还有一个基础，那就是产品架构的思路逐渐成熟，在最初的产品规划期就有一个相对详细的路线参照。比如说最近很热的中台化架构，利弊已经很明显，如果企业的规划中是多产品线，有共用的能力或组件，就可以朝着中台化架构的方向去构思规划。再比如流量池式的架构方式，把多个产品的流量用多种产品方式做连接联合，建立流量闭环。
02 产品架构原则
在公司内提出产品架构的时候，一定会有不同的声音，产品经理不可能用一张图或者几份文件，就能满足各部门的需求，但这里想说的是，一定要勇于提出整体产品架构，哪怕是错的，也给了大家讨论的方向，给了产品架构逐渐清晰的可能性，或许还能给各部门间的连接提供机会。产品架构是逐渐清晰的，是不断修改才会逐渐逐渐准确，所以大胆的画一画产品架构图，大胆的拿着蓝图PPT去找领导聊一聊。
在大公司，比如前公司内八大事业群，公司五六万人的时候，做全公司整体产品架构基本不可能，除非你是CXO。对大部分不是CXO的产品人员来说，可以构想本事业部或者本产品线的整体架构。如果只负责一个产品模块的化，可以先构建单模块架构，对规划产品也是有帮助。
（1）确保产品架构的可延展性
产品架构一定是可延展，可迭代的。随着业务推进，可以说只有企业愿景、核心价值观、总目标是基本不变的，其余的都可变，更何况本来就是蓝图属性的产品架构。
（2）产品架构需高度抽象化，标准化
产品架构是高度抽象，先不考虑具体内容，重点是建立一套系统矩阵，功能或信息模型。产品架构规定标准化产品规则，后期所有的新增产品都需要遵守同一套标准，甚至可以是产品红线，维护整体机构的健康。通过标准化的规则建立产品，是个捷径。
这里做一个类比，产品架构就是一个书架，产品就是每个隔间的书，有大小不同规格，根据时间或者阅读的需求，逐步把书放到该放的隔间中，这就是产品的增量。
（3）产品架构内需要限定清晰的边界
产品架构中需要有明确的分割边界，明确规定每一个产品或模块的属性、范围、职能。尤其是对于有多产品间信息流转的业务，更要注意这一点。
站在业务人员的角度，当然希望一个系统大而全，或者用一个流程涵盖一切，这样最方便。但产品角度去考虑，完全不是这样，系统有明确的细分逻辑，规划阶段需要明确各细分属性。
（4）产品架构需考虑产品矩阵关系网
产品架构可以抽象为产品+关系，就是多产品构成的矩阵，结合产品间的关系，够成的网络。
关系可以是业务属性，比如流程、业务流转等；关系可以是流量属性，比如流量流转路径、流量分发方式；关系也可以是产品属性，比如增量关系、迭代关系等。
考虑产品关系的时候，绕不开项目角度的思考，比如放在项目集中思考，在项目组合中思考，结合运营一起思考等等方式，作为产品关系网的辅助。
03 产品架构方式
一般是以企业愿景为基础，以现有产品作为起点，绘制产品架构图。
把企业目标愿景落地成系统布局，再分步规划达到目标系统的步骤、过程，这就构成了产品架构的主线。辅助业务线架构，由主业务线延伸，往往作为分支存在。把支持型产品和外部对接产品并入架构，如OA、财务等。同步构建关系网，业务流转等。
企业都会关心“四流”，信息流、商流、物流，还有资金流，对应到产品层面，是我们常说的两个模型：
- 信息流对应信息模型，模型涉及信息的进入、流转、分析、转出，信息的完整度、有效性等方面。
- 商流、资金流、物流对应功能模型，或者说是交易模型。企业可以说是建立在交易模型的基础之上的，交易主体、交易方向、交易过程等，是商流需要考虑的问题；具体到业务层面，货物的运输也就是物流、收付款也就是资金流，都可以是交易模型的子功能集。
借助信息模型和交易模型，基本可以构建完整的产品架构。可同时思考流量模型和用户模型，流量模型的核心的流量闭环，是增量和存量的处理，可以作为产品架构前置部分的逻辑参考。用户模型的核心就是用户建模，单用户模型、用户群模型，结合流量、交易一起思考的流量属性、业务属性等等，都可以作为产品架构底层部分的思考。
最后，还是回到开头那个问题，试想，如果在做公司第一个产品的时候，就构建产品架构，后期产品布局都是“架构射程范围内的事情”，可能就不会出现那么多意料之外棘手的情况。
一个产品不可能是单独的存在，开始规划的时候，就先有产品架构的意识，提前踩坑，后面产品的增速会越来越快。
本文作者 @谢宇
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
