30/60/90 Hari Pertama Anda sebagai Data Scientist Baharu

Pukul 9:47 pagi hari ketiga. Anda baru sahaja mengetahui saluran Slack mana yang penting. Kopi anda masih panas. Satu mesej masuk dari seseorang yang anda temui sekali semasa onboarding: "hei, boleh awak tengok model churn? ia dah off untuk seketika."

Tahniah. Anda baru sahaja mewarisi 18 bulan keputusan orang lain. Dua pemilik sebelumnya, tiada dokumentasi yang bernilai dibaca, set ciri yang tiada siapa faham sepenuhnya, dan CFO yang sudah enam minggu bertanya bila "pelaburan AI" itu akan membuahkan hasil. Model itu tidak dilatih semula sejak Ogos. Anda pun belum dapat menyediakan laptop sepenuhnya lagi.

Ini ialah pengalaman hari ketiga yang sebenar bagi kebanyakan Data Scientist baharu dalam B2B SaaS, dan godaannya amat kuat: hantar sesuatu yang cepat, apa-apa sahaja, supaya kelihatan seperti anda sedang membuktikan nilai diri. Jangan. Sembilan puluh hari pertama ialah masa anda menetapkan naratif sama ada kepimpinan melihat anda sebagai penggiat hasil atau sebagai baris anggaran seterusnya yang dipotong apabila lembaga bertanya di mana headcount melambung. Dan jawatan sains data dipotong lebih cepat daripada mana-mana fungsi teknikal lain apabila kisah nilai perniagaan tidak jelas.

Berikut ialah pelan 90 hari yang tidak memerlukan heroisme, tidak bergantung kepada anda menjadi seorang genius, dan tidak berakhir dengan anda memiliki model churn yang rosak milik orang lain sebagai KPI anda.

Mengapa Audit Lebih Baik daripada Membina (Dan Mengapa Kebanyakan Pengambilan DS Baharu Tersilap)

Kesilapan terbesar yang dilakukan Data Scientist baharu ialah menghantar model baharu pada minggu kedua untuk kelihatan produktif. Ia terasa hebat. Ia juga bermakna anda kini memiliki sesuatu yang tidak anda fahami konteks perniagaannya, anda telah memberi isyarat kepada pihak berkepentingan bahawa "menghantar model" ialah cadangan nilai anda (bukan begitu), dan anda telah melangkau satu-satunya tetingkap yang akan anda miliki untuk bertanya soalan bodoh tanpa penilaian.

Anda mendapat satu tempoh bulan madu sahaja. Gunakannya untuk mendengar, bukan membina. Berita baiknya ialah mendengar menghasilkan artifak ketara (memo audit, peta pihak berkepentingan, helaian panduan gudang data) yang kelihatan sama produktifnya kepada pengurus anda seperti model separuh siap, dan ia tidak menghasilkan hutang teknikal.

Hari 1-30: Audit dan Dengar

Tiga puluh hari pertama mempunyai satu matlamat: bina peta yang boleh dipertahankan tentang apa yang wujud, apa yang rosak, dan apa yang orang sebenarnya mahukan. Tiada model baharu. Tiada "eksperimen cepat." Tiada janji.

Inventori Setiap Model dalam Pengeluaran

Buat hamparan. Satu baris per model yang berjalan di mana-mana: pengeluaran, notebook berjadual, benda dalam Airflow yang tiada siapa mengakui sebagai model. Untuk setiap satu, isi tiga lajur:

Prestasi berbanding prestasi yang didakwa. Apa yang kad model atau ulasan suku tahun terakhir katakan ia lakukan (AUC, ketepatan pada desil teratas, MAPE, apa sahaja)? Apa yang ia sebenarnya lakukan pada data 90 hari terakhir? Anda akan menemui sekurang-kurangnya satu model di mana jurangnya memalukan. Model churn biasanya merupakan pesalah terburuk. Hanyutan 15-25% pada ciri-ciri utama adalah normal dalam B2B SaaS di mana campuran pelanggan berubah setiap suku tahun.
Keadilan dan hanyutan data. Adakah taburan input masih hampir dengan yang dilatih model? Untuk model jadual, pemeriksaan Population Stability Index (PSI) cepat pada lima ciri teratas biasanya memberitahu anda segalanya. PSI melebihi 0.25 bermakna model beroperasi di luar taburan latihannya dan ramalan adalah hingar yang berpakaian sebagai isyarat.
Nilai perniagaan sebenar. Siapa yang menggunakan output? Keputusan apa yang dipacu? Apa yang akan berlaku jika model mengembalikan nilai tetap esok? Jika jawapannya ialah "jujurnya, mungkin tiada apa-apa," tulis itu. Anda akan memerlukannya kemudian.

Tiga hingga lima model adalah normal. Lapan atau lebih bermakna seseorang membina untuk kelihatan sibuk dan anda telah mewarisi perkuburan.

Hadiri Lima Sesi Sinkronisasi Pihak Berkepentingan

Bukan lima perbualan. Lima sinkronisasi berulang yang anda sertai sebagai pemerhati senyap untuk dua atau tiga mesyuarat pertama sebelum anda mula menyumbang. Pilih satu dari setiap:

Operasi jualan (ketepatan ramalan, liputan saluran, aduan pemarkahan lead)
Kejayaan pelanggan (isyarat churn, permainan pengembangan, pautan NPS-ke-hasil)
Produk (penggunaan ciri, pengaktifan, apa yang mereka A/B test dengan tidak betul)
Kewangan (ramalan hasil, ekonomi unit, model sebenar perniagaan CFO)
Kejuruteraan / platform data (kos gudang, kebolehpercayaan saluran, apa yang sedang terbakar)

Anda mendengar untuk dua perkara: keputusan mana yang dibuat berdasarkan gerak hati yang boleh dibuat berdasarkan data, dan keputusan mana yang dibuat berdasarkan data yang sebenarnya salah. Perkara kedua lebih biasa daripada yang orang akui. Operasi jualan yang menjalankan ramalan saluran dari laporan Salesforce yang mengira semula pembaharuan adalah hit terbesar lima teratas di kebanyakan syarikat B2B SaaS.

Ketahui Di Mana Penipuan Hidup dalam Gudang Data

Setiap gudang data mempunyai lapisan kebenaran kecil yang menyedihkan. Lajur yang dinamakan semula tiga kali. Baris yang dipadam secara lembut yang alat BI diam-diam memasukkan. Pepijat zon masa yang menjadikan Isnin di Singapura muncul sebagai Ahad. Medan revenue_usd yang pra-diskaun dalam satu jadual dan pasca-diskaun dalam jadual di sebelahnya.

Luangkan seminggu dengan sesiapa yang memiliki lapisan analitik. Bawa buku nota. Tanya mereka: "Apa yang anda harap orang tahu sebelum menanya jadual ini?" Anda akan mendapat lebih banyak nilai dari soalan tunggal itu daripada tiga minggu membaca dokumen dbt.

Menjelang hari ke-30 anda seharusnya mempunyai: hamparan audit, nota dari lima sinkronisasi pihak berkepentingan, dokumen satu halaman "perangkap gudang data", dan sifar model baharu dalam perjalanan.

Hari 31-60: Matikan, Hantar, Cadang

Sekarang anda mula menghasilkan kerja yang kelihatan. Tiga hasil, dalam susunan ini.

Matikan Satu Model yang Rosak secara Terbuka, dengan Memo

Ini kedengarannya menghadkan kerjaya. Sebaliknya. Mematikan model yang rosak ialah perkara yang paling tinggi leverage yang boleh anda lakukan sebagai DS baharu, kerana:

Ia membebaskan pengiraan, perhatian headcount, dan lebar jalur pihak berkepentingan.
Ia menunjukkan bahawa anda mempunyai pertimbangan, bukan sekadar hasil.
Ia menetapkan bahawa "hantar model" bukan satu kebajikan jika model itu salah.

Pilih pesalah terburuk dari audit anda. Calon klasik ialah model churn yang telah dilatih semula dua kali dalam 18 bulan, mempunyai hanyutan ciri 22%, tidak mendorong sebarang permainan pengekalan sebenar (wakil CS mengabaikan skor), dan memerlukan $400/bulan dalam pengiraan. Tulis memo satu halaman: apa yang model dakwa, apa yang ia sebenarnya lakukan, berapa kosnya, keputusan apa yang sepatutnya ia dorong, apa yang anda cadangkan untuk menggantikannya (sering: "laporan kohort mudah, disegar seminggu sekali").

Hantar memo kepada pengurus anda dan pihak berkepentingan asal. Biar mereka bertindak balas. Sembilan kali daripada sepuluh mereka akan berkata "ya, kami berhenti melihatnya beberapa bulan lalu." Kini ia hilang dengan rekod bertulis, dan anda telah menunjukkan kepimpinan bahawa anda akan memotong kerja anda sendiri apabila kerja itu tidak membuahkan hasil.

Templat ringkas yang berfungsi:

Memo: Berhentikan model [nama model]
Pengarang: [anda]
Tarikh: [tarikh]

Apa yang ia lakukan hari ini: [satu ayat]
Apa yang ia dakwa semasa dilancarkan: [metrik dan nilai]
Apa yang ia sebenarnya lakukan pada 90 hari terakhir: [metrik dan nilai]
Kos pengiraan: [$/bulan]
Keputusan yang ia dorong: [senarai, jujur jika jawapannya "tiada"]
Cadangan: Berhentikan menjelang [tarikh]. Ganti dengan [perkara lebih mudah atau tiada].
Risiko jika tidak diberhentikan: [penyelenggaraan berterusan + keyakinan palsu dalam ramalan lapuk]

Itu sahaja. Satu halaman. Tiada lampiran.

Hantar Satu Analisis Kemenangan Cepat yang Benar-benar Diminta oleh Pihak Berkepentingan

Kembali kepada nota sinkronisasi pihak berkepentingan anda. Cari permintaan yang paling kecil dan paling konkrit, yang orang sebut secara lalu, dengan keputusan yang jelas dilampirkan. Bukan "kita patut gunakan AI untuk X." Sesuatu seperti: "Saya ingin tahu langkah onboarding mana yang menyebabkan paling banyak pengguguran dalam 14 hari pertama."

Buat yang itu. Penulisan mesra Slack. Tiga carta maksimum. Cadangan dalam perenggan pertama. Libatkan orang yang bertanya, ditambah pengurus mereka. Anda tidak cuba memenangi pertandingan Kaggle. Anda membuktikan anda boleh menukar soalan nyata kepada jawapan nyata dalam bawah sepuluh hari kerja.

Cadangkan Pelan Hala Tuju ML 6 Bulan yang Terikat kepada 2-3 Metrik Perniagaan

Menjelang hari ke-60 anda seharusnya mempunyai konteks yang cukup untuk merangka pelan hala tuju. Dua hingga tiga metrik perniagaan, maksimum. Untuk setiap satu, hipotesis 1-2 ayat, pendekatan model atau analisis, anggaran usaha (kecil / sederhana / besar), dan yang paling penting, kriteria pembatalan (apa yang akan membuat anda berhenti bekerja pada ini).

Kriteria pembatalan ialah yang membezakan pelan hala tuju dari senarai keinginan. "Jika pada minggu ke-8 peningkatan garis asas kurang daripada 5%, kami berhenti dan realokasi" adalah baris pelan hala tuju. "Bina model churn" bukan.

Kongsi pelan hala tuju dengan eksekutif yang mengambil anda. Dapatkan maklum balas. Semak semula. Matlamatnya ialah agar mereka dapat menerangkan dua suku tahun anda yang seterusnya dalam satu ayat kepada sesiapa sahaja dalam C-suite.

Hari 61-90: Miliki Satu Metrik, Bentang, dan Rancang H2

Tiga puluh hari terakhir adalah tentang peralihan dari "DS baharu" kepada "orang yang memiliki X."

Miliki Satu Metrik Perniagaan yang Terikat kepada Model

Frasa kritikal di sini: anda memiliki metrik, bukan model. Jika anda memiliki "model churn," anda mewarisi identiti orang lain dan anda akan dinilai berdasarkan sesuatu yang tidak anda reka. Jika anda memiliki "pengekalan logo 12 bulan dalam segmen PKS," anda boleh menggunakan apa-apa kombinasi model, analisis, dan perubahan operasi yang menggerakkan angka.

Pilih satu. Satu sahaja. Ia seharusnya:

Metrik yang kewangan dan pasukan eksekutif sudah jejaki (jangan cipta yang baharu)
Dalam lingkungan pengaruh anda (model menyentuhnya, tetapi begitu juga aliran kerja CS, penetapan harga, dan produk)
Boleh diukur dalam tetingkap 60-90 hari, bukan 12 bulan

Pilihan baik biasa untuk DS baharu dalam B2B SaaS: kadar churn PKS, penukaran lead-ke-peluang, penukaran percubaan percuma ke berbayar, hasil pengembangan per CSM. Pilihan buruk biasa: jumlah hasil (terlalu banyak input, anda tidak akan mendapat kredit), NPS (terlalu bising), "ketepatan model" (bukan metrik perniagaan).

Bentangkan Laporan 90 Hari kepada Eksekutif yang Mengambil Anda

Mesyuarat 15 minit. Dek lima slaid. Struktur yang berfungsi:

Apa yang saya temui. Audit, dalam satu carta (model yang diberhentikan, model yang sihat, model dalam pengawasan).
Apa yang saya hantar. Analisis kemenangan cepat, memo pemberhentian, metrik yang kini saya miliki.
Apa yang saya pelajari tentang perniagaan. Dua atau tiga perkara yang mengejutkan anda (isu kualiti data, keputusan yang tidak dibuat berdasarkan data, permintaan yang terus datang).
Pelan hala tuju. Rancangan 6 bulan anda, dengan kriteria pembatalan.
Apa yang saya perlukan. Headcount, infrastruktur, akses pihak berkepentingan, keputusan.

Slaid lima ialah yang paling penting dan paling kerap dilangkau. Jika anda tidak dapat menyatakan apa yang anda perlukan untuk berjaya dalam 90 hari yang seterusnya, eksekutif akan menganggap anda tidak memerlukan apa-apa, dan kemudian mereka akan tertanya-tanya pada bulan keenam mengapa kemajuan terhenti.

Cadangkan Pelan ML H2 dengan Headcount, Infrastruktur, dan Kriteria Pembatalan

Ini ialah pelan hala tuju dari hari ke-60, kini dipertajamkan dengan tiga bulan konteks. Tiga perkara masuk dalam pelan H2 yang tidak ada dalam pelan hala tuju asal:

Matematik headcount. "Untuk melaksanakan pelan ini saya memerlukan X hari kejuruteraan dan Y hari kejuruteraan data setiap suku tahun. Hari ini saya mempunyai Z. Berikut ialah jurangnya." Bersikap spesifik. Jurutera ML adalah mahal. Kapasiti kejuruteraan data adalah kesesakan pada 60% kerja DS di kebanyakan kedai B2B SaaS, dan mengatakan itu dengan lantang lebih awal melindungi anda daripada dipersalahkan atas masalah penghantaran yang bukan milik anda.
Keperluan infrastruktur. Stor ciri? Penjejakan eksperimen? Platform inferens yang diurus? Senaraikan dengan kos kasar. CFO lebih suka melihat item baris $30K/tahun sekarang daripada kejutan $30K/tahun dalam Q3.
Kriteria pembatalan, disegar semula. Enam bulan kerja sentiasa mendedahkan pertaruhan mana yang salah. Kodifikasikan bila anda akan berhenti, bukan sahaja bila anda akan bermula.

Perbualan Di Mana CFO Bertanya tentang ROI

Perbualan ini akan datang. Mungkin pada minggu ke-5 atau ke-6. Ia biasanya berbunyi seperti: "Jadi bila kita mula nampak pulangan daripada pelaburan AI?"

Jawapan yang salah: "Ia adalah pelaburan jangka panjang." "AI mengambil masa." "Kita masih dalam fasa eksperimen." Semua ini benar. Tiada satu pun yang berkesan. CFO bertanya soalan yang sah dan layak mendapat jawapan yang sah.

Jawapan yang berkesan:

"Sekarang saya dalam mod audit. Saya telah menemui dua model yang memerlukan kira-kira $X/bulan dan tidak mendorong sebarang keputusan, dan saya akan memberhentikannya menjelang akhir bulan. Menjelang hari ke-90 saya akan memiliki metrik churn PKS dan mempunyai pelan hala tuju dengan dua atau tiga pertaruhan, masing-masing terikat kepada metrik perniagaan yang anda sudah jejaki, masing-masing dengan kriteria pembatalan. Jawapan jujur kepada 'bila kita nampak pulangan' ialah: menjelang akhir Q3 jika saya betul, dan kita akan tahu awal cukup untuk beralih jika saya salah."

Itulah pembingkaian. Tindakan jangka dekat yang konkrit, satu metrik yang akan anda miliki, tarikh, dan rancangan untuk gagal cepat jika pertaruhan tidak berhasil. CFO bertindak balas dengan baik kepada kriteria pembatalan kerana mereka tidak pernah mendengar Data Scientist menyebutnya sebelum ini.

Perangkap Biasa yang Akan Diam-diam Menenggelamkan 90 Hari Pertama

Beberapa perangkap yang menangkap walaupun pengambilan DS berpengalaman:

Membina pada minggu kedua untuk "kelihatan produktif." Anda akan mewarisi kesalahan untuk model itu selama-lamanya. Tahan diri.
Mengatakan ya kepada permintaan "satu AI" tanpa mengskopkan keputusan sebenar. Apabila VP berkata "boleh kita gunakan AI untuk [perkara kabur]?", jawapan yang betul ialah "keputusan apa yang anda akan buat secara berbeza dengan output?" Jika mereka tidak dapat menjawab, projek itu belum wujud lagi. Jangan sukarela untuk membinanya juga. (Mengskopkan Permintaan AI yang Kabur pergi lebih mendalam di sini.)
Mewarisi model churn yang rosak sebagai KPI anda. Model ialah alat. Pengekalan ialah metrik. Miliki metrik.
Mengabaikan cukai kejuruteraan data. 60% masa anda dalam tahun pertama akan pergi ke paip data: membaiki saluran, menyahpepijat gabungan, mengesahkan bahawa angka gudang sepadan dengan angka alat BI. Anggarkan untuk itu. Jangan berpura-pura ia akan menjadi 20%.

Mengukur Kejayaan pada Hari ke-90

Ujian jujur bagi 90 hari pertama yang berjaya bukan "adakah anda menghantar model." Ia adalah:

Anda boleh menamakan tiga metrik perniagaan teratas dan model mana yang menyentuh setiap satu
Satu model yang rosak sudah mati, dengan rekod bertulis
Satu analisis kemenangan cepat dihantar dan mendapat kredit dari pemohon
Anda memiliki satu metrik, bukan lima
Eksekutif yang mengambil anda boleh menerangkan pelan hala tuju anda dalam satu ayat

Jika lima perkara tersebut benar pada hari ke-91, anda bersedia untuk tahun yang kukuh. Data Scientist yang keletihan pada bulan kesembilan hampir selalu membina model baharu pada bulan pertama dan menghabiskan lapan bulan berikutnya mempertahankannya.

Buku Panduan Data Scientist