在To G行业，有三种大型平台：数据平台、业务中台和运营平台，不同平台的重点和设计都不一样。这篇文章，作者总结了自身的设计经验，给大家讲解如何通过平台来支撑产品的设计和发展。
做产品这事儿，时间长了，你就会有种感觉：业务需求像滚雪球一样越滚越大，产品功能设计也跟着膨胀，销售的需求更是变得比翻书还快。单一的产品？哼，根本满足不了市场这个大胃王！老板经常一句话就把你打回原形：“这个产品和之前那个差不多，赶紧给我做出来！”
于是，随着做产品的深入，我们就开始要进入到平台的设计范畴，通过平台来支撑产品的设计和发展。
那么，G端行业做产品，主要涉及到哪些平台呢？笔者这里就给大家晒晒我们做过的几个平台，顺便总结点设计经验，让大家一起少走弯路，多走花路！
政务领域的信息化产品，买单的不是使用的。
为此，就会存在两类用户对产品的不同需求。业务部门的产品需求自然不用多讲，就是产品要好用不要给他增加工作负担，别给他找麻烦。而领导层（也就是决定买单的人）他并不太关心产品是不是好用，毕竟他也不用，他更关心的是产品能不能被看到，能不能体现出政绩成效。
采购硬件产品看得见、摸得着；建设办案用房能参观、能体验；唯独软件产品，没有实体东西，就一个网址账号，很难让领导感知到这东西有啥好。
虽然业务系统只是服务于业务部门，那是不是就只需要把产品功能做好就可以。很多产品经理都是这种“终端用户”思维，也是单纯的“匠人思维”，不能说这种思维不好，只能说更适合C端产品。对于G端产品会有一些不一样，如何把产品“包装”出来，让领导可以直观的感受到，对于政府单位的客户来讲，“看起来不错”比“用起来不错”更重要。
我之前就纳闷，为什么有些客户的微信公众号啥内容都往外发。就是带个无人机出去飞了一圈，没有收集到有效的线索，没有针对某个案件的取证，真的就是带出去飞了一圈，就这么个事情也得整两张照片写篇新闻在单位公众号中发出来。后来我想明白一点，干了活就得让大家知道，就得让领导看到。
回到产品设计的角度来讲，只要你在做某个业务系统设计，就一定要考虑规划上一个数据平台，这个数据平台也许对业务部门没啥卵用，但是对领导特别有用。
数据平台即是让工作成果可以被单位的领导看到，也是让单位的领导可以给外部参观考察的领导做成果介绍。
当然，部门领导也有对业务监督管理的需要，有数据可以客观且直观的呈现出来，还是要方便不少。即可以及时发现风险、主动干预，也可以作为分析决策的依据，还便于作出成绩向上报喜。一举多得。你看，数据平台是不是成了一种“刚需”。
在TOG市场，客户已经不再满足于二维的数据图表，开始对贴合“数字孪生”概念，采用虚实动静结合的3D数据可视化趋之若鹜。
从过往给客户做产品演示收到的反馈，和近些年各厂家做过的数据平台案例来看，数据平台设计在表意清晰、维度正确、布局合理的基础上，高端、炫酷的可视化效果，会更容易博取用户的眼球，获得用户的赞许，在产品竞争中脱颖而出、顺利中标。
那么，怎么让数据平台体现出酷炫的效果呢？
基于看过的各种可视化数据平台，总结出一些共同的特性：
牛逼的视觉呈现是保障数据平台效果酷炫的首要关键，不过这也意味着要运用各种有含金量的技术来支持呈现。以下这段话可以用来做数据平台介绍的时候，起到给“领导整不会、听不懂”的效果使用。
“通过底层基于光流法的短临预报技术，神经网络深度学习技术，三线性插值的回归算法以及基于WebGL的3D可视化技术，实现数据可视化平台的超酷炫效果。”
数据平台不仅仅是展示各种酷炫的效果，也不是简单的进行数据图表的罗列，而是要通过数据分析，挖掘出数据所蕴含的规律、态势、结论。切实帮助客户发现数据背后隐藏的问题，预测业务发展的潜在规律。
因此，在设计数据平台之前，需要充分的客户调研，弄清楚：需要构建什么样的数据平台？构建数据平台希望解决什么问题，起到什么效果，达成什么目的？
我认为，从G端产品过往的设计经验来看，数据平台主要是满足三个方面的需求：数据分析统计、流程监控预警、业务实时指挥。
1）数据分析统计：数据统计的主要目的就是帮助领导通过数据全面了解业务，科学进行决策。在做功能设计的时候，就需要基于客户的目的、需要解决的问题，思考通过那些数据指标可以达到用户想要的东西。
2）流程监控预警：在G端场景中，通过监控实现对业务数据异常预警和分析定位，帮助领导及时采取控制措施，即保障业务损失降至最低，影响范围缩至最小。
可以做到的监控场景有哪些呢？
3）业务实时指挥：包括即时指挥调度、任务生成与下发、任何跟踪及执行情况反馈等功能。可以支持文书、图像、音视频等多种指挥手段，可以提供外部系统数据接入的标准通信协议。
可以有哪些设备应用于指挥调度呢？
上线发展了一年后的G端产品，迭代的成本会逐年增加（当然上线一年多也没卖出去几套的产品，不在我这个话题的讨论范围内）。并且，产品内部要保证各业务线产品功能的一致性也变得越来越不容易。为解决这一问题，中台、组件会是你的不二之选。
业务中台的建设就是针对各业务条线的产品进行抽象和设计，让产品就像搭积木一样灵活组建。基于重复利用现成产品的组件，快速组装出新的产品，从而节约产品开发成本，高效支撑新业务条线产品的开展。
由于互联网行业多年来信奉的“快鱼吃慢鱼”模式，大家在做产品功能优先级排序的时候，往往会倾向于去做业务价值最明显的，可以最快上线带来产品收益的事项。而业务中台属于重要但不紧急的事项，自然就不在大家的任务序列之中。
那么，为什么还要去做业务中台的设计呢？有如下几点思考：
业务中台产品设计初期，没有必要为未来不确定的事情提前做过多的布局，适度的业务逻辑抽象，弹性的复用功能设计即可。因为很有可能未来根本用不到，掉进了过度设计的坑里。
在没有明确的产品收益的情况下，强行采用中台理念设计，不仅会造成业务系统设计的过于复杂，还可能会给产品的不好用，带来客户怨气值的加压加码，气到原地爆炸。
具体应该怎么做呢？
这部分内容主要是涉及到研发人员需要了解的，当然，如果你想要成为一个全能型的产品经理，能够和研发同学在一个认知水平上展开对话，那么，你就有必要也看一看。
在业务流转过程中，通过对业务对象模型的梳理和提取，建立不同的服务中心，通过各服务中心提供的服务能力支撑前台各类业务场景。
这些服务中心不同于单个系统的模块化，每个服务中心所提供的服务能力并不是单单给前台的某一个业务系统或场景使用提供服务，而是对前台所有的场景进行支撑。
从技术架构设计上，需要考虑到如下几点。
当前一些aPaaS厂商，如国内的明道云、简道云、氚云等，用户通过可视化的系统页面，无需代码即可从零搭建出许多业务逻辑比较简单且通用的企业级应用。包括，我们常用的钉钉，也是可以任何组合搭建出你需要的各种办公审批流程。
零代码或低代码的系统设计已经成为了做B端行业应用的主流，G端其实也属于B端产品的一个分支，为此，我们应该适应潮流、跟上时代，对于存在多样化业务场景的流程，进行可配置化设计。
做运营平台的设计，关键要梳理清楚哪些人做哪些事，以及人和事、人和人、事和事之间的联系。从而输出业务规则和业务流程，不同业务属性，有不同的任务特性，通过业务属性条件的设置来实现多样化的任务配置。
在产品的销售过程中，不可避免的会收到各种个性化的需求，其中绝大部分的需求都是对产品界面效果、功能布局、文字图标的调整。毕竟客户也不懂怎么设计产品功能，只能是对看得到的页面指点几下，做出和别人不一样的产品效果，好给领导汇报自己选购产品也是费了不少心思。
因此，在产品的设计上（特别是互联网端的产品），就有必要在后台设计界面的个性化配置功能。这样既可以快速满足客户的需求，也可以减少研发投入的成本，还便于做产品的版本管理。我们在宣传服务云产品上，已经实现了PC端首页的个性化配置。指南针产品，接下来应该也需要做这样的设计。
如下的一些界面元素可以考虑做自定义配置：
为了减少交付实施的工作量，可以做好一些默认的配置。当然，这些配置的功能尽可能都要在我们内部的运营系统上，不要让客户去做配置的操作，减少客户的工作，也是便于我们做集中的管理。
当前G端市场上的绝大多数产品都是划分了基础版、标准版、高级版两个或三个型号版本，甚至还有基于功能模块任意组合搭配的自定义版本。这样做的目的主要是便于制定出不同档次的产品报价，以便于满足省级、市级和区县级不同级别客户的采购需要。
要满足这样的多版本销售，关键还是在产品功能上做出不同版本的区分，因此，就得设计好产品的功能模块要支持自定义配置。
要做好产品功能的自定义配置，需要把握住如下几个原则：
如果产品需要区分出不同的版本销售，在产品设计之初就得做好功能菜单的配置化设计。
政务信息化产品的设计不仅要满足业务部门的实际需求，更要从领导层的视角出发，打造出直观、酷炫且实用的数据平台。同时，通过业务中台的组件化和服务化设计，实现产品的快速响应和稳定迭代。最后，运营平台的配置化设计将满足客户的多样化需求和个性化体验，为产品的灵活销售提供有力支持。
没有“一招吃遍天”的打法，只有不断踩坑之后总结出来的一些教训。
本文由@武林 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Pixabay，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。