面对伪中台如何做好产品设计

　　中台的概念到处都是，笔者所在的公司玩出了一个伪中台，针对这个伪中台，笔者该如何进行产品设计呢？
　　愿景：在笔者的产品工作中经理的一些比较有意思的坑，分享出来，可以给大家一点思考，一点启发。
　　目标人群：产品人amp；amp；年龄amp；lt；2岁
　　idea：分享一些实际的产品设计案例
　　竞争对手：个人兴趣、时间、惰性
　　预计耗时：阅读本文预计耗时7分钟
　　写在前面的话：
　　其实随着做产品的不断深入，我们都会遇到各种各样的坑。比如同事的不靠谱、领导的错误抉择又或者是鸡肋的产品架构或者不清晰的产品定位，这些都可能会导致我们在进行产品设计的时候感到无奈和超级想吐槽。
　　但是吐槽完了之后，还是得按照客观条件进行设计产品，不然，你的产品方案可能就无法落地。
　　所以，笔者认为，我们的产品工作，其实限制蛮大的，也需要在这样的限制下，去做好一些微创新，通过一些微创新的方式来平衡我们的产品认知和现实客观条件的矛盾。
　　好了，接下来我们开始进入正题，如何基于伪中台做好产品设计。在这里，笔者将会结合自己的实际案例，给大家进行解剖。
　　一、中台概述
　　1。中台是什么
　　这里，笔者首先为大家列举几个常见的中台名称：微服务开发框架、容器云、Paas平台、用户中心、订单中心等。
　　是否觉得这几个名称很熟悉？
　　其实如果名称再包装一下，就是我们所熟悉的技术中台又或者是业务中台，所以中台并不是什么很稀奇的概念。
　　但业内其实并没有一个对中台的准确定义，所以笔者选取其中一个比较靠谱的定义供读者们认知中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构）。
　　它存在的唯一目的，就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
　　2。中台的价值是什么
　　从定义中，我们就能知道，中台的价值就是进一步提高服务用户的效率和质量。
　　但为什么这么说呢？
　　这是由于在传统的架构中，我们只是将产品分为前台和后台。前台就是和用户的触电，类似于网页、APP、小程序、公众号等，而后台就是对企业资源的管理，类似与CRM系统、ERP系统等等。
　　其实在这里我们可以了解到，前台和后台并非一一对应，前台主要是服务于用户；而后台更多的是服务于企业的管理，提高企业管理效率和降低成本。
　　因此，会出现一个现象，前台变化快而后台变化慢且稳定。所以这个时候，很多为了服务于用户的需求，都堆积在前台，使得前台越来越臃肿，而换一个行业的用户，又需要重新起一个前台，重复工作量大。
　　所以，中台的出现，实际上就可以将臃肿的前台系统中的稳定通用业务能沉降到中台层，恢复前台的响应；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力提取到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的支撑能力。
　　所以，企业在平台化的过程中，需要建设自己的中台层，这里强调一下，是平台化的过程中，而非一定要建设中台。
　　二、笔者接触的伪中台
　　笔者所在公司，今年提出了中台战略，但是笔者很不能理解为什么要做中台。笔者的理由如下：
　　公司的业务都还没有做透，就急于做中台，包装公司的产品；
　　公司业务目前还很简单，技术团队规模并不大，服务需求的响应效率也非常及时，完全没必要建设中台；
　　公司当前的技术团队的技术沉淀不足，无人进行技术架构，进行中台建设。
　　但是，我们产品经理，在无法说服金主爸爸的时候，也不得不按照金主爸爸的要求进行产品设计。
　　在公司内部，直接拉了一个团队过来，建设公司的用户中台、资源中台。
　　虽然笔者没有直接参与中台建设，但是笔者所建设的产品是要直接于中台进行对接的。笔者了解到，建设出来的中台是这样的。
　　1。用户中台
　　首先，笔者的产品需要进行用户注册，根据用户属性不同，注册方式不同，达到的效果也不一样。
　　如果是A类用户，该用户如果需要同时使用2个产品，那么首先要在用户中台进行用户信息注册，然后再到笔者的产品这边，再次录入用户信息。两个产品都需要是手工录入，无法进行同步，而且录入的信息不一致，也会有冲突。
　　如果是B类用户，该用户仅需要使用笔者的产品，那么就可以直接在笔者的产品里面录入用户信息，这里录入之后就会直接同步到用户中台进行用户信息保存。
　　但是如果想要再申请使用其他产品，这里无法在笔者的产品进行权限更改，也无法在用户中台进行权限更改。
　　因为用户中台认为笔者产品同步过来的信息字段不足，需要特殊处理，不允许进行用户权限更改。
　　其次，笔者的产品需要进行登陆，但是登陆的流程需要经历2个关卡。通过笔者的产品登陆入口，是直接进入到用户中心的用户登陆页面。
　　在该页面进行用户登陆，登陆成功之后，由用户中心通知笔者的产品，用户登陆成功，而笔者的产品还需要进行一次登陆验证。因为有可能这个用户是其他产品的用户，但不是笔者产品的用户（所以，这里读者可以考虑下如何建设好用户中台）。
　　最后，笔者的产品如果需要更改用户的账户信息，比如进行手机号变更、微信绑定等，都需要拉着所有使用用户中台的产品进行一起讨论，这样的改动会不会影响到其他产品。
　　笔者认为，中台是服务于产品业务的，既然都建设成了中台，那么就应该屏蔽笔者的产品与其他的产品关联，笔者只是需要使用中台的某些业务服务，而不需要关心和其他产品的关系。
　　2。资源中台
　　资源中台，是负责管理公司所产生的所有供业务使用的资源，包括视频、文档、PPT、Excel，文件包等等。但是这一类的资源，资源中台又要求笔者的产品按照他们的规则进行资源设计。
　　但是，这样的规则又不符合笔者的业务要求。
　　如果，强行按照资源中台的规则去设计的话，实际上，在笔者的产品运行使用过程中，用户反馈是非常糟糕的体验，要求更改资源的设计规则。
　　所以，如果是一个建设失败的伪中台，实际上并不能达到快速响应用户需求的效果，反而会大大降低服务效率，增加产品设计、开发的工作量、增加公司的成本，得不偿失。
　　三、如何适配伪中台做好产品设计
　　笔者还是得适配公司的伪中台进行产品设计，不然产品方案就无法落地，也没有按照公司的大方向走，恐怕产品经理的日子也会很快到头（开个玩笑）。
　　这里笔者就以设计的微信解绑为案例，进行讲解，如何根据伪中台做好产品设计，以及如何把控产品需求。
　　微信解绑原始需求：
　　微信解绑，只能由公司运营在后台进行解绑，禁止B端用户自行进行解绑（为了防止账号公用）；
　　用户更换了手机号，需要重新设置账号内容，进行微信重新绑定，就需要对该用户进行解绑；
　　用户可能绑定的是组织或者部门提供的分配账号，但是需要更换账号绑定，就需要进行微信解绑，但是用户不知道自己绑定的账号是什么；
　　如果运营在笔者产品这边把用户删除了（是允许未解绑进行删除的，但绑定关系还在），用户要求进行微信解绑，无法进行解绑，只能通过刷数据库的方式。
　　这里，就需要结合笔者上诉所说的伪中台的现状，进行设计，毕竟用户的微信账号绑定关系，也是存放在用户中台的。
　　所以，笔者设计的思路就是，尽可能减少和中台的交互！
　　用户中台仅需要提供针对单个或者多个userid进行解绑的接口接口，只需要给笔者的产品返回解绑成功的code码即可。
　　解绑的用户，全部从笔者的产品这边查询出来，不依赖用户中台，在笔者产品中的成员管理列表，增加要给操作解绑和批量解绑。
　　不设计用户的微信绑定状态，原因是用户中台的微信绑定关系不会通知到笔者的产品端，在笔者产品端进行微信解绑的操作可以感知到微信绑定状态。但是，如果微信绑定操作是从其他产品入口进行操作，笔者的产品端是无法及时感知到的，会误导使用者（也就是，笔者也放弃了从用户中台查询用户绑定关系的功能）。
　　产品设计的一点原则是，每一个操作都有响应。因此，笔者设计了一个微信解绑记录给使用者，凡是解绑成功的账户信息都会记录到这个微信解绑记录中。使用者进行解绑操作之后，就能知道哪些账号是解绑成功的，哪些失败了，系统也会有微信解绑操作响应。
　　由于微信的安全性，不会将用户的微信账号信息返回给第三方，所以笔者的产品是无法拿到用户的微信信息的，因此也就无法根据微信账号进行解绑，只能根据绑定的账号信息进行解绑。
　　针对用户不知道自己绑定的账号是什么，所以在用户的账户信息中，增加绑定账号信息内容，提供给用户；用户需要进行解绑，首先登陆查询到绑定的账号信息，然后再将该账号信息告知到公司运营进行解绑。
　　针对删除的用户，笔者无法设计，删除即解除绑定关系的功能在产品里面。因为，有可能该用户使用多个公司产品，TA只是不使用笔者的产品，但依然使用其他产品，那么就会影响用户使用。
　　针对删除用户，为了满足运营，笔者设计了删除记录，可以通过查询账户信息的内容，查询到删除的用户信息；通过重新添加到笔者产品中，进行微信解绑，然后再次删除即可。
　　综上，笔者就根据微信解绑的使用场景，设计了这8条原则，从而满足微信解绑的需要。
　　四、总结
　　笔者实际上是依据问题拆分的方法，将微信解绑的一个大的问题拆解，拆分成多个小场景，并根据每个小场景，设计解决方案，从而解决这个大问题。
　　另外，通过减少和中台的交互，舍弃一些不是必要的需要，从而能够快速的进行版本迭代，响应用户的需求。
　　所以，我们所能做的，就是在大原则下，不断包装自己，进行微创新，提高自己的效率。