Sehari dalam Kehidupan Data Scientist

Pukul 8:07 pagi. Ponsel Anda bergetar pukul 6:42 dengan peringatan penurunan kualitas model dari MLflow. PM mengirim Slack DM pukul 7:55: "pertanyaan singkat, mengapa pengguna ini ditandai churn?" Anda belum membuka laptop. Selamat datang di pekerjaan yang tidak pernah dideskripsikan dengan akurat di LinkedIn.

Deskripsi pekerjaan yang Anda daftarkan menjanjikan "membangun model ML, menghasilkan insights, bermitra dengan pemangku kepentingan." Semua itu benar, secara teknis. Proporsinya tidak. Pada hari Selasa tipikal di perusahaan B2B SaaS, membangun model mungkin hanya seperempat hari Anda. Rekayasa fitur dan pekerjaan plumbing SQL menghabiskan porsi besar lainnya. Sisanya adalah pekerjaan terjemahan: menjelaskan kepada VP mengapa presisi bukan akurasi, mempertahankan interval kepercayaan kepada pemimpin sales, menulis Loom yang tidak ditonton siapa pun, dan mengingatkan tim platform bahwa ya, model dbt yang rusak setiap hari Rabu masih rusak setiap hari Rabu.

Ini bukan versi DS-senior-di-LinkedIn tentang pekerjaan ini. Ini adalah yang sesungguhnya. Jika Anda baru tiga bulan dan minggu Anda tidak sama sekali seperti peran yang Anda wawancarai, itu bukan cacat pada diri Anda. Itu adalah perannya.

Berikut seperti apa hari Selasa nyata.

8:00 hingga 8:30 pagi: Pemeriksaan performa model

Kopi di tangan, laptop terbuka, tab pertama selalu MLflow atau Weights & Biases. Anda memindai prediksi kemarin terhadap label yang masuk semalam. AUC model churn turun dari 0,84 menjadi 0,79 selama akhir pekan. Itu bukan bencana, tetapi cukup untuk diselidiki sebelum standup.

Anda memeriksa hal-hal yang jelas terlebih dahulu. Apakah distribusi input bergeser? Anda membuka dashboard penyimpangan fitur. Dua fitur sedang menyimpang. Satu adalah "hari sejak login terakhir," yang masuk akal karena tim produk merilis alur onboarding baru pada hari Jumat dan banyak pengguna lama dipancing kembali masuk. Yang lain adalah "tiket dukungan dalam 30 hari terakhir," yang tidak memiliki penjelasan yang jelas. Anda membuat catatan untuk digali setelah standup.

Pemeriksaan tiga puluh menit ini adalah salah satu bagian pekerjaan yang paling diremehkan. Separuh DS senior yang saya kenal mendapat promosi berkat menangkap sesuatu di sini yang tidak akan ditangkap orang lain. Modelnya tidak rusak. Dunia tempat model dilatih rusak sedikit, dan Anda memperhatikannya sebelum orang lain.

Anda juga memeriksa eksperimen yang dijalankan kemarin di MLflow. Dua rekan Anda memulai pekerjaan pelatihan pukul 11 malam. Satu berhasil. Satu meledak karena seseorang mengganti nama kolom di tabel sumber tanpa memberi tahu siapa pun. Selamat datang di pekerjaan data.

9:30 hingga 11:30 pagi: Desain eksperimen (90 menit berdebat tentang metrik)

PM masuk ke standup dengan pertanyaan: "Apakah halaman harga baru lebih baik konversinya?" Mudah, bukan? Ukuran sampel, uji dua proporsi, kirim.

Tidak pernah semudah itu.

Anda menghabiskan 90 menit di Hex untuk memeriksa ruang lingkup eksperimen. Matematikanya adalah bagian yang mudah. Berikut yang sebenarnya memakan waktu:

Mendefinisikan "menang." PM ingin mengukur klik pada tombol "Mulai uji coba gratis". Anda menunjukkan bahwa klik bukan sama dengan mulai, mulai bukan sama dengan aktivasi, dan aktivasi bukan sama dengan konversi berbayar. Pada saat Anda selesai, metrik sukses telah berubah tiga kali dan Anda memiliki metrik pengaman untuk retensi minggu pertama karena funnel halaman harga lama memiliki kebocoran yang diketahui setelah aktivasi.

Pemeriksaan realitas kalkulasi power. Dengan lalu lintas mingguan Anda saat ini, mendeteksi peningkatan relatif 3% dalam konversi berbayar memerlukan menjalankan pengujian selama enam minggu. PM menginginkan hasil dalam dua. Anda setuju untuk metrik proxy yang lebih berisik (mulai percobaan) untuk pembacaan awal dan metrik nyata (konversi berbayar) untuk keputusan akhir.

Metrik pengaman. Bagaimana jika halaman baru meningkatkan mulai percobaan tetapi menurunkan kualitas percobaan tersebut? Anda menambahkan pengaman pada tingkat aktivasi. Bagaimana jika mengubah campuran pemilihan tier paket? Anda menambahkan pengaman pada rata-rata pendapatan per pelanggan baru. Sekarang ada tiga metrik, dua pengaman, dan aturan berhenti.

Pre-commit segmentasi. PM bertanya apakah Anda bisa "memotongnya berdasarkan ukuran perusahaan setelahnya." Anda berkata tidak, lalu ya, tetapi hanya dengan koreksi Bonferroni dan daftar segmen yang dituliskan sebelum pengujian dimulai. Anda menulis daftarnya bersama. Ini akan menyelamatkan pekerjaan seseorang nanti.

Anda mempublikasikan dokumen desain eksperimen ke workspace Hex tim, menautkannya di halaman Notion proyek, dan menandai PM dan eng lead. Matematikanya membutuhkan 15 menit. Percakapannya membutuhkan 75. Rasio itu kurang lebih benar untuk sisa karier Anda.

12:30 hingga 2:00 siang: Async dengan eng tentang penerapan produksi

Anda makan siang tergesa-gesa di meja. Blok sore adalah yang paling membuat frustrasi DS baru: model Anda telah "siap dirilis" selama tiga minggu, dan hambatannya tidak ada hubungannya dengan model.

Modelnya sendiri baik-baik saja. Masalahnya adalah alur fitur. Model churn Anda memerlukan fitur yang disebut weighted_engagement_30d, yang merupakan jumlah tertimbang login, pengiriman pesan, dan kehadiran rapat selama 30 hari terakhir. Fitur tersebut dihitung dalam model dbt yang disebut fct_user_engagement_daily. Model dbt rusak setiap Rabu pagi antara pukul 6 dan 7 pagi Pasifik karena bergantung pada sinkronisasi Salesforce yang selesai secara tidak konsisten.

Anda tidak memiliki model dbt tersebut. Tim analytics engineering yang memilikinya. Mereka tahu model itu tidak stabil. Mereka memiliki tiket untuk itu. Mereka sudah memiliki tiket selama dua bulan.

Jadi tugas hari ini adalah menulis komentar PR yang panjang pada penerapan staging. Anda menjelaskan:

Alur fitur memiliki jendela kegagalan mingguan yang diketahui
Model Anda memerlukan fitur dengan kesegaran paling lama 24 jam
Pemantauan saat ini pada model dbt menyala setelah fitur sudah basi
Anda ingin tim platform memperbaiki model dbt hulu atau menghubungkan fallback yang menggunakan snapshot terakhir yang baik dari fitur dengan tanda kesegaran

Anda menandai platform team lead, menautkan peringatan pemantauan dbt dari Rabu lalu sebagai bukti, dan menautkan dokumen persyaratan kesegaran model Anda. Anda tidak eskalasi. Anda tidak mengeluh. Anda meninggalkan komentar PR yang tenang dan spesifik dengan tiga opsi yang diurutkan berdasarkan preferensi Anda dan rekomendasi default. Kemudian Anda menutup tab.

Ini adalah bagian pekerjaan yang JD sebut "kolaborasi lintas fungsional." Ini sebagian besar adalah menunggu, dengan advokasi tenang yang terputus-putus, untuk sesuatu yang tidak bisa Anda perbaiki agar diperbaiki oleh orang lain. Damaikan ini lebih awal.

2:00 hingga 3:00 siang: Rapat "prediksi ini salah"

Seorang pemimpin sales telah memesan tiga puluh menit di kalender Anda. Baris subjek: "Chat singkat tentang model churn, salah satu pelanggan yang ia tandai baru saja memperbarui kontrak tiga tahun."

Anda tahu bagaimana ini akan berlangsung. Anda telah mengikuti rapat ini sekitar empat belas kali sejak Anda mulai. Anda memiliki skrip. Berikut gambaran kasarnya:

Buka dengan rasa ingin tahu, bukan pertahanan. "Ceritakan tentang pelanggan ini. Apa kisah mereka?" Anda membiarkan pemimpin sales meluapkan selama lima menit tentang bagaimana model akan mempermalukan tim, bagaimana pelanggan akan merasa tersinggung jika mereka tahu, dan bagaimana mereka sudah punya firasat model itu tidak dapat diandalkan.

Reframe metrik tanpa membuat mereka merasa bodoh. "Model memprediksi pada presisi 87% untuk kelompok 'risiko churn tinggi'. Itu berarti dari setiap 100 akun yang ditandai model, sekitar 87 benar-benar churn dalam 90 hari. Yang lain 13 tidak. Akun ini adalah salah satu dari 13 tersebut. Itu bukan model gagal. Itu model berkinerja persis seperti yang dirancang."

Bawa dashboard Looker, bukan nada defensif. Anda berbagi layar dan membuka Looker performa model churn. Anda menunjukkan kurva precision-recall. Anda menunjukkan bahwa menurunkan threshold untuk menangkap lebih banyak churn berarti bahkan lebih banyak false positive, dan menaikkannya akan melewatkan churn nyata. Anda menunjukkan nilai dolar dari churn yang tertangkap kuartal lalu ($2,4 juta) versus nilai dolar false positive jika setiap akun yang ditandai pergi (jauh lebih tinggi dari itu, tetapi mereka tidak perlu tahu).

Tutup dengan tujuan model, dalam bahasa mereka. "Model ini adalah alat triase. Bukan vonis. Model ini memberi tahu tim Anda di mana harus menghabiskan jam pertama minggu mereka. Fakta bahwa satu akun yang ditandai memperbarui berarti tim Anda melakukan pekerjaan mereka. Mereka melakukan intervensi. Itulah kondisi kemenangan."

Pemimpin sales meninggalkan panggilan lebih tenang dari ketika mereka masuk. Anda menambahkan percakapan ke log eksperimen. Anda menambahkan slide ke sinkronisasi DS-ke-Sales bulanan berikutnya yang berjudul "Presisi bukan Akurasi" karena jika Anda sudah mengikuti percakapan ini 14 kali, sisa organisasi sales lebih sering dari yang mereka akui.

4:00 hingga 5:30 sore: Pembersihan notebook dan log eksperimen

Blok terakhir hari ini kembali di Jupyter. Anda membuka notebook analisis dari pagi tadi tentang ruang lingkup eksperimen halaman harga. Ini berantakan. Separuhnya adalah kode sketsa. Ada sel yang hanya bertuliskan df.head() tanpa komentar. Ada chart tanpa label sumbu. Ada kueri SQL terhadap skema yang salah.

Anda membersihkannya. Disiplin di sini lebih penting dari keindahan. Anda tidak membuatnya cantik untuk diri sendiri. Anda membuatnya dapat dibaca untuk versi Anda tiga bulan dari sekarang yang perlu mengingat mengapa Anda memilih ukuran sampel 4.200 dan bukan 5.000. Konvensi pada tim Anda:

Sel markdown di bagian atas notebook dengan pertanyaan, tanggal, dan kesimpulan
Setiap bagian memiliki header markdown satu baris di atas kode
Chart memiliki judul, label sumbu, dan interpretasi satu kalimat di bawah
Sel terakhir adalah sel markdown dengan rekomendasi dan tindakan berikutnya

Anda melakukan commit notebook ke repo tim. Anda menulis ringkasan 200 kata di log eksperimen tim, yang ada di halaman Notion bersama. Anda juga mendorong perubahan model dbt yang Anda tulis pagi ini. Itu ada di branch terpisah dan ditandai untuk ditinjau besok.

Hal terakhir sebelum Anda menutup laptop: Anda memeriksa catatan rapat pemimpin sales dari pukul 2 siang dan menambahkan TODO ke backlog tim. "Bangun dashboard Looker untuk sales yang menampilkan presisi dan recall model churn dalam bahasa sederhana, diperbarui setiap minggu." Ini adalah ketiga kalinya Anda memikirkan untuk membangunnya. Mungkin minggu ini Anda benar-benar akan melakukannya.

Apa yang tidak akan diberitahu JD kepada Anda

Beberapa hal yang akan dilewatkan JD yang layak diketahui pada hari pertama.

Anda akan menulis lebih banyak SQL daripada Python. Snowflake atau BigQuery akan menjadi bahasa kedua Anda. Semakin bersih SQL Anda, semakin cepat loop iterasi Anda. Sebagian besar hambatan dalam minggu Anda bukan pemodelan. Mereka adalah "data belum dalam bentuk yang tepat."

Rekayasa fitur menghabiskan 40% waktu pemodelan Anda. Model XGBoost membutuhkan 20 menit untuk dilatih. Fitur-fitur yang masuk ke dalamnya membutuhkan dua minggu untuk dibangun, divalidasi, dan dihubungkan ke pipeline. DS baru selalu meremehkan ini.

"Masalah ML" yang paling sulit biasanya adalah pemangku kepentingan yang tidak mempercayai output. Anda bisa memiliki model yang dikalibrasi dengan indah dengan AUC layak publikasi dan nol dampak, karena tidak ada yang akan bertindak berdasarkan itu. Kepercayaan dibangun melalui penjelasan yang dapat diulang, dashboard dalam bahasa pemangku kepentingan, dan hadir ke rapat "prediksi ini salah" dengan tenang.

Kepanikan "prediksi ini salah" adalah acara mingguan. Siapkan skrip. Bawa dashboard. Jangan bersikap defensif. Percakapan adalah pekerjaannya, bukan gangguan dari pekerjaan.

Penerapan produksi lebih lambat dari yang Anda pikirkan. Bukan karena kodenya sulit. Karena dependensi data tidak stabil, lingkungan staging adalah cermin dari produksi kuartal lalu, dan tim platform juga melakukan yang terbaik mereka.

Alat yang benar-benar Anda gunakan

Stack bervariasi menurut perusahaan, tetapi bentuknya konsisten. Di sebagian besar toko B2B SaaS dengan fungsi DS nyata pada tahun 2026:

Python dan Jupyter untuk analisis dan pemodelan. Beberapa tim telah memindahkan pekerjaan yang lebih berat ke VS Code dengan notebook-sebagai-percent-files, tetapi Jupyter masih merupakan default untuk eksplorasi.
SQL pada Snowflake atau BigQuery untuk semua yang menyentuh data produksi. Jika Anda berasal dari tempat yang menggunakan Postgres langsung, model mental warehouse berbeda, dan Anda akan memikirkan biaya per kueri untuk pertama kalinya.
dbt untuk transformasi. Anda akan membaca lebih banyak model dbt daripada yang Anda tulis, tetapi Anda akan menulis beberapa.
MLflow atau Weights & Biases untuk pelacakan eksperimen. Sebagian besar tim memiliki salah satunya; hampir tidak masalah yang mana.
Hex untuk notebook kolaboratif yang bisa dibaca PM dan analis. Hex melakukan untuk analitik apa yang dilakukan Figma untuk desain.
Looker untuk dashboard yang menghadap pemangku kepentingan. Dashboard yang Anda bangun di sini adalah yang menjadi dasar penilaian pemangku kepentingan terhadap Anda, meskipun model di baliknya adalah pekerjaan sebenarnya.
Opsional tetapi umum: Airflow, Prefect, atau Dagster untuk orkestrasi. Anda mungkin atau mungkin tidak memiliki ini.

Anda tidak akan menggunakan semua ini di setiap tim. Anda mungkin akan mempelajari yang baru dalam 90 hari pertama Anda.

Seperti apa "bagus" setelah 90 hari

Jika Anda baru dalam peran ini, berikut definisi sukses yang berguna pada tanda tiga bulan. Lupakan jumlah model. Cari yang berikut:

Anda bisa menyebutkan pertanyaan nyata tiga pemangku kepentingan utama Anda, dalam bahasa mereka, tanpa dokumen di depan Anda.
Anda memiliki satu model dalam produksi. Bahkan yang kecil. Bahkan regresi logistik pada satu fitur. Produksi mengalahkan notebook.
Anda berhenti terkejut ketika pemangku kepentingan mengirim pesan "prediksi ini salah." Anda memiliki skrip. Anda membawa dashboard.
Anda tahu model dbt mana yang rusak setiap minggu dan fitur mana yang tidak stabil. Anda berhenti terkejut oleh kerusakan hari Rabu.
Anda telah menulis setidaknya satu dokumen yang ditautkan oleh DS lain di tim. Pengetahuan yang berkembang mengalahkan analisis yang terlupakan.

Itulah standarnya. Bukan "merilis lima model" atau "menggandakan kecepatan tim." Metrik itu tidak bertahan dalam kontak dengan realitas. Daftar di atas bertahan.

Pembagian 50/50 antara pekerjaan teknis dan pekerjaan terjemahan bukan cacat dalam peran ini. Itu adalah perannya. Terjemahan bukan di bawah pemodelan. Itulah cara pemodelan benar-benar mengubah sesuatu. DS yang bersandar pada itu lebih awal dari rekan-rekan mereka adalah yang mendapat promosi ke Senior dalam 18 bulan alih-alih 30.

Peringatan penurunan kualitas model pukul 6:42 pagi akan bergetar lagi besok. Sarapan dulu.

Panduan Praktis Data Scientist