在很多大資料公司裡，不論大資料專案的大小，技術部門和業務部門總有或多或少的矛盾。本文由科多大資料的張老師分享。

我們深知：技術服務於業務，業務驅動技術去發展，兩者密不可分。換句話來說，技術幫助業務去解決問題，業務給技術一個機會去證明價值，兩者相輔相成。不過在大多數公司裡，技術的存在感會弱於業務，這可能會讓你感到不舒服，但它就是一個不爭的事實。

作為一個技術人，你認為自己很厲害。但是如果業務人員和你溝通協作起來效果很差，或者認為你的業務能力很薄弱的話，他們很有可能就會否定了你的成果，這種結局在一定程度上也會影響你的工作熱情和能力提升。

而且平臺運營的決策權在於業務人員手裡，在一些業務人員看來，需求是他們從實戰運營中提出來的，最終的落地也需要他們親自去實施，至於如何去實現這個想法，那就交給技術人員去開發好了，他們負責把關驗收就行。

所以，在真正面對這樣的機會時，一定要多關心業務方的需求，理解業務的痛點，特別是做資料相關的專案時，試錯成本會很高，業務方也沒有耐心去給你重複調整的時間，畢竟業務每天都在變化。如果把握錯了業務，這個專案極大可能性會泡湯。這裡舉一些反面的例子。

① 資料中心想單獨去開發一套「演算法平臺」，藉助Spark的計算優勢，同時封裝一些演算法庫去給業務部門提供流程化的挖掘功能，支援頁面互動來使用，支援資料視覺化。再開放R和Python的介面，提供業務方的自定義建模。

說簡單一些就像把SPSS軟體的功能重新開發一遍，接入大量的資料來源，再配上一個高速的計算引擎。

這個構思看起來很美好，但是卻很難實施和落地，因為業務方真正的需求不在於這，所謂的資料探勘也沒有想象中的如此簡單，況且本地計算機對生產環境的資料訪問被堡壘機所切斷，叢集資源的隔離也是需要考慮的問題。

總而言之，即使你耗盡全力去開發出「演算法平臺」，但卻很難去派上用場，因為業務方的痛點可能只是想讓你開放資料介面，讓他們所關心的使用者資料定期同步到自己的資料庫中，再選擇自己擅長的工具去構建模型。

② 再談談「標籤系統」的產品，資料中心做厭煩了資料報表，決定從使用者畫像的角度做一個底層標籤系統，橫向可以不斷擴充套件使用者標籤，且支援單個標籤的實時更新。對跨部門可以提供資料服務，從而支援線上的使用者運營和營銷工作。

這個構思同樣看似美好，但如果沒有理解業務需求的話，難免又被淪落為一張資料報表的結局，同樣沒有多大價值。

我瞭解下來，很多做「標籤系統」的平臺，一張寬表包含了500多個標籤，不定期還有新的業務指標新增進來，而這些欄位大多數都來源於業務的日常營銷需求中，特別零散、初級和臨時。如果你是做業務運營的，面對這500多個欄位，你很難選擇精準的標籤去做營銷。

所以說，看起來是支撐線上使用者做營銷，但卻沒有理解使用者畫像的核心，甚至是沒有正確去理解和引導業務的需求，而業務方只關心如何去提升營銷效果。所以正確的做法就是專注一些挖掘性質的標籤開發，從根本上去解決運營的痛點營銷需求。

③ 我所看到的，還有一些失敗的專案，比如反欺詐系統、知識圖譜、使用者全生命週期、智慧客服等等，基本都是在自娛自樂的專研。

「資料中心」想跳出以往的「BI報表」體系去做一些分析型或決策型的資料產品，這個出發點本身沒有錯。但是卻因為沒有經驗，只想著資料創新，很少去主動的調研業務需求，去理解業務痛點，去構思應用場景。這樣的話，整個部門所做的一堆資料專案，可能就會陷入尷尬的局面，要麼產品開發不出來，要麼產品解決不了業務痛點，要麼產品的決策效果不佳。

大方向如果沒有把握正確，何談資料價值的探