TL;DR
Produktivitas data analyst nggak ditentukan sama kecepatan nulis query, tapi sama sistem yang nyaring request sebelum masuk. Lima komponennya: intake form yang maksa orang nulis keputusan apa yang mau diambil, matriks prioritas dampak-versus-usaha, time block buat kerja dalam, template query yang bisa dipakai ulang, dan skrip buat nunda request tanpa bikin orang tersinggung.
Produktivitas data analyst nggak ditentukan sama seberapa cepat kamu nulis query. Ditentukan sama seberapa banyak request yang berhasil kamu saring sebelum masuk.
Aku pernah ngitung ini di satu tim: dari 47 request yang masuk dalam sebulan, 19 hasilnya nggak pernah dibuka sama yang minta. Itu 40% waktu kerja yang nguap.
Masalahnya bukan analyst-nya lambat. Masalahnya nggak ada pintu masuk.
Ini sistem 5 langkah yang aku pakai. Setup-nya sehari, efeknya kerasa dari minggu pertama.
Tiga penyebab yang selalu sama.
Nggak ada pintu tunggal. Request masuk lewat WhatsApp, Slack DM, email, dan colekan di pantry. Nggak ada yang ke-track, jadi nggak ada yang bisa diprioritaskan.
Request datang tanpa konteks. "Minta data penjualan dong." Penjualan apa, periode kapan, buat apa? Kamu balik nanya, mereka balas 4 jam kemudian, dan setengah hari hilang buat klarifikasi.
Semua dianggap urgent. Kalau semua urgent, nggak ada yang urgent. Yang menang jadi siapa yang paling berisik, bukan yang paling penting.
Semua request lewat satu form. Nggak ada pengecualian, termasuk buat bos kamu.
Google Form yang nyambung ke Sheets udah cukup buat tim di bawah 30 orang. Gratis dan setupnya 20 menit.
Isi form-nya cuma 5 pertanyaan:
Pertanyaan nomor 4 itu senjata utamanya. Di tim yang aku bantu, sekitar seperempat request berhenti di situ. Orangnya sadar sendiri hasilnya nggak akan dipakai buat apa-apa.
Pertanyaan nomor 1 juga penting. "Aku mau data penjualan Q2" itu permintaan data. "Aku mau tau kota mana yang layak ditutup outlet-nya" itu pertanyaan bisnis. Jawabannya mungkin cuma butuh 1 tabel, bukan 8 tab spreadsheet.
Cara ngasih taunya ke tim: jangan bilang "jangan chat aku lagi". Bilang "request lewat form dikerjain duluan, soalnya aku bisa lihat konteksnya langsung". Insentif, bukan larangan.
Setelah request masuk, taruh di satu dari 4 kotak.
| Usaha rendah | Usaha tinggi | |
|---|---|---|
| Dampak tinggi | Kerjain sekarang | Jadwalin, pecah jadi tahap |
| Dampak rendah | Batch: kerjain barengan Jumat | Tolak, atau tawarin self-service |
Kotak kanan bawah yang paling sering bikin analyst kelelahan. Request yang makan 2 hari, hasilnya dipakai sekali, terus dilupain.
Cara ngukur dampak tanpa debat: tanya berapa rupiah keputusan yang nyangkut. Request buat nentuin alokasi budget iklan Rp 400 juta dampaknya jelas beda dari request buat ngerapiin format laporan.
Kotak kiri bawah (dampak rendah, usaha rendah) jangan dikerjain satu-satu. Kumpulin, kerjain barengan sekali seminggu. Konteks switching itu mahal.
Kerjaan analis butuh konsentrasi panjang. Query yang rumit nggak bisa dikerjain di sela-sela 20 menit antar meeting.
Ini pembagian yang aku pakai:
| Hari | Blok | Isi |
|---|---|---|
| Senin | Pagi | Triase request minggu ini, balas semua yang masuk |
| Selasa-Rabu | Full | Kerja dalam: dashboard, data model, analisis besar |
| Kamis | Pagi | Request dampak tinggi usaha rendah |
| Jumat | Pagi | Batch request kecil, dokumentasi |
| Jumat | Sore | Otomatisasi: apa yang minggu ini kamu kerjain 3x manual? |
Selasa dan Rabu itu yang harus dijaga mati-matian. Blokir kalender, matiin notifikasi, dan jangan terima meeting kecuali beneran genting.
Jumat sore buat otomatisasi itu investasi. Kalau kamu 3 kali seminggu ngejalanin query yang sama dengan tanggal beda, itu kandidat pertama buat dijadwalin otomatis.
Sebagian besar request ad-hoc itu variasi dari 5-6 pola yang sama.
Simpan template-nya di satu tempat, kasih parameter, tinggal ganti tanggal.
-- Template: performa penjualan per dimensi
-- Ganti {{DIMENSI}} dengan: kota, kategori, channel, atau sales_id
-- Ganti {{TGL_AWAL}} dan {{TGL_AKHIR}} sesuai request
WITH periode_ini AS (
SELECT
{{DIMENSI}},
SUM(total_belanja) AS revenue,
COUNT(DISTINCT id) AS jml_transaksi,
COUNT(DISTINCT pelanggan_id) AS jml_pelanggan
FROM transaksi
WHERE status = 'selesai'
AND tanggal_transaksi BETWEEN '{{TGL_AWAL}}' AND '{{TGL_AKHIR}}'
GROUP BY {{DIMENSI}}
),
periode_lalu AS (
SELECT
{{DIMENSI}},
SUM(total_belanja) AS revenue_lalu
FROM transaksi
WHERE status = 'selesai'
AND tanggal_transaksi BETWEEN
'{{TGL_AWAL}}'::date - INTERVAL '1 month'
AND '{{TGL_AKHIR}}'::date - INTERVAL '1 month'
GROUP BY {{DIMENSI}}
)
SELECT
i.{{DIMENSI}},
i.revenue,
l.revenue_lalu,
ROUND(
100.0 * (i.revenue - l.revenue_lalu) / NULLIF(l.revenue_lalu, 0),
1
) AS growth_persen,
i.jml_transaksi,
ROUND(i.revenue / NULLIF(i.jml_transaksi, 0)) AS avg_transaksi
FROM periode_ini i
LEFT JOIN periode_lalu l USING ({{DIMENSI}})
ORDER BY i.revenue DESC;Satu template ini nutupin request "penjualan per kota", "penjualan per kategori", dan "penjualan per channel" sekaligus. Ganti satu kata.
Yang bikin template ini kepakai: kolom growth-nya udah ikut. Stakeholder yang minta angka mentah hampir selalu bakal nanya "ini naik apa turun dibanding bulan lalu?" 10 menit kemudian.
Jawab duluan. Hemat satu putaran bolak-balik.
Kalau CTE masih asing, itu cara mecah query panjang jadi blok-blok yang kebaca. Fungsi NULLIF di situ buat nyegah error kalau revenue bulan lalu kebetulan nol.
Ini bagian yang paling bikin analyst gugup. Padahal polanya cuma satu.
Jangan bilang "nggak bisa". Bilang "bisa, tapi ini yang harus digeser."
Contoh balasan yang aku pakai:
"Bisa dikerjain. Estimasi 1,5 hari.
Antrean aku minggu ini: dashboard forecast buat rapat board (Rabu), analisis churn buat tim retensi (Kamis).
Kalau ini mau masuk minggu ini, salah satu dari dua itu mundur ke minggu depan. Yang mana yang boleh mundur?"
Tiga hal terjadi setelah pesan ini.
Pertama, kamu nggak nolak. Kamu bikin biayanya kelihatan. Kedua, keputusan trade-off pindah ke orang yang punya wewenang. Ketiga, dan ini yang paling sering, request-nya mundur sendiri.
Dari pengalamanku, sekitar 6 dari 10 request "urgent" jadi nggak urgent begitu orangnya harus milih apa yang dikorbanin.
Buat request yang beneran nggak layak dikerjain, tawarin alternatif:
"Angka ini udah ada di dashboard penjualan, tab 'Per Kota'. Aku kirim link-nya, kalau ada yang nggak jelas, aku bantu 10 menit di call."
Ngajarin sekali lebih hemat daripada ngerjain 12 kali.
Ini data dari satu tim data 2 orang yang support 34 karyawan di perusahaan retail.
Sebelum sistem dipasang, rata-rata sebulan:
Setelah 6 minggu:
| Metrik | Sebelum | Sesudah |
|---|---|---|
| Request masuk per bulan | 47 | 21 |
| Berhenti di intake form | - | 11 |
| Diselesaikan lewat dashboard yang udah ada | - | 9 |
| Waktu klarifikasi rata-rata | 2 jam | 15 menit |
| Hari kerja dalam per minggu | 0 | 2 |
Yang paling ngagetin: 9 request diselesaikan sama dashboard yang udah ada dari 4 bulan lalu. Orang nggak tau dashboard itu ada.
Jadi masalahnya sebagian bukan beban kerja. Masalahnya distribusi: kerjaan yang udah selesai nggak ketemu sama orang yang butuh.
Aksi yang paling murah dari semua ini: bikin satu halaman berisi daftar dashboard yang ada, dengan satu kalimat penjelasan tiap dashboard jawab pertanyaan apa. Makan waktu 40 menit. Ngilangin 9 request per bulan.
Bikin form yang kepanjangan. Lebih dari 6 pertanyaan, orang bakal balik ke WhatsApp. Lima cukup.
Ngasih pengecualian buat bos. Sekali kamu terima request bos lewat DM, sistemnya mati. Semua orang bakal ikut.
Nggak pernah nunjukin antrean. Kalau stakeholder nggak bisa lihat kamu lagi ngerjain apa, mereka bakal ngira kamu nganggur. Bikin antrean itu publik.
Otomatisasi terlalu dini. Jangan bikin pipeline buat laporan yang baru diminta sekali. Tunggu sampai request-nya berulang 3 kali.
Buat kerangka prioritas yang lebih formal, prinsip appetite dari Shape Up-nya Basecamp lumayan cocok dipinjam buat tim data. Tentuin dulu berapa waktu yang layak dihabiskan, baru desain solusinya.
Jangan bilang "nggak bisa". Bilang "bisa, tapi ini yang harus digeser". Tunjukin daftar antrean kamu dan minta mereka yang mutusin mana yang turun prioritas. Ini mindahin keputusan trade-off ke orang yang punya wewenang, dan biasanya request yang nggak penting bakal mundur sendiri begitu mereka lihat biayanya.
Nggak ada angka baku, tapi patokan yang aku pakai: kalau lebih dari 40% waktu kamu habis buat request dadakan, sistemnya yang rusak, bukan kamu yang lambat. Sisakan minimal 2 hari penuh per minggu buat kerjaan yang punya dampak panjang: bikin dashboard, rapiin data model, atau otomatisasi laporan rutin.
Nggak. Google Form yang nyambung ke Sheets udah cukup buat tim di bawah 30 orang, dan gratis. Yang penting bukan tool-nya, tapi apakah semua request lewat satu pintu. Request yang masuk lewat WhatsApp jam 9 malam nggak akan pernah ke-track, sebagus apa pun tool yang kamu bayar.
Cek request 3 bulan terakhir dan hitung mana yang polanya sama. Kalau ada 5 orang beda nanya angka penjualan per kota tiap minggu, itu bukan 5 request. Itu satu dashboard yang belum dibikin. Dari yang aku lihat, 30-40% request ad-hoc bisa hilang cuma dengan satu dashboard self-service yang bener.
Empat hal: keputusan apa yang mau diambil dari data ini, kapan deadline-nya dan kenapa, siapa yang bakal pakai hasilnya, dan apa yang terjadi kalau request ini nggak dikerjain. Pertanyaan terakhir yang paling ampuh: sekitar seperempat request bakal berhenti di situ karena si peminta sadar sendiri hasilnya nggak akan dipakai.
Sistem ini nggak bikin kamu nulis query lebih cepat. Sistem ini ngurangin jumlah query yang nggak perlu kamu tulis.
Mulai dari yang paling murah: bikin satu halaman daftar dashboard yang udah ada. Di tim yang aku bantu, itu doang ngilangin 9 dari 47 request per bulan.
Habis itu baru pasang intake form-nya.
Mau bikin dashboard self-service yang beneran dipakai orang, bukan cuma dibuka sekali? Mampir ke panduan prinsip desain dashboard. Dan buat rapiin query yang bakal dibaca orang lain, cek SQL style guide.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Cara pakai pandas rolling buat hitung moving average dan haluskan data time series yang naik-turun. Lengkap dengan contoh penjualan harian UMKM.
Data transaksi harian sering terlalu ramai buat dilihat. Pandas resample ngeringkasnya jadi total per minggu atau per bulan cuma dengan satu baris, asal indeksnya tanggal.
Kolom tanggal yang kebaca sebagai teks bikin sortir dan hitung selisih hari jadi kacau. Ini cara pd.to_datetime ubah teks jadi tanggal asli, plus tangani format berantakan.