Sehari dalam Kehidupan Seorang Data Analyst

Deskripsi kerja menyebut "drive insights untuk memaklumkan keputusan perniagaan." Kemudian ping Slack pertama pada pukul 8:47 pagi adalah "hey soalan cepat, kenapa MRR berbeza $3K dari board deck minggu lepas?" dan anda menghabiskan sembilan puluh minit berikutnya membuktikan bahawa deck itu betul.

Jurang antara JD dan realiti harian inilah yang menyebabkan kadar peralihan pekerja analitik di syarikat SaaS mencapai kira-kira 22-28% setiap tahun. Tiada siapa yang memberi amaran bahawa peranan ini adalah separuh SQL, separuh terjemahan, dan satu per empat mempertahankan nombor yang anda tulis tiga bulan lalu. (Ya, itu 125%. Matematik adalah sebahagian daripada masalah.)

Inilah yang benar-benar berlaku pada hari Selasa biasa bagi seorang Data Analyst IC di syarikat B2B SaaS atau mid-market, dengan pengalaman 1-4 tahun. Bukan versi LinkedIn. Yang sebenar.

Mengapa Ini Penting Sekarang

Jumlah permintaan ad hoc telah berganda kira-kira dua kali ganda sejak alat BI layan diri menjadi arus perdana. Setiap PM merasakan mereka memerlukan potongan kohort tersuai menjelang hari Selasa. Setiap VP mempunyai andaian yang mereka ingin sahkan menjelang hari Jumaat. Perkakasan yang dijanjikan mendemokrasikan data telah menghasilkan banjir permintaan.

Calon yang memilih pekerjaan ini dengan sangggapan ia adalah meja yang sunyi untuk membina model sepanjang hari akan berhenti dalam lapan belas bulan. Mereka yang kekal belajar melakukan sesuatu yang tidak pernah disebut dalam JD: melindungi masa berfikir mereka sambil tetap kelihatan responsif. Itulah kemahiran sebenar peringkat senior.

Jika anda sedang mengambil pekerja, mengetahui perkara ini mengubah cara anda membuat saringan. Jika anda bekerja sebagai Data Analyst, menamakan corak-corak ini menjadikannya lebih mudah ditangani. Mari kita lalui hari tersebut.

8:00 Pagi, Semakan Kesihatan Papan Pemuka

Sebelum Slack dibuka, sebelum pihak berkepentingan pertama terjaga, imbas enam hingga lapan papan pemuka yang benar-benar dibuka oleh eksekutif anda. Bukan kesemua dua puluh yang telah anda bina. Yang benar-benar diklik.

Anda mencari tiga perkara:

• Nilai NULL di mana ia tidak sepatutnya ada. Nombor hasil yang kosong untuk semalam. Bilangan pendaftaran yang menunjukkan sifar pada hari Rabu.
• Cantuman jadual yang rosak selepas jalanan dbt semalam. Sebuah model gagal secara senyap dan papan pemuka menunjukkan data lapuk dengan cap masa terkini. Ini adalah jenis pepijat yang paling teruk kerana tiada siapa yang perasan sehingga mereka membuat keputusan berdasarkannya.
• Lonjakan pelik. Trafik 4x ganda normal? Sama ada pemasaran melancarkan sesuatu yang tidak diberitahu kepada anda, atau peristiwa penjejakan terpicu dua kali. Kedua-duanya memerlukan mesej Slack sebelum orang lain bertanya.

Keseluruhan semakan mengambil masa lima belas minit jika semuanya bersih. Empat puluh lima minit jika tidak. Tujuannya adalah untuk menemui pepijat sebelum CFO membuka papan pemuka pada pukul 9:15 pagi dan bertanya kepada anda "adakah ini betul?"

Semakan pagi yang bersih adalah kerja yang tidak kelihatan. Anda tidak akan mendapat kredit untuknya. Tetapi hari di mana anda melangkauinya adalah hari ahli lembaga pengarah melihat nombor yang rosak, dan hari itu jauh lebih bergolak berbanding seratus pagi yang sunyi sebelumnya.

9:30 Pagi, Triage Permintaan Ad Hoc

Barisan Jira mempunyai sebelas tiket baru. Slack mempunyai enam DM. Seorang VP menghantar mesej ke telefon peribadi anda, yang anda sesali memberikannya kepadanya semasa majlis Krismas.

Triage adalah pengasingan, bukan penyelesaian. Setiap permintaan dimasukkan ke dalam salah satu daripada empat kelompok:

• Tarian 10 minit. Seseorang mahukan kiraan, senarai, penapis cepat. Lakukan secara dalam baris, hantar jawapan dalam thread, teruskan.
• Analisis 2 hari. Soalan sebenar yang memerlukan model, kohort, atau laporan bertulis. Jadualkan.
• Pendua. Seseorang bertanya apa yang orang lain tanya bulan lepas. Cari jawapan lama, pautan, tutup tiket. Dengan sopan.
• Tidak jelas. Permintaan tidak menyatakan keputusan apa yang ia menyokong. Ini memerlukan balas lima minit yang mengemukakan soalan yang menyelamatkan anda empat jam.

Soalan itu ialah: "Apakah keputusan yang akan berubah dengan ini?"

Diungkapkan dengan baik: "Seronok untuk menyiasat. Semak cepat dahulu: apa yang anda rancang buat secara berbeza bergantung kepada apa yang data katakan?" Jika jawapannya adalah "tiada apa, saya hanya ingin tahu," anda boleh deprioritize dengan jujur. Jika jawapannya adalah "kami sedang memutuskan sama ada hendak menghentikan aliran percubaan pada hari Jumaat," anda menaikkan keutamaannya. Dalam kedua-dua kes, anda telah melakukan kerja anda sebelum menulis sebarang SQL.

Templat pengambilan yang berfungsi, tampal ini ke dalam Jira/Linear/apa sahaja yang anda gunakan:

**Keputusan yang analisis ini akan memaklumkan:**
**Tarikh anda perlukan:**
**Siapa lagi yang menilai keputusan:**
**Apa yang telah anda lihat:**
**Tahap ketepatan yang boleh diterima (anggaran kasar atau gred audit):**

Separuh permintaan terhenti pada ruang pertama kerana pemohon menyedari mereka belum membuat keputusan lagi. Itu satu kelebihan.

11:00 Pagi, Temu Bual Keperluan di Tengah Hari

Tiga puluh minit di Zoom bersama PM yang berkata "saya perlukan data churn."

Permintaan sebenar sentiasa tiga lapisan lebih dalam. Kerja anda adalah untuk mengebor dari samar kepada spesifik tanpa membuatkan mereka berasa bodoh. Triknya adalah mengemukakan soalan diagnostik, bukan soalan interogasi.

Aliran yang berfungsi:

1. Nyatakan semula, kemudian kembangkan. "Jadi anda ingin memahami peralihan pelanggan. Untuk memastikan saya menghirisnya dengan betul: adakah kita bercakap tentang peralihan pelanggan, peralihan hasil, atau peralihan logo? Ia bergerak secara berbeza."
2. Tanya tentang keputusan. "Apa yang akan anda buat setelah anda mendapatkan ini? Adakah anda mengira headcount pasukan penyimpan, atau cuba mencari segmen mana yang perlu diperbaiki dahulu?"
3. Tentukan kohort. "Apabila anda menyebut 'pelanggan yang pergi', adakah anda bermaksud yang membatalkan dalam 30 hari lepas, atau yang membatalkan dan tidak mengaktifkan semula? Dan adakah penurunan tahap dikira?"
4. Tetapkan sasaran ketepatan. "Adakah anda perlukan ini tepat secara arah menjelang EOD, atau gred audit untuk QBR? Jawapannya mengubah cara saya melakukan ini lebih kurang sehari."

Kebanyakan PM tidak mahu kelihatan tidak pasti di hadapan kepimpinan, jadi mereka meminta sesuatu dalam bahasa deck yang perlu mereka bentangkan. Kerja anda adalah untuk menterjemah balik kepada soalan yang boleh dijawab oleh SQL. Anda tidak merendahkan mereka dengan bertanya. Anda melindungi mereka daripada membentangkan carta yang tidak menyampaikan apa yang mereka fikir ia menyampaikan.

Peraturan Camellia: jangan benarkan pihak berkepentingan meninggalkan panggilan keperluan tanpa anda berdua menyatakan dengan lantang apakah deliverable itu, apakah kohort itu, dan keputusan apa yang ia menyokong. Jika anda tidak dapat memuatkan itu dalam satu mesej Slack selepas mesyuarat, anda belum mempunyai spesifikasi lagi.

1:30 Petang, Async Bersama Jurutera dan Produk

Tetingkap antara makan tengah hari dan pukul 4 petang adalah masa di mana anda melakukan kerja yang tidak diminta oleh sesiapa tetapi menentukan sama ada suku seterusnya boleh diuruskan.

Ini adalah blok async. Tiga jenis input:

Semakan PR dbt. Seorang jurutera data mengubah cara model fct_subscriptions mengendalikan penukaran percubaan. Anda membaca perbezaan. Contoh komen yang benar-benar berguna:

Perubahan ini kelihatan betul untuk percubaan baru, tetapi saya
rasa ia akan mengira dua kali mana-mana akaun yang menukar,
menurun gred, kemudian menukar semula dalam suku yang sama.
Kami mempunyai kira-kira 40 akaun sedemikian suku (disemak
dalam #data-quality bulan lepas). Boleh kita tambah ujian pada
keunikan `subscription_id` dalam model pementasan sebelum ini
digabungkan? Saya sedia menulisnya.

Spesifik. Merujuk data sebenar. Menawarkan bantuan. Tidak menghalang PR atas sebab samar.

Komen spesifikasi produk. Seorang PM menjatuhkan spesifikasi untuk aliran onboarding baru. Bahagian penjejakan peristiwa menyebut "tembak onboarding_completed apabila pengguna selesai." Anda meninggalkan komen: langkah mana yang dikira sebagai "selesai"? Bagaimana jika mereka melangkau langkah tiga? Adakah kita menembak onboarding_completed untuk setiap varian aliran atau mempunyai peristiwa berasingan? Lebih baik bertanya sekarang daripada menggali data buruk dalam enam minggu.

Bendera perubahan skema. Jurutera akan menamakan semula lajur dalam pengeluaran pada hari Jumaat. Anda mencari setiap Looker explore, Hex notebook, dan model dbt untuk nama lajur tersebut. Empat papan pemuka akan rosak. Anda menghantar mesej kepada ketua jurutera dengan senarai dan sama ada menangguhkan penamaan semula atau menyelaraskan peralihan. Tugas dua puluh minit ini adalah perbezaan antara Sabtu yang tenang dan Sabtu yang dihabiskan membina semula papan pemuka eksekutif sementara anak anda menonton televisyen.

Di sinilah Data Analyst senior mendapat gelaran mereka. IC menulis SQL. Senior mengesan kerosakan tiga minggu sebelum ia berlaku.

4:00 Petang, Pengeluaran Data Eksekutif Hujung Hari

CFO memerlukan tiga nombor untuk persediaan board esok. Mereka menghantar mesej kepada anda pada pukul 3:47 petang. Mesyuarat board pada pukul 8 pagi.

Inilah saat SQL bertemu kepentingan. Anda menanya Snowflake (atau BigQuery, atau Postgres, mana sahaja yang digunakan syarikat anda), dan anda menyemak semula setiap nombor berbanding angka yang dilaporkan suku lepas. Jika pengeluaran baru tidak diselaraskan dengan nombor lama, anda tidak menghantar apa-apa sehingga anda memahami sebabnya.

Deliverable bukan tiga nombor. Ia adalah tiga nombor ditambah konteks. Format yang berfungsi untuk nota Notion atau Confluence:

**Pengeluaran cepat S1 2026 untuk persediaan board**

1. ARR bersih baharu: $1.42 juta
   (berbanding $1.38 juta yang dilaporkan dalam deck S4, +3%, selari)
   Catatan: termasuk 2 perjanjian yang bertarikh tutup 31/3 tetapi
   dibukukan pada 2/4; dikecualikan daripada pandangan S1 ketat di bawah.

2. Kadar peralihan logo: 4.1% (disetahunan)
   Pandangan S1 ketat: $1.40 juta, 4.4%
   Ditarik pada 4:35 petang 28/4; akan disegar semula jika anda perlukan sebelum 8 pagi.

3. Percubaan kepada berbayar: 18.7%
   (berbanding 17.2% dalam S4, didorong oleh kohort ujian harga Feb,
   iaitu peningkatan sementara, bukan perubahan langkah. Jangan
   membuat unjuran lurus untuk nombor ini.)

Model sumber: fct_subscriptions, fct_trials, dim_accounts.
Hubungi saya jika ada yang tidak sepadan dengan apa yang anda lihat.

Empat perkara, empat baris catatan. CFO boleh membentangkan ini tanpa perlu bertanya semula. Yang paling penting, apabila seseorang dalam mesyuarat board berkata "tunggu, itu tidak sepadan dengan apa yang anda katakan pada bulan Februari," CFO sudah mempunyai jawapan.

Inilah kerja yang mendapat anda dinaikkan pangkat. Bukan SQL. Empat baris konteks di bawahnya.

Dua Krisis Berulang

Dua corak akan memakan minggu anda jika anda membiarkannya. Menamakanya membantu.

Krisis Pertama: Letupan Ad Hoc

Anda berkata ya kepada permintaan cepat pada hari Isnin. Pemohon memberitahu rakan sejawatnya bahawa anda sangat membantu. Kini empat orang berada dalam DM anda pada hari Rabu. Menjelang hari Jumaat, anda mempunyai lapan belas tiket dan tiada masa untuk projek strategik yang sebenarnya dinilai oleh pengurus anda.

Ini adalah gelung permintaan pendua. Ia berganda kerana berkata ya lebih cepat pada masa itu berbanding menetapkan proses, dan kerana setiap "soalan cepat" tidak terasa seperti permintaan. Ia hanya terasa seperti perbualan.

Corak yang sebenarnya berfungsi:

• Waktu pejabat, dua kali seminggu. Blok 60 minit di mana sesiapa sahaja boleh datang dengan soalan. Kebanyakan permintaan "saya perlukan nombor cepat" sesuai dengan format ini dan tidak memerlukan tiket Jira sama sekali.
• Borang permohonan untuk segala-galanya. Dipautkan dalam profil Slack anda dan dalam topik saluran. Termasuk templat empat ruang di atas. Jika seseorang menghantar DM kepada anda, balas anda adalah "soalan bagus, masukkan dalam borang supaya saya boleh mengutamakannya berbanding dua belas lagi yang ada, ini pautan."
• Ringkasan mingguan apa yang anda selesaikan. Dihantar dalam #data pada hari Jumaat. Tiga baris bagi setiap tiket yang ditutup: siapa yang bertanya, apa yang mereka mahukan, apa jawapannya. Membina sejarah yang boleh dicari, mengurangkan permintaan pendua, dan menunjukkan kepada pasukan anda apa yang sebenarnya anda hantar.

Anda bukan menjadi penghalang. Anda melindungi sepuluh jam kerja fokus setiap minggu di mana anda membina perkara yang penting.

Krisis Kedua: Panik Ketidakpadanan Definisi

Mesej Slack dari seorang Pengarah, pukul 5:55 petang pada hari Khamis: "Laporan ini salah. Pengguna aktif turun 30% minggu ke minggu dan itu bukan yang dilihat oleh pemasaran."

Sembilan puluh peratus daripada masa, laporan itu betul dan Pengarah sedang membandingkan dua definisi yang berbeza. Pemasaran mengira "aktif" sebagai sesiapa yang melawat laman. Papan pemuka produk mengira "aktif" sebagai sesiapa yang melengkapkan tindakan yang bermakna. Kedua-duanya betul. Ia tidak akan pernah bersetuju.

Skrip triage:

1. Akui kepentingan mendesak, jangan biarkan kepanikan menular. "Sedang menyemak sekarang, kembali dalam sepuluh minit dengan apa yang saya dapati."
2. Tarik definisi dahulu, nombor kemudian. Medan apa yang digunakan oleh sumber Pengarah? Medan apa yang digunakan oleh papan pemuka? Jika ia berbeza, anda sudah menyelesaikannya.
3. Tawarkan perbandingan sebelah menyebelah. Jangan hanya berkata "mereka menggunakan metrik yang berbeza." Tunjukkan dua nombor bersebelahan dengan definisi di bawahnya. "Sumber pemasaran: aktif-pandangan halaman, 142K. Papan pemuka: aktif-tindakan, 98K. Penurunan 30% itu nyata jika anda bermaksud aktif-tindakan; ia adalah penurunan 4% jika anda bermaksud aktif-pandangan halaman."
4. Dokumentasikan ketidakpadanan. Tambah nota dalam kamus data atau dokumen definisi anda. Pautkan dalam balas anda. Kali berikutnya ini berlaku, anda membalas dengan pautan.

Pengarah itu tidak salah. Mereka bekerja dari definisi yang berbeza. Kerja anda adalah untuk mendedahkan jurang definisi cukup cepat agar tiada siapa yang perlu membuat semula satu deck.

Semakan Realiti Tindanan

Alat yang sebenarnya akan anda gunakan:

• SQL. Snowflake, BigQuery, atau Postgres. Pilih apa yang ada di syarikat anda. Pelajari satu dengan baik, yang lain mudah diterjemah. Fungsi tetingkap, CTE, dan QUALIFY (Snowflake/BQ) meliputi 90% kerja.
• Satu alat BI. Looker, Tableau, Hex, atau Mode. Setiap satu mempunyai falsafah yang berbeza: Looker menyandar pada lapisan semantik, Tableau adalah visual seret dan lepas, Hex dan Mode menyandar pada gaya notebook dengan SQL+Python. Anda akan mengkhusus dalam mana yang dipilih oleh syarikat anda. Jangan cuba menjadi pakar Looker dan pakar Tableau; sintaks LookML dan pengiraan Tableau tidak dipindahkan dengan mudah.
• dbt untuk pemodelan. Membaca YAML dan menulis SQL. Jika syarikat anda mempunyai pasukan jurutera data, anda akan lebih banyak menyemak PR mereka berbanding menulis model sendiri, tetapi anda perlu membaca dbt dengan lancar untuk memahami apa yang berada di hulu setiap papan pemuka.
• Notion atau Confluence. Untuk dokumentasi, rekod keputusan, dan nota catatan empat baris. Alat itu tidak penting; disiplin untuk menulis perkara itulah yang penting.
• Jira (atau Linear, atau Shortcut). Untuk barisan permintaan. Mana sahaja yang digunakan syarikat anda untuk tiket jurutera, lalukan kerja data melaluinya juga. Jika data berada dalam sistem berasingan, ia akan diabaikan.

Jika deskripsi kerja menyenaraikan kelima-limanya sebagai keperluan dan mengharapkan tahap kepakaran dalam setiap satu, itu adalah tanda amaran. Tiada siapa yang pakar dalam kelima-limanya. Versi jujur adalah: mendalam dalam satu alat BI, lancar dalam SQL, selesa membaca dbt, teratur dalam Notion, responsif dalam Jira. Itu sahaja.

Apa yang JD Tidak Memberitahu Anda

Kira-kira lima puluh peratus minggu anda adalah komunikasi dan terjemahan, bukan analisis. Panggilan keperluan, thread Slack, hujah definisi, semakan PR async, nota catatan hujung hari. SQL adalah hujung gunung ais.

Kemahiran yang paling kerap anda gunakan adalah bertanya "keputusan apa yang cuba anda buat?" Yang kedua paling kerap adalah berkata tidak tanpa kelihatan seperti penghalang. Yang ketiga adalah mendokumentasikan keputusan supaya Data Analyst seterusnya tidak perlu mengulang perbahasan yang sama.

IC Data Analyst yang keletihan adalah mereka yang berfikir SQL adalah kerja itu. Mereka yang dinaikkan pangkat adalah mereka yang menyedari SQL adalah dua puluh peratus daripada nilai, dan lapan puluh peratus lagi adalah segala-galanya di sekelilingnya: triage, terjemahan, catatan, dokumentasi definisi, ringkasan Jumaat.

Jika itu kedengaran seperti pekerjaan yang anda mahukan, anda akan melakukan dengan baik. Jika ia kedengaran seperti tipu muslihat, itu wajar juga dan lebih baik mengetahuinya sekarang berbanding tiga tahun kemudian.

Ketahui Lebih Lanjut

• Templat Deskripsi Kerja Data Analyst
• Cara Triage Permintaan Data Ad Hoc
• Menjalankan Temu Bual Keperluan Pihak Berkepentingan
• Mempertahankan Nombor Anda Apabila Pengarah Berkata "Ini Salah"