就作者个人而言，公司数据部门都是一种被用户摧残的感受，明明自己做了很多数据的工作，但用户并不买账，对数据缺乏信任，价值感和认同感严重缺失。出现这种现象，问题出在哪里？该如何解决？本文进行探讨，一起来看看吧。

近期一直在思考关于数据服务的话题，一是自己这些年经历的这些公司的数据部门都是一种被用户摧残的感受，不论是在大公司中公司还是小公司，自己做了很多数据的工作，但用户并不买账，对数据缺少信任，价值感和认同感严重缺失。另一方面从用户的感受来看，他们也不是无端的责备，而是切实有数据应用的痛处。

仔细深思这个现象，到底是哪里出现了问题？为什么我们都很努力的去解决问题，但还是达不到皆大欢喜的效果？基于最近的工作和对以往的回顾，我认为可能是我们忽视了贴身感的数据服务。缺少从全局视角深度的设计数据服务，没有做好数据建设与数据应用的桥接。如何帮助一个非专业的小白用户用好数据是我们都知道的，但从来没有在数据的工作的每一个细节中都渗透这个概念。

从用户的数据使用体感来说，就我自己也有过非常不愉快的体验：使用某数据系统前要考试，不及格不能使用；遇到一个问题，需要自己找到和这个问题相关的所有产品、研发，历经七七四九劫难才得以解决；要想晋升必须通过XX的学习并认证通过；想想这些与数据、产品完全不搭调的绑定动作就很领人厌恶。我是一个平时极少用到数据的产品经理，但晋升必须通过中台的工具考试才可以申报，想必此时任何一个人都会骂上几句吧。

数据服务，也许是我们平时忽视的事情，可能它看不见摸不着，但是它就像一个人的表情，带给你的是一种感受，切实存在着。

一、用户的烦恼

最近我和朋友都在周末遇到了用户反馈的系统或者数据问题：

朋友负责他公司的某个系统，由于用户的操作不当，导致系统出了问题，数据有很多没有采集上来，下游的指标数据出现错误。可解这个问题的过程让用户特别糟心，用户通过ONCALL系统寻求帮助，可惜系统没有周末值班人员，然后他们就通过各种方式联系到了产品负责人，但产品负责人只负责产品问题，数据的问题涉及到一些技术问题，分管这块的技术负责人和产品不是一个部门，所以用户又通过产品负责人的连线到了技术负责人，就这样，用户自己前前后后打了10来通电话，联系到了系统的所有负责人，等了大半天，才算解决了部分问题，但数据的恢复工作还需要再等到第二天才能完全恢复。

事后同事跟我说，这个业务的用户感受非常不好，如果不是平时关系还不错，肯定要向上投诉的。他说最烦的是他是一个用户，解决问题的全程都需要自己来协调处理，可作为系统方，没有一个全局人或者接口人能够帮助协调，这一点着实令人气愤。就如同去4S店保养汽车，从进入4S园区开始，一切汽车保养的流程都需要靠自己协调来完成：找前台、描述问题、分别找不同的保养师傅、自己开到洗车区、缴费、自己打开停车场出门杆..

二、你到底服务与谁

现在绝大多数的中大型公司都有非常长的数据加工流。如果看一个报表的制作，大的模块上来看，就有数据采集、加工、分析、可视化4个步骤，每个步骤下还有很多细分领域。随着公司组织的扩大，这些细分领域都需要细分的角色来完成流水线上的每一步动作，每个角色的工作都非常的专精化，例如做埋点的专职做埋点、做数据加工的专职做数据加工、做工具的专职做工具，甚至一个大型的产品、项目需要多角色协同完成，比如工具的建设，同时需要研发、产品和测试3个角色。

所以这些数据流水线上的角色服务范围只是流水线的一段，它不是全局。每个角色专精在自己工作领域内，但他可能对自己确切的服务对象并不是了解的很清晰。还是拿埋点来举例子，专职做埋点的人，他直接服务的对象是谁？他是否和用户有直接的联系？是否有明确的服务动作和服务流程？

服务的灰区

另一方面，对于数据的应用方来讲，绝大多数的用户是不知道流数据水线有几个角色，他们之间是怎么协同工作的，他们不是数据方面的专业人士，发现问题只能看到问题的表象但是不能拆解问题定位到数据流水线的具体哪个角色上。如果出现了数据问题，在流水线的一侧我们没有设立好问题的对接机制和流程的话，用户体验就会非常糟糕，随着长时间处理问题，他需要了解流水线是怎么运作的，出了问题如何定位到具体的流水线角色。

这就产生出服务的灰区，流水线上的角色，或许从来没想到过自己的客户是谁，也没人告诉他，我的上下游是谁，明确的边界在哪里，以及到底有哪些动作是要协调工作的。协同工作偏“感性”，很多日常事务没有明确的规章制度，基本上口头相传，工作中不懂就问，出现问题临时拉群，临时性随意性占据主要成分。

三、服务均衡

之所以会有用户认为数据难用，工具不好使，一方面确实是数据部门在数据服务和用户成功方面投入的太少，另一方面数据部门的人力资源不足与组织设定的不匹配也是重要的原因。

数据部门从公司建设初期到成熟期的发展，也是结合不同的需求来进行人员的组建和调整的。绝大多数公司是以数仓当核心，围绕数仓进行拓展建设，数仓是核心团队，他们掌控着全量数据的采集加工和输出。

假设公司只有数仓团队，公司的数据也是可以运转起来的。因为用户可以“张口就要”：我要XX天的销售数据；你帮我做一个运营日报；下周要进行季度总结，需要上经营分析大会，你帮我准备一下数据….

索要过程是简单的，只要结果，减少非专业用户在此投入的精力，本身符合人性，也符合经济学规律。如果你能通过数据告诉我下一步做什么，那再好不过了，之所以chatgpt能够给人如此大的期待，就是相信随着发展，它能有一天最大限度的给与用户在数据应用的场景上做到秒级的“张口就要”。

现实情况是，数据的需求是多样化的，临时性的，不可预测的。所以我们在消化数据需求的过程中，必然会产生对需求的理解，以及对它们的定制化开发。

需求不是批量生产的过程，随着公司规模的扩大，对数据有需求的用户越来越多，但数据团队的人并非是同一时期稳步增长的。原本因为数据需求的不确定性导致数据部门疲于应对数据需求，如何能够高效的解决杂乱不确定的数据需求是数据部门的一个较大的挑战。

如果数据需求过多，解决需求的耗时过长，就会进入到需求做不完，一个“简单的”需求要T+1周起的状态。

不论是数据部门，还是用户，从体感上来讲，都会很差。数据部门的人每日重复工作，大多数是提数、报表等数据处理工作，然后就会出台一些列的限制性条约来约束用户的数据需求，例如给个表单，所有信息填清楚才可以开发需求，然后走排期流程等，至少需要用户想清楚再提，至于数据问题、数据、产品易用性等服务所投入的资源就更少了，自然达不到“服务”的标准。

用户也不敢轻易的提出需求，对数据的应用心态逐步演变成了尽量自己解决，疑难杂症再去寻求数据部门的帮助。随着时间的变化，数据部门和用户之间默默的达成了服务均衡状态。

所以让用户自己学习数据知识、工具，自己实现部分的数据诉求，是有原因的。

四、服务端到端

如酒店饭店、火车站、飞机场、游乐园等大型机构，它们所提供的服务感就很好。

例如你去火车站，车站里的标记会指引你如何进行安监、买票、进站、乘车。与其配套的还会有固定的咨询点、贴在墙上或者大屏幕上的各种服务电话，随时来应对你遇到的各种问题。你无需了解火车站的运转逻辑，你也无需关心火车如何调度，工作人员是如何排班的。

我认为如果作为一个普通人，除非兴趣使然，如果你在使用一个实体服务前必须了它的工作原理，从体感上来讲，你获得的服务感受一定是不好的。

我们去机场，核心目的是登机，除了登机之外的事情，都不应该是你需要特意了解的，理应是顺其自然。增加被动需要就增加了服务成本，例如安检，它是必要的，但是它和登机本身没有直接关系。

对于服务，我想以端到端的方式来理解。完成一件客户服务，其实就可以比作买卖，一手交钱，一手交货。明确客户的诉求，然后交付诉求，中间不掺杂任何其他的过程和行为，这是最简洁、纯粹的服务。

但在公司的数据服务层面，绝大多数的公司，几乎都缺乏明确的数据服务体系，更难做到端到端。这个并不难发现，很多公司会明令要求一些非数据专业的数据应用者去学习很多数据课程，还需要有强制考试，甚至是在使用某些产品之前先需要经过考试并且及格才能使用。这些不但是典型的非端到端服务，硬是把用户的“客户”身份变成了参与者，他们不得不去花时间精力去学习考试，增加了很多的学习成本，并占用了本该去做本职工作的时间。

我们经常会“教育”用户了解BI工具，了解数据中台，了解OLAP是什么，了解维度、埋点，但作为业务，他们真的需要了解这些吗？

我们换一个场景，作为一个汽车的拥有者，我需要了解CVT，可变正时，空气悬挂，托森差速这些知识吗？回归到出行工具的本质，我只需会驾驶它，是不是就足够了？所以驾校的学习是必要的，汽车知识的学习是“非必要”的。在数据产品和服务的过程中，我们是否能够区分出哪些是必要的，哪些是非必要的？

是否可以调研一下这些被迫学习的非专业用户，他们有多少人是自愿来学习的？他们诉求是不是想要时就能提供，到手就用，而无需任何学习成本？

五、用户成功

我相信绝大多数产品人在产品创建之初的核心目标是帮助用户解决实际问题，深入到用户的场景中去，让用户能够成功。

公司内的数据部门，几乎不存在用户成功团队，所有跟用户的交互，不是在会议室、社交软件上沟通，就是产品的直接交互。主动的触达与体系化的辅助工作是完全没有的。在前几年很多公司几乎不设立内部工具、内容的运营团队，数据更是如此，用户成功团队几乎更不可能。

用户成功和运营团队的工作是不同的。运营的目的是让用户更了解产品工具体系、内容体系，更偏重“批量统一模式”。传统的对工具的运营方式是工具的培训、内容的推送、系统的迭代更新发版、深入一点的会有用户关系维系等。但这些并不能很好的帮助用户建立产品心智。因为很多运营手段都是“批量给与”的，例如统一的培训，产品宣讲，甚至是产品调研，这些手段本身并不精益。虽然它可以解决一些通用性问题，但很难做到用户和产品的完全结合。

我们自己问一下自己，是不是我们自己做了很多运营动作后，就很难深入下去了？有一种使了很大力之后，没有任何回响的感受？

例如产品培训，做了一期、两期、三期之后，似乎咨询量一点没少，该问的还是会问？

而用户成功，则需要站在用户身旁，与用户一起达到目标，需要深入。这里讲究的是一个换位或者伴随的过程。在把产品交给用户前，可以问一问自己：

• 你知道用户在该场景下，都要做哪些事情吗，没有产品或者你以及你的服务，他们怎么把事情跑起来？
• 他们遇到了问题，怎么去解决？
• 他们工作中的上下游都是谁，组织间是如何协同的？

帮助用户成功的过程，首先要有足够的观察，观察他们在没有产品时，是如何运作的。然后进行深入的分析，明确他们想要什么，我们的产品能在哪个环节渗透进去，渗透进去的效果是什么。

用户成功与运营的本质不同在于，作为数据提供方，需要与业务制定共同的目标，在数据应用上能为业务提供什么价值，这个价值是双方认可的，由数据团队提供专业的辅导与产品方案，帮助用户独立或半独立的实现价值。

最关键的是，不能站在数据部门的角度去执行，要以用户的角度，拿来数据和工具后，怎么达到价值的视角来制定成功计划。

六、做好数据服务的一些思考

数据服务始终不是数据部门的主线，但如果稍加在此投入一些精力进行设计与实践，相信对于数据部门和用户都能够有较大的收获。

我想，要想做好数据服务，需要从以下几点来看：

1. 心态与价值共鸣

好的心态是好的服务的前提。在公司里很少有特定对心态的专业性建设的，一般都会去考量工作量和工作产出。

好的心态建设要体现在独立的个体与团队两方面。其中比较关键的是两点：一方面是自我认同，一方面是他人认同。

价值共鸣很重要，如果你去问问数据部门的人，你服务的用户是谁，你的价值是什么，想必有很多人是答不出来的。然后再去问问用户，你觉着数据带给你什么价值，这个价值是谁带给你的，他们可能会零星说出几个人，但基本上都是通过平时和他对接人的态度、交付质量相对感性的理解来判断的，是相对感性的，并不是服务体系整体的支撑产生的。

自我认同和他人认同都很模糊，自然就缺少相互的换位的思考。双方都清楚自身服务于谁，被谁服务，产生价值共鸣，对心态的正向引导是非常有必要的。

疲于应对需求，主张技术攻克，但缺少和用户联动，逐步进入被动状态，往往对心态或多或少的产生不利的影响。

好的心态与价值共鸣，需要从组织上切入。也需要组织的负责人来统筹规划，不能只盯着一些技术、运营层面的指标，而不关注这些深层次无法度量的事情。更要明确每个部门中角色的权责，定义好边界和流程，既是保护也是正义。

紧密的合作伙伴也是关键的要素，很多时候我们推出产品，目标用户有很多，反而没有核心的VIP用户，用户没有分层和针对性的深入，是很难找到价值共鸣的，VIP用户会明确你提供的服务范围，他更需要知道你能为他提供什么样的价值。

注意，价值共鸣不是跪着服务，而是相互尊重，相互成就。如果任何一方是单向的，都不会有价值共鸣。因为如果是单方意愿，那么你做什么都是被记为及格分，不会有优秀的感情分。

2. 从被动到主动

主动服务于被动服务是两个截然不同的状态，在这里特意拿出来说，是因为部门间的服务均衡往往是被动形成的，而不是一个服务部门主动规划形成的。对于业务的数据需求、数据能够产生多少价值，很多数据部门的掌控程度很低。它们不是没有技术、不是没有数据、甚至于存在很多技术大咖，但依然不能有效的掌控业务在数据上的应用体感。

例如数据出现问题，影响业务决策时，用户反馈给部门领导时，多数时候数据部门总是显得那么窘迫，而不是从容的对待。对需求，对问题，数据部门似乎极少时间能够有很强的掌控，所以数据服务的主动性掌控是非常必要的，不是你说了我做，而是你不说我也要做的转变。

对数据服务的掌控，也能够很好的规划出部门到底需要什么样的技术、人才、和组织形式，最终达到最大化效率和价值体现。

3. 整体设计

如何扭转被动性？需要在技术、组织、产品层面上进行整体的设计。它的设计需要有几个原则：

1、部门要给服务流出资源和精力，需要有人深入的思考，数据如何更好的服务给业务，转变作为数据提供者思维，站在用户视角看服务

2、需要深入的观察，观察业务是如何应用数据的，它们使用数据的深度是什么，如果能把使用深度分级，他们处于第几级？

3、需要量化业务用户的使用行为，能够在你不看见业务用户真人的情况下，详细的了解他们是如何使用数据的

4、寻求良性的服务均衡，减少迫于需求压力而导致的被动需求均衡，减少无需求的技术投入，增加投入的技术价值

5、增加主动服务的能力，以和业务融合的方式，帮助用户成功

6、寻找明确的价值共鸣，并传递至部门所有人

7、需要一个全局人，明确服务灰区，减少灰区间带来的服务断层问题

3分靠产品，7分靠运营，我相信在绝大多数产品让用户使用的过程中，都是一个非常适用的规则。

总的来说，数据部门在勤勤恳恳的设计数仓架构、优化突破技术方案、专心制作数据工具产品等工作之外，真的需要有一个固定的角色来从服务的角度审视我们生产出来的“产品”如何让用户“用起来”，切实的帮助用户产生了真正的价值。而不是9分埋头苦干做技术解决需求，1分处理客户关系及服务。避免在产出的过程中，因没有思考这些服务方式而让产品、数据离“易用”较远。

其实现实情况，想做到上面的事情是很难的，毕竟很多公司不是新公司，有很深的历史痕迹，打破重来很难，全局性的服务还要有产品工具的易用性、以及好的规则的延续、组织间权责明确、组织的稳定性等条件同时具备才能让好的数据服务成功的概率更大。

好的数据服务不是一蹴而就形成的，它需要用户的洗礼和时间的沉淀，能够在长时间周期中延续存活下来，就已经胜出了。未来借助人工智能，也许数据服务会变得更“单纯”、“简单”，可能不用和那么多服务角色打交道，只要做好知识库让机器处于活跃的服务一线，才是未来好的数据服务的终景吧。