记数据建模研发起源
从一个刑警支队的真实调研说起
"如果数据分析跟计算器一样就好了"
数年前,某市公安局投资两千余万元建设大数据平台。平台建成了,一线民警却怨声载道——数据被统一收走后,上级部门不懂业务、不响应需求,很多业务陷入半停滞状态。
负责开发的上市公司派驻80多人现场定制开发,仍然无法满足一线海量的分析需求。公安业务数据分析需求复杂、专业性强,每个案子都不一样,定制开发的方式既不经济、也无法规模化复制。
在一次与刑警支队的调研沟通中,一线民警描述了日常工作的真实困境:
"有任务来了,先找工程师讲一个小时业务逻辑,然后工程师去写代码。第一次得到的分析结果往往不正确,工程师对思路不完全理解。再讲思路、再修正算法,这样往返很多次才可能得到正确结果。我们讲思路很累,工程师加班更辛苦。"
民警还提到,即使企业来调研需求,意义也不大——"我给你讲什么是区域性犯罪,讲一个小时也不一定讲明白,即使做出了这个功能,可能只会用一次,以后再也不用了,因为每个案子都不一样。"
"我们30~40岁的警察,基本上都是人民公安大学毕业,破案思路、业务能力是很强的,只是不会写程序而已。如果数据分析能跟计算器一样,给几个计算符号我们可以自己算是最理想的。我们再也不用找你们去讲一堆业务逻辑,讲多了还泄密。"
这段话直接点燃了可视化建模最初的产品构想——把复杂的代码变成图形化的"计算符号",让懂业务的人自己动手。
授之以渔,不如授之以渔
这次调研带来了深刻的启发:到底做怎样的分析场景,只有一线业务人员最清楚。不论多专业的软件公司,都不可能替代最终用户成为业务专家。数据是原材料,不同思路可以产生不同结果——不可能为每一个分析需求开发一个功能。
定制开发的困境是双向的:开发本身很慢,不可能做到及时响应;同时用户也无法承受海量定制的价格。如果一个小的分析功能要1千元,1千个需求就是1百万元——而一个单位每月的统计需求可能远超千个。
方向明确了:授之以渔不如授之以渔。给一线人员一个自己能用的数据分析工具,他们获得了解放,企业也从无尽的需求定制中解脱出来。可视化建模的产品理念,诞生于这一刻。
一线用户给我们的选型标准
在一次与情报指挥中心领导的交流中,对方给出了大数据分析产品的选型四要素。这些标准来自一线用户的真实感受,至今仍是桐果云产品设计的核心准则: