如何成功打造一款中台（PaaS）产品

Posted 2020-08-13

       现如今，很多互联网公司在向“大中台，小前台”方向靠拢，通过打造高度可用、高度可定制的中台，来支撑前台业务的快速发展、个性化功能定制。但在构建中台产品（即所谓公司级平台）的时候，如何能成功让一款产品从0到1，即，能顺利诞生，落地，并产生价值呢？这里，我们抛开技术话题，探讨在产品设计规划时要考虑的。

       笔者曾经经历过四次中台产品打造，一次不成功，三次成功。打造一个成功的中台产品，一方面可以提高前台业务部门的效率，减少后续开发投入，还可以通过中台产品，集成前台业务数据，达到数据集成统一接入发布，甚至能发掘潜在客户需求，也有助于对前台需求进行启发。中台成功后，可以在全公司得到重视，进而影响整个公司的技术体系，当然其中个人和团队的获益也是显而易见的；中台不成功，就是没有人用，落不了地，boss认为浪费资源，从而否定产品经理和开发团队的能力（在这儿笔者需要感叹一下，虽然网上经常说开发和产品经理是死敌，其实二者是绑在一根绳上的蚂蚱，再牛逼的开发，如果没有成功落地的产品证明自己，也是空谈技术）。笔者通过复盘总结，得到一些经验和教训，希望读者能引以为鉴、为戒。

       产品诞生前，经常是源于公司前台产品出现大量重复性需求，boss希望能够进行提取抽象，做成中台产品。那么，在这个时候，需要注意遵循2-8法则，即寻找实现20%的功能，来撬动80%的需求场景。那么，具体做法是，产品经理需要收集各个业务线对于此需求的现状、短期的规划、以及未来的考虑。（在这个阶段，最好跟业务线产品经理达成一致，当我们的中台产品上线后，能够立刻接入，一个没有业务线用的中台产品是落不了地的）。通过整理总结各业务线反馈，标出该需求对业务线是否重要？商用价值是否高？未来是否需要？还是无关轻重的？然后，在这些需求中，按照2-8法则，找出撬动80%场景的那20%的功能，然后作为产品的MVP（最小可交付产品）推动实现。（一定要注意，实现尽可能少的功能，满足尽可能多价值高的业务场景）

       设计和开发阶段，产品和架构师（或者主程）必须达到深入沟通，让开发深入理解到此中台产品解决业务线什么场景，核心需求是什么，产品定位是什么，未来会向哪些方向发展。MVP能解决业务线哪些场景，还有哪些场景未解决。架构师基于此，选择合适的技术架构，封装好核心，对未来的扩展留出接口。好的中台产品，往往能无限扩展，比如快速开发平台（Bei...Clou.）能做出无限多的增删改查表单列表功能、前端组件化平台（Pa..Buil...）能搭建出无穷多的页面，自动化测试框架（BAT）能实现无限多的业务线自动化测试集。那么，就需要架构师在这时，设计好中台产品的核心架构，业务线如何使用，以及针对特殊个性化需求的扩展能力。

       一旦MVP上线（第一版），首先要做的不是继续增加功能满足更多的场景。而是要放慢开发脚步，转而去推动业务线进行接入。为什么呢？因为新需求的开发，势必会让中台产品变得“重”（臃肿），增加业务线或客户的使用成本，让中台代码变得复杂难以维护；而此时MVP上线，正是需要向boss和公司业务线展示产品价值的时候，而中台价值的体现，是从业务线那儿得到的，这也关系到boss是否能继续支持投入做这个产品，从而达到良性循环。如果能有多个业务线使用中台产品搭建出前台业务，那么，就可以证明中台确实能够提升开发效率，降低成本，能落地。如果一味逼开发上线新功能，往往团队看不到产品价值，有挫败感，业务线感觉不到你的存在，boss不认可从而不继续投入，导致恶行循环。。

       打造明星客户作为标杆。平台上线后，想要在公司一炮走红，或者让boss一眼就能看到产品价值，认为这是个牛逼的应用，必须打造出来一个标杆产品。以在前端组件化平台（Pa..Buil...）基础上打造个性化主页（Profi..）为例，当时为了推广中台，而推出了Profi..产品。而这个产品让大家眼前一亮，进而后续各业务线产品经理（可能本来没这需求的业务线）理解Pa..Buil...的作用，进而产生把Pa..Buil...应用在自己产品内的想法。

       当业务线开始试用后，势必会提出各种各样的花式需求。。此时，不管是产品还是开发，一定要有拒绝能力，能表示“这个功能暂时支撑不了”，或者通过什么方式扩展，对于业务线需求不能照单全收。要让业务线在中台的设计规范内进行扩展。不能为了实现某个业务需求，而在中台设计上“巧妙”实现，甚至hack中台产品（如果一定要做，也要明确跟业务线表示，中台升级的时候未必支持）。否则，当你的中台升级时，对于老数据的兼容会让你头疼死。

       中台的开发节奏一定要慢，要“小步慢跑”，要留出时间重构代码，填平技术债，不要做过多的临时方案。产品在提出新需求前，需要考虑好对之前业务的影响，对现有各业务线的影响。别出现中台升级，前台挂掉的情况。最好有专门的人去支撑业务线对接，解答业务使用中的问题（没有的话，team leader充当也行）。

 

注意：
第一戒，禁止去满足业务线所有场景。。做平台的产品，一定要懂得取舍，有些功能属于平台必须提供支撑业务线nocode（拿来即用，或者通过简单配置不接触代码即可满足场景）；有些功能是平台提供扩展接口让业务线轻便扩展即可；有些功能是平台不支持，需要业务线自己开发。

第二戒，明确中台产品边界，禁止把业务功能渗透到中台产品中。比如，BAT的逻辑是启动Selenium、生成报表、提供版本控制、解析运行脚本、异常封装处理，而“打开登录页面”这种代码，不能出现在BAT的产品代码中。再比如，人才VS中，加载对比项、调用业务接口获取数据、业务接口超时自动开车是人才对比的功能，而加载测评活动列表绝对不能出现在人才对比框架中。这里需要注意，不混入业务，并不是说中台产品运行时没有业务，那就失去了中台的意义了。而是，不要把业务逻辑混到中台逻辑里。简言之，中台必须跟前台严格划清界限，我的是我的，你的是你的，你的逻辑不要进入。当中台产品中，出现对业务的特殊处理，就需要反思，是不是中台产品设计的不够好，需要特殊判断才能支撑业务。

 

总结：
1. 规划阶段，明确业务线现有需求，提取抽象中台MVP，满足2-8法则。
2. 尽早跟业务线约定好MVP上线时间，以及业务线使用时间。
3. 设计开发阶段，跟架构师讲透产品定位、扩展点以及发展方向，架构上要明确业务如何使用，如何扩展。
4. 产品MVP上线后，要推动业务应用，让中台产品落地，不要急于扩展新功能。
5. 后续迭代，要小步慢跑，留出时间重构、填技术债、解决业务问题。