在很多大数据公司里,不论大数据项目的大小,技术部门和业务部门总有或多或少的矛盾。
我们深知:技术服务于业务,业务驱动技术去发展,两者密不可分。换句话来说,技术帮助业务去解决问题,业务给技术一个机会去证明价值,两者相辅相成。不过在大多数公司里,技术的存在感会弱于业务,这可能会让你感到不舒服,但它就是一个不争的事实。
作为一个技术人,你认为自己很厉害。但是如果业务人员和你沟通协作起来效果很差,或者认为你的业务能力很薄弱的话,他们很有可能就会否定了你的成果,这种结局在一定程度上也会影响你的工作热情和能力提升。
而且平台运营的决策权在于业务人员手里,在一些业务人员看来,需求是他们从实战运营中提出来的,最终的落地也需要他们亲自去实施,至于如何去实现这个想法,那就交给技术人员去开发好了,他们负责把关验收就行。
所以,在真正面对这样的机会时,一定要多关心业务方的需求,理解业务的痛点,特别是做数据相关的项目时,试错成本会很高,业务方也没有耐心去给你重复调整的时间,毕竟业务每天都在变化。如果把握错了业务,这个项目极大可能性会泡汤。这里举一些反面的例子。
① 数据中心想单独去开发一套「算法平台」,借助Spark的计算优势,同时封装一些算法库去给业务部门提供流程化的挖掘功能,支持页面交互来使用,支持数据可视化。再开放R和Python的接口,提供业务方的自定义建模。
说简单一些就像把SPSS软件的功能重新开发一遍,接入大量的数据源,再配上一个高速的计算引擎。
这个构思看起来很美好,但是却很难实施和落地,因为业务方真正的需求不在于这,所谓的数据挖掘也没有想象中的如此简单,况且本地计算机对生产环境的数据访问被堡垒机所切断,集群资源的隔离也是需要考虑的问题。
总而言之,即使你耗尽全力去开发出「算法平台」,但却很难去派上用场,因为业务方的痛点可能只是想让你开放数据接口,让他们所关心的用户数据定期同步到自己的数据库中,再选择自己擅长的工具去构建模型。
② 再谈谈「标签系统」的产品,数据中心做厌烦了数据报表,决定从用户画像的角度做一个底层标签系统,横向可以不断扩展用户标签,且支持单个标签的实时更新。对跨部门可以提供数据服务,从而支持线上的用户运营和营销工作。
这个构思同样看似美好,但如果没有理解业务需求的话,难免又被沦落为一张数据报表的结局,同样没有多大价值。
我了解下来,很多做「标签系统」的平台,一张宽表包含了500多个标签,不定期还有新的业务指标添加进来,而这些字段大多数都来源于业务的日常营销需求中,特别零散、初级和临时。如果你是做业务运营的,面对这500多个字段,你很难选择精准的标签去做营销。
所以说,看起来是支撑线上用户做营销,但却没有理解用户画像的核心,甚至是没有正确去理解和引导业务的需求,而业务方只关心如何去提升营销效果。所以正确的做法就是专注一些挖掘性质的标签开发,从根本上去解决运营的痛点营销需求。
③ 我所看到的,还有一些失败的项目,比如反欺诈系统、知识图谱、用户全生命周期、智能客服等等,基本都是在自娱自乐的专研。
「数据中心」想跳出以往的「BI报表」体系去做一些分析型或决策型的数据产品,这个出发点本身没有错。但是却因为没有经验,只想着数据创新,很少去主动的调研业务需求,去理解业务痛点,去构思应用场景。这样的话,整个部门所做的一堆数据项目,可能就会陷入尴尬的局面,要么产品开发不出来,要么产品解决不了业务痛点,要么产品的决策效果不佳。
大方向如果没有把握正确,何谈数据价值的探索
转载自网络 不用于商业宣传 版权归原作者所有,侵权删。