近几年，随着数据和人工智能越来越受关注，数据与人工智能项目（统称数据项目）也遍地开花，和传统应用类项目相比，数据项目有其自身的特点和挑战，本文就来盘一下这些挑战。
01 数据质量，横亘在理想与现实之间那道坎
企业想从数据里面发掘价值，首先需要有数据，大部分企业面临的问题不是无数据可用，而是无可用数据。
多年的业务经营，许多企业已经积累了大规模的数据，看上去是一笔巨大的财富，这就会造成一种假象，会让企业的管理者和高层过高估计数据给他们带来的价值，相应的也会对数据项目产生过高的预期。
理想状态下，数据是能够带来价值的重要的生产要素，但现实是，真正打开之后，才会发现可以直接拿来使用的数据并不多，比如数据存在各个系统孤岛里，获取不到；比如，数据的标准不统一，口径不一致；比如，数据中出现大量的错误，许多关键数据是缺失的，矛盾的，等等，这些都是数据质量问题。
举个典型的例子，服务过的某家车企，想做一些老客深挖、通过老客引入购车机会的事情，这个工作需要基于数据分析老客的特点和行为特征，从而预测老客带来新客户的可能性，但当真正基于数据做客户分析和模型开发时，发现只有不到40%的数据可用，可想而知，模型结果也就不具备很高的参考性，这和企业的期望是相背的。
所以数据项目从立项那一刻起往往就背上了一个不切实际的预期，项目被认为是炼丹炉，数据进去，丹药出来，包治百病，很少会有人考虑炼丹成功的几率问题。
要提高胜算的几率，也是有方法可循的，比如盘资产、提质量、推确权，解决历史数据中的遗留问题，从源头上管控好数据的生产问题，也就是把企业的数据统一、科学、专业地管理起来。
唯有如此，才有可能提高数据价值兑现的可能性，但这需要一个过程，这也是企业的系统工程。
总的来说，数据质量问题，是横亘在理想与现实之间难以逾越的那道坎，解决这个问题，需要决策者保持清醒的头脑，也需要决策者拥有大胆革新的魄力。
02 跨部门合作问题，人的问题最关键
许多企业里面，数据的生产者、使用者、管理者、所有者来自于不同的团队，所以和应用类项目的开发比起来，数据项目需要更多的团队和部门参与和支持，但由于大部分部门的KPI是和部门内部的职责相关的，每个部门的权责利清晰，当跨部门的协作和本部门的资源或者利益出现冲突，协作的动力便会出现问题，所以跨团队合作在很大程度上增加了数据项目的复杂度。
举个现实中的例子，曾参与过某家零售企业数据驱动的供应链数字化转型项目，项目由一把手推动，轰轰烈烈展开，启动会议上，各部门的负责人也是拍着胸脯喊口号、表决心，给人一种上下一盘棋、未来可期的壮丽景象。
但当真的着手开展工作时，会发现各部门有各部门的生存压力，年度指标压着，部门考核绑着，资源计划空着，整个数据项目就是在各自KPI之外的“爱心工程”，项目进展到第二个月，大部分部门的参与度就已经明显降低，信息收集不上来，任务推进不下去，接口人频繁变更，最终连会议也很少参加了，刚开始的时候，一把手过问一次，紧迫感提升一点，但一把手也苦于没有精力紧盯执行细节，渐渐地也就相信了各部门已经尽了最大的努力在做好份内的事情，数据工作不是想象的那样立竿见影，可以在未来徐徐图之，只是这个未来在什么时候，是不确定的事情。
这就是为什么很多数据项目，会经历高高举起、轻轻放下的过程。
总的来说，数据项目要做到有始有终，有目标、有行动、有结果，跨部门协作是绕不开的话题，归根结底这也是解决人的问题，这需要在立项的时候，相应的有组织设计上面的辅助支撑，比如，责权利的重新界定，比如KPI的调整设计，等等，跨部门协作的事情如果不能得到解决，企业里一系列和数据相关的工作，很容易变成只有开始没有下文的结局。
03 价值衡量的问题，一个悬而未决的问题
数据项目还会遇到另外一个挑战，也和跨部门协作相关，那便是如何衡量价值，如何测算ROI（投资回报率），这是很现实的一个问题。
因为要持续获得投入和支持，就要看项目的产出结果，也要看投入产出比，要获得跨部门多个团队的支持，就要给对方带来看得见的利益和价值，归根结底，数据项目如何衡量结果和价值呢？
这些价值对应到应用类开发项目，可以是上手的功能，华丽的界面，友好的用户交互体验，可以用“姣好的颜值”、顺畅的流程、提升的效率来衡量结果，也可以用获得的客户满意度来证明价值，但很多数据项目，大部分工作隐藏在“冰山”之下，比如，数据接入、数据处理、数据清洗，比如，模型开发、测试、优化，比如，数据治理，套用冰山模型来解释的话，这些数据工作如果能让人看到冰山之上30%的结果，通常代表冰山之下至少有70%的投入，所以，数据项目的投入产出比经常会受到挑战。
尽管有许多从业者已经在不断寻求和验证数据项目的衡量标准，但直到现在业界没有很好的实践和标准供参考，在这个标准被找到之前，估计还会有很长的一段路需要摸索。
04 业务与技术的调和问题，志不同则道不合
业务团队和技术团队的出发点不一样，经常会体现在诉求的不一致上，但项目的成功依赖于两个团队对于目标的认识保持一致，也需要双方对行动方案给予支持。
现实场景中，业务拥有最多的上下文，希望技术团队快速满足业务诉求是最高优先级，哪怕诉求还没有成体系，也可能会存在频繁变更的可能，但“多快好省”是永远正确的追求，但技术团队要考虑变动带来的影响，要考虑架构，考虑资源，考虑远期目标与短期需求，所以，满足了“多”，不一定能“省”，要追求“好”，实现起来不一定“快”。
比如，建设中台，或许能解决远期的效率，但未必能提升近期的速度，比如，数据治理，能辅助未来的决策更贴近“精”和“准”，但既需要业务团队参与，又需要时间周期，而业务团队背着指标分身乏力，开展业务紧迫在时间上往往也等不起。
业务和技术的矛盾，尤其在数据工作上，调和起来有很大的难度和挑战，但两个团队又互相依赖，在很多企业里面，业务依赖技术团队走项目流程，技术依赖业务提供需求上下文，并给予产出结果肯定或反馈。
解决这个问题，需要双方共同努力，业务和技术分享业务上下文，帮助技术了解诉求背后的原因和压力，技术帮助业务了解数字化和数据背后的原理，双方统一语言，频繁沟通，最终实现认知和理解上的一致。
以上是一种理想的状态，要达到这种状态，企业在文化上要鼓励沟通，尤其是跨部门沟通，在环境上要营造开放的氛围，倡导包容与理解，在组织结构和绩效考核上，要设置一些促进信息共享、跨部门合作的标准和激励。
如此，企业在整体的协作上得到调和，企业级的信息共享问题才有可能得到缓解或解决。
05 数据思维问题，一切问题的起点
在这个上下文中，数据思维是一种思考的能力，简单来讲就是如何看待数据，以及对数据能带来什么价值、如何带来价值的认知。
近几年，数据被提的次数多了，加上数据经常会和人工智能一起被提及，不同的人对数据思维的理解有着千差万别，这里面也不乏有一些错误的认知。
比如，数据是面魔法镜，能够看过去知未来，如果数据告诉不了我答案，那一定是方法有问题；比如，数据问题是技术问题，和业务没有关系；比如，数据如果不正确，一定是计算逻辑出了问题，系统的错；比如，技术是个魔法棒，如果结果达不成预期，那肯定是能力跟不上。
之所以出现这样一些认知，是因为数据思维还没有建立起来，确切地说，是科学合理的数据思维没有建立起来。
很多应用类项目的开发，是思维先于行动的，也就是说，先对结果有了相对合理的预期，然后开展行动，而很多数据项目是从尝试开始的，过程中充满探索，充满未知，许多传统企业沿袭的是“不承诺结果便不能投入”的决策规则，所以数据项目立起来困难重重，即使是冲破各种困难走上探险之路，在开发的同时，也肩负着和具有不同数据思维的人沟（ZHAN）通（DOU）并影（JIAO）响（YU）他们的工作，这些都会使数据项目的困难度和复杂度陡增。
总的来说，数据如同企业的生命线，它的产生和流转贯通企业的业务和运营，数据的工作牵一发而动全身，绝不是拿着钳子拧螺丝就能解决的简单明了且具体的事情，要把数据工作想清楚，规划好，执行下去，既要做正确的事，又要正确的做事，需要企业上上下下具备数据思维。
这种思维需要在业务和数据之间建立联系，既要创新又要谨慎，既要守住优势，又要探索新知，不保守不冒进，所以说，数据思维是企业整体的能力，建设这种能力也是数据项目的挑战和使命。
总结一下，和应用类项目比起来，开展数据项目会面临一些新的挑战，这些挑战给数据项目的开发和管理带来了新的困难，如何更专业更成功的管理好数据项目，这些实践值得被探索和总结。
文/Thoughtworks 陈庆敏
原文链接：谈谈数据项目的挑战-Thoughtworks洞见