数据科学项目中常见的问题

随着计算能力的飞跃和深度神经网络的发展，数据科学，无论在国外还是国内，都是最近几年高科技领域的一个热点。很多公司和互联网企业都急切地涌入到这一波热潮中。但是成功的产品却并不多。大多数集中于创业企业的数据科学/机器学习项目都没能实现最初都愿景，有的不了了之，有的难以兑现价值，并且有相当多的项目只是拿来做融资的噱头。这里总结一下基于数据科学的项目和产品中一些常见问题

项目和产品不够明确 

初始的讨论就缺乏可行性，可操作性，或者有一些项目本来就不需要是一个数据科学的项目。这里考验的是一个产品经理或者公司执行者的视野和能力。我曾经在一个电商公司工作过一段时间，当时成立data science团队是受到投资人的推动，于是急匆匆招兵买马架起了队伍。在具体讨论项目和产品时候，CEO只给出来了一个“简单”的目标，把用户平均消费额提高10%。市场部原封不动的将这个目标传递到了DS团队，没有任何具体的方案和建议，没有具体的对接人，没有指定的产品经理或者项目经理。带着其他部门一厢情愿的理解，DS团队开始了研发，然后就是一团糟：数据模型做出来之后没有任何现实意义，单纯对于用户的聚类却不能给出销售行为具体指导。面对更复杂的分析和活动，市场部既没有条件来实现，IT部门也没法支持。最后只剩下一堆PPT，和一些描述性的结论，并没有具体的产品。 

CEO的动机非常清晰：提升销售额。但是这在商业上是一个极其庞大和复杂的课题，并没有一个简单的解决方案。这种项目或产品，一开始的定位就缺乏具体性和可行性。一个好的产品经理，应该将其具体化到小的课题以及可行的解决方案：比如如何通过优化优惠券的发放来提高用户单位订单，如何优化新品推荐短消息的内容等。确立了具体的靶点之后，再协调各部门共同开展项目，而非依赖于单一部门。一个好的CTO更不能自绝于DS之外。在互联网时代的项目中，几乎每一个都是跨部门多功能的。保证所有参与方之间明确产品的功能和定位，是进入项目开发前必须的一步，虽然很耗费精力，但是磨刀不误砍柴工。 

Data Scientists 缺乏研发软件产品的能力 

数据科学家这个职位听起来很sexy，很吸引人。可惜这并不是一个“科学家”。可以这么讲，一个好的data scientist需要的是一个科学家和一个工程师的集合。市场上有两类典型的“数据科学家”：一类是学习软件工程出身，可能干过程序员，对写程序比较轻车熟路。然后自学了一些网上的课程，就开始做DS了。他们科学研究相对弱一些，可能按部就班做工作更多一些。另一类是研究生出身，写过论文或者接触过科学研究，比较擅长读文献，看教科书，推导公式做习题。但是缺少软件开发的经验。主要是缺少在软件项目团队中合作的经历。就我看来，这两种DS都有缺陷，都需要改进。这里主要说第二类问题，缺少软件开发背景的DS 

五年前，我曾经在一个饮食行业的独角兽企业DS团队中工作过。当时的团队有3个博士，2个硕士，大家在一起很喜欢聊最近的研究论文，数学和统计学上的一些问题和简介。整个团队里面每个人很聪明，工作也很有热情，大家每个人主导一个项目，每周讨论非常活跃。但是这样一个团队，一年时间里几乎一事无成，拿不出来被认可的产品。究其原因，团队里面的研究气氛浓郁，却缺少将模型转化成产品的能力。 Google有一篇关于数据项目的文章的观点很有代表性：建立数据和工作流程比做一个预测模型本身更重要。当时的团队就是陷入了一个误区，做出来的模型越来越复杂，数据流却从来没有理清楚，从来不了解如何设计软件的架构，没有CI/CD，没有测试和运维。一个在软件工程看来很直接明了的需求，却始终无法实现。 

用比较糙的话来总结：这些DS可以称为“伪数据科学家”。大家追逐炫酷的模型的同时，不应忘记一个企业一个项目追求的根本是商业价值，体现在一个软件产品的客户价值上。一个项目背后的模型可以是简单的逻辑回归，甚至是rule-based，但是不能缺少良好的软件设计和实现。尽管这对于一个没有软件开发背景的纯研究出身的人来说比较苛刻，但是现实就是这样。我可以接受你模型做的不够完美，但是能交付产品。我不能接受一个完美的模型和PPT作为最终产品，除非我们做的生意只是套投资人的钱而已。 在组建团队的时候，也一定要把这点作为重要考量，即团队中至少要有一个软件开发经验充足的数据科学家。 

与工程师团队无法有效合作 

通常在一个cross-functional的项目中，软件工程师是必不可少的。这时候就需要DS和工程师有效合作，共同开发产品。现实中，这样的合作常常是问题百出。常见的问题有： 

1. 工作模式不同

对于研究型的学者来说，从事的工作都是全新的，而且通常很难。这类的工作很难预估或者事前计划。而对于传统的软件开发而言，以scrum为代表的敏捷开发非常流行。这两者其实并不能很好的统一，或者说本质上不应该试图统一。我曾经在的项目中就经常遇到这类问题，建模组需要一些数据来验证一个新的想法（或者模型），而相应的数据工程师团队要求必须在每周二sprint会议之前提要求，否则要推到下一个sprint。如此一来二去，整个项目进展缓慢。这源于一些团队对于敏捷开发的理解过于局限，过于拘泥形式。应该明白的是，敏捷开发不是形式而是思想。

2. 对于以数据科学为中心的项目理解不同

很多工程师还是基于以前软件开发的经验，在与DS的合作中没能认识到半科研半工程项目的特殊性，过分专注于代码本身。比如，很多时候，DS项目就是一个不断试错的过程，重复验证了多个可行性之后才有可能找到一个最理想的方案。这需要快速试错，prototyping，而非过分纠结于最终产品。这一过程没有办法预知，也难以做到测试驱动。与项目利益方的不断互动，可能使得整个项目可能永远就是在不断的交付一个又一个MVP。这不妨碍成为一个成功的DS项目，但是却有别于传统的软件开发目标。 

3. Teamwork

一个专业的工程师，到底是应该对别人代码中的问题牙呲必究还是应该适可而止？这个问题没有标准的答案， 主要取决于整个项目的目标和企业利益。现实中常常见到DS的代码不尽人意，而又不愿意花大力气改进，毕竟没有事情是完美的。个人认为最好的办法就是项目经理必须明确到底项目最重要的目标和底线，各方认同这一底线，从实际出发，避免DS团队的过度工程化。 

缺乏创新能力 

一个良好的DS团队不能只会实用现成的软件包开训练模型，不能只分析数据，而应该具有独立开发新算法新模型的能力。也许目前的项目并不需要这些过的工作，但是整个团队应该保持至少20%的时间和资源用来做原创性的研发工作。比如研究一些最新的理论进展，follow一些论文，组织学习小组系统地学习新知识，积极参加相关的会议。这些讲起来容易，其实做起来很难，因为项目经常会安排很满，难以给予足够的时间来做充实团队，或者做一些技术储备。 

总结 

很多企业都在构建数据科学团队和相关的项目，但是又经常抱怨投入产出比低下。一个成功的产品需要不仅仅优秀的DS团队，还需要决策层和相关部门对于数据科学的理解和配合。本质上，数据科学是软件开发而非科学研究，是对人类既有流程和工作效率的优化而非替代。寻找一个优秀的数据项目经理，远比寻找一个优秀的数据科学家难。