大資料文摘出品

編譯：張大筆茹、LYLM、夏雅薇

今天文摘菌為讀者們推薦一篇文章，來自一位資料工程師Taylor Murphy分享的，他成為資料團隊經理一年以來的經驗教訓。

2018年4月到2019年5月期間，我擔任GitLab資料團隊的經理。在我的經理離職後，我開始以資料工程師的身份直接向CFO彙報工作。

我記得對他說：“對於您來說，讓我擔任經理似乎不是正確的選擇。”我還表示不想長期擔任經理的角色，因為我之所以來到GitLab，從經理變為工程師，就是為了專注於資料工程領域。

下面是我任職資料團隊經理一年學到的（並重新學習的）一些經驗教訓。我的目標是再次成為一名經理，希望能記住這些經驗並學到更多。

計劃幫助業務增長

我擔任資料團隊經理期間，GitLab的規模增長了約300％。對於以前只在知名公司和一家很小的初創公司工作過的我來說，我並沒有準備好應對這種增長水平及相伴隨的的資源壓力。

最近我對資料部門中的同事做了個調查，發現大多數公司資料團隊的數量佔全體員工數量的2％至8％。

這意味著一家擁有200名員工的公司應至少有4名資料人員，實際上大約有10名人員，包括數分析師，工程師，科學家和經理。2018年4月，我們的人員低於1％（1/300），且整個2018年繼續低於1％。

隨著公司的發展，我並沒有完全瞭解企業計劃的實施以及資料團隊將如何擴張以滿足各部門的資料需求。由於缺乏戰略思維，我對資料和分析的需求應該達到多少才算合理感到迷茫而不知所措。

雖然我聘用了更多優秀的人才，但沒有做好我的工作來幫助我的團隊取得成功。

經驗：資料團隊經歷應該瞭解公司的發展軌跡，擁有和期望承擔的工作量，合理選擇人員的數量，堅持招聘並考慮團隊結構。

個人貢獻者還是帶團隊？選其一

2018年底，我們的資料團隊由三個人組成：一個數據分析師，一個數據工程師和我。可以自信地說，我們三個人的工作能力都十分出色，超出三個普通全職員工的工作水平。

但是我們也有侷限，很多事還是來不及做。

由於工作量巨大，有時我需要同時承擔分析師和工程師的工作。所以我常常一次想同時做好幾件事。

有時候，我需要做很多管理工作，所以就沒時間處理分配給我的工作。如果專注只做我自己的事，我又沒法管理團隊。最糟糕的時候是我同時想做兩件事情，但一件也做不好。

隨著時間的流逝，這種分身無力的情況變得越來越糟，我開始感到身心俱疲。

我本可以僱用更多的人，但這又對我的管理能力提出了更多要求，工作量在增加，而我還是程式碼庫的主要編輯者和維護者。後來，我覺得自己既不是一個好經理，技術也在變差。

經驗：如果你是經理，請做一名全職經理。是的，你需要承擔一些工作，尤其是在專案開始時，但要想清楚退出機制，以便將這項工作交接給團隊，團隊會比你做得更好。

僱傭最棒的員工

僱用優秀的人才會使你的工作更輕鬆。最初資料團隊的四名員工（2018年兩人，2019年初兩人）擁有令我歎服的好奇心，堅韌和智慧。

我從以前的工作和老闆那裡學到了尋找優秀人才的重要性，以及他們在完成工作時的驚人效率。

經驗：堅持僱用優秀人才，並考慮如何能夠大量招到賢才。

專注於過程

我從Emilie Schario（我僱用的第一位資料分析師）那裡學到了這一課。她教我思考公司擴大規模時如何以及在何處需要流程，以便保持高效。

我們用GitLab來管理程式碼，並且內建了合併請求工作流，但是她花了一些時間來思考圍繞該流程的混亂的人員管理。

她建立了一個簡單的列表：

新分析師的入職準備；

入職指令碼以幫助新分析師快速進入角色；

合併請求的模板，因此每個人都遵循同一個待查清單。

雖然她不是經理，但她經驗豐富並且知道在公司哪些環節掉鏈子會拖慢整個團隊的進度，她想讓工作儘可能自動化。我從公司外部那裡聽說很多人對我們的文件，尤其是入職流程十分讚賞。

這件事說明這位同事非常擅長思考如何讓工作效益規模化，也有同理心去理解GitLab新手的處境，從他們的角度去看問題。

隨著資料團隊的成長和發展，技術化越來越重要。這意味著投資技術流程也很重要：包括對所做的一切都設計版本控制，變更控制（合併請求），自動化測試和文件。

一些工具可以使實施技術流程變得更好，更容易，我將在下一節中重點介紹。

經驗：

（1）深入思考過程並記錄一切。

（2）保持初學者的心態並不斷思考對新人來說第一天使用GitLab是什麼體驗。

（3）對過程下血本，文件和測試會讓你在未來十分受用。

選擇最佳工具

隨著過程的進行，選擇合適的工具可以成為團隊事半功倍。一開始，我們使用PostgreSQL作為資料庫。Postgres不是面向序列的，且在一些時候不能將其用作分析資料庫。

但無論如何，選擇Postgres是因為我們相信使用無聊的解決方案，並且它與我們的迭代價值保持一致。對於要處理的資料量，Postgres的表現十分讓人滿意。使用CloudSQL託管的版本，該版本能夠使用GitLab CI進行出色的程式設計工作（詳見我的另一篇文章）。

一旦超過Postgres的處理能力，我們就決定用Snowflake。

當然，GitLab的產品可以用於任何事物，這為我們節省了挑選工具的壓力。從編碼的角度來看，它有你想要的所有功能，而作為經理，它能幫你提升團隊辦公室協作效率。不需要單獨使用Trello，Jira和其他工具。

到目前為止，對於資料團隊的效率而言，最好的工具是dbt（資料構建工具）。如果沒有dbt和偉大的團隊，我們將無法以如此有限的人手來為公司和社群提供良好的支援。

經驗：團隊最佳工具，用dbt！

如何對待表現不佳的員工是一個挑戰

直到2019年，除了幾名實習生，我沒有僱用過一個能力不足的人。主要原因是我有挖優秀人才的能力比較好，但也有可能只是運氣比較好。

去年，我的團隊中有兩名能力不足的員工，現在我意識到當時本可以提供更好的支援。當我沒有把自己當經理時，我就很難與員工好好溝通。我的建議是要關注前幾周的工作表現，如果發現技能或積極性上有問題，儘可能以友好和高效的方式指出改進方向，然後為員工提供一切提高的機會。

經驗：要做好團隊管理，需及時察覺事件的發生，積極為團隊提供幫助。

開會

GitLab有優秀的開會文化。

首先會議要準時開始，要提前確定議程，若議程順利可提早結束會議。但即便有如此嚴格的紀律，你還是會發現你的經理日程表被大量會議佔據。但這都不是問題。這是工作的的一部分。

我仍會建議你減少會議時間，但如果你需要開會，如果可能的話，儘量讓團隊中其他隊員免於會議。對於生產者來說，比如你的直接下屬，會議是件很麻煩的事。儘可能幫他們擋掉不必要的會議。

經驗：會議是工作的一部分，但要儘可能減少，避免團隊成員參與不必要的會議。

你需要高層的支援

我當初很樂意加入GitLab的原因是因為公司管理層很支援建立一支資料團隊。即使在細節和執行方式還處於模糊階段，CEO和CFO都明白資料團隊能帶來的效益。這很重要。如果公司管理層沒有人能夠明白描述性和預測性分析的價值，你就會處於一個艱難的位置。資料素質是一種企業文化，如果CEO不想推動，這種素質是不太可能發展起來的。

在一定程度上，你要有超出團隊經理所需的資料領導力。你需要一個主管級別以上的人在公司內部離推資料。高管需處理的日常工作很多，因此沒法在這方面花費太多時間。

經驗：要小心那些公司管理層不相信資料的公司。最好要有主管級別以上的人員在公司推動資料。

做好做一些投資的準備

公司高管對資料團隊的支援是非常重要的，因為搭建資料團隊並不便宜。要提高效率，必須僱傭多名員工或者為加強資料管理購買第三方軟體。

首先，你需要諸如Stitch或Fivetran之類的資料提取和載入工具，需要資料庫（例如Snowflake， BigQuery或Redshift），需要計算來轉化資料，還需要BI工具。也有些免費的工具可以湊合一段時間，但如果你需長時間使用，最好投入一些資金。

經驗：遠期的成功離不開投資。剛開始可能可以少花些錢，但兩上去了必然需要花費資金。

不要自己造輪子

尤其像從比如Salesforce， Zendesk， 或是Zuora等工具中提取資料時，千萬別自己寫指令碼來完成。花點錢讓第三方公司幫你完成即可。否則你會把大量時間花費在不能為公司帶來效益的事情上，還可能有無盡的後續麻煩。

你應該把時間花在能夠為公司創造效益的事情上，比如自動彙報和提供洞察等，而不是把Salesforce的Snowflake提取器又寫一遍。

經驗：一般的資料提取任務花點錢在Stitch或Fivetran上完成就好。

經理是一份不一樣的職業

不要把成為經理當做是你作為技術人員生涯的延伸。這是一條不同的職業道路，你的IC技能肯定能幫你成為一個更好的經理。但是，管理有它自己的一套技能，選擇進入該領域會使你走向不同的職業道路。對你而言是否是更好的道路取決於你如何定義成功。

進入管理道路，要認清你是換道而行而非更進一步。不過這也不是永久性的，想掉頭隨時可以。

經驗：不要認為成為經理是IC晉升的必經之路。認真思考你的職業生涯。可參考《選工程師還是經理》一文。

文章連結：

https：//charity。wtf/2017/05/11/the-engineer-manager-pendulum/

It‘s okay to be a little selfish

自私一點也可以

我曾經有些糾結如何變得自私些。我是討好型心態，這種心態在企業初創時期非常有用：初創企業需要大家樂意為公司的成功不計回報地付出（當然了，要合理！）。不過一旦公司開始走向上升階段後，這種心態就會使你異常疲憊。

在我待的上家公司裡只有不到30名職員。保持不斷學習和實踐的態度是很有用的。我學到了非常多，身上也揹負了很多責任，也發展了公司的業務。到了GitLab後，剛開始這種態度是可行的。隨著時間推移，很明顯我沒法掌控所有事情，我的精力開始備受考驗。

自私點是指我必須接受自己想從經理的位置往後退一步退回IC的想法。（提醒：其實不是後退一步！看看上面提到那點！）

我得承認我希望專注在程式設計工作上，而繼續在經理道路上前進對我目前來說並不是一條正確的道路。這個想法其實有點自私，因為現在看公司其實需要的是一位想要當經理的人。我雖恰好處於這個職位，但不一定由我繼續發揮經理的作用。

雖然我退回到IC角色對團隊會有些短期影響，但我會更加舒服，現在我們團隊有著兩位經理，相信比我單人帶領團隊走得更遠。

經驗：

（1）要作出優先順序排序，為自己身心健康著想，自私些是好事。

（2）勇敢地說“不，我不想再繼續做下去了”。

（3）公司需要喜歡自己崗位的職員-這樣他們表現會更好，人也更開心。

結語

我希望這些經驗對你來說有價值，能夠適用於你的生活和工作。歡迎提出相反意見，或與我分享你在資料工作上的故事和經驗。感謝閱讀。

相關報道：

https：//about。gitlab。com/blog/2020/02/10/lessons-learned-as-data-team-manager/