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

接著梁寧系列課程的思考，這節(jié)課梁寧講的是產(chǎn)品“系統(tǒng)能力”模塊里的效率，在課后她留的作業(yè)是：

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

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

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

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

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

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

2018年的一次跳槽，我從策略平臺產(chǎn)品經(jīng)理，轉行成為了X公司的數(shù)據(jù)產(chǎn)品經(jīng)理。

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

共事的初期，Todd 總會提醒我：“做數(shù)據(jù)最重要的兩點就是準確性和計算速率?！?/p>

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

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

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

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

最后值得一提的是，作為非商業(yè)化的公司內部系統(tǒng)產(chǎn)品，經(jīng)過整個 unicorn 項目組的討論，我們采取了2周一個迭代的開發(fā)周期，這些都為未來 unicorn 的 DAU 數(shù)據(jù)打下了堅實的根基！

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

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

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

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

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

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

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

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

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

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

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

2018年時，雖然我已經(jīng)有了幾年的產(chǎn)品經(jīng)驗，但是數(shù)據(jù)產(chǎn)品的經(jīng)驗卻是0。且數(shù)據(jù)產(chǎn)品會涉及技術性的工作，所以一開始我更多是跟著開發(fā)的思路去走。

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

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

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

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

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

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

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

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

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

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

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

SELECT column_name? //展示數(shù)據(jù)，即拖入 BI工具中的行、列字段

FROM table_name? //應用的數(shù)據(jù)集/圖表

WHERE Filters? //篩選字段

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#專欄作家#

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

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協(xié)議