很多大資料的從業者，都清楚的知道，在大資料公司裡，或者是大資料的專案裡，都設有獨立的資料部門，而且如果部門內的的人員規模足夠大的話，還會進一步考慮劃分成幾個小組，比如BI、大資料、資料產品和UED，甚至還可能會有資料探勘組、爬蟲組。大家各盡其責，在自己的崗位上相互獨立的去工作，雖然經常會遇到「資料專案」需要大家一起協作完成，但卻很少有人徹頭徹尾的去了解整個專案中的資料遷移，頂多也只是任務之間的對接而已。

如果每個人都只扮演著流水線上的一顆螺絲釘，那這種半封閉式的工作流程到底好不好呢？

我認為，如果站在「資料專案」敏捷開發的角度，讓所有人都只專注自己熟悉的技術領域，短期內這或許是一件好事。但是長期下來，從專案的質量和創新來說，不見得是一件好事，因為認知的侷限性，很難有人去全方位把控「資料專案」的方向和深度，從而導致同質化的資料產品一大堆，但都普遍缺乏創新性，也談不上價值。同時從個人的成長進階來看，弊肯定大於利。

別讓「侷限」矇蔽了你的雙眼，讓你失去了無限的想象空間，也讓你很難去最大化輸出個人價值。

如果ETL工程師不懂業務的話，那麼他就只是一個工具罷了，由業務人員提供需求和邏輯，他只負責加工資料，但卻很難去驗證資料的準確性，更別談理解資料質量。

如果資料分析師不懂技術的話，那麼他就只是在玩轉小資料，由業務人員提供需求和表源，他就負責寫SQL去分析資料。但他常常會把簡單的SQL語句寫得巨耗時，也不懂得去挖掘資料背後的意義，更別談去做深度分析。

如果資料產品經理不懂的資料和技術的話，那麼他就只是在天馬行空，一切的構思都源於競品分析，他就負責去完成功能堆積。但他卻不理解功能背後的技術細節，也不懂得資料價值如何去落地，更別談去推動產品運營。

而這些「如果」，並不是「假設」，而是實際發生在我們身邊，無時無刻不引起注意的案例。

自從部門對外開放了「資料查詢平臺」給業務運營人員和資料分析人員使用以後，總是會在後臺看到幾百~上千行的SQL語句，先不談執行效率，這語法邏輯跑出來的資料，其準確性都值得質疑，還如何談後續的深度分析工作。

曾經還有一位資料產品經理在規劃智慧營銷產品時，憑空堆積了很多無腦的功能，不去解決「效果跟蹤分析」，反倒是列舉了一些沒價值的資料指標做大屏展示。還有所謂的「資料管理」、「模型訓練」，都讓你無法直視。根本不知道他在解決什麼痛點需求，所以後續就不帶一起玩了。

所以說，我一直在提倡大家要致力成為「綜合性資料人才」，這也是未來市場上最緊缺的資料人才。而所謂的「綜合」，並不是要求你在每一個數據環節都要專研很深，而是要讓你在資料認知的廣度上打破盲區，這樣才能更好的服務於你所扮演的資料角色，更全面去理解資料的價值。

就像資料探勘工程師一樣，你不能只關注資料建模的環節，如果你只把精力全放在「演算法專研」和「演算法調優」上，不親自去了解底層資料，也不結合業務去做使用者分析和資料清洗，甚至不去思考模型結果後的業務運營以及產品包裝，那你就不能說是在探索「資料價值」了。

總而言之，資料沒有邊界，你也不應該閉門造車，資料認知的廣度和深度也是相輔相成的。