产品规划考虑：浅析渠道化架构

　　本次文章的主题，便是前段时刻，以及接下来的工作要点——渠道化改造。渠道型产品司理也是产品司理中的一个稀缺物种，就此刻机我也来聊聊渠道产品司理与一般产品司理的同与异。

　　从产品视点来看，电商事务的需求有两个特色，事务需求多且冗杂；事务需求时效要求极高。这两个特定是由电商的特色决议的。关于电商来说：

　　1、顾客丢失门槛低。关于电商来说，顾客丢失门槛极低，因而需求时刻紧盯顾客的一举一动去巴结他们，偏偏人又都是喜新厌旧的动物，因而需求常常进行事务上的调整；

　　2、电商已是红海，一同工作抄袭成风，因而有新的事务时机需求赶快上马，战机少纵即逝。

　　面临这两个事务上的特色，简单导致的状况是，开发同学被事务同学推着走，一见面便是这又有XX个需求，都很急啊，先做上线再说吧。这会导致的问题是，在如此短的时刻内上线功用，难以进行体系性、大局的考虑，导致新的事务逻辑在原有体系逻辑上，像打补丁相同一块接一块，终究体系不堪重负，然后使全体的功率及稳定性下降。面临这样的问题，一般咱们都会选用体系重构的方法来处理。

　　俗话说得好，船小好调头，小的体系重构起来很简单，大的体系上跑的事务多，依靠多，事务逻辑杂乱，重构本钱十分高，仍是要尽量削减重构体系的次数。在不得不重构体系的状况下，怎样重构体系，才能在开发功率要求越来越高的状况下，完结可持续开展，尽量削减体系重构次数呢？这就触及架构规划的问题。一个合理的架构，能够在进步开发功率的一同，使体系的可用性越来越高。

　　在我的了解，渠道化是一种底层功用的架构计划，其完结的是将事务从事务耦合，多头办理，刚性支撑到事务分治，归口办理，柔性支撑的架构改变。

　　这儿说的事务耦合，并不是指正常的事务耦合，而是是指过紧的，不健康的耦合。

　　与其对应的概念是事务分治，指的是事务别离办理，依靠事务之间坚持较松的，健康的耦合联系。在事务开展初期事务较少的状况下，新事务处于探索阶段或许事务鸿沟含糊不清的状况下很简单呈现事务耦合的状况。后续跟着新事务、含糊事务中的两边都越来越杂乱之时，若没有及时解耦，耦合就会越来越紧，体系保护本钱本来越大，终究影响到两方各自的开展。

　　渠道化，方针之一完结的是从事务的不健康耦合到健康耦合的改变，这就要求要划清事务鸿沟，一同推进耦合两边共同完结解耦。

　　多头办理是一个下级一同承受多个上级领导的现象，在实践事务场景中，表现为一块事务，由多个团队进行保护的现象。这种状况导致的坏处首要有三个：

　　无论如何，都是弊大于利。而归口办理，则是按事务领域进行分工办理，不同团队，不同体系，不同模块各司其职，事务鸿沟清楚。渠道化，方针之二是完结事务归属从多头办理到归口办理的改变，这要求明晰事务功用，明晰团队责任，确认接口团队，一致保护事务。

　　先来说柔性支撑。柔性支撑是从柔性供应链学习来的一个概念，是指外部的需求在需求小批量，多批次，时效要求高的状况下，以合理的本钱水平敏捷满意事务方需求的才能，需求完结的越敏捷，支付的本钱越低，其具有的支撑柔性越好。柔性的根底，是复用性，可拓展性，模块式的规划方法。其对应的是刚性支撑，即没有考虑体系柔性的支撑。在事务初期，刚性支撑能快速满意事务方的需求，但久而久之体系全体功率下降，开发的边沿本钱越来越高，明显无法习惯事务的快速开展。渠道化方针之三，便是完结事务的柔性支撑，这就要求笼统出事务模型，从此前的以点为维度的支撑，换为以面为维度的支撑。

　　电商作为轻财物工作，最重的财物其实是人才，而人才中，占比最大的往往是咱们的技能同学们。在实施渠道化之后，由于完结了柔性支撑的联系，能极大解放技能同学，使其快速能完结事务需求，有更多精力投入到比方稳定性，功用进步，技能改造，技能学习等其他重要事项中，这也进步了人效，从另一个方面下降了公司的本钱。

　　渠道化之后，由于能够快速支撑事务方的日常需求，也使得咱们能更快把握住战机，一同在对外协作上，也更有商洽的筹码。

　　渠道化会进行事务分治及归口办理，这需求对现有的事务进行整理，事务鸿沟会变得愈加明晰。一同由于归口办理，各个团队对事务能进行更标准的办理，进步沟通功率，防止一件小事找了半响都没有人敢决定的状况。

　　关于渠道化，在推广的过程中由于概念较为笼统，不同事务线使用场景差异较大，因而在了解有许多误区，我也和咱们沟通下我个人的一些观点：

　　渠道化是一种架构方法的叫法，而不是做大的通用渠道才叫渠道化。在我的了解，只要被多使用场景，多事务方需求，高需求时效要求，不明晰的事务鸿沟搞得体系快hold不住的事务，就能够考虑进行渠道化改造。

　　做了大的事务渠道，完结了事务分治，我个人感觉，是渠道化的开端。事务分治，归口办理以及柔性支撑，其实是渠道化由浅及深的三个阶段。每个阶段对出产功率都会有必定程度的进步，但悉数完结之后，对出产功率的进步会到达一个全新的高度。路漫漫其修远，咱们仍需加油。

　　并不是一切事务都合适进行渠道化，咱们也不发起为了渠道化而渠道化。有一些事务，面临的事务方较少，事务改变少，体系压力小，此刻是否需求做渠道化，就需求评论一下了。究竟渠道化改造，需求投入的资源，时刻较多，假如投入产出比较低，则不必定要做。

　　这段时刻，经过关于渠道化的考虑，我总结了渠道化的通用产品模型，在此抛砖引玉，期望咱们一同评论下：

　　这一层首要对应的是渠道化中的事务分治的要求，要求事务鸿沟划清楚确，专业的人干专业的事。

　　我个人觉得事务功用能够由三种要素组合组成，别离为前端才能，后端才能以及事务规矩组成，因而柔性支撑应该在这三种要素中均进行表现。详细的做法，便是经过前端的模块化，后端的流程可装备化以及事务规矩的可装备化，来完结事务功用的柔性支撑。

　　这一层首要对应的渠道化中的归口办理的要求。经过接口层，由一个底层服务团队对多个事务方一致供给服务，然后做到底层功用的归口办理。

　　事务方只需求对应接口层，即可完结想要的功用，对他们来说，底部的功用完结都是黑箱的，他们是需求用相似SDK的方法来与接口层进行交互即可。

　　以上是我关于渠道化的了解。综上，渠道化架构是一个在面临需求小批量、多批次、时效要求高的事务场景下的好挑选，关于出产功率的进步是有极大优点的。

　　功用层有点不大好了解！！！可否举例论述下，这几个层级是否有自底而上的序？功用层为什么是在事务层和接口层之间的？

　　渠道化对资源的要求很高，并且许多时分，渠道刚推出来，并不见得对项目的支撑功率有进步，反而影响项目的开发功率，这样，很简单被人扔掉，大部分公司仍是按项目的短平快的方法来进行开发； 渠道化这条路不好走

　　个人主张：要点理清楚事务后边的规划，是否必定要做渠道化（由于像文章所说，渠道化占用资源极大，ROI需求好好评价的）；然后产品的要点工作是笼统事务，构成有用的事务模型（首要的事务需求能够笼统为哪些事务模块的组合，这是最检测产品司理才能的点，笼统少了一个维度都是坑开发和运营，笼统多了会被开发喷）；终究依据这些事务模块和开发一同规划产品和技能计划。最重要是第一点。牢记千万不要为了kpi起项目，这是产品司理的工作操行底线

　　听到许多言论说在我国程序员是吃芳华饭的，那么产品司理呢，也吃芳华饭吗？

　　人人都是产品司理（）是以产品司理、运营为中心的学习、沟通、共享渠道，集媒体、训练、社群为一体，全方位服务产品人和运营人，建立11年举行在线+期，线+场，产品司理大会、运营大会50+场，掩盖北上广深杭成都等20个城市，在工作有较高的影响力和闻名度。渠道聚集了很多BAT美团京东滴滴360小米网易等闻名互联网公司产品总监和运营总监，他们在这儿与你一同生长。