产品设计思考：浅析平台化架构.docVIP

产品设计思考：浅析平台化架构 　　本次文章的主题，就是前段时间，以及接下来的工作重点——平台化改造。平台型产品经理也是产品经理中的一个稀缺物种，就此机会我也来聊聊平台产品经理与一般产品经理的同与异。 　　 　　由于笔者从事电商行业，因此就以电商行业举例说明。 　　一、平台化是什么 　　从产品角度来看，电商业务的需求有两个特点，业务需求多且繁杂；业务需求时效要求极高。这两个特定是由电商的特点决定的。对于电商来说： 　　1、消费者流失门槛低。对于电商来说，消费者流失门槛极低，因此需要时刻紧盯消费者的一举一动去讨好他们，偏偏人又都是喜新厌旧的动物，因此需要经常进行业务上的调整； 　　2、电商已是红海，同时行业抄袭成风，因此有新的业务机会需要尽快上马，战机稍纵即逝。 　　面对这两个业务上的特点，容易导致的情况是，开发同学被业务同学推着走，一见面就是这又有XX个需求，都很急啊，先做上线再说吧。这会导致的问题是，在如此短的时间内上线功能，难以进行系统性、全局的考虑，导致新的业务逻辑在原有系统逻辑上，像打补丁一样一块接一块，最后系统不堪重负，从而使整体的效率及稳定性降低。面对这样的问题，一般大家都会采用系统重构的方法来解决。 　　俗话说得好，船小好调头，小的系统重构起来很简单，大的系统上跑的业务多，依赖多，业务逻辑复杂，重构成本非常高，还是要尽量减少重构系统的次数。在不得不重构系统的情况下，怎么重构系统，才能在开发效率要求越来越高的情况下，实现可持续发展，尽量减少系统重构次数呢？这就涉及架构设计的问题。一个合理的架构，可以在提高开发效率的同时，使系统的可用性越来越高。 　　这就要有请我们本次文章的主角，平台化出场了。 　　在我的理解，平台化是一种底层功能的架构方案，其实现的是将业务从业务耦合，多头管理，刚性支撑到业务分治，归口管理，柔性支撑的架构转变。 　　这么说可能不太好理解，让我来解释几个概念： 　　1、业务耦合-业务分治 　　这里说的业务耦合，并不是指正常的业务耦合，而是是指过紧的，不健康的耦合。 　　与其对应的概念是业务分治，指的是业务分别治理，依赖业务之间保持较松的，健康的耦合关系。在业务发展初期业务较少的情况下，新业务处于摸索阶段或者业务边界模糊不清的情况下很容易出现业务耦合的情况。后续随着新业务、模糊业务中的双方都越来越复杂之时，若没有及时解耦，耦合就会越来越紧，系统维护成本原来越大，最终影响到两方各自的发展。 　　平台化，目标之一实现的是从业务的不健康耦合到健康耦合的转变，这就要求要划清业务边界，同时推动耦合双方共同完成解耦。 　　2、多头管理-归口管理 　　多头管理是一个下级同时接受多个上级领导的现象，在实际业务场景中，表现为一块业务，由多个团队进行维护的现象。这种情况导致的弊端主要有三个： 负责团队多，互相踢皮球；不同团队之间团队墙导致的沟通成本过高；业务难以标准化，业务方接入成本高。　　无论如何，都是弊大于利。而归口管理，则是按业务范畴进行分工管理，不同团队，不同系统，不同模块各司其职，业务边界分明。平台化，目标之二是实现业务归属从多头管理到归口管理的转变，这要求明确业务功能，明确团队职责，确定接口团队，统一维护业务。 　　3、刚性支撑-柔性支撑 　　先来说柔性支撑。柔性支撑是从柔性供应链借鉴来的一个概念，是指外部的需求在需求小批量，多批次，时效要求高的情况下，以合理的成本水平迅速满足业务方需求的能力，需求完成的越迅速，付出的成本越低，其具有的支撑柔性越好。柔性的基础，是复用性，可拓展性，模块式的设计方式。其对应的是刚性支撑，即没有考虑系统柔性的支撑。在业务初期，刚性支撑能快速满足业务方的需求，但长此以往系统整体效率下降，开发的边际成本越来越高，显然无法适应业务的快速发展。平台化目标之三，就是实现业务的柔性支撑，这就要求抽象出业务模型，从此前的以点为维度的支撑，换为以面为维度的支撑。 　　二、为什么要做平台化 　　以上是我对平台化的理解，接下来说下做了平台化，我们能收获什么？ 　　在我看来，平台化的效果主要有三点： 　　1、降本增效，提高效率。 　　电商作为轻资产行业，最重的资产其实是人才，而人才中，占比最大的往往是我们的技术同学们。在实行平台化之后，由于实现了柔性支撑的关系，能极大解放技术同学，使其快速能完成业务需求，有更多精力投入到比如稳定性，性能提高，技术改造，技术学习等其他重要事项中，这也提高了人效，从另一个方面降低了公司的成本。 　　2、快速支撑，响应业务。 　　平台化之后，由于能够快速支撑业务方的日常需求，也使得我们能更快把握住战机，同时在对外合作上，也更有谈判的筹码。 　　3、边界清晰，管理规范。 　　平台化会进行业务分治及归口管理，这需要对现有的业务进行梳理，业务边界会变得更加清晰。同时由于归口管理，各