30/60/90 Hari Pertamamu sebagai Data Analyst Baru

Pukul 9:47 pagi di hari ke-3. Kamu baru saja berhasil mengakses VPN. Sebuah pesan Slack masuk dari seseorang yang namanya tidak kamu kenal: "hei selamat datang! satu hal cepat, bisa tarikkan MRR per segmen untuk deck board besok? cukup dipotong berdasarkan band ARR dan saluran akuisisi. makasih!"

Bagaimana kamu menjawab pesan itu menentukan dua belas bulan ke depanmu.

Jika kamu bilang iya dan menjalankan kueri, kamu baru saja menandatangani kontrak. Kamu sekarang adalah orang yang hanya menarik data ad hoc. Kamu akan menghabiskan 40 jam seminggu untuk "hal-hal cepat" dan tidak menghasilkan pekerjaan strategis apa pun. Di hari ke-91, ketika manajermu bertanya apa yang sudah kamu capai, kamu akan punya arsip Slack, bukan cerita.

Jika kamu bilang tidak, kamu adalah analis baru yang memblokir deck board. Itu juga buruk.

Ada jalan ketiga. Panduan ini adalah jalan itu.

Mengapa Analis Lebih Butuh Kerangka 30/60/90 dari Siapa Pun

Engineer mendapat backlog. PM mendapat roadmap. Designer mendapat file Figma yang sudah berjalan. Analis masuk ke pekerjaan di mana setiap pemangku kepentingan merasa diri mereka adalah prioritas, analis sebelumnya tidak meninggalkan dokumentasi apa pun, dan TV perusahaan menampilkan dasbor yang tidak disentuh selama delapan bulan. Setengahnya salah. Tidak ada yang tahu setengah yang mana.

Tanpa kerangka, kamu menjadi mesin penjual SQL. Dengan kerangka, kamu menjadi seseorang yang menghapus 30 dasbor rusak, mengirimkan satu model pendapatan kanonik, dan masuk ke rapat perencanaan H2 dengan roadmap analitik yang tidak diminta VP-mu tetapi tiba-tiba dibutuhkan.

Kerangkanya sederhana: audit, lalu kirimkan satu hal, lalu kuasai sebuah metrik. Tiga bulan. Satu tugas per bulan. Jangan loncat ke depan.

Hari 1-30: Audit, Jangan Membangun

Kesalahan terbesar yang saya lihat dari analis baru adalah membuka editor SQL di hari ke-4 dan mencoba "memperbaiki" sesuatu. Kamu belum tahu apa yang rusak. Kamu belum tahu mana yang penting. Kamu tidak tahu dasbor mana yang "rusak" itu sebenarnya satu-satunya yang dipercaya CFO.

Bulan pertama adalah pengintaian. Kamu hampir tidak menulis kueri apa pun. Kamu banyak mencatat.

Minggu 1: Inventaris Dasbor

Tarik daftar setiap dasbor, laporan, dan kueri tersimpan di alat BI-mu (Looker, Mode, Tableau, Metabase, apa pun yang kamu warisi). Untuk setiap dasbor, catat lima kolom:

• Nama
• Pemilik (atau "tidak diketahui")
• Jumlah tampilan terakhir (60 hari terakhir)
• Tanggal pengeditan terakhir
• Status (aktif / mencurigakan / mati)

Mati berarti: nol tampilan dalam 60 hari, ATAU terakhir diedit oleh seseorang yang meninggalkan perusahaan lebih dari enam bulan lalu. Di perusahaan SaaS berukuran sedang, kamu akan menemukan 60-70% dasbor sudah mati. Di perusahaan terakhir saya, kami punya 312 dasbor. Setelah audit, hanya 47 yang benar-benar digunakan. Sisanya adalah kapal hantu.

Jangan hapus apa pun dulu. Cukup buat daftarnya.

Minggu 2: Tur Skema dan Perdebatan Pendapatan Kanonik

Sekarang kamu membaca. Buka repositori dbt (atau gudang datamu jika tidak ada dbt). Temukan lima tabel yang akan sering kamu sentuh setiap minggu (biasanya semacam accounts, subscriptions, events, users, dan satu tabel pendapatan). Baca definisi model. Baca komentar kolom. Baca makronya.

Dengan kepastian statistik, kamu akan menemukan bahwa perusahaanmu memiliki beberapa definisi pendapatan. Di satu perusahaan tempat saya bekerja, kami punya 14 versi pendapatan yang ada di gudang data. ARR dipesan. ARR ditagih. ARR diperkirakan. ARR baru bersih. ARR dipertahankan kotor. Masing-masing benar untuk suatu tujuan tertentu dan salah untuk tujuan lain. Finance menggunakan satu. Sales menggunakan yang lain. CEO punya Google Sheet dengan versi ketiga.

Ini normal. Ini juga tugas terpentingmu di minggu kedua. Pilih satu pertemuan dengan rekan finance-mu. Tanya: "Yang mana dari ini yang menjadi sumber kebenaran untuk board?" Dapatkan jawabannya secara tertulis. Bukan pesan Slack, sebuah dokumen. Percakapan itu adalah fondasi dari segalanya.

Jika finance tidak bisa memberi tahumu, itu adalah temuan. Catat.

Minggu 3: Sinkronisasi Pemangku Kepentingan (Dengarkan, Jangan Promosikan)

Ikuti lima rapat: revenue ops, customer success, marketing, product, finance. Kamu tidak ada untuk presentasi. Kamu tidak ada untuk "memperkenalkan diri." Kamu ada untuk mendengarkan pertanyaan yang berulang.

Pola yang kamu cari: pertanyaan yang sama ditanyakan oleh tiga tim berbeda dengan tiga cara berbeda. Itu adalah dasbor minggu ke-5-mu.

Contoh yang pernah saya dengar dalam sinkronisasi minggu ke-3:

• Kepala RevOps: "Kami tidak pernah tahu segmen mana yang sebenarnya terkonsentrasi dalam pipeline kami."
• Director CS: "Saya ingin bisa melihat ARR ekspansi berdasarkan industri tanpa mengekspor ke spreadsheet."
• CMO: "Pipeline yang bersumber dari marketing per segmen ada di lima tempat berbeda."

Itu pertanyaan yang sama tiga kali. Itu dasbor yang kamu bangun di bulan kedua.

Bawa buku catatan. Jangan buka laptopmu. Jangan menawarkan untuk "mengambil sesuatu dengan cepat." Ketika ditanya, katakan: "Saya dalam mode audit selama dua minggu ke depan. Mari tambahkan ke formulir permintaan begitu sudah aktif." (Lebih lanjut tentang formulir permintaan dalam sesaat.)

Minggu 4: Daftar Penghapusan

Sekarang kamu mengusulkan untuk menghentikan bertahap dasbor yang mati. Di sinilah analis baru biasanya takut dan melompat ke depan. Jangan.

Kembali ke inventarismu. Untuk setiap dasbor mati, temukan pembuat aslinya (atau tim yang menaunginya) dan tanya: "Ini tidak dilihat selama X hari. Apakah kamu setuju saya mengarsipkannya?" 80% dari waktu jawabannya "ya Tuhan, saya lupa itu ada." 15% dari waktu jawabannya "sebenarnya tetap ada, saya menggunakannya sebulan sekali." 5% dari waktu kamu akan mempelajari sesuatu yang penting tentang bisnis.

Dapatkan persetujuan secara tertulis. Thread Slack sudah cukup. Kemudian arsipkan, jangan hapus. Sebagian besar alat BI memungkinkan pengarsipan dengan pemulihan satu klik. Kamu menginginkan jejak dokumen.

Ini skrip yang berhasil bagi saya:

Hei [nama], saya sedang melakukan pembersihan dasbor sebagai bagian dari onboarding. "[nama dasbor]" tidak memiliki tampilan selama 73 hari dan terakhir diedit oleh [orang yang sudah pergi]. Saya ingin mengarsipkannya (dapat dipulihkan, tidak menghapus). Apakah boleh? Jika kamu lebih memilih untuk menyimpannya, tidak masalah, hanya ingin mengonfirmasi bahwa seseorang memilikinya.

Kirim ini dalam kelompok 10. Jangan mengejar respons. Diam setelah 5 hari kerja = arsipkan. Dokumentasikan segalanya.

Pada akhir minggu ke-4, kamu biasanya sudah menghapus 40-150 dasbor. Itu adalah deliverable pertamamu. Itu juga satu-satunya deliverable yang bisa kamu klaim yang tidak memerlukan satu baris SQL pun, yang memang itulah intinya.

Hari 31-60: Kirimkan Satu Hal, Tetapkan SLA

Bulan kedua adalah tempat pekerjaan nyata muncul. Tapi kamu hanya boleh melakukan tiga hal. Kirimkan satu dasbor. Terbitkan SLA. Bangun satu model dbt. Itu saja. Tahan dorongan untuk melakukan lebih.

Kirimkan Satu Dasbor yang Semua Orang Minta

Ingat pertanyaan dari minggu ke-3 yang ditanyakan tiga tim? Bangun dasbor itu. Hanya itu saja.

Disiplin di sini sangat ketat. Orang akan meminta "selagi kamu sedang di sana, bisakah kamu juga tambahkan..." dan jawabannya adalah tidak. Bukan karena permintaan mereka buruk, tapi karena setiap "selagi kamu ada di sana" berubah menjadi perangkap orang yang hanya menarik data ad hoc dengan langkah ekstra. Kirimkan satu hal. Buat itu bagus. Kirimkan.

Dasbor "bagus" pertama berarti:

• Satu pertanyaan, dijawab dengan jelas. Bukan lima pertanyaan.
• Definisi metrik adalah definisi kanonik yang kamu perjuangkan di minggu ke-2, dan footer dasbor menyatakannya. ("Pendapatan didefinisikan sesuai [tautan ke model dbt]. Terakhir ditinjau dengan Finance pada [tanggal].")
• Maksimal tiga filter. Segmen, rentang tanggal, satu potongan khusus tim.
• Satu paragraf "Cara membaca ini" di bagian atas.
• Seorang pemilik (kamu) dan sebuah channel Slack "ada pertanyaan?".

Poin terakhir tidak bisa dinegosiasikan. Setiap dasbor tanpa pemilik akan menjadi kapal hantu dalam 18 bulan. Kamu akan menjadi analis yang memutus pola itu.

Terbitkan SLA Ad Hoc

Ini adalah momen kamu berhenti menjadi mesin penjual SQL. Kamu menerbitkan satu halaman (dokumen Notion, halaman Confluence, apa pun yang digunakan perusahaanmu) yang menyatakan:

Formulir permintaan data ad hoc

1. Kirimkan melalui [formulir / channel #data-requests]. DM Slack kepadaku akan diarahkan ke sana.
2. Tiga kolom yang wajib diisi: apa yang kamu butuhkan, kapan kamu membutuhkannya, keputusan apa yang akan diinformasikan.
3. SLA: permintaan di bawah 4 jam kerja, hari yang sama atau pagi berikutnya. Permintaan lebih dari 4 jam, dimasukkan ke sprint berikutnya.
4. Apa pun yang ditandai "deck board" atau "tinjauan eksekutif" didahulukan dalam antrean.

Tiga kolom yang wajib. Bukan tujuh. Bukan formulir permintaan 14 pertanyaan. Kolom ketiga (keputusan apa yang akan diinformasikan) adalah yang melakukan keajaiban. Setengah permintaan gugur di sana karena pemohon menyadari mereka sebenarnya tidak membutuhkan datanya, mereka hanya penasaran. Setengah lainnya datang lebih terfokus karena pemohon harus berpikir terlebih dahulu.

Minta manajermu yang mengirimkan pengumumannya, bukan kamu. "Hei tim, [namamu] sekarang mengelola permintaan analitik. Gunakan formulir mulai sekarang." Kalimat itu bernilai lebih dari seratus DM Slack yang tidak perlu kamu terima.

SLA bukan tentang mengatakan tidak. Ini tentang menjadikan "sprint berikutnya" sebagai jawaban normal, bukan sebuah pertarungan.

Bangun Satu Model dbt

Model dbt adalah definisi pendapatan kanonik yang kamu perjuangkan di minggu ke-2. Hanya itu saja. Bukan lapisan metrik. Bukan refaktor semantik. Satu model.

Beri nama fct_revenue_canonical atau apa pun konvensi repositorimu. Tulis blok dokumentasinya. Tambahkan pengujian. Dapatkan tinjauan. Gabungkan. Perbarui dasbor minggu ke-5-mu agar mengambil sumber darinya.

Ini adalah momenmu "saya memang layak di sini." Pertama kali seseorang dalam rapat berkata "tunggu, angka pendapatan mana yang kita gunakan?" dan seorang rekan menjawab "yang kanonik, itu model dbt yang [namamu] kirimkan," itu adalah momen kamu berhenti menjadi analis baru dan mulai menjadi analis.

Jangan, dalam kondisi apa pun, mencoba merefaktor seluruh gudang data di bulan kedua. Pemakaman analis baru dipenuhi dengan orang-orang yang mencoba "membangun ulang segalanya" di minggu ke-6 dan merusak laporan board di minggu ke-8. Kirimkan satu model. Lanjutkan.

Hari 61-90: Kuasai Sebuah Metrik, Presentasikan Rencana

Bulan ketiga adalah tempat kamu berhenti diukur berdasarkan tiket yang diselesaikan dan mulai diukur berdasarkan apa yang kamu miliki.

Adopsi Waktu Menuju Wawasan sebagai Metrikmu

Pilih satu metrik tingkat tim dan miliki itu. Yang terkuat untuk analis adalah waktu menuju wawasan: median jam dari "permintaan dikirimkan" hingga "jawaban data dikirimkan." Beberapa tim menyebutnya first-response-to-data-question. Ide yang sama.

Ukur dari formulir permintaanmu (kamu sudah punya sekarang). Tetapkan baseline di minggu ke-9. Tetapkan target untuk minggu ke-12. Milikku adalah: median 6 jam, target di bawah 4.

Mengapa metrik ini dan bukan, katakanlah, "tingkat adopsi dasbor" atau "kueri yang dijalankan"? Karena waktu menuju wawasan adalah yang dirasakan pemangku kepentinganmu. Mereka tidak memperhatikan ketika tingkat adopsi naik. Mereka memperhatikan ketika pertanyaan mereka dijawab sebelum makan siang, bukan Selasa depan.

Laporkan setiap minggu dalam standup timmu. Tiga angka: median, p90, jumlah. Itu saja.

Laporan 90 Hari

Sekitar hari ke-85, tulis laporanmu kepada manajer dalam satu halaman. Empat bagian, dalam urutan ini:

Yang Dihapus. Jumlah dasbor yang diarsipkan, dengan daftar. Total perkiraan beban yang dihemat di gudang data jika bisa diukur.

Yang Dikirimkan. Satu dasbor. Satu model dbt. Formulir permintaan dengan dua bulan data throughput.

Yang Rusak. Apa yang kamu temukan yang masih salah. Spesifik. "Model MRR per segmen menghitung ganda konversi trial di wilayah EMEA. Mempengaruhi 4 dasbor. Perbaikannya adalah proyek 1 minggu." Jangan melunak. Manajermu menginginkan daftarnya.

Selanjutnya. Dua proyek strategis, satu investasi platform, satu permintaan kepegawaian jika relevan. Konkret. Dengan perkiraan waktu kasar.

Satu halaman. Tidak lebih. Kirim sebagai dokumen, lalu bahas dalam 1:1-mu.

Pitch Rencana H2

Laporan 90 hari adalah pemanasan. Pitch adalah yang berikutnya. Dalam 1:1 yang sama, kamu berkata: "Saya ingin memiliki rencana analitik H2. Ini bentuk kasarnya: dua proyek strategis (X dan Y), satu investasi platform (lapisan metrik / reverse ETL / kerangka eksperimen), dan satu keputusan kepegawaian (apakah kita merekrut IC kedua atau senior untuk memimpin?). Saya akan memiliki dokumen lengkap pada [tanggal]."

Ini adalah momen yang membedakan analis yang tetap menjadi IC selama lima tahun dari yang memimpin tim dalam 18 bulan. Sebagian besar analis menunggu manajernya merencanakan untuk mereka. Kamu akan merencanakan untuk manajermu.

Kamu akan mendapat penolakan. Rencananya akan diedit. Dua proyekmu akan dihapus. Tidak apa-apa. Pitch-nya adalah tindakannya, bukan artefaknya.

Jebakan (Ini Akan Menggodamu, Jangan Terjatuh)

Mengatakan iya untuk setiap ad hoc di bulan 1. Saya katakan di awal, saya ulangi lagi. Treadmill ad hoc adalah pintu satu arah. Kamu bilang iya di minggu ke-1, kamu masih bilang iya di tahun ke-2.

Membangun ulang gudang data di minggu ke-2. Kamu belum memahami bisnisnya. Model yang "jelas rusak" itu penting bagi seseorang yang belum kamu temui. Audit dulu.

Diam selama 60 hari, lalu menjatuhkan audit 40 halaman. Tidak ada yang meminta audit itu. Mereka meminta bukti bahwa kamu ada. Kirimkan daftar penghapusan di minggu ke-4. Terbitkan SLA di minggu ke-6. Tampil.

Mengirimkan dasbor dengan definisi pendapatan yang salah. Kamu melewatkan rekonsiliasi dengan finance di minggu ke-2. Sekarang dasbor-mu bertentangan dengan deck board. Kepercayaan terbakar. Sulit dipulihkan. Jangan.

Template yang Benar-Benar Akan Kamu Gunakan

Spreadsheet inventaris dasbor. Enam kolom: nama, pemilik, terakhir dilihat (tanggal), terakhir diedit (tanggal), status (aktif/mencurigakan/mati), keputusan hapus-atau-simpan. Satu baris per dasbor. Urutkan berdasarkan terakhir-dilihat secara menaik, dan yang mati akan mengapung ke atas.

Daftar pertanyaan sinkronisasi pemangku kepentingan. Lima pertanyaan, berurutan: (1) Keputusan apa yang kamu buat kuartal lalu yang kamu harap punya data lebih baik? (2) Angka apa yang kamu cek setiap pagi? (3) Dasbor mana yang benar-benar kamu gunakan, dibanding dasbor mana yang ada untukmu? (4) Pertanyaan apa yang terus kamu terima dari atasanmu yang tidak bisa kamu jawab dengan cepat? (5) Jika saya bisa memberikanmu satu tampilan baru tentang bisnis ini, apa itu? Perhatikan tidak satu pun dari mereka yang berbunyi "apa yang kamu butuhkan dari saya." Pertanyaan itu memberimu daftar keinginan. Pertanyaan-pertanyaan ini memberimu kebenaran.

Formulir permintaan ad hoc. Tiga kolom. Permintaan. Tenggat waktu. Keputusan yang diinformasikan. Itu saja.

Laporan 90 hari. Satu halaman. Yang Dihapus. Yang Dikirimkan. Yang Rusak. Selanjutnya. Poin-poin, bukan paragraf.

Seperti Apa "Berhasil" di Hari ke-90

Pada hari ke-90, jumlah dasbor di alat BI-mu berkurang, bukan bertambah. Ada satu model dbt kanonik untuk metrik yang biasa diperdebatkan perusahaanmu. Pemangku kepentingan menggunakan formulir permintaan, bukan mengirim DM kepadamu. Manajermu punya rencana H2 tertulis darimu, bukan sebaliknya. Dan di suatu tempat di TV perusahaan, dasbor masih menampilkan angka yang sama pada hari Selasa seperti pada hari Jumat.

Kamu bukan orang yang hanya menarik data ad hoc. Kamu adalah analis.

Itulah pekerjaannya.

Pelajari Lebih Lanjut

• Job Description Data Analyst (JD yang dipasangkan dengan playbook ini)
• Sehari dalam Kehidupan Seorang Data Analyst
• SQL dan Pemodelan Data yang Berskala
• Penerjemahan Pemangku Kepentingan: Dari Permintaan Samar ke Analisis yang Bisa Dikirimkan
• Metrik Data Analyst: Waktu Menuju Wawasan, Tingkat Adopsi, Dampak
• Kesalahan Umum Data Analyst