起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標(biāo)識5個關(guān)于“效率”的故事，帶你搞懂?dāng)?shù)據(jù)可視化產(chǎn)品
編輯導(dǎo)語：數(shù)據(jù)可視化產(chǎn)品的存在意義之一，便是幫助提升企業(yè)的業(yè)務(wù)效率和數(shù)據(jù)處理效率，進(jìn)而推動業(yè)務(wù)流程和決策。本篇文章里，作者結(jié)合了自己的經(jīng)歷，講述了幾個利用數(shù)據(jù)可視化產(chǎn)品來提升“效率”的故事，不妨來看一下，也許能讓你對數(shù)據(jù)可視化產(chǎn)品更加了解。
接著梁寧系列課程的思考，這節(jié)課梁寧講的是產(chǎn)品“系統(tǒng)能力”模塊里的效率，在課后她留的作業(yè)是：
企業(yè)是效率分工的產(chǎn)物，那么你所在的企業(yè)的護(hù)城河在哪？你覺得它在哪個方面的效率比別人做得更好？
在這節(jié)課中梁寧提到了“效率是保障系統(tǒng)能力的核心指標(biāo)”，其實我學(xué)習(xí)了這節(jié)課后，重新梳理了對“效率”的認(rèn)知：效率不僅包括上一篇文章提到的數(shù)據(jù)效率（“加載速率”、“數(shù)據(jù)準(zhǔn)確度”等指標(biāo)），還包括功能操作、bug 處理、產(chǎn)品迭代、運(yùn)營推廣、系統(tǒng)間耦合、業(yè)務(wù)賦能的效率，簡而言之就是從“產(chǎn)品本身→系統(tǒng)生態(tài)”的效率。
但產(chǎn)品出現(xiàn)并不是無中生有，而是通過人工生產(chǎn)得到，所以在它的背后包含著開發(fā)、設(shè)計、管理、運(yùn)營、生態(tài)5個方面的具體工作，從而保證產(chǎn)品從“能用→易用→好用→有用”的過渡。
本次作業(yè)我就不聊企業(yè)了，就把梁寧留的作業(yè)范圍縮小一下，聊聊前公司那款 DAU 從幾人到幾百人的數(shù)據(jù)可視化產(chǎn)品（DAU雖是虛榮指標(biāo)，但作為一款內(nèi)部工具產(chǎn)品，這個數(shù)據(jù)表現(xiàn)已經(jīng)很優(yōu)秀了）。
這次我將化身一位講故事的人，通過5個“效率”有關(guān)的故事帶你來搞懂?dāng)?shù)據(jù)可視化產(chǎn)品（亦稱 BI 可視化工具）。
一、故事1：開發(fā)效率——從入行到敏捷開發(fā)改革
2018年的一次跳槽，我從策略平臺產(chǎn)品經(jīng)理，轉(zhuǎn)行成為了X公司的數(shù)據(jù)產(chǎn)品經(jīng)理。
同期，研發(fā)部門也發(fā)生了一次人事變動，X公司公認(rèn)的最優(yōu)秀的大數(shù)據(jù)開發(fā)工程師 Todd 成為了 unicorn （X公司自研的一款數(shù)據(jù)可視化 BI 工具產(chǎn)品）的后端研發(fā)負(fù)責(zé)人。作為初涉大數(shù)據(jù)領(lǐng)域的產(chǎn)品人，與認(rèn)真、專業(yè)的技術(shù)同學(xué)合作是一件非常開心的事。
共事的初期，Todd 總會提醒我：“做數(shù)據(jù)最重要的兩點就是準(zhǔn)確性和計算速率?！?/p>
所以在最初的近3個月時間里，unicorn幾乎沒有做任何新功能的迭代（特別影響用戶體驗的功能除外），除了給內(nèi)部數(shù)倉同事使用外，甚至上沒有給其他部門做推廣。
因為早期的 unicorn 有兩個特別大的問題：一個是所有的計算邏輯全部由前端實現(xiàn)，增加了圖表渲染的時間；另一個就是歷史存在很多計算異常的功能，造成數(shù)據(jù)計算不準(zhǔn)確。
在那段時間，我們把所有的計算邏輯加工由前端轉(zhuǎn)到后端實現(xiàn)，加快了圖表數(shù)據(jù)展示的速率。同時，我們還為 unicorn 設(shè)計了一套緩存機(jī)制，確保相同數(shù)據(jù)查詢直接訪問上次已查詢好的數(shù)據(jù)。
另一方面，在早期的用戶群里反饋的計算錯誤問題，后端開發(fā)們一直保持今日事今日畢。
最后值得一提的是，作為非商業(yè)化的公司內(nèi)部系統(tǒng)產(chǎn)品，經(jīng)過整個 unicorn 項目組的討論，我們采取了2周一個迭代的開發(fā)周期，這些都為未來 unicorn 的 DAU 數(shù)據(jù)打下了堅實的根基！
二、故事2：體驗效率——快速構(gòu)建一張 Dashboard
unicorn 的用戶和所有的 BI 可視化工具一樣，主要分為兩類角色：作圖者（一般為數(shù)據(jù)分析師）和看圖者（一般為業(yè)務(wù)人員）。
因為有這兩種角色，所以“高效”也有兩大特點：看圖者能夠快速定位、探查問題，這里的細(xì)節(jié)可以參考之前的文章《數(shù)據(jù)+產(chǎn)品就是數(shù)據(jù)產(chǎn)品？漫談數(shù)據(jù)可視化場景》，這里將不再贅述。
而對作圖者而言，“高效”意味著能夠快速搭建一張 Dashboard。
使用過 BI 可視化工具的同學(xué)應(yīng)該清楚，配置儀表盤的主要流程分為三步：連接數(shù)據(jù)源 → 配置數(shù)據(jù)集 → 制作報表。
其實絕大多數(shù)的 BI 工具在“連接數(shù)據(jù)源 → 配置數(shù)據(jù)集”環(huán)節(jié)的操縱基本都差不多（有一種特殊的方式，后面有機(jī)會將會用整張篇幅介紹），而在“制作報表”環(huán)節(jié)上， unicorn 卻經(jīng)歷過一次由低效到快捷的變革。
在接手 unicorn 時，“制作報表”是參考一個開源的 BI 工具的制作流程：創(chuàng)建畫布后，需要添加已經(jīng)創(chuàng)建好的圖表，全局篩選器可以在畫布區(qū)域添加，而針對單表的是篩選器是創(chuàng)建圖表時添加（Dashboard 包含三個主要元素：畫布、圖表、篩選器）：
其實，上述過程我們可以看到是一個工程化思維的過程，圖表和圖表篩選器是一一對應(yīng)的關(guān)系，畫布與全局篩選器也是一一對應(yīng)的關(guān)系，圖表之間是存放在一起的組合關(guān)系，而畫布則是包含這些圖表的關(guān)系。
如果用這種方式向他人介紹 BI 可視化工具，那是非常棒的，但是交給用戶去操作不難發(fā)現(xiàn)儀表盤的創(chuàng)建是不連貫的。為了保證用戶的操作連貫性，我們把 unicorn的操作方式做了修改，讓用戶創(chuàng)建畫布、圖表、篩選器都是在同一個視窗下完成的：
除了整體流程的優(yōu)化，各個功能模塊的優(yōu)化也滿足用戶的心智模型，在“故事3”中我會繼續(xù)講述相關(guān)的內(nèi)容。
三、故事3：管理效率——由被動到主動，由抄襲到創(chuàng)新
2018年時，雖然我已經(jīng)有了幾年的產(chǎn)品經(jīng)驗，但是數(shù)據(jù)產(chǎn)品的經(jīng)驗卻是0。且數(shù)據(jù)產(chǎn)品會涉及技術(shù)性的工作，所以一開始我更多是跟著開發(fā)的思路去走。
在接手 unicorn 時，用戶全為本部門的幾個數(shù)倉同學(xué)，基本上他們提什么需求方案就跟著做什么需求方案，實現(xiàn)方式也被動接受后端開發(fā)的設(shè)計思路，作為一個產(chǎn)品人把大腦交給別人是一件非常痛苦的事情。
一個多月的時間里，我開始一方面記錄 unicorn 的迭代路徑，發(fā)現(xiàn)產(chǎn)品的迭代基本上是東一榔頭西一棒槌，缺乏方向性的規(guī)劃；另一方面從零開始學(xué)習(xí)基礎(chǔ)的 SQL 查詢語句，學(xué)習(xí)每個功能背后數(shù)據(jù)流轉(zhuǎn)，了解了現(xiàn)存功能亟待改善的功能點。
“你可以跟我提需求，但是你必須得跟我講背景……”看過我之前文章的朋友應(yīng)該知道，這句話是我對數(shù)倉同學(xué)說的與一開始發(fā)生180°反轉(zhuǎn)的話，這也是我做數(shù)據(jù)產(chǎn)品發(fā)生改變的起點。
隨后我開始重新制定了新的需求提報標(biāo)準(zhǔn)（需求錄入表），增加“講背景、說問題”的環(huán)節(jié)，而不是直接說解決方案。為了避免過分改革帶來潛在的影響（感興趣的朋友可以了解一下王莽改革），我保留了數(shù)倉同學(xué)愛直接提方案的行為，只是在備注了其為“建議方案”，即最終實現(xiàn)以產(chǎn)品設(shè)計為準(zhǔn)。
同時，需求的優(yōu)先級、排期等設(shè)定的歸屬權(quán)歸為我們項目組討論處理，參考如下（僅白色填充的表頭所在列，支持需求提出人編輯填寫）：
伴隨著需求池的規(guī)范化整理、分類，整體方向性的迭代規(guī)劃也有了藍(lán)圖。
此外， unicorn 的設(shè)計也不是完全抄襲著 Tableau、網(wǎng)易有數(shù)等之類的商業(yè)化 BI 工具功能流程，就以篩選器作用圖表的功能為例吧，Tableau 支持如下圖所示的應(yīng)用范圍選項：
其實，Tableau 是以數(shù)據(jù)視角而非圖表視角設(shè)計這項功能的，“僅此工作表”還容易理解，但前面兩個選項（選項1是跨數(shù)據(jù)源篩選的功能，選項2是針對同一數(shù)據(jù)源的所有圖表）的名稱就是要讓用戶更關(guān)注數(shù)據(jù)而非圖表本身，讓用戶用不同視角去理解并列關(guān)系的選項，這種設(shè)計本身就很反人性。
再者，如果在 Tableau 上想跨多個數(shù)據(jù)源篩選數(shù)據(jù)還要得保持字段名稱一致，如果不同的分析師在數(shù)據(jù)集命名出現(xiàn)不統(tǒng)一的情況（數(shù)據(jù)集存在 BI 工具下，而非存在數(shù)倉，所以命名規(guī)范一般沒有強(qiáng)要求），還需要重新改一下，真的是很麻煩。
第二個突出問題在 Tableau、網(wǎng)易有數(shù)兩款產(chǎn)品上都有表現(xiàn)，在設(shè)置篩選器的步驟上，都是先要先“選擇篩選字段”再“選擇對應(yīng)的圖表”，如下是 Tableau 與網(wǎng)易有數(shù)的配置截圖：
可是我每次使用時都有些變扭，總感覺順序和我心里想的不一樣。我們寫過 SQL 語句的朋友都知道，我們在查詢數(shù)據(jù)時一般都是寫形如下方的語句，篩選條件都寫在最后：
SELECT column_name? //展示數(shù)據(jù)，即拖入 BI工具中的行、列字段
FROM table_name? //應(yīng)用的數(shù)據(jù)集/圖表
WHERE Filters? //篩選字段
所以我在設(shè)計篩選器設(shè)置流程時，就改變了配置的順序：
在咨詢完一些分析師同學(xué)后，他們也覺得這樣的方式體驗更佳。同時，我們還在設(shè)置上做了一定的優(yōu)化，比如當(dāng)設(shè)置其中一個圖表的字段后，若其他圖表也有同樣名稱的字段，其他圖表會默認(rèn)選中該字段：
四、故事4：運(yùn)營效率——從領(lǐng)導(dǎo)包圍團(tuán)隊，用認(rèn)真留住用戶
在文章開頭我們就提到了unicorn 是 DAU 從幾人到幾百人的數(shù)據(jù)可視化產(chǎn)品，那在公司已經(jīng)有 Tableau 的背景下，這個內(nèi)部的 BI 工具是怎樣運(yùn)營推廣的呢？
其實，一開始我盲目的在作圖人（分析師）、看圖人（業(yè)務(wù)人員）間兩頭推，可是近一個月時間下來，只從幾人推廣到了十幾人。
后來我開始調(diào)研了之前推廣的同事為什么不用 unicorn，他們的回復(fù)驚人的一致：“我們看分析看板都是用 Tableau”。
我意識到unicorn在大家的眼里并沒有存在感，再用這種常規(guī)的方式推廣肯定還是很少的人在用，如果想讓更多的同事使用，那就有必要采取自上而下的方式推廣了。
我和主管一塊找到了兩個大部門的負(fù)責(zé)人，給他們演示了我們的系統(tǒng)，并了解到了他們目前共同擁有的最大痛點：用 Tableau 必須在公司網(wǎng)絡(luò)環(huán)境下才可以使用，而在路上想去便捷的查看數(shù)據(jù)時基本不可能。
為了讓這些部門主管協(xié)助我們在他們內(nèi)部推廣，首先就是解決主管們的痛點。
在接下來的一個迭代周期立項后，我們前端同學(xué)終于研發(fā)出了 Dashboard 的截屏功能，并打通了釘釘群的接口，支持配置定時任務(wù)向釘釘群發(fā)送截圖。這樣手機(jī)不用下載 Tableau APP 且不連接公司 VPN 也可以在上下班路上查看數(shù)據(jù)了。
解決了這些部門負(fù)責(zé)人的痛點后，他們自然而然地開始在部門內(nèi)部推廣。因為用戶量的擴(kuò)大，很多產(chǎn)品的問題也開始從發(fā)現(xiàn)到修復(fù)或優(yōu)化。
因為有了一個部門的使用，我們在給其他部門推廣時就方便了很多，每次推廣都會說：“***部門已經(jīng)開始使用了，他們用的效果非常好，你們可以問問他們……”
為了更好地留住客戶，我們在產(chǎn)品頂部增加了“吐個槽”入口，并開通了釘釘群，讓有問題的同事可以即時上報問題。在“故事1”中也提到了，用戶反饋的問題基本上保證盡快的處理，而計算錯誤的問題，一直保持當(dāng)日反饋當(dāng)日解決。
最后，我們還為 unicorn 打造了一個客景監(jiān)控看板：“哪些用戶經(jīng)常訪問unicorn”、“哪些用戶登錄過一次至今就不再登錄”……這些數(shù)據(jù)都盡收眼底，而我每周也會從中抽取1~2位客戶去了解他們的使用情況，也為未來的系統(tǒng)規(guī)劃提供了寶貴的建議。
五、故事5：賦能效率——中臺化，unicorn 不再是一個單純的 BI 工具
unicorn如何做好賦能，除了狹義上的賦能，即提供更高效的可視化展示（包括支持多樣化的圖表、支持個性化的預(yù)警、提示用戶關(guān)注相關(guān)指標(biāo)等）外，還包括廣義上的賦能。
其實 BI 可視化工具本質(zhì)上屬于 B 端產(chǎn)品，所以其追求的還是在于“效率”。
在企業(yè)內(nèi)部，除了 BI 可視化工具外，很多內(nèi)部系統(tǒng)都會有圖表展示的需求。比如投放系統(tǒng)“投放后的效果如何？”可以用可視化系統(tǒng)展示，同樣 CRM 系統(tǒng)“各個銷售同事的業(yè)績?nèi)绾?？”也可以用可視化系統(tǒng)展示。如果我們給兄弟部門的系統(tǒng)支持可視化的能力，是不是就能夠節(jié)省他們的開發(fā)資源，并提升 unicorn 自身的價值呢？
我們在這項工作上，給其他業(yè)務(wù)系統(tǒng)提供了兩種不同的支持服務(wù)：一種是輕量級的支持，僅提供圖表可視化能力；另一種是重量級的支持，同時提供圖表可視化能力以及數(shù)據(jù)計算能力的服務(wù)。
在 unicorn 中臺化支持服務(wù)中，“圖表可視化能力”主要是依賴我們前端同學(xué)開發(fā)的圖表庫組件，為滿足業(yè)務(wù)的展示需求，在 Echarts 開源圖表上進(jìn)行了改造。
而數(shù)據(jù)計算能力，考慮到不對 unicorn 做太多的系統(tǒng)改造，我們創(chuàng)造性地設(shè)計了一個參數(shù)傳遞功能。這是在 Tableau 參數(shù)傳遞功能上的進(jìn)一步創(chuàng)新，目前 Tableau 僅支持內(nèi)部儀表盤之間的參數(shù)傳遞，或者是內(nèi)部圖表對外部系統(tǒng)的參數(shù)傳遞，唯獨(dú)缺少外部系統(tǒng)對系統(tǒng)內(nèi)圖表的參數(shù)傳遞。
在支持 CRM 系統(tǒng)“讓各個銷售同事查看自己銷售業(yè)績”的項目中，我們將公司統(tǒng)一賬戶系統(tǒng)的“用戶 ID”作為參數(shù)變量，在 unicorn 內(nèi)用包含銷售業(yè)績的數(shù)據(jù)集，創(chuàng)建了包含若干圖表的儀表盤，再將該儀表盤通過加密外鏈嵌入到 CRM 內(nèi)，就實現(xiàn)了“千人千面”的銷售數(shù)據(jù)展示，即每個登錄 CRM 的銷售同事僅能查看到自己的銷售數(shù)據(jù)：
5個小故事到此就講述完了，讀完之后你是否對數(shù)據(jù)可視化產(chǎn)品有了更深入的認(rèn)識呢？如果你有其他問題或者不一樣的見解，歡迎在下方留言與我討論。
#專欄作家#
兮兮，微信公眾號：孤身旅人（ID：gushenlvren），人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注人工智能、toB產(chǎn)品、大文娛等領(lǐng)域。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自 Unsplash，基于 CC0 協(xié)議
有數(shù)新增的篩選器，會默認(rèn)關(guān)聯(lián)已有的圖表，也可以說沒有先后??
（捕獲4群的兮兮童鞋哈哈）
當(dāng)時我們是2018年就設(shè)計了，嘿嘿。（話說我改了馬甲了，哈哈）
作者覺得ifind的BI模塊怎么樣
你說的是同花順工具里面的BI模塊嗎？
是啊
留言的伙伴越來越少，支持一下
謝謝~