盒马数据产品反思

首先吐槽算法可视化项目,其本质上就是一种传统的cube的可视化类型;唯一不同的是一颗可展开互动的树结构。树会包含预警展示信息(理论上是森林结构)。

产品的开发链路为 产品->(交互)->UI->研发。这个开发链路是盒马惯用的开发模式,但是由于盒马的交互/UI风格非常传统保守,且极度匮乏数据产品的知识,基本上在设计产品时采用在图表库中查找能用的图标来强行套用。很多图标对数据的展示能力极度匮乏。与此同时,基于图表的思考方式会极大程度降低分析人员对数据与图形的理解能力(这一点在GoG中有提到)。也导致G2本身的价值完全丧失,也就是集团消耗高成本投资的新式图形系统资产完全被浪费掉,同时会使得底层开发人员对G2本身产生极大的质疑,在技术选型上内心甚至会更倾向于echarts。

数据产品,在进入研发前,必须由数据分析/数据可视化(来自通用式BI/GS一线研发团队)的专业人员进行产品原型的设计。这一环节也是反馈到集团图形系统研究的重要环节,帮助构建图形系统的开发理论与方法。

非可视化开发专业人员在进行数据可视化时,往往缺乏对任意数据情况下的可视化效果的思考。对于数据特性(数据量、特征值、维度、度量、层级结构)发生变化时不能给出可视化自动切换或检测的边界条件。使得可视化产出是“死”的,不够灵活。对于什么原因会导致可视化性能降低、如何避免此问题完全不知,所以在可视化设计这一环节,必须交由专业的可视化开发人员进行。否则团队永远难以积累可视化开发经验,只是在自己的安逸区开发着马马虎虎可以应付交差的产品。

另外,数盒竟无法支持这样一个产品,而需要专门配置开发人员,为何不反思数盒在此的局限性?这也是数盒团队中缺少一个专业的可视化leader来持续跟进优化产品,单纯只是对一些用户提出的必须解决的需求逐个解决,不思考其中的共同性,不去总结,不去反思。那么这个产品又死掉了。

数盒究竟能否成员盒马内部可视化团队中的可视化开发人员的原型开发工具,tableau是否可以,数盒与tableau在原型产品开发上的区别在哪里,各自的优势劣势在哪里?

当然,一味的抱怨是没有用的,这里对目前来说更为有价值的反思是自身如何对当前环境做出决策。首先,研究数盒目前内部有价值的部分,结合盒马的业务做出客观的分析。然后看哪些优势是可以集成到canary中的。思考如何设计GoG的图形系统,开发GoG目前所遇到的局限性在哪里,有哪些部分是G2导致的,哪些不是,其他可视化库能否解决该问题,不能的话,是为什么,自己手动解决该问题的难度评估。

另外,在这样的环境中,如何尽力影响团队。在当前体制下,这种影响会受到哪些阻碍,有什么方法减小这些阻碍的影响。

Author: Lobay Kanna
Link: http://lobay.moe/2019/03/25/2019-3-25/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.