都去炒AI和大数据了，落地的事儿谁来做？

摘要

几乎每个企业都期望建立自己的完善的合体的数据体系，但成功的例子并不多。本文希望用一些实践阐述以下几个观点：

• 数据产品应该朴实无华
• 浮躁的认知会有大麻烦
• 如何正确认识自己，如何敏捷

前言

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

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

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

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

为什么要做数据产品

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

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

• Why？很明显，企业需要看数据，用户需要看数据。不管你是做战略计划、公司愿景、企业架构、运维治理、扩张市场、客户流失、目标营销，甚至做OKR、KSF、KPI、威士忌分析，或者告诉你的老板或下属做得有多成功或，，，多失败，你需要数据，这是你的价值。
• What？When？Who？这是你的内容（范围和服务），你的视野（过程和效率），你的上帝（细分）。

到底怎样做？一个笨手笨脚的人（Klutz）都告诉你可以这样做：

• KNOW 找准自己的定位，企业用户尚在起步阶段，是没有能力去索取更多的数据的。此外，还需要精通业务流程，数据流离不开业务流，不论你是To B还是To C，把握好用户痛点和需求，是首要的。
• LIGHT 不用再介绍一次KISS原则了吧。保持轻装上阵吧，那样就算死，也死得轻松。
• USE 动手吧，"想总是问题，做才是答案"。试错是如此的关键，一个企业是否有这个价值观，甚至影响了是否最终的成败。后面会提到完美主义者，是如何总是在关键时候触礁的。
• TELL 告诉你的用户或老板，这个产品现在该有多糟糕，虽然你和它已经竭尽全力在工作。奇迹是，他们总会站在你这边。
• ZANY 莎士比亚造了这个词“滑稽”，是让我们轻松点，数据人已经很累了。“数据科学家”，这个称号显然已经违背了这个原则，背负了太多。我更倾向于数据分析师，人人皆可当之。

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

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

 

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

 

• 动辄“大”

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

• “大”代表，首先，很fasion了。
• “大”代表平台很大，数据很多。
• “大”代表业务应用很广，至少传统方式做不了了。
• “大”代表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度看数据，那是你的两大支柱之一（算法+数据），多快好省是你的职责。
• 数据分析师 ，？？度看数据，你在哪儿，你去哪儿，你是谁，谁是你？想清楚。

 

图：不同视角看Score Card

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

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

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

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

• 积累 业务数据，重点在采集。Excel，SQL够了。
• 推送 信息到用户，重点在快速提供。Excel，SQL够了。
• 自助 式体验，重点在提升。Excel，SQL够么？
• 平台 ，重点在交互。Excel，SQL不够了。

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

结束语

有客户问我何为敏捷？我的答复如下，不仅仅只针对数据产品：

• 我竭力面对任何一个需求，可能优先级上会有区别，可能个人能力上会理所不能及，或者让自己无法权衡处理好每一个事情。但我仍然愿意告诉每一个希望我帮助的人，我会竭力帮助他， 哪怕其实我答应的实情超出了我的能力。
• 敏捷，本质就是靠近用户，有效沟通，快速迭代产品，不追求完美，要求脚踏实地。做产品就是要满足领导要求，要满足用户需求，而这两者常常会有冲突，就会很心累，这点在很多公司特别突出。这种情况，任何一个有丰富经验的项目管理者或者产品经理，都不能很好的协调。所以，搭建好领导，产品，用户几方之间的相互理解的桥梁，用用户导向的工作方式，尽量让你的方案能落地，尽量让目标达成一致而不是冲突，是每个做数据产品的人士应该牢记的工作原则。