編輯導語：數據可視化產品的存在意義之一，便是幫助提升企業的業務效率和數據處理效率，進而推動業務流程和決策。本篇文章里，作者結合了自己的經歷，講述了幾個利用數據可視化產品來提升“效率”的故事，不妨來看一下，也許能讓你對數據可視化產品更加了解。

接著梁寧系列課程的思考，這節課梁寧講的是產品“系統能力”模塊里的效率，在課后她留的作業是：

企業是效率分工的產物，那么你所在的企業的護城河在哪？你覺得它在哪個方面的效率比別人做得更好？

在這節課中梁寧提到了“效率是保障系統能力的核心指標”，其實我學習了這節課后，重新梳理了對“效率”的認知：效率不僅包括上一篇文章提到的數據效率（“加載速率”、“數據準確度”等指標），還包括功能操作、bug 處理、產品迭代、運營推廣、系統間耦合、業務賦能的效率，簡而言之就是從“產品本身→系統生態”的效率。

但產品出現并不是無中生有，而是通過人工生產得到，所以在它的背后包含著開發、設計、管理、運營、生態5個方面的具體工作，從而保證產品從“能用→易用→好用→有用”的過渡。

本次作業我就不聊企業了，就把梁寧留的作業范圍縮小一下，聊聊前公司那款 DAU 從幾人到幾百人的數據可視化產品（DAU雖是虛榮指標，但作為一款內部工具產品，這個數據表現已經很優秀了）。

這次我將化身一位講故事的人，通過5個“效率”有關的故事帶你來搞懂數據可視化產品（亦稱 BI 可視化工具）。

一、故事1：開發效率——從入行到敏捷開發改革

2018年的一次跳槽，我從策略平臺產品經理，轉行成為了X公司的數據產品經理。

同期，研發部門也發生了一次人事變動，X公司公認的最優秀的大數據開發工程師 Todd 成為了 unicorn （X公司自研的一款數據可視化 BI 工具產品）的后端研發負責人。作為初涉大數據領域的產品人，與認真、專業的技術同學合作是一件非常開心的事。

共事的初期，Todd 總會提醒我：“做數據最重要的兩點就是準確性和計算速率。”

所以在最初的近3個月時間里，unicorn幾乎沒有做任何新功能的迭代（特別影響用戶體驗的功能除外），除了給內部數倉同事使用外，甚至上沒有給其他部門做推廣。

因為早期的 unicorn 有兩個特別大的問題：一個是所有的計算邏輯全部由前端實現，增加了圖表渲染的時間；另一個就是歷史存在很多計算異常的功能，造成數據計算不準確。

在那段時間，我們把所有的計算邏輯加工由前端轉到后端實現，加快了圖表數據展示的速率。同時，我們還為 unicorn 設計了一套緩存機制，確保相同數據查詢直接訪問上次已查詢好的數據。

另一方面，在早期的用戶群里反饋的計算錯誤問題，后端開發們一直保持今日事今日畢。

最后值得一提的是，作為非商業化的公司內部系統產品，經過整個 unicorn 項目組的討論，我們采取了2周一個迭代的開發周期，這些都為未來 unicorn 的 DAU 數據打下了堅實的根基！

二、故事2：體驗效率——快速構建一張 Dashboard

unicorn 的用戶和所有的 BI 可視化工具一樣，主要分為兩類角色：作圖者（一般為數據分析師）和看圖者（一般為業務人員）。

因為有這兩種角色，所以“高效”也有兩大特點：看圖者能夠快速定位、探查問題，這里的細節可以參考之前的文章《數據+產品就是數據產品？漫談數據可視化場景》，這里將不再贅述。

而對作圖者而言，“高效”意味著能夠快速搭建一張 Dashboard。

使用過 BI 可視化工具的同學應該清楚，配置儀表盤的主要流程分為三步：連接數據源 → 配置數據集 → 制作報表。

其實絕大多數的 BI 工具在“連接數據源 → 配置數據集”環節的操縱基本都差不多（有一種特殊的方式，后面有機會將會用整張篇幅介紹），而在“制作報表”環節上， unicorn 卻經歷過一次由低效到快捷的變革。

在接手 unicorn 時，“制作報表”是參考一個開源的 BI 工具的制作流程：創建畫布后，需要添加已經創建好的圖表，全局篩選器可以在畫布區域添加，而針對單表的是篩選器是創建圖表時添加（Dashboard 包含三個主要元素：畫布、圖表、篩選器）：

其實，上述過程我們可以看到是一個工程化思維的過程，圖表和圖表篩選器是一一對應的關系，畫布與全局篩選器也是一一對應的關系，圖表之間是存放在一起的組合關系，而畫布則是包含這些圖表的關系。

如果用這種方式向他人介紹 BI 可視化工具，那是非常棒的，但是交給用戶去操作不難發現儀表盤的創建是不連貫的。為了保證用戶的操作連貫性，我們把 unicorn的操作方式做了修改，讓用戶創建畫布、圖表、篩選器都是在同一個視窗下完成的：

除了整體流程的優化，各個功能模塊的優化也滿足用戶的心智模型，在“故事3”中我會繼續講述相關的內容。

三、故事3：管理效率——由被動到主動，由抄襲到創新

2018年時，雖然我已經有了幾年的產品經驗，但是數據產品的經驗卻是0。且數據產品會涉及技術性的工作，所以一開始我更多是跟著開發的思路去走。

在接手 unicorn 時，用戶全為本部門的幾個數倉同學，基本上他們提什么需求方案就跟著做什么需求方案，實現方式也被動接受后端開發的設計思路，作為一個產品人把大腦交給別人是一件非常痛苦的事情。

一個多月的時間里，我開始一方面記錄 unicorn 的迭代路徑，發現產品的迭代基本上是東一榔頭西一棒槌，缺乏方向性的規劃；另一方面從零開始學習基礎的 SQL 查詢語句，學習每個功能背后數據流轉，了解了現存功能亟待改善的功能點。

“你可以跟我提需求，但是你必須得跟我講背景……”看過我之前文章的朋友應該知道，這句話是我對數倉同學說的與一開始發生180°反轉的話，這也是我做數據產品發生改變的起點。

隨后我開始重新制定了新的需求提報標準（需求錄入表），增加“講背景、說問題”的環節，而不是直接說解決方案。為了避免過分改革帶來潛在的影響（感興趣的朋友可以了解一下王莽改革），我保留了數倉同學愛直接提方案的行為，只是在備注了其為“建議方案”，即最終實現以產品設計為準。

同時，需求的優先級、排期等設定的歸屬權歸為我們項目組討論處理，參考如下（僅白色填充的表頭所在列，支持需求提出人編輯填寫）：

伴隨著需求池的規范化整理、分類，整體方向性的迭代規劃也有了藍圖。

此外， unicorn 的設計也不是完全抄襲著 Tableau、網易有數等之類的商業化 BI 工具功能流程，就以篩選器作用圖表的功能為例吧，Tableau 支持如下圖所示的應用范圍選項：

其實，Tableau 是以數據視角而非圖表視角設計這項功能的，“僅此工作表”還容易理解，但前面兩個選項（選項1是跨數據源篩選的功能，選項2是針對同一數據源的所有圖表）的名稱就是要讓用戶更關注數據而非圖表本身，讓用戶用不同視角去理解并列關系的選項，這種設計本身就很反人性。

再者，如果在 Tableau 上想跨多個數據源篩選數據還要得保持字段名稱一致，如果不同的分析師在數據集命名出現不統一的情況（數據集存在 BI 工具下，而非存在數倉，所以命名規范一般沒有強要求），還需要重新改一下，真的是很麻煩。

第二個突出問題在 Tableau、網易有數兩款產品上都有表現，在設置篩選器的步驟上，都是先要先“選擇篩選字段”再“選擇對應的圖表”，如下是 Tableau 與網易有數的配置截圖：

可是我每次使用時都有些變扭，總感覺順序和我心里想的不一樣。我們寫過 SQL 語句的朋友都知道，我們在查詢數據時一般都是寫形如下方的語句，篩選條件都寫在最后：

SELECt column_name //展示數據，即拖入 BI工具中的行、列字段

FROM table_name //應用的數據集/圖表

WHERe Filters //篩選字段

所以我在設計篩選器設置流程時，就改變了配置的順序：

在咨詢完一些分析師同學后，他們也覺得這樣的方式體驗更佳。同時，我們還在設置上做了一定的優化，比如當設置其中一個圖表的字段后，若其他圖表也有同樣名稱的字段，其他圖表會默認選中該字段：

四、故事4：運營效率——從領導包圍團隊，用認真留住用戶

在文章開頭我們就提到了unicorn 是 DAU 從幾人到幾百人的數據可視化產品，那在公司已經有 Tableau 的背景下，這個內部的 BI 工具是怎樣運營推廣的呢？

其實，一開始我盲目的在作圖人（分析師）、看圖人（業務人員）間兩頭推，可是近一個月時間下來，只從幾人推廣到了十幾人。

后來我開始調研了之前推廣的同事為什么不用 unicorn，他們的回復驚人的一致：“我們看分析看板都是用 Tableau”。

我意識到unicorn在大家的眼里并沒有存在感，再用這種常規的方式推廣肯定還是很少的人在用，如果想讓更多的同事使用，那就有必要采取自上而下的方式推廣了。

我和主管一塊找到了兩個大部門的負責人，給他們演示了我們的系統，并了解到了他們目前共同擁有的最大痛點：用 Tableau 必須在公司網絡環境下才可以使用，而在路上想去便捷的查看數據時基本不可能。

為了讓這些部門主管協助我們在他們內部推廣，首先就是解決主管們的痛點。

在接下來的一個迭代周期立項后，我們前端同學終于研發出了 Dashboard 的截屏功能，并打通了釘釘群的接口，支持配置定時任務向釘釘群發送截圖。這樣手機不用下載 Tableau APP 且不連接公司 VPN 也可以在上下班路上查看數據了。

解決了這些部門負責人的痛點后，他們自然而然地開始在部門內部推廣。因為用戶量的擴大，很多產品的問題也開始從發現到修復或優化。

因為有了一個部門的使用，我們在給其他部門推廣時就方便了很多，每次推廣都會說：“***部門已經開始使用了，他們用的效果非常好，你們可以問問他們……”

為了更好地留住客戶，我們在產品頂部增加了“吐個槽”入口，并開通了釘釘群，讓有問題的同事可以即時上報問題。在“故事1”中也提到了，用戶反饋的問題基本上保證盡快的處理，而計算錯誤的問題，一直保持當日反饋當日解決。

最后，我們還為 unicorn 打造了一個客景監控看板：“哪些用戶經常訪問unicorn”、“哪些用戶登錄過一次至今就不再登錄”……這些數據都盡收眼底，而我每周也會從中抽取1~2位客戶去了解他們的使用情況，也為未來的系統規劃提供了寶貴的建議。

五、故事5：賦能效率——中臺化，unicorn 不再是一個單純的 BI 工具

unicorn如何做好賦能，除了狹義上的賦能，即提供更高效的可視化展示（包括支持多樣化的圖表、支持個性化的預警、提示用戶關注相關指標等）外，還包括廣義上的賦能。

其實 BI 可視化工具本質上屬于 B 端產品，所以其追求的還是在于“效率”。

在企業內部，除了 BI 可視化工具外，很多內部系統都會有圖表展示的需求。比如投放系統“投放后的效果如何？”可以用可視化系統展示，同樣 CRM 系統“各個銷售同事的業績如何？”也可以用可視化系統展示。如果我們給兄弟部門的系統支持可視化的能力，是不是就能夠節省他們的開發資源，并提升 unicorn 自身的價值呢？

我們在這項工作上，給其他業務系統提供了兩種不同的支持服務：一種是輕量級的支持，僅提供圖表可視化能力；另一種是重量級的支持，同時提供圖表可視化能力以及數據計算能力的服務。

在 unicorn 中臺化支持服務中，“圖表可視化能力”主要是依賴我們前端同學開發的圖表庫組件，為滿足業務的展示需求，在 Echarts 開源圖表上進行了改造。

而數據計算能力，考慮到不對 unicorn 做太多的系統改造，我們創造性地設計了一個參數傳遞功能。這是在 Tableau 參數傳遞功能上的進一步創新，目前 Tableau 僅支持內部儀表盤之間的參數傳遞，或者是內部圖表對外部系統的參數傳遞，唯獨缺少外部系統對系統內圖表的參數傳遞。

在支持 CRM 系統“讓各個銷售同事查看自己銷售業績”的項目中，我們將公司統一賬戶系統的“用戶 ID”作為參數變量，在 unicorn 內用包含銷售業績的數據集，創建了包含若干圖表的儀表盤，再將該儀表盤通過加密外鏈嵌入到 CRM 內，就實現了“千人千面”的銷售數據展示，即每個登錄 CRM 的銷售同事僅能查看到自己的銷售數據：

5個小故事到此就講述完了，讀完之后你是否對數據可視化產品有了更深入的認識呢？如果你有其他問題或者不一樣的見解，歡迎在下方留言與我討論。

#專欄作家#

兮兮，微信公眾號：孤身旅人（ID：gushenlvren），人人都是產品經理專欄作家。關注人工智能、toB產品、大文娛等領域。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議