【精】关于组件化、可视化的思考

别的公司是如何做数据可视化的？

通用型

这种一般会组建一个专门的团队，和我们现在类似。该团队对外的输出就是可视化作图组件，比如折线图、柱状图、饼图之类的。

这种团队一般会在组件成熟后，逐渐减少团队人员，只留下一两个维护人员。

业务型

和具体业务绑定，只对自己团队的业务负责，不对其他团队负责。

输出的一般是具体的业务可视化成果，比如企查查的关系图、全历史的关系图这种。

一般是不怎么考虑通用性的。

而数据可视化，大部分都是走的这个方向，和业务绑定。像数据可视化的书籍，也是按照这个思路编写的，通用的只是方法，而不是结果。

创意 VS 通用

通用意味着必须有规范，要考虑不同的场景和需求，也就意味着一定是偏抽象的，不能和具体业务绑定。其实也就意味着会有诸多的限制。

创意则是无拘无束(可能会有一些限制，但是比较少)，更偏向于自由。

因此创意和通用，本身就是存在矛盾的。

现在公司期望我们团队能够输出通用的可视化成果来改善公司全部产品的视觉效果，这个期望本身是存在矛盾的。如何解决这个矛盾，是 20 年的关键问题。

前端组件和后端服务的差异

可控性

后端服务，必须借助服务器资源，通过通信协议(比如 http、tcp、udp 等)对外提供，这样服务的控制权在服务提供方手里，提供方可以很方便的知道哪些业务用了这个服务、使用量是多少等等。而且一般同一个业务，都是由同一个部门提供的(比如搜索业务就肯定是问财搜索组提供的)，其他人提供不了，所以你没得选，只能用这个服务。因此针对服务来说，服务提供方=垄断型卖家，服务使用方=买家。

前端组件，用不用完全看前端业务方，如果对方不愿意，你是不知道具体这个组件的使用情况的；而且前端效果，别人不用你的组件，还可以用其他人的组件，还可以自己写，因此组件提供方不具备垄断性，可控性很弱。

差异性

后端服务都是纯数据服务，不涉及用户界面，因此同样的业务，差异性非常小。这也就让后端服务的通用性变得很强，很容易实施。

前端组件则是直面用户的，同样的业务，在不同的产品上，因为产品经理/设计师可能不一样，最终呈现出来的效果也可能会不一样。这就让前端组件的通用性和一致性难以实施下去。

策略

牢记：做强需求(大家都必须用的，或者某些业务的核心功能，比如 docker、语音)，做可量化的需求，做领导认可的需求。

数据可视化专家

我们必须培养一个可视化专家，不管是外招还是内部培养。

一个能在专业性上 KO 掉其他所有人的专家。这是我们推行可视化的关键。

通用组件库

我们提供(可视化组件库)，或者我们推动别人维护和提供(常规 UI 组件库，让手炒团队维护)。

价值体现：应用到的业务功能数量、IP、PV、UV

业务可视化

针对产品：我们负责对需求进行汇总分析，找出里面可以可视化的点，提供可视化想法。

针对设计：提供可视化设计方面的培训，提升设计人员的可视化设计能力。

针对开发：提供可视化开发方面的培训，提升开发人员的前端可视化能力。

价值体现：

1、数据可视化系统(输入需求，输出可视化方案)

2、案例数量、用户调研、竞品分析

数据可视化系统

这个是为了先解决产品设计时，没想到可视化的这个问题；后续再解决可视化做得好不好的问题。

类似语音组，他们提供的其实就是一个系统，输入文字，输出语音。

我们可视化也是一样的，要想大范围扩散，就得形成系统，输入需求，输出可视化方案，甚至是可视化效果。

这个可以当成一个产品来做(招一个产品经理)，把要解决的问题开发成产品功能，比如：

输入的需求应该是什么格式的，要涵盖哪些内容？

怎么输入？人工？还是程序解析文档？

怎么将可视化的理论、原则、方法程序化？

具体输出什么内容？如何输出？

……

我们可以先学习下外面的可视化创业公司，比如数可视是怎么做的。