就作者個人而言，公司數據部門都是一種被用戶摧殘的感受，明明自己做了很多數據的工作，但用戶并不買賬，對數據缺乏信任，價值感和認同感嚴重缺失。出現這種現象，問題出在哪里？該如何解決？本文進行探討，一起來看看吧。

近期一直在思考關于數據服務的話題，一是自己這些年經歷的這些公司的數據部門都是一種被用戶摧殘的感受，不論是在大公司中公司還是小公司，自己做了很多數據的工作，但用戶并不買賬，對數據缺少信任，價值感和認同感嚴重缺失。另一方面從用戶的感受來看，他們也不是無端的責備，而是切實有數據應用的痛處。

仔細深思這個現象，到底是哪里出現了問題？為什么我們都很努力的去解決問題，但還是達不到皆大歡喜的效果？基于最近的工作和對以往的回顧，我認為可能是我們忽視了貼身感的數據服務。缺少從全局視角深度的設計數據服務，沒有做好數據建設與數據應用的橋接。如何幫助一個非專業的小白用戶用好數據是我們都知道的，但從來沒有在數據的工作的每一個細節中都滲透這個概念。

從用戶的數據使用體感來說，就我自己也有過非常不愉快的體驗：使用某數據系統前要考試，不及格不能使用；遇到一個問題，需要自己找到和這個問題相關的所有產品、研發，歷經七七四九劫難才得以解決；要想晉升必須通過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分處理客戶關系及服務。避免在產出的過程中，因沒有思考這些服務方式而讓產品、數據離“易用”較遠。

其實現實情況，想做到上面的事情是很難的，畢竟很多公司不是新公司，有很深的歷史痕跡，打破重來很難，全局性的服務還要有產品工具的易用性、以及好的規則的延續、組織間權責明確、組織的穩定性等條件同時具備才能讓好的數據服務成功的概率更大。

好的數據服務不是一蹴而就形成的，它需要用戶的洗禮和時間的沉淀，能夠在長時間周期中延續存活下來，就已經勝出了。未來借助人工智能，也許數據服務會變得更“單純”、“簡單”，可能不用和那么多服務角色打交道，只要做好知識庫讓機器處于活躍的服務一線，才是未來好的數據服務的終景吧。