數(shù)據(jù)可視化可以幫助我們更好的分析數(shù)據(jù)，本文作者對項目流程進行分析與難點總結，分享了自己在實戰(zhàn)中的經驗，通過簡單的例子幫助大家在項目實施中避免踩坑，一起來看看吧。

本文以to G領域為例，從產品經理的角度，講述數(shù)據(jù)可視化項目在實施過程中的一些經驗，通過對項目實施全流程、階段難點的總結，希望能夠對大家有所啟發(fā)。

拋開項目售前、立項階段的產品支撐，在數(shù)據(jù)可視化項目實施過程中，需要我們產品經理參與的通常有需求調研、系統(tǒng)設計、研發(fā)跟進等多個階段。

可以將其總結為一個流程“需求調研—系統(tǒng)設計—研發(fā)管理—項目驗收”，同時每個階段又有若干關鍵子任務，見下圖。

本文主要針對實施流程的關鍵任務、典型問題以及項目管理知識的講解，為大家提供一些思路。

一、項目實施流程

下面是對項目實施主要流程的簡介，要注意的是每個階段都要有明確的產出物。

1. 需求調研

當項目立項后，產品經理可能會出差客戶現(xiàn)場，進行各項調研，常見的有業(yè)務調研、數(shù)據(jù)調研、競品調研。

（1）業(yè)務調研：調研項目建設方的業(yè)務訴求、組織架構以及各部門關系。

（2）數(shù)據(jù)調研：調研數(shù)據(jù)提供方的業(yè)務數(shù)據(jù)范圍、數(shù)據(jù)質量以及信息化程度。數(shù)據(jù)調研是可視化項目實施的關鍵，決定了可視化的業(yè)務價值及效果展現(xiàn)，同時也是指標體系搭建的關鍵步驟，決定項目建設方能接入的數(shù)據(jù)量、如何接入的內容。

（3）競品調研：調研行業(yè)內的做法，對齊行業(yè)頭部產品。當我們了解客戶需求、數(shù)據(jù)情況后，在進行系統(tǒng)設計時，不能全靠產品經理自己經驗來做，尤其是對于一個不熟悉的項目領域。

2. 系統(tǒng)設計

當?shù)谝浑A段工作完成后，根據(jù)開始進入指標體系的搭建、原型設計，此階段的目標是快速驗證產品經理對項目業(yè)務的理解，拿到客戶的認可，降低需求變更風險。

（1）指標體系搭建：對齊業(yè)務需求，完成指標體系搭建。指標體系搭建是個大工程，不僅要考慮業(yè)務的維度與指標，還要考慮數(shù)據(jù)質量問題。這里暫且不做詳細的設計闡述。

（2）系統(tǒng)原型設計：線框圖對思路，高保真對內容。使用線框圖快速向客戶匯報思路，使用高保真原型讓客戶感知可視化效果。這里要注意業(yè)務指標與各類圖表的選擇，要讓圖表清晰表達，為了美觀可以在圖表UI上美化，而不是自己發(fā)明一種圖表。

指標體系、原型設計都不是一步到位的，往往要進行多次調整優(yōu)化，盡可能將全面、詳細同客戶確認需求，以此降低后續(xù)研發(fā)中的變更成本。

3. 研發(fā)管理

當設計方案通過客戶認可后，產品經理下一步要做的就是對接研發(fā)，此階段主要目標是讓研發(fā)團隊理解系統(tǒng)需求、根據(jù)排期進入研發(fā)，最終上線系統(tǒng)。在這里要說明的是，研發(fā)排期、團隊分工等主要是由研發(fā)經理進行，產品經理知曉即可。

（1）開發(fā)評審：同步研發(fā)需求，減少信息差。在這個階段，產品經理要拉上研發(fā)經理、研發(fā)團隊一同評審需求。從上而下的方式，大致講解業(yè)務需求，再詳細對接原型內容。

（2）需求管理：管理需求變更及優(yōu)先級，降低研發(fā)風險。在系統(tǒng)進入開發(fā)時，需求變更是避免不了的。要做好需求的管理，尤其是優(yōu)先級的管理。

（3）BUG跟蹤：執(zhí)行測試計劃，BUG優(yōu)化落實到人、及時更改狀態(tài)。測試計劃由測試人員進行，產品經理要及時跟進并驗證。

4. 項目驗收

中大型項目的驗收通常會有初驗、試運行、終驗等階段，項目經理會統(tǒng)籌整個項目的驗收，產品經理涉及到的內容也比較多，如驗收文檔、培訓等內容，此階段主要目標是順利通過驗收，其他方面的事項優(yōu)先級靠后。

（1）系統(tǒng)演示：充分體現(xiàn)客戶可視化效果、數(shù)據(jù)價值。可視化大屏最重要的就是如何體現(xiàn)數(shù)據(jù)價值，為了保證演示順利進行，可以提前準備演示腳本、演示數(shù)據(jù)、操作流程等內容。

（2）驗收文檔：常見的有概要設計、詳細設計等內容，產品經理要配合研發(fā)一同編寫。

（3）驗收會議：驗收會議不單指一個會議，可能會包含專家評審、使用培訓等內容，產品經理在這部分做好支撐即可。

二、典型問題與解決方案

一個中大型的數(shù)據(jù)可視化項目實施有多組織、數(shù)據(jù)質量差、可視化個性化等特點，每個環(huán)節(jié)都會遇到棘手的問題，下面羅列出三個典型的例子，并給出了一些解決方案。

1. 可視化效果意見不一

本質上每個人對可視化的審美不同，導致了客戶對可視化效果意見不一。這其實也是很大的一個風險，很可能導致開發(fā)返工、需求蔓延以及超出工期。

解決方案：

• 畫高保真原型，讓客戶有清晰認知。線框圖對于可視化大屏來說很雞肋，無法將視覺效果良好地傳達給客戶。所以要出高保真數(shù)據(jù)可視化原型，必要時求助設計師出素材。
• 定期匯報，說服客戶認可設計方案。設計完系統(tǒng)后，及時同客戶開會評審，包括業(yè)務方案、指標體系、UI風格等內容，拿出自己對行業(yè)的理解說服客戶認同方案，盡可能減少需求蔓延。

2. 跨組織協(xié)調難，數(shù)據(jù)對接難

跨組織協(xié)調本身就不是容易的事情，而且涉及到各個單位對數(shù)據(jù)的安全性很敏感，導致相關方配合意愿不強。

解決方案：

• 針對縱向單位，通過上級單位的通知執(zhí)行命令。比如在建設市級大數(shù)據(jù)中心時，需要對接區(qū)縣數(shù)據(jù)，有些單位不配合，那么就可以通過這種方法。
• 針對橫向單位，通過單位間舉行座談會、發(fā)函等渠道協(xié)商。通過正式的方式了解各方對于數(shù)據(jù)的顧慮，拋出單位間利益相關之處。
• 簽訂保密協(xié)議，保證數(shù)據(jù)安全?？蛻魡挝慌c數(shù)據(jù)提供單位簽訂保密協(xié)議，打消數(shù)據(jù)提供方的顧慮。

3. 數(shù)據(jù)質量有問題，導致可視化效果差

當系統(tǒng)設計、指標體系都得到客戶認可時，數(shù)據(jù)質量導致系統(tǒng)價值體現(xiàn)以及效果展示無法達到最佳。

如數(shù)據(jù)源由于接口開發(fā)預算、安全性等各種問題遲遲接入不了，導致已經開發(fā)好的系統(tǒng)無法展示良好的效果。

解決方案：

• 學會取舍，永遠要有Plan B。當我們完成原型設計后，根據(jù)數(shù)據(jù)調研情況，預估下哪部分數(shù)據(jù)質量可能有問題，再調整業(yè)務出一版本設計，以防萬一。
• 向客戶說明情況，討論解決方案。由于外部原因導致的數(shù)據(jù)質量問題，一定要先同客戶說明，再進一步決定取舍。

三、風險管理知識補充

上面提到了很多問題，同時也是項目的風險，做好風險管理能夠有效幫助我們順利完成項目。

項目風險管理包括規(guī)劃風險管理、識別風險、開展風險分析、規(guī)劃風險應對、實施風險應對和監(jiān)督風險的各個過程，主要目標是在于提高正面風險影響和降低負面風險影響，從而提高項目成功可能性。

下面舉個例子來講述規(guī)劃風險應對的過程。

小明是一個程序員，平時工作挺忙，為了鍛煉表達能力，于是參加了一個脫口秀演講比賽。加入比賽有個條件，面試分數(shù)達到90分或者直接交1000元會員費也可進入決賽。

通常情況下他每晚七點下班，周末雙休；在趕項目期間可能會加班到凌晨，周末休息時間隨叫隨到。

他的表達能力不是很好，而且對脫口秀比賽毫無經驗，需要經過大量訓練才有可能進入決賽。

在案例中可以看出風險來源于多個方面，如時間管理風險，技能經驗風險等。針對這些威脅可以考慮一下備選策略。

1. 規(guī)避

規(guī)避高風險操作。

對于小明來說，他并不具備脫口秀相關演講的技能，會導致他可能進入不了決賽，這就是嚴重的負面風險，已經達到了風險臨界值即無法參賽。

這個時候可以采用規(guī)避的策略，將風險拉回臨界值內。

對于小明來說，交會員費進入決賽這個是項目中的高風險工作，因為通過這種方式進入決賽導致無法獲獎的結果可能性很大，應該避免這種行為。

2. 開拓

開拓正面風險。

分數(shù)達到90分，這是個正面風險，因為通過不斷地練習，提高演講能力后達到了90分，這對進入決賽以及在決賽中的表演都起到了正面的作用。

需要采取開拓策略提高效益，如參加脫口秀演講培訓，鍛煉自己的寫段子能力和演講能力。

3. 接受

主動接受風險。

正在參加培訓的小明突然被叫回去加班，同時又無法做出時間調整。

這個時候只能采取被動接受策略，即定期地對發(fā)生這種風險的情況進行審查，確保在自己可控范圍內。

同時還可采取主動接受方法，預留出一部分時間以保證培訓課程的完成。

風險會在項目生命周期內持續(xù)發(fā)生，所以，項目風險管理過程也應不斷迭代開展。

在項目規(guī)劃期間，就應該通過調整項目策略對風險做初步處理。接著，應該隨著項目進展，監(jiān)督和管理風險，確保項目處于正軌，并且突發(fā)性風險也得到處理。

作者：Shawn，某大數(shù)據(jù)公司BI產品經理；擅長數(shù)據(jù)可視化、低代碼領域；“數(shù)據(jù)人創(chuàng)作者聯(lián)盟”成員。

本文由 @一個數(shù)據(jù)人的自留地 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

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