Sehari dalam Kehidupan Seorang Data Analyst

Job description menulis "dorong wawasan untuk menginformasikan keputusan bisnis." Lalu ping Slack pertamamu pukul 8:47 pagi berbunyi: "hey pertanyaan cepat, kenapa MRR selisih $3K dari board deck minggu lalu?" dan kamu menghabiskan sembilan puluh menit berikutnya membuktikan bahwa deck tersebut sudah benar.

Kesenjangan antara JD dan kenyataan itulah yang membuat angka attrition analis di perusahaan SaaS mencapai sekitar 22-28% per tahun. Tidak ada yang memperingatkanmu bahwa peran ini adalah setengah SQL, setengah penerjemahan, dan seperempat mempertahankan angka yang kamu tulis tiga bulan lalu. (Ya, itu 125%. Matematika memang bagian dari masalahnya.)

Inilah gambaran nyata hari Selasa seorang Data Analyst IC di perusahaan B2B SaaS atau mid-market, dengan pengalaman 1-4 tahun. Bukan versi LinkedIn. Yang sesungguhnya.

Mengapa Ini Penting Sekarang

Volume permintaan ad hoc hampir dua kali lipat sejak alat BI swalayan menjadi arus utama. Setiap PM merasa butuh potongan kohort khusus sebelum Selasa. Setiap VP punya firasat yang ingin divalidasi sebelum Jumat. Tooling berjanji mendemokratisasi data dan malah menghasilkan banjir permintaan.

Kandidat yang masuk ke pekerjaan ini dengan bayangan suasana meja tenang untuk membangun model sepanjang hari akan keluar dalam delapan belas bulan. Mereka yang bertahan belajar melakukan sesuatu yang tidak pernah disebutkan JD: melindungi waktu berpikir sambil tetap terasa responsif. Itulah keterampilan senior yang sesungguhnya.

Jika kamu sedang merekrut, memahami hal ini mengubah cara kamu menyaring kandidat. Jika kamu bekerja sebagai analis, memberi nama pada pola-pola ini membuatnya bisa dijalani. Mari kita telusuri hari tersebut.

8:00 Pagi, Pemeriksaan Kesehatan Dasbor

Sebelum Slack dibuka, sebelum pemangku kepentingan pertama terbangun, periksa enam hingga delapan dasbor yang benar-benar dibuka oleh para eksekutifmu. Bukan semua dua puluh yang sudah kamu buat. Yang benar-benar diklik.

Kamu mencari tiga hal:

• Nilai kosong di tempat yang seharusnya tidak ada. Angka pendapatan yang kosong untuk kemarin. Jumlah pendaftaran yang menunjukkan nol pada hari Rabu.
• Penggabungan tabel yang rusak setelah proses dbt tadi malam. Sebuah model gagal secara diam-diam dan dasbor menampilkan data usang dengan cap waktu terbaru. Ini adalah jenis bug terburuk karena tidak ada yang menyadarinya sampai mereka mengambil keputusan berdasarkan data tersebut.
• Lonjakan aneh. Traffic 4 kali lebih tinggi dari normal? Entah marketing meluncurkan sesuatu tanpa memberi tahumu, atau sebuah event tracking menembak ganda. Keduanya layak mendapat pesan Slack sebelum orang lain bertanya.

Seluruh pemindaian memakan waktu lima belas menit jika semuanya bersih. Empat puluh lima menit jika tidak. Tujuannya adalah menemukan bug sebelum CFO membuka dasbor pukul 9:15 pagi dan menghubungimu dengan "apakah ini benar?"

Pemeriksaan pagi yang bersih adalah pekerjaan yang tidak terlihat. Kamu tidak akan pernah mendapat kredit untuk itu. Tapi hari ketika kamu melewatinya adalah hari seorang anggota dewan melihat angka yang rusak, dan hari itu jauh lebih berisik dari seratus pagi yang tenang sebelumnya.

9:30 Pagi, Triase Permintaan Ad Hoc

Antrean Jira memiliki sebelas tiket baru. Slack memiliki enam DM. Satu VP mengirim pesan ke ponselmu, yang kamu sesali memberikannya saat pesta Natal.

Triase adalah penyortiran, bukan penyelesaian. Setiap permintaan masuk ke salah satu dari empat kategori:

• Pengambilan 10 menit. Seseorang menginginkan hitungan, daftar, atau filter cepat. Lakukan langsung, posting jawaban di thread, lanjutkan.
• Analisis 2 hari. Pertanyaan nyata yang membutuhkan model, kohort, atau laporan tertulis. Jadwalkan.
• Duplikat. Seseorang menanyakan apa yang sudah ditanyakan orang lain bulan lalu. Temukan jawaban lama, tautkan, tutup tiket. Dengan sopan.
• Tidak jelas. Permintaan tidak menyebutkan keputusan apa yang akan didorong. Ini membutuhkan balasan lima menit untuk menanyakan pertanyaan yang menghemat empat jam kerja.

Pertanyaan itu adalah: "Keputusan apa yang akan berubah dengan ini?"

Jika disampaikan dengan baik, kalimatnya: "Senang menggali lebih dalam. Cek cepat dulu: apa yang kamu rencanakan untuk dilakukan berbeda tergantung pada apa yang dikatakan data?" Jika jawabannya "tidak ada, saya hanya penasaran," kamu bisa mendeprioritaskannya dengan jujur. Jika jawabannya "kami memutuskan apakah akan menghapus alur percobaan pada hari Jumat," kamu eskalasi. Dalam kedua kasus, kamu telah melakukan pekerjaanmu sebelum menulis SQL apa pun.

Template formulir permintaan yang bisa langsung dipakai, tempel ke Jira/Linear/apa pun yang kamu gunakan:

**Keputusan yang akan diinformasikan analisis ini:**
**Tanggal kamu membutuhkannya:**
**Siapa lagi yang akan meninjau hasilnya:**
**Apa yang sudah kamu lihat:**
**Tingkat presisi yang dapat diterima (perkiraan kasar vs. tingkat audit):**

Setengah permintaan berhenti di kolom pertama karena pemohon menyadari mereka belum memiliki keputusan. Itu adalah fitur, bukan bug.

11:00 Pagi, Wawancara Kebutuhan di Tengah Hari

Tiga puluh menit di Zoom dengan PM yang bilang "saya butuh data churn."

Permintaan sebenarnya selalu tiga lapis lebih dalam. Tugasmu adalah menggali dari yang samar ke yang spesifik tanpa membuat mereka merasa bodoh. Triknya adalah mengajukan pertanyaan diagnostik, bukan pertanyaan interogasi.

Alur yang bisa langsung diterapkan:

1. Nyatakan ulang, lalu perluas. "Jadi kamu ingin memahami churn. Untuk memastikan saya memotongnya dengan tepat: apakah kita bicara customer churn, revenue churn, atau logo churn? Ketiganya bergerak berbeda."
2. Tanyakan keputusannya. "Apa yang akan kamu lakukan setelah mendapat ini? Apakah kamu menghitung headcount tim save, atau mencoba mencari segmen mana yang perlu diperbaiki terlebih dahulu?"
3. Tentukan kohortnya. "Ketika kamu bilang 'pelanggan yang churn', maksudmu yang membatalkan dalam 30 hari terakhir, atau yang membatalkan dan tidak mengaktifkan kembali? Dan apakah downgrade dihitung?"
4. Tetapkan target presisi. "Apakah kamu butuh ini secara arah yang benar sebelum EOD, atau tingkat audit untuk QBR? Jawabannya mengubah cara saya mengerjakannya sekitar satu hari."

Kebanyakan PM tidak ingin terlihat tidak yakin di depan pimpinan, jadi mereka meminta sesuatu dalam bahasa deck yang harus mereka presentasikan. Tugasmu adalah menerjemahkan itu kembali menjadi pertanyaan yang bisa dijawab SQL. Kamu tidak melemahkan mereka dengan bertanya. Kamu melindungi mereka dari mempresentasikan grafik yang tidak mengatakan apa yang mereka kira.

Aturan Camellia: jangan biarkan pemangku kepentingan meninggalkan sesi kebutuhan tanpa kamu berdua menyatakan dengan lantang apa deliverablenya, apa kohortnya, dan keputusan apa yang didorong. Jika kamu tidak bisa meringkasnya dalam satu pesan Slack setelah rapat, kamu belum punya spesifikasi.

1:30 Siang, Async dengan Tim Engineering dan Product

Jendela antara makan siang dan pukul 4 sore adalah saat kamu mengerjakan hal yang tidak ada yang memintamu lakukan tetapi yang menentukan apakah kuartal berikutnya bisa dijalani.

Ini adalah blok async. Tiga jenis input:

Tinjauan pull request dbt. Seorang data engineer mengubah cara model fct_subscriptions menangani konversi trial. Kamu membaca diffnya. Contoh komentar yang benar-benar berguna:

Perubahan ini terlihat tepat untuk trial baru, tapi saya rasa ini akan
menghitung ganda akun yang melakukan konversi, downgrade, lalu
konversi ulang dalam kuartal yang sama. Kami punya sekitar 40
akun seperti itu per kuartal (dicek di #data-quality bulan lalu).
Bisakah kita menambahkan pengujian pada keunikan `subscription_id`
di model staging sebelum ini digabungkan? Saya siap menulisnya.

Spesifik. Mereferensikan data nyata. Menawarkan bantuan. Tidak memblokir pull request tanpa alasan jelas.

Komentar spesifikasi product. Seorang PM menjatuhkan spesifikasi untuk alur onboarding baru. Bagian pelacakan event mengatakan "tembakkan onboarding_completed ketika pengguna selesai." Kamu meninggalkan komentar: langkah mana yang dianggap "selesai"? Bagaimana jika mereka melewati langkah tiga? Haruskah kita menembakkan onboarding_completed untuk setiap varian alur atau memiliki event terpisah? Lebih baik ditanyakan sekarang daripada harus menggali data buruk enam minggu ke depan.

Tanda perubahan skema. Engineering akan mengganti nama sebuah kolom di produksi pada hari Jumat. Kamu mencari setiap Looker explore, Hex notebook, dan model dbt untuk nama kolom tersebut. Empat dasbor akan rusak. Kamu mengirim pesan ke kepala engineering dengan daftarnya dan meminta penundaan penggantian nama atau koordinasi untuk transisi. Tugas dua puluh menit ini adalah perbedaan antara Sabtu yang tenang dan Sabtu yang dihabiskan membangun ulang dasbor eksekutif sementara anakmu menonton TV.

Di sinilah analis senior mendapatkan gelar mereka. IC menulis SQL. Senior menangkap kerusakan tiga minggu sebelum terjadi.

4:00 Sore, Pengambilan Data Eksekutif di Akhir Hari

CFO membutuhkan tiga angka untuk persiapan board besok. Mereka menghubungimu pukul 3:47 sore. Rapat board pukul 8 pagi.

Ini adalah momen di mana SQL bertemu dengan taruhan tinggi. Kamu melakukan kueri ke Snowflake (atau BigQuery, atau Postgres, mana pun yang digunakan perusahaanmu), dan kamu memeriksa ulang setiap angka terhadap angka yang dilaporkan kuartal lalu. Jika pengambilan baru tidak cocok dengan angka lama, kamu tidak mengirimkan apa pun sampai kamu memahami alasannya.

Deliverable-nya bukan tiga angka. Ini tiga angka ditambah konteks. Format yang bisa langsung dipakai untuk catatan Notion atau Confluence:

**Pengambilan cepat Q1 2026 untuk persiapan board**

1. ARR baru bersih: $1,42 juta
   (vs. $1,38 juta yang dilaporkan di deck Q4, +3%, sesuai ekspektasi)
   Catatan: mencakup 2 kesepakatan yang tanggal penutupannya 31/3 tapi
   dibukukan 2/4; dikecualikan dari tampilan Q1 ketat di bawah.

2. Tingkat logo churn: 4,1% (disetahunkan)
   Tampilan Q1 ketat: $1,40 juta, 4,4%
   Ditarik pukul 4:35 sore 28/4; akan diperbarui jika dibutuhkan sebelum pukul 8 pagi.

3. Trial ke berbayar: 18,7%
   (vs. 17,2% di Q4, didorong oleh kohort uji harga Februari,
   yang merupakan kenaikan sementara, bukan perubahan permanen.
   Jangan mengekstrapolasi angka ini secara lurus.)

Model sumber: fct_subscriptions, fct_trials, dim_accounts.
Hubungi saya jika ada yang tidak cocok dengan yang kamu lihat.

Empat poin, empat baris catatan. CFO bisa mempresentasikan ini tanpa bertanya ulang. Yang terpenting, ketika seseorang dalam rapat board berkata "tunggu, itu tidak cocok dengan yang kamu katakan bulan Februari," CFO sudah memiliki jawabannya.

Inilah pekerjaan yang membuatmu dipromosikan. Bukan SQL-nya. Empat baris konteks di bawahnya.

Dua Krisis Berulang

Dua pola akan menghabiskan minggu kerjamu jika kamu membiarkannya. Memberi nama pada keduanya membantu.

Krisis Pertama: Ledakan Ad Hoc

Kamu bilang iya pada permintaan cepat hari Senin. Pemohon memberi tahu rekannya bahwa kamu membantu. Sekarang empat orang ada di DM-mu pada hari Rabu. Pada hari Jumat, kamu punya delapan belas tiket dan tidak ada waktu untuk proyek strategis yang sebenarnya dievaluasi oleh manajermu.

Ini adalah lingkaran permintaan duplikat. Ini berkembang karena mengatakan iya lebih cepat dalam sesaat daripada menetapkan proses, dan karena setiap "pertanyaan cepat" tidak terasa seperti permintaan. Hanya terasa seperti percakapan.

Pola yang benar-benar berhasil:

• Office hours, dua kali seminggu. Blok 60 menit di mana siapa saja bisa hadir dengan pertanyaan. Sebagian besar pertanyaan "saya butuh angka cepat" sesuai dengan format ini dan tidak memerlukan tiket Jira sama sekali.
• Formulir permintaan untuk segala hal lainnya. Ditautkan di profil Slack-mu dan di topik channel. Jika seseorang mengirim DM kepadamu, balasanmu adalah "pertanyaan bagus, masukkan ke formulir agar saya bisa memprioritaskannya dibanding dua belas lainnya yang ada, ini tautannya."
• Ringkasan mingguan apa yang sudah diselesaikan. Diposting di #data setiap Jumat. Tiga baris per tiket yang ditutup: siapa yang meminta, apa yang mereka inginkan, apa jawabannya. Membangun riwayat yang bisa dicari, mengurangi permintaan duplikat, dan menunjukkan kepada timmu apa yang sebenarnya sudah kamu kirimkan.

Kamu tidak menghalangi. Kamu melindungi sepuluh jam kerja terfokus per minggu di mana kamu membangun hal-hal yang penting.

Krisis Kedua: Kepanikan Ketidakcocokan Definisi

Pesan Slack dari seorang Director, pukul 5:55 sore hari Kamis: "Laporan ini salah. Pengguna aktif turun 30% minggu ke minggu dan itu bukan yang dilihat marketing."

Sembilan puluh persen dari waktu, laporan itu benar dan Director membandingkan dua definisi berbeda. Marketing menghitung "aktif" sebagai siapa saja yang mengunjungi situs. Dasbor product menghitung "aktif" sebagai siapa saja yang menyelesaikan tindakan yang berarti. Keduanya benar. Keduanya tidak akan pernah cocok.

Skrip triase:

1. Akui urgensinya, jangan ikut panik. "Sedang melihatnya sekarang, kembali dalam sepuluh menit dengan temuan saya."
2. Tarik definisinya terlebih dahulu, baru angkanya. Kolom apa yang digunakan sumber Director? Kolom apa yang digunakan dasbor? Jika keduanya berbeda, kamu sudah menyelesaikannya.
3. Tawarkan perbandingan berdampingan. Jangan hanya mengatakan "mereka menggunakan metrik berbeda." Tunjukkan dua angka berdampingan dengan definisi di bawahnya. "Sumber marketing: aktif berdasarkan tampilan halaman, 142K. Dasbor: aktif berdasarkan tindakan, 98K. Penurunan 30% itu nyata jika yang dimaksud adalah aktif-tindakan; ini penurunan 4% jika yang dimaksud adalah aktif-tampilan halaman."
4. Dokumentasikan ketidakcocokannya. Tambahkan catatan di kamus data atau dokumen definisi. Tautkan di balasanmu. Lain kali ini terjadi, kamu membalas dengan tautannya.

Director tidak salah. Mereka bekerja dari definisi yang berbeda. Tugasmu adalah mengungkap kesenjangan definisi cukup cepat sehingga tidak ada yang harus mengerjakan ulang deck.

Pemeriksaan Realitas Stack

Alat yang benar-benar akan kamu gunakan:

• SQL. Snowflake, BigQuery, atau Postgres. Pilih yang ada di perusahaanmu. Pelajari satu dengan baik, yang lain akan bisa ditransfer. Fungsi window, CTE, dan QUALIFY (Snowflake/BQ) mencakup 90% pekerjaan.
• Satu alat BI. Looker, Tableau, Hex, atau Mode. Masing-masing memiliki filosofi berbeda: Looker condong ke lapisan semantik, Tableau adalah visual drag-and-drop, Hex dan Mode condong ke gaya notebook dengan SQL+Python. Kamu akan berspesialisasi di mana pun yang dipilih perusahaanmu. Jangan mencoba menjadi ahli Looker dan ahli Tableau sekaligus; sintaks LookML dan perhitungan Tableau tidak bisa ditransfer dengan bersih.
• dbt untuk pemodelan. Membaca YAML dan menulis SQL. Jika perusahaanmu memiliki tim data engineering, kamu akan lebih banyak meninjau pull request mereka daripada menulis model sendiri, tetapi kamu perlu membaca dbt dengan lancar untuk memahami apa yang ada di hulu setiap dasbor.
• Notion atau Confluence. Untuk dokumentasi, catatan keputusan, dan catatan konteks empat baris. Alatnya tidak penting; disiplin menulis hal-hal itu yang penting.
• Jira (atau Linear, atau Shortcut). Untuk antrean permintaan. Apa pun yang digunakan perusahaanmu untuk tiket engineering, arahkan juga pekerjaan data melaluinya. Jika data hidup di sistem terpisah, itu akan diabaikan.

Jika sebuah job description mencantumkan kelimanya sebagai syarat wajib dan mengharapkan keahlian tingkat expert di masing-masing, itu adalah tanda bahaya. Tidak ada yang ahli di kelimanya sekaligus. Versi jujurnya: mendalam di satu alat BI, fasih dalam SQL, nyaman membaca dbt, terorganisir di Notion, responsif di Jira. Itu saja.

Yang Tidak Diceritakan JD

Sekitar lima puluh persen minggu kerjamu adalah komunikasi dan penerjemahan, bukan analisis. Sesi kebutuhan, thread Slack, perdebatan definisi, tinjauan pull request async, catatan konteks akhir hari. SQL adalah ujung gunung es.

Keterampilan yang paling sering kamu gunakan adalah bertanya "keputusan apa yang coba kamu buat?" Yang kedua paling sering adalah mengatakan tidak tanpa terdengar menghalangi. Yang ketiga adalah mendokumentasikan keputusan agar analis berikutnya tidak perlu berdebat lagi.

Analis IC yang kelelahan adalah mereka yang mengira SQL adalah pekerjaan itu. Mereka yang dipromosikan adalah mereka yang menyadari SQL hanya dua puluh persen nilainya, dan delapan puluh persen sisanya adalah segala hal di sekitarnya: triase, penerjemahan, catatan, dokumentasi definisi, ringkasan hari Jumat.

Jika itu terdengar seperti pekerjaan yang kamu inginkan, kamu akan berhasil. Jika itu terdengar seperti iming-iming palsu, itu juga adil, dan lebih baik mengetahuinya sekarang daripada tiga tahun kemudian.

Pelajari Lebih Lanjut

• Template Job Description Data Analyst
• Cara Melakukan Triase Permintaan Data Ad Hoc
• Menjalankan Wawancara Kebutuhan dengan Pemangku Kepentingan
• Mempertahankan Angkamu Ketika Director Berkata "Ini Salah"