大家都在炒AI和大数据,落地的事儿有人做吗?观点

来源:AI前线 / 作者:杨雷 / 2018-08-06 14:34
最近读到一篇文章"SQL 足以解决你的问题,别动不动就是机器学习",教我们落地之法,在这个浮躁的世界中,犹如一股清流,实在大快人心。就像皇帝的新衣一样,终于有人说了出来。
几乎每个企业都期望建立自己的完善的合体的数据体系,但成功的例子并不多。本文希望用一些实践阐述以下几个观点:

- 数据产品应该朴实无华

- 浮躁的认知会有大麻烦

- 如何正确认识自己,如何敏捷
前  言

最近读到一篇文章"SQL 足以解决你的问题,别动不动就是机器学习",教我们落地之法,在这个浮躁的世界中,犹如一股清流,实在大快人心。就像皇帝的新衣一样,终于有人说了出来。

有位做供应链数据分析的朋友很开心的说正在创业中,打算在供应链金融方面有一番作为,用神经网络的方法做用户画像,然后进行市场精准营销。作者工科数学博士一枚,每每看到有人探讨这么实际应用的东西,都觉得汗颜(自己不懂)与欣慰(越来越多人参与)并存,以至于给我已经是博导的师姐说,“好好鼓励你的弟子,数学系的春天来了!”

但是,要泼一下冷水,想必每个投身于大数据、人工智能的人士都碰到过某个瓶颈阶段,就是想要更深入了解原理的时候,那些公式算法实在是看不懂啊。每次我只能劝慰说,就当那是个黑盒,你只要知道输入输出,就能得到想要的结果。难道我要告诉实情其实是,最快你得花费半年到一年时间恶补数学知识,才能知道什么时候用模式识别,什么时候用小波分形,什么时候那个东西是动态规划······

这篇文章,继续泼冷水,“如果所有人都去做人工智能了,落地的事情谁来做?”,好比烧饭师傅都去研究自动炒菜机,在“懒人创造新的世界”之前,世界上的人都已经饿死了。认清自己手头要做的事情,比展望未来更关键,至少你能先存活下来。

为什么要做数据产品

不论是初创、上升期、转型还是平台期的企业,回答好自己是谁,为谁服务,服务得如何,怎样更好的获利这几个问题,离不开数据。

从产品的角度看数据产品:

  • Why?很明显,企业需要看数据,用户需要看数据。不管你是做战略计划、公司愿景、企业架构、运维治理、扩张市场、客户流失、目标营销,甚至做 OKR、KSF、KPI、威士忌分析,或者告诉你的老板或下属做得有多成功或,,,多失败,你需要数据,这是你的价值。

  • What?When?Who?这是你的内容(范围和服务),你的视野(过程和效率),你的上帝(细分)。

到底怎样做?一个笨手笨脚的人(Klutz)都告诉你可以这样做:

  • KNOW 找准自己的定位,企业用户尚在起步阶段,是没有能力去索取更多的数据的。此外,还需要精通业务流程,数据流离不开业务流,不论你是 To B 还是 To C,把握好用户痛点和需求,是首要的。

  • LIGHT 不用再介绍一次 KISS 原则了吧。保持轻装上阵吧,那样就算死,也死得轻松。

  • USE 动手吧,"想总是问题,做才是答案"。试错是如此的关键,一个企业是否有这个价值观,甚至影响了是否最终的成败。后面会提到完美主义者,是如何总是在关键时候触礁的。

  • TELL  告诉你的用户或老板,这个产品现在该有多糟糕,虽然你和它已经竭尽全力在工作。奇迹是,他们总会站在你这边。

  • ZANY 莎士比亚造了这个词“滑稽”,是让我们轻松点,数据人已经很累了。“数据科学家”,这个称号显然已经违背了这个原则,背负了太多。我更倾向于数据分析师,人人皆可当之。

数据产品的各种"圈钱"模式

让我们先来看看领英 2017 的一个岗位增长报告,谁说大数据已死的?

曾几何时,作为数据库管理员或者 java 工程师的你也动心想深入了解下何为数据科学,何为机器学习,何为大数据?别犹豫,其他人早就开始了(来自领英 2018 的行业报告):

 动辄“

一个很有趣的讨论,来自我和一位 BAT 数据分析师:  

  • “大”代表,首先,很 fashion 了。

  • “大”代表平台很大,数据很多。

  • “大”代表业务应用很广,至少传统方式做不了了。

  • “大”代表 0 到 1 已经平安度过,深挖广种是时候了。

  • “大”代表,有很多钱做事,需要你也很“贵”才行。

自然,我们在每一个评价后面,跟了一个“?”。但不管,就像项目竞标最好有个博士牵头一样,“大”代表着,新来的老板很喜欢。

 动辄“智能

同样,新来的老板更喜欢另外一个词“智能”,毋庸置疑的 Top One。作为数学专业出身的我,从来没想到过会有那么多人来问“神经网络”的算法怎样才能实现。他们都,疯了么?还是世上本无路,走的人多了,就有路了。每次我都用这个来安慰自己,这是一条光明之路,需要越来越多的人前仆后继,不管你扛着的是步枪还是大炮。

  • 图像处理,落地了。

  • 语音处理,落地了。

  • 还有?

我们是如何失败的
 失败案例一:零售行业中的零库存

在本世纪初期,新零售流行“一单到底”和“零库存”这两个东西,愿望是美好的。我“不幸”也参与了其中对库存优化的计划中,那是一个零售业的 IT 供应商,为打造这个美好的愿景老板给了我一个艰巨的任务,3 个月拿出一个算法实现先进的补货策略。

于是,加班加点,带着一群人搜索学习了各种算法对进货渠道、缺货周期、日销售情况进行了分析,最终开发出一个几千行代码几十个输入变量的程序,准备上马。

这时,老板问了一句,“这算法准么? 某便利店商品 A 今天销售 20 件,库存只有 5 件,你算出来要补进 30 件,我排不过来货运啊?而且这两天卖得好是因为天热,过几天下雨咋办?”

最后,老板决定,还是按照老办法,盘点时由店长决定,快断货的时候补一周的货,灵活处理。

 失败案例二:仓储行业中的自动化监控

2005 年,作为方案架构师,“有幸”参与了某大型跨国物流集团仓储中心产能监控系统设计。系统要求很简单,监控每个节点的容量、吞吐、以及排队情况,提供优化方案改善效率。

不知道谁头脑一热,前期要做一个非常漂亮的 3D 效果的模拟系统,还能显示每个热点并进行预警。于是乎,一个加大伯克利的博士(现不知所踪),一个清华的博士(现某外资银行做算法),一个人大的硕士(现某金融系统分析员),一个交大博士(现某行业产品经理),开始学习 Photoshop 和 AutoCAD。悲惨的一幕随着数据从客户传来而开始,2000 多个线程并发跑,还是 B/S 的 3D 效果,性能可想而知。

被客户拿掉后,大家回顾说,还不如老老实实用 Excel 做几个表格和图形,能反映性能状态,发送问题原因,再研究下优化算法其实并不难。

 失败案例三:教育行业中进度控制

这是一个 CRM 体系再造项目,用 Salesforce 替换原有老系统,作者参与的是其中 Business Intelligence 系统的再造,也就是俗称的企业报表系统。背景如下:

  • 老板是完美主义者,需要漂亮的结果向投资人证明自己的成功。

  • 用户对新产品信心不足,抗拒心很强,并不太配合前期需求调研和后期产品验收。

  • 产品经理以及技术经理都是新人,并且有远大的做好事情的抱负。

  • 开发人员 80% 都是新人,技术力量参差不齐;老员工属于内向型。

其实,它最终没有失败,只是所有人都累垮了:  

  • Salesforce 平台作为数据源,初期系统尚在开发中,技术经理考虑不想将来重复工作(rework),决定暂缓启动开发计划。这个决定直接导致中期项目进度确认时一无所有,于是被老板和项目高层标识为危险而责难,而后期用户伸手要数据时,各种没有准备也导致整个项目被推迟上线。

分析:敏捷之一大忌就是怕重复工作,那是设计分析能力问题,不是延迟工作的借口,谁说数据产品就不能敏捷?  

  • 到底是完全拷贝原来的系统 KPI,还是重新定义,以及是否要设计全新的前端展示?这个问题从一开始到结束,困扰了整个团队的每个人。老板严要求 + 产品新人 + 业务不配合 + 老员工的惰性,导致举步维艰。最后,一套七零八落的半成品系统展示在用户面前,正确率和使用率很低。

分析:从上往下剥离,老板要求的不一定就是对的(这往往无解),产品和业务必须在目标和方向上达成一致,以及技术决定生产力,这几点缺一不可,要突破却难上加难。  

  • 需求要考量教育平台学生成绩,一个学生某次考试会有各种技能的不同分数。问题来了,是需要数据准备到最细粒度,还是汇总聚合?爱好完美和细节的技术经理又出现了,一定要到最低粒度。不幸的是,由于项目进度紧迫,出现了各种设计和需求脱节以及数据不一致问题出现,各种会议讨论甚至互相指责随之而来。

分析:还是敏捷问题,数据仓库权威 Ralph Kimabll 是一个典型的细节专家,他所追求的细节是数据架构设计以及企业数据平台建设的愿景。但是,这个项目是一个典型的 CRM 系统切换,业务再造是基本目标,这时追求极致的细节变成了不切实际的要求,带来的后果就是本末倒置,所有人疲于其实不那么重要的问题上。

远离斜视

有位猎头顾问对我说,目前大数据分析师的岗位不多,我近乎惊讶的回答到,''怎么会,这个时代,你招人不说和大数据相关,都会觉得不够档次啊'。事实总是证明我们是错的,拿开障目的那片叶子,正视真实需求,是多么难能可贵的企业家精神。

科学家是严谨的代名词,而大数据不需要严谨。是这样么?责任不同,视角也应该不同:  

  • 老板,720 度看数据,3-5 年规划中打算带着企业到什么样的数据成熟度 -- 这个成熟度一定和企业规模,组织管理,业务流程的成熟度成正比。用户,360 度看数据,这里把用户摆到很高的视角,因为他们不是傻子,是最知道怎么看和用数据的人。

  • 产品经理,30-180 度看数据,首要近视看眼前问题,不然会被用户骂死。也要远视看路线图,不然会被老板下岗。

  • 技术经理,60-120 度看数据,短期 + 长期规划,切忌操之过急,切忌漫无目的。

  • 前后端程序员,90 度看数据,那是你的两大支柱之一(算法 + 数据),多快好省是你的职责。

  • 数据分析师,??度看数据,你在哪儿,你去哪儿,你是谁,谁是你?想清楚。

落地是如此的简单 -- 80/20 原则

传统与自动化的纠缠,从古至今一直存在。再一次提及这篇令人爱恨交加的"SQL 足以解决你的问题,别动不动就是机器学习",如果传统方式能达到 95% 的精确度,够了么?

当我们在所有的算法中,对于圆周率的使用仅仅是 3.14 就已经足矣,又有多少人知道并在乎 3.1415926 后面的一位是 5 呢?

最后那 5% 的精准度,是红海最后的利润。这是收到最多的一个反驳的论点。但是当我们的企业,有超过 80% 的用户对数据的认知,还停留在填鸭阶段;当我们的运维还相当大程度依赖于半自动化,是不是该多花点心思写个 SQL 之类的。搭建数据产品的过程和企业以及用户的认知息息相关:  

  • 积累业务数据,重点在采集。Excel,SQL 够了。

  • 推送信息到用户,重点在快速提供。Excel,SQL 够了。

  • 自助式体验,重点在提升。Excel,SQL 够么?

  • 平台,重点在交互。Excel,SQL 不够了。

认知的过程是相当漫长的,每一步都要踏踏实实落地,跑之前要学会走。

结束语

有客户问我何为敏捷?我的答复如下,不仅仅只针对数据产品:

  • 我竭力面对任何一个需求,可能优先级上会有区别,可能个人能力上会理所不能及,或者让自己无法权衡处理好每一个事情。但我仍然愿意告诉每一个希望我帮助的人,我会竭力帮助他, 哪怕其实我答应的实情超出了我的能力。

  • 敏捷,本质就是靠近用户,有效沟通,快速迭代产品,不追求完美,要求脚踏实地。做产品就是要满足领导要求,要满足用户需求,而这两者常常会有冲突,就会很心累,这点在很多公司特别突出。这种情况,任何一个有丰富经验的项目管理者或者产品经理,都不能很好的协调。所以,搭建好领导,产品,用户几方之间的相互理解的桥梁,用用户导向的工作方式,尽量让你的方案能落地,尽量让目标达成一致而不是冲突,是每个做数据产品的人士应该牢记的工作原则。
     

阅读延展

1
3