Perangkap Biasa Data Analyst: 7 Kesilapan yang Merosakkan Kerjaya Anda (Dan Cara Membetulkannya)

Slack anda sibuk. Looker anda mempunyai 47 papan pemuka dengan nama anda tertulis padanya. Pengurus anda memanggil anda "stabil" dalam sesi 1:1. Dan entah bagaimana, apabila VP Jualan memutuskan untuk menstruktur semula wilayah pada suku tahun hadapan, tiada siapa yang menjemput anda ke mesyuarat di mana keputusan dibuat.

Selamat datang ke paradoks analyst 14 bulan. Anda cukup cekap untuk lemas dalam kerja, dan belum cukup senior untuk menolak mana-mana daripadanya. Kerja yang memenuhi kalender anda membawa anda ke IC2. Tiada satu pun daripadanya yang akan membawa anda ke tahap Senior.

Saya telah menyemak kitaran prestasi untuk analyst di syarikat dari 80 orang hingga 8,000 orang. Yang paling lambat hampir selalu lambat atas sebab yang sama. Bukan kemahiran. SQL boleh dipelajari. dbt boleh dipelajari. Python boleh dipelajari dalam hujung minggu jika anda benar-benar membuka laptop. Perangkap dalam artikel ini adalah tabiat, dan tabiat lebih sukar untuk ditinggalkan berbanding konsep untuk dipelajari.

Jadi inilah tujuh yang paling banyak memudaratkan. Setiap satu datang dengan gejala yang akan anda kenali dari minggu ini, nombor sebenar untuk dibandingkan dengan diri anda, dan pembetulan yang boleh anda mulakan pada Isnin pagi.

Mengapa Tetingkap 6-18 Bulan Menentukan Trajektori Anda

Dalam ulasan prestasi analyst yang pernah saya lihat, lebih kurang 73% orang yang terhenti di IC2 berbuat demikian kerana corak yang terbentuk antara bulan 6 dan 18. Itulah tetingkap selepas latihan awal (onboarding) berakhir tetapi sebelum anda mendapat modal politik untuk menetapkan skop sendiri. Anda menghabiskan enam bulan pertama membuktikan bahawa anda boleh menghantar kerja. Anda menghabiskan bulan 6-18 memutuskan jenis analyst apakah yang anda akan jadi sepanjang baki kerjaya anda.

Kebanyakan orang tidak membuat keputusan. Mereka hanyut. Hanyutan itu kelihatan seperti berkata ya kepada setiap ping Slack, membina papan pemuka yang tiada siapa buka, dan mengukur kejayaan dalam tiket yang ditutup. Dua tahun kemudian, peranan itu membeku. Menjelang bulan ke-24, rakan sekerja anda yang menetapkan sempadan sedang mendapat tawaran Senior. Anda mendapat "mari kita tinjau semula pada kitaran seterusnya."

Ketujuh perangkap ini adalah hanyutan, yang dinamakan.

Perangkap 1: Menjadi Meja Bantuan

Gejala: Lebih daripada 60% minggu anda adalah permintaan ad hoc yang kurang daripada 30 minit setiap satu. Anda belum menyentuh analisis yang lebih mendalam yang anda tetapkan skopnya enam minggu yang lalu.

Anda boleh mengesan ini sendiri dalam kalender anda dalam lima minit. Buka Slack, cari mesej di mana anda menghantar hasil pertanyaan, kira berapa banyak yang mengambil kurang daripada setengah jam untuk diselesaikan. Jika nombor itu melebihi 25 dalam seminggu biasa, anda bukan data analyst. Anda adalah pekhidmat SQL.

Perangkap itu ialah menjadi meja bantuan terasa seperti berguna. Setiap emoji "terima kasih!" adalah sentuhan dopamin yang kecil. Setiap tindak balas pantas menjadikan anda kelihatan responsif. Dan setiap minit yang anda habiskan untuk tiket tersebut adalah minit yang tidak anda gunakan untuk membina sesuatu yang mempromosikan anda, iaitu pertimbangan.

Pembetulan yang anda laksanakan minggu ini:

Tetapkan SLA triaj dan siarkan dalam saluran pasukan anda. Milik saya berbunyi:

Permintaan ad hoc: saya kelompokkan ini dua kali sehari, pukul 11 pagi dan 4 petang. Apa-apa yang benar-benar menghalang, tag saya dengan urgent dan tarikh akhirnya. Untuk soalan berulang, berikut adalah papan pemuka layan diri: [pautan]. Jika soalan itu mengambil masa lebih daripada 45 minit, ia menjadi tiket dan melalui penentuan keutamaan dengan pengurus saya.

Kemudian bina perpustakaan pertanyaan layan diri. 10 soalan yang paling kerap anda jawab, didedahkan sebagai papan pemuka atau Looker explore tersimpan dengan dokumentasi. Anda akan mengurangkan volum meja bantuan anda sebanyak 40-60% dalam dua minggu. Pengurus anda akan menyedarinya. Pihak berkepentingan anda akan mengadu selama seminggu dan kemudian berhenti.

Ketidakselesaan berkata "ini melalui penentuan keutamaan" adalah harga untuk dilayan seperti analyst dan bukan seperti enjin carian.

Perangkap 2: Melangkau Persetujuan Keperluan

Gejala: Anda berada pada pusingan semakan ke-3 bagi sebuah projek, dan pihak berkepentingan baru berkata, "Sebenarnya, yang saya maksudkan ialah..." Anda akan membina semula model dan menghantar semula pada Jumaat.

Ini menelan lebih banyak kos daripada yang anda sangka. Satu pasukan analitik syarikat bersaiz sederhana yang pernah saya bekerja mengaudit kadar kerja semula mereka dan mendapati 31% jam analyst dihabiskan untuk projek yang telah pun "dihantar" sekali. Tiga daripada setiap sepuluh jam, mengulang kerja kerana spesifikasi adalah utas Slack.

Anda melangkau persetujuan keperluan kerana memintanya terasa lambat. Meminta pihak berkepentingan untuk menuliskan apa yang mereka mahu, menandatanganinya, dan berkomitmen kepada kriteria penerimaan terasa seperti birokrasi. Jadi anda melangkauinya. Dan kini hari Rabu dan anda sedang membina semula corong (funnel) untuk kali ketiga dan VP Pemasaran "kecewa dengan masa pemulihan analitik."

Pembetulan yang anda laksanakan minggu ini:

Brifing satu halaman, setiap projek yang melebihi empat jam kerja. Templat:

Projek: [nama]
Pemohon: [nama + peranan]
Keputusan yang didorong analisis ini: [keputusan sebenar]
Pembuat keputusan: [siapa yang bertindak berdasarkan ini]
Tarikh akhir keputusan: [tarikh]
Kriteria penerimaan: [senarai 3-5 output khusus yang mesti ada agar ini dianggap "selesai"]
Di luar skop: [apa yang TIDAK kita lakukan]
Persetujuan pihak berkepentingan: [nama + tarikh]

Hantarkan melalui e-mel. Tunggu "diluluskan." Kemudian baru tulis SQL. Jika pihak berkepentingan tidak mahu menandatangani, projek itu tidak nyata dan anda tidak perlu memulakannya.

Ya, ini melambatkan 24 jam pertama projek. Ia menghapuskan 24 jam kerja semula yang seterusnya. Matematik itu tidak halus.

Perangkap 3: Membina Papan Pemuka Sebelum Mendefinisikan Keputusan

Gejala: Papan pemuka terbaru anda mempunyai 14 jubin, tiga penapis, dan pemilih julat tarikh. Apabila ditanya tindakan apa yang ia picu, bilik menjadi sunyi.

Ini adalah tabiat buruk yang paling biasa saya lihat, dan yang paling keras analyst pertahankan. Naluri itu ialah "lebih banyak lebih baik." Berikan pengguna setiap hirisan, setiap pecahan, setiap dimensi, dan biarkan mereka mengiris. Hasilnya adalah papan pemuka yang tiada siapa boleh gunakan kerana tiada soalan yang dijawabnya.

Penanda aras dalaman tahun 2024 daripada syarikat SaaS 400 orang: daripada 287 papan pemuka dalam contoh Looker mereka, 41 mempunyai lebih daripada 10 pemapar setiap minggu. 246 yang lain adalah kawasan sunyi. 41 yang berfungsi itu semuanya menjawab tepat satu soalan dan memicu satu tindakan. 246 yang tidak adalah papan pemuka "gambaran keseluruhan," papan pemuka "ringkasan eksekutif," papan pemuka "kesihatan pasukan": kata nama samar yang disolek sebagai hasil kerja.

Pembetulan yang anda laksanakan minggu ini:

Sebelum sebarang papan pemuka baharu, jawab empat soalan secara bertulis:

1. Keputusan apa yang ini dorong?
2. Siapa yang membuat keputusan itu?
3. Pada kadar kekerapan apa (harian, mingguan, suku tahunan)?
4. Tindakan apa yang diambil apabila metrik melepasi ambang?

Jika anda tidak dapat menjawab kesemua empat, anda tidak membina papan pemuka. Anda membina wallpaper. Kembalikan projek itu kepada pemohon sehingga mereka dapat menjawabnya bersama anda.

Papan pemuka yang dibina dengan cara ini mempunyai 3-7 jubin, satu julat tarikh, dan seruan "jika nombor ini jatuh di bawah X, buat Y" yang jelas. Ia digunakan kerana ia menjawab sesuatu yang spesifik.

Perangkap 4: Terlalu Bergantung pada Eksport Excel

Gejala: Setiap "nombor muktamad" yang pihak berkepentingan anda petik berada dalam CSV di desktop seseorang, terakhir diubah suai tiga minggu yang lalu.

Butang eksport adalah musuh analitik yang dipercayai. Setiap eksport adalah garpu dalam data anda. Sebaik sahaja nombor meninggalkan gudang dan mendarat dalam S3_pipeline_v4_MUKTAMAD_sebenar.xlsx, anda kehilangan kawalan ke atasnya. Enam minggu kemudian, CFO akan memetik fail itu dalam paparan lembaga pengarah dan ia akan salah, dan nombor yang silap itu akan dikaitkan kepada anda.

Saya pernah melihat pasukan kewangan memetik liputan pipeline 19% daripada CSV apabila nombor gudang langsung adalah 14%. CSV itu adalah dari sebelum urusan diklasifikasi semula sebagai komit. CFO membentangkan 19% kepada lembaga pengarah. Dua bulan kemudian, lembaga pengarah bertanya mengapa kami terlepas begitu jauh. Jawapannya ialah "hamparan itu lapuk," yang bukan jawapan yang bertahan dalam mesyuarat lembaga pengarah.

Pembetulan yang anda laksanakan minggu ini:

Bina lapisan semantik yang ditadbir. Model dbt, metrik yang ditakrifkan, didedahkan melalui Looker / Sigma / Hex / apa sahaja yang digunakan dalam timbunan anda. Akses baca sahaja untuk pihak berkepentingan. Kemudian, dalam saluran pasukan anda, buat pengumuman ini:

Bermula [tarikh], sumber kebenaran untuk [pipeline | hasil | pengekalan | metrik yang penting] adalah [pautan papan pemuka]. CSV yang lebih lama daripada 24 jam tidak akan didamaikan. Jika anda memerlukan nombor untuk slaid, pautkan papan pemuka.

Sesetengah pihak berkepentingan akan membantah. Tidak mengapa. CFO yang membantah adalah CFO yang sama yang akan berterima kasih kepada anda kali pertama gudang data menangkap nombor yang hamparan tidak akan tangkap.

Bunuh tabiat eksport. Reputasi yang anda selamatkan adalah milik anda sendiri.

Perangkap 5: Tiada Kawalan Versi pada SQL atau dbt

Gejala: Pertanyaan atribusi pengeluaran anda berada dalam utas Slack dari bulan Mac. Atau lebih teruk, ia berada dalam jubin Looker dan tiga orang telah menyuntingnya tanpa pengetahuan anda.

Yang ini terasa terlalu memalukan untuk diakui, tetapi saya telah mengaudit pasukan analitik di syarikat Siri C di mana pengiraan nilai sepanjang hayat (lifetime value) adalah pertanyaan 400 baris yang ditampal ke dalam jadual terbitan Looker tanpa komen dan tanpa rekod siapa mengubah apa bila. Analyst yang menulisnya berhenti pada tahun 2024. Tiada siapa yang boleh menukar apa-apa dengan yakin.

Anda fikir kawalan versi adalah untuk jurutera. Bukan. Ia untuk sesiapa sahaja yang kerjanya orang lain bergantung, iaitu anda. Analyst tanpa kawalan versi adalah satu cantuman buruk atau satu padam tidak sengaja jauh dari insiden sehari penuh.

Pembetulan yang anda laksanakan minggu ini:

Walaupun anda adalah analyst tunggal, sediakan:

1. Repo git untuk SQL anda, dinamakan analytics-sql atau seumpamanya.
2. dbt untuk mana-mana model yang digunakan oleh lebih daripada satu orang atau satu papan pemuka.
3. Semakan PR. Jika anda berseorangan, semak PR anda sendiri pada pagi berikutnya. Baca semula diff dengan pandangan segar sebelum anda cantumkan.
4. Pemeriksaan CI (dbt test, walaupun tiga yang asas: tidak null, unik, nilai diterima).

Bulan pertama terasa lambat. Bulan kedua anda akan menangkap pepijat dalam semakan yang sepatutnya menurunkan pengiraan bonus pemimpin jualan sebanyak 8%. Dari itu seterusnya, anda tidak akan kembali.

Analyst senior di syarikat anda mempunyai semua ini. IC2 yang tidak pernah dinaikkan pangkat tidak mempunyai mana-mana. Itulah kebanyakan jurangnya.

Perangkap 6: Mengabaikan Semakan Pemansuhan

Gejala: Anda menyelenggara 200+ papan pemuka. Anda tidak dapat memberitahu saya 12 mana yang benar-benar digunakan secara aktif. Anda juga tidak dapat memberitahu saya yang mana perlu dipadam, jadi anda mengekalkan semuanya, dan setiap perubahan dbt merebak melalui 200 jubin hiliran.

Audit mudah di kebanyakan pasukan BI: papan pemuka dengan 3 atau lebih sedikit pemapar unik dalam 30 hari yang lalu. Di syarikat bersaiz sederhana biasa, itu adalah 60-75% daripada inventori. Kosnya bukan sekadar storan, tetapi rintangan. Setiap pemfaktoran semula, setiap perubahan definisi metrik, setiap penamaan semula lajur perlu diuji regresi terhadap papan pemuka yang tiada siapa buka.

Anda tidak menjalankan audit kerana pemadaman terasa bersifat politik. Seseorang membuat setiap papan pemuka tersebut. Seseorang mungkin masih menginginkannya. Jadi anda mengekalkannya, dan sampah saraf itu bertambah, dan binaan dbt anda semakin lambat, dan masa untuk menghantar metrik baharu anda meningkat dari dua hari ke dua minggu.

Pembetulan yang anda laksanakan minggu ini:

Semakan pemansuhan suku tahunan. Jemputan kalender, 90 minit, setiap suku tahun, berulang selama-lamanya:

1. Tarik statistik penggunaan: papan pemuka dengan kurang daripada 3 pemapar unik sebulan sepanjang suku tahun lalu.
2. Maklumkan pemilik (atau @channel jika tiada pemilik): "Papan pemuka ini berada dalam senarai pemansuhan. Jika anda masih memerlukannya, balas menjelang [tarikh]. Jika tidak, ia akan diarkibkan."
3. Arkib (jangan padam; pindahkan ke folder berasingan selama 90 hari, kemudian padam).
4. Jejaki bilangannya. Sasarkan untuk bersara 20-30% inventori dalam audit pertama anda. Kurang daripada itu dan anda tidak cukup agresif.

Pihak berkepentingan akan lebih lantang daripada yang anda jangkakan dalam pusingan pertama dan lebih senyap setiap pusingan selepas itu. Menjelang pusingan ketiga, pasukan itu lebih ramping dan binaan dbt anda selesai sebelum tengah hari.

Perangkap 7: Mengukur Penggunaan Tanpa Impak Keputusan

Gejala: Dokumen ulasan prestasi anda menyebut "paparan papan pemuka: 1,200 sebulan" dan "tiket ditutup: 47 sebulan." Ia tidak menyebut apa-apa tentang apa yang berubah dalam perniagaan kerana anda.

Inilah pembunuh kerjaya paling senyap daripada ketujuh-tujuhnya, kerana ia tidak terasa silap semasa anda melakukannya. Paparan halaman meningkat, tiket ditutup, anda kelihatan produktif. Dan kemudian kitaran kenaikan pangkat tiba dan analyst senior di pod sebelah mendapat kenaikan pangkat dengan separuh bilangan tiket anda, kerana penilaian diri mereka berkata:

"Membina model pengekalan kohort yang mengubah hala pergerakan pembaharuan pasukan kejayaan pelanggan. Menyebabkan $1.4 juta ARR diselamatkan dalam S3 dengan membenderakan akaun berisiko 60 hari lebih awal daripada model sebelumnya."

Ayat itu mengalahkan "paparan papan pemuka: 1,200/bulan" setiap kitaran. Ia tidak hampir.

Perangkap itu ialah metrik aktiviti mudah dikira dan impak keputusan adalah sukar. Jadi anda mengira yang mudah, dan analyst senior mengira yang penting. Teka siapa yang mendapat jawatan itu.

Pembetulan yang anda laksanakan minggu ini:

Mulakan "log keputusan." Satu baris setiap analisis, lajur:

Kebanyakan minggu anda akan menambah 0-2 baris. Itulah intinya. Ukurannya ialah "keputusan berubah kerana analisis ini," bukan "saya menghantar nombor." Jika anda tidak dapat mengisi lajur ke-4, kerja itu tidak menggerakkan apa-apa, dan itu juga isyarat yang berguna. Mungkin projek itu adalah projek yang salah.

Pada masa kenaikan pangkat, penilaian diri anda menulis sendiri. Dan perbualan dengan pengurus anda beralih dari "adakah anda berjaya mengikuti tiket" kepada "apakah keputusan seterusnya yang patut dibuat."

Kos Berganda Membawa Ini ke Tahun Kedua

Pilih satu daripada ini dan anda akan merasakannya sebagai titik geseran tetapi pulih. Bawa tiga atau lebih ke tahun kedua dan trajektori itu mengeras. Reputasi terbentuk. Anda menjadi "orang papan pemuka" atau "orang SQL" dan bukannya "analyst yang mendesak kami untuk menghapuskan langkah latihan awal yang salah."

Reputasi itulah yang sebenarnya sukar untuk dibatalkan. Kelewatan kenaikan pangkat selama 9-15 bulan adalah perkara biasa. Jawatan Senior diberikan kepada rakan sebaya yang menghantar lebih sedikit kod tetapi menjalankan lebih banyak keputusan. Dan hasil terburuk bukan bahawa anda tidak dinaikkan pangkat, tetapi anda mula mempercayai bahawa versi meja bantuan peranan itu ADALAH peranan itu, dan anda berhenti mencapai untuk apa-apa yang lain.

Berita baiknya ialah pemulihan mengambil masa satu suku tahun, bukan setahun. Kebanyakan analyst yang membetulkan corak ini melihat peralihan yang ketara dalam cara mereka dilayan dalam masa 6-8 minggu. Pihak berkepentingan mula bertanya "apa yang patut kita lakukan?" berbanding "boleh anda tarik nombor ini?" Itulah keseluruhan permainan.

Penetapan Semula 30 Hari

Jangan cuba membetulkan kesemua tujuh sekaligus. Anda tidak akan membetulkan satu pun.

Pilih dua yang paling kuat kesannya. Jujurlah. Yang paling tidak mahu anda akui mungkin adalah yang terbaik untuk dimulakan. Kebanyakan analyst yang saya bimbing memilih "menjadi meja bantuan" dan "mengukur penggunaan tanpa impak keputusan." Keduanya cenderung bergabung.

Kemudian:

• Minggu 1: Pilih perangkap #1. Tulis pembetulan sebagai pelan satu halaman. Beritahu pengurus anda bahawa anda sedang melaksanakannya.
• Minggu 2-3: Laksanakan pembetulan. Jejaki apa yang berubah: jam anda yang dikembalikan, tentangan pihak berkepentingan anda, kualiti output anda.
• Minggu 4: Tambah lapisan perangkap #2. Buku panduan yang sama.

Menjelang hari ke-30 anda akan mempunyai dua tabiat baharu. Menjelang hari ke-90 ia akan terasa automatik. Menjelang hari ke-180 anda akan melihat kembali kepada analyst yang anda dahulu dan tidak mengenalinya.

Itulah kerjanya. Bukan mempelajari alat baharu. Bukan menjadi lebih bijak. Cuma menolak untuk hanyut.

Senarai semak audit diri

Jalankan ini pada Isnin pagi. Jawapan jujur sahaja:

• Kurang daripada 40% minggu saya adalah permintaan ad hoc yang kurang daripada 30 minit
• Setiap projek melebihi 4 jam mempunyai brifing bertulis yang ditandatangani sebelum SQL ditulis
• Setiap papan pemuka yang saya miliki boleh menamakan keputusan yang didorongnya, pembuat keputusan, dan kadanya
• Pihak berkepentingan saya memetik papan pemuka langsung, bukan CSV, dalam mesyuarat mereka
• Setiap SQL atau model dbt yang saya miliki ada dalam git dengan sejarah PR
• Saya menjalankan audit pemansuhan suku tahunan dan mengarkibkan sekurang-kurangnya 20% inventori yang tidak digunakan
• Penilaian diri saya mempunyai sekurang-kurangnya 5 entri dalam log keputusan dengan impak yang dinamakan

Skor diri anda dari 7. Apa-apa di bawah 4, anda mempunyai hanyutan. Apa-apa 4-5, anda biasa-biasa sahaja. 6-7 bermakna anda beroperasi seperti analyst senior dan mungkin patut dibayar seperti itu, yang merupakan perbualan berbeza untuk minggu berbeza.

Ketahui Lebih Lanjut

• Templat Penerangan Kerja Data Analyst
• Laluan Kerjaya Data Analyst: IC1 ke Staff
• Terjemahan Pihak Berkepentingan: Daripada Permintaan Samar kepada Analisis yang Boleh Dihantar
• Reka Bentuk Papan Pemuka yang Mendorong Keputusan