大数据学习之抓不住业务痛点，何谈技术价值

在很多大数据公司里，不论大数据项目的大小，技术部门和业务部门总有或多或少的矛盾。本文由科多大数据的张老师分享。

我们深知：技术服务于业务，业务驱动技术去发展，两者密不可分。换句话来说，技术帮助业务去解决问题，业务给技术一个机会去证明价值，两者相辅相成。不过在大多数公司里，技术的存在感会弱于业务，这可能会让你感到不舒服，但它就是一个不争的事实。

作为一个技术人，你认为自己很厉害。但是如果业务人员和你沟通协作起来效果很差，或者认为你的业务能力很薄弱的话，他们很有可能就会否定了你的成果，这种结局在一定程度上也会影响你的工作热情和能力提升。

而且平台运营的决策权在于业务人员手里，在一些业务人员看来，需求是他们从实战运营中提出来的，最终的落地也需要他们亲自去实施，至于如何去实现这个想法，那就交给技术人员去开发好了，他们负责把关验收就行。

所以，在真正面对这样的机会时，一定要多关心业务方的需求，理解业务的痛点，特别是做数据相关的项目时，试错成本会很高，业务方也没有耐心去给你重复调整的时间，毕竟业务每天都在变化。如果把握错了业务，这个项目极大可能性会泡汤。这里举一些反面的例子。

①数据中心想单独去开发一套「算法平台」，借助Spark的计算优势，同时封装一些算法库去给业务部门提供流程化的挖掘功能，支持页面交互来使用，支持数据可视化。再开放R和Python的接口，提供业务方的自定义建模。

说简单一些就像把SPSS软件的功能重新开发一遍，接入大量的数据源，再配上一个高速的计算引擎。

这个构思看起来很美好，但是却很难实施和落地，因为业务方真正的需求不在于这，所谓的数据挖掘也没有想象中的如此简单，况且本地计算机对生产环境的数据访问被堡垒机所切断，集群资源的隔离也是需要考虑的问题。

总而言之，即使你耗尽全力去开发出「算法平台」，但却很难去派上用场，因为业务方的痛点可能只是想让你开放数据接口，让他们所关心的用户数据定期同步到自己的数据库中，再选择自己擅长的工具去构建模型。

②再谈谈「标签系统」的产品，数据中心做厌烦了数据报表，决定从用户画像的角度做一个底层标签系统，横向可以不断扩展用户标签，且支持单个标签的实时更新。对跨部门可以提供数据服务，从而支持线上的用户运营和营销工作。

这个构思同样看似美好，但如果没有理解业务需求的话，难免又被沦落为一张数据报表的结局，同样没有多大价值。

我了解下来，很多做「标签系统」的平台，一张宽表包含了500多个标签，不定期还有新的业务指标添加进来，而这些字段大多数都来源于业务的日常营销需求中，特别零散、初级和临时。如果你是做业务运营的，面对这500多个字段，你很难选择精准的标签去做营销。

所以说，看起来是支撑线上用户做营销，但却没有理解用户画像的核心，甚至是没有正确去理解和引导业务的需求，而业务方只关心如何去提升营销效果。所以正确的做法就是专注一些挖掘性质的标签开发，从根本上去解决运营的痛点营销需求。

③我所看到的，还有一些失败的项目，比如反欺诈系统、知识图谱、用户全生命周期、智能客服等等，基本都是在自娱自乐的专研。

「数据中心」想跳出以往的「BI报表」体系去做一些分析型或决策型的数据产品，这个出发点本身没有错。但是却因为没有经验，只想着数据创新，很少去主动的调研业务需求，去理解业务痛点，去构思应用场景。这样的话，整个部门所做的一堆数据项目，可能就会陷入尴尬的局面，要么产品开发不出来，要么产品解决不了业务痛点，要么产品的决策效果不佳。

大方向如果没有把握正确，何谈数据价值的探索