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

Pukul 9:47 pagi pada hari ketiga. Anda hampir selesai mengetahui VPN anda. Mesej Slack tiba daripada seseorang yang namanya anda tidak kenal: "hey selamat datang! soalan cepat, boleh tarik MRR mengikut segmen untuk board deck esok? hanya perlu dihiris mengikut band ARR dan saluran pemerolehan. terima kasih!"

Cara anda menjawab mesej itu menentukan dua belas bulan berikutnya.

Jika anda berkata ya dan menjalankan pertanyaan, anda baru sahaja menandatangani kontrak. Anda kini adalah Orang Pengeluaran Ad Hoc. Anda akan menghabiskan 40 jam seminggu untuk "soalan cepat" dan menghantar sifar kerja strategik. Menjelang hari ke-91, apabila pengurus anda bertanya apa yang anda capai, anda akan mempunyai arkib Slack bukannya sebuah cerita.

Jika anda berkata tidak, anda adalah Data Analyst baharu yang menghalang board deck. Juga teruk.

Terdapat laluan ketiga. Panduan ini adalah laluan tersebut.

Mengapa Data Analyst memerlukan rangka kerja 30/60/90 lebih daripada sesiapa pun

Jurutera mendapat backlog. PM mendapat roadmap. Pereka mendapat fail Figma yang sudah berjalan. Data Analyst memasuki pekerjaan di mana setiap pihak berkepentingan berfikir mereka adalah keutamaan, Data Analyst terdahulu tidak meninggalkan dokumentasi, dan televisyen syarikat menunjukkan papan pemuka yang tidak disentuh selama lapan bulan. Separuh daripadanya salah. Tiada siapa tahu separuh yang mana.

Tanpa rangka kerja, anda menjadi mesin pengeluaran SQL. Dengan rangka kerja, anda menjadi seseorang yang menyingkirkan 30 papan pemuka rosak, menghantar satu model hasil kanonik, dan memasuki mesyuarat perancangan H2 dengan roadmap analitik yang tidak diminta oleh VP anda tetapi tiba-tiba diperlukan.

Rangka kerjanya mudah: audit, kemudian hantar satu perkara, kemudian miliki satu metrik. Tiga bulan. Satu kerja sebulan. Jangan langkau ke hadapan.

Hari 1-30: Audit, jangan bina

Kesilapan terbesar yang saya lihat Data Analyst baharu lakukan adalah membuka editor SQL pada hari ke-4 dan cuba "membaiki" sesuatu. Anda belum tahu apa yang rosak. Anda belum tahu apa yang asas. Anda belum tahu papan pemuka mana yang "rosak" sebenarnya adalah satu-satunya perkara yang dipercayai oleh CFO.

Bulan pertama adalah peninjauan. Anda hampir tidak menulis sebarang pertanyaan. Anda mengambil banyak nota.

Minggu 1: Inventori papan pemuka

Tarik senarai setiap papan pemuka, laporan, dan pertanyaan yang disimpan dalam alat BI anda (Looker, Mode, Tableau, Metabase, apa sahaja yang anda warisi). Bagi setiap satu, rakam lima ruang:

• Nama
• Pemilik (atau "tidak diketahui")
• Bilangan paparan terakhir (60 hari terakhir)
• Tarikh suntingan terakhir
• Status (hidup / syak / mati)

Mati bermaksud: sifar paparan dalam 60 hari, ATAU disunting terakhir oleh seseorang yang meninggalkan syarikat lebih daripada enam bulan lalu. Dalam syarikat SaaS saiz sederhana yang tipikal, anda akan mendapati 60-70% papan pemuka adalah mati. Di syarikat terakhir saya, kami mempunyai 312 papan pemuka. Selepas audit, 47 sahaja yang sebenarnya digunakan. Selebihnya adalah kapal hantu.

Jangan padam apa-apa lagi. Hanya senaraikan.

Minggu 2: Lawatan skema dan pertarungan hasil kanonik

Sekarang anda membaca. Buka repositori dbt (atau gudang data anda jika tiada dbt). Cari lima jadual yang akan anda sentuh setiap minggu (biasanya sejenis accounts, subscriptions, events, users, dan satu jadual hasil). Baca definisi model. Baca komen lajur. Baca makro.

Anda akan, dengan kepastian statistik, mendapati bahawa syarikat anda mempunyai pelbagai definisi hasil. Di satu syarikat yang saya bekerja, kami mempunyai 14 versi hasil yang hidup dalam gudang data. ARR ditempah. ARR dibilkan. ARR dijangkakan. ARR bersih baharu. ARR kasar dikekalkan. Setiap satu adalah betul untuk tujuan tertentu dan salah untuk tujuan yang lain. Kewangan menggunakan satu. Jualan menggunakan yang lain. CEO mempunyai Google Sheet dengan yang ketiga.

Ini adalah normal. Ini juga adalah tugas paling penting minggu ke-2 anda. Pilih mesyuarat dengan rakan kewangan anda. Tanya: "Yang mana antara ini adalah sumber kebenaran untuk board?" Dapatkan jawapan secara bertulis. Bukan mesej Slack, tetapi dokumen. Perbualan itu adalah asas tempat semua perkara lain bergantung.

Jika kewangan tidak dapat memberitahu anda, itulah penemuan. Catatkannya.

Minggu 3: Penyegerakan pihak berkepentingan (dengar, jangan syorkan)

Duduk dalam lima mesyuarat: ops hasil, kejayaan pelanggan, pemasaran, produk, kewangan. Anda bukan di sana untuk membentang. Anda bukan di sana untuk "memperkenalkan diri." Anda di sana untuk mendengar soalan berulang.

Corak yang anda cari: soalan yang sama ditanya oleh tiga pasukan yang berbeza dengan tiga cara yang berbeza. Itulah papan pemuka minggu ke-5 anda.

Contoh apa yang saya dengar dalam penyegerakan minggu ke-3:

• Ketua RevOps: "Kami tidak pernah tahu segmen mana sebenarnya Pipeline kami tertumpu."
• Pengarah CS: "Saya harap saya boleh melihat ARR pengembangan mengikut industri tanpa mengeksport ke helaian."
• CMO: "Pipeline bersumber pemasaran mengikut segmen ada di lima tempat berbeza."

Itulah soalan yang sama tiga kali. Itulah papan pemuka yang anda bina pada bulan dua.

Bawa buku nota. Jangan buka komputer riba. Jangan sukarela untuk "tarik sesuatu dengan cepat." Apabila ditanya, katakan: "Saya dalam mod audit untuk dua minggu lagi. Mari tambah ke borang permohonan apabila ia sudah siap." (Lebih lanjut tentang borang permohonan dalam sebentar.)

Minggu 4: Senarai pembunuhan

Kini anda mencadangkan pemansuhan beransur papan pemuka yang mati. Di sinilah Data Analyst baharu menjadi takut dan melangkau. Jangan.

Kembali ke inventori anda. Bagi setiap papan pemuka yang mati, cari pencipta asal (atau pasukan yang menaunginya) dan tanya: "Ini tidak dilihat dalam X hari. Adakah anda OK jika saya mengarkibkannya?" 80% masa jawapannya adalah "Ya ampun ya, saya lupa ia wujud." 15% masa jawapannya adalah "sebenarnya simpan, saya gunakannya setiap bulan." 5% masa anda akan mempelajari sesuatu yang penting tentang perniagaan.

Dapatkan persetujuan secara bertulis. Thread Slack sudah mencukupi. Kemudian arkib, jangan padam. Kebanyakan alat BI membolehkan anda mengarkib dengan pemulihan satu klik. Anda mahukan jejak kertas.

Ini adalah skrip yang berfungsi untuk saya:

Hai [nama], saya sedang melakukan pembersihan papan pemuka sebagai sebahagian daripada onboarding. "[nama papan pemuka]" tidak dilihat selama 73 hari dan disunting terakhir oleh [orang yang telah keluar]. Saya ingin mengarkibkannya (boleh dipulihkan, tidak dipadam). OK dengan anda? Jika anda lebih suka menyimpannya, tiada masalah, hanya ingin mengesahkan seseorang memilikinya.

Hantar ini dalam kelompok 10. Jangan kejar respons. Senyap selepas 5 hari perniagaan = arkib. Dokumentasikan segala-galanya.

Menjelang akhir minggu ke-4, anda biasanya menyingkirkan 40-150 papan pemuka. Itulah deliverable pertama anda. Ia juga adalah satu-satunya deliverable yang boleh anda dakwa yang tidak memerlukan sebaris SQL pun, dan itulah intipatinya.

Hari 31-60: Hantar satu perkara, tetapkan SLA

Bulan dua adalah di mana kerja muncul. Tetapi anda hanya boleh melakukan tiga perkara. Hantar satu papan pemuka. Terbitkan SLA. Bina satu model dbt. Itu sahaja. Tahan dorongan untuk melakukan lebih.

Hantar satu papan pemuka yang semua orang minta

Ingat soalan dari minggu ke-3 yang tiga pasukan tanya? Bina papan pemuka itu. Hanya itu sahaja.

Disiplin di sini adalah sukar. Orang akan bertanya "sambil anda berada di sana, boleh anda juga tambah..." dan jawapannya adalah tidak. Bukan kerana permintaan mereka itu buruk, tetapi kerana setiap "sambil anda berada di sana" bertukar menjadi perangkap Orang Pengeluaran Ad Hoc dengan langkah tambahan. Hantar satu perkara. Buat ia baik. Hantarnya.

Papan pemuka "baik" pertama bermaksud:

• Satu soalan, dijawab dengan jelas. Bukan lima soalan.
• Definisi metrik adalah yang kanonik yang anda perjuangkan pada minggu ke-2, dan footer papan pemuka menyatakannya. ("Hasil ditakrifkan mengikut [pautan ke model dbt]. Disemak terakhir bersama Kewangan pada [tarikh].")
• Tiga penapis maksimum. Segmen, julat tarikh, satu potongan khusus pasukan.
• Satu perenggan "Cara membaca ini" di bahagian atas.
• Pemilik (anda) dan saluran Slack "soalan?".

Titik terakhir itu adalah tidak boleh dirundingkan. Setiap papan pemuka tanpa pemilik menjadi kapal hantu dalam 18 bulan. Anda akan menjadi Data Analyst yang memecahkan corak itu.

Terbitkan SLA ad hoc

Inilah saat anda berhenti menjadi mesin pengeluaran SQL. Anda menerbitkan satu halaman (dokumen Notion, halaman Confluence, apa sahaja yang digunakan oleh syarikat anda) yang menyatakan:

Pengambilan permintaan data ad hoc

1. Hantar melalui [borang / saluran #data-requests]. DM Slack kepada saya akan diarahkan ke sini.
2. Tiga ruang diperlukan: apa yang anda perlukan, bila anda perlukan, keputusan apa yang ia memaklumkan.
3. SLA: permintaan di bawah 4 jam kerja, hari yang sama atau pagi berikutnya. Permintaan melebihi 4 jam, ditriaj ke sprint seterusnya.
4. Apa-apa yang ditag "board deck" atau "ulasan eksekutif" akan didahulukan.

Tiga ruang diperlukan. Bukan tujuh. Bukan borang permohonan 14 soalan. Ruang ketiga (keputusan apa yang ia memaklumkan) adalah yang melakukan keajaiban. Separuh permintaan terhenti di sini kerana pemohon menyedari mereka sebenarnya tidak memerlukan data itu, mereka hanya ingin tahu. Separuh lagi masuk dengan lebih ketat kerana pemohon terpaksa berfikir dahulu.

Minta pengurus anda menghantar pengumuman, bukan anda. "Hai pasukan, [nama anda] kini menguruskan pengambilan analitik. Sila gunakan borang mulai sekarang." Ayat itu bernilai seratus DM Slack yang tidak perlu anda serap.

SLA bukan tentang berkata tidak. Ia tentang menjadikan "sprint seterusnya" sebagai jawapan biasa bukannya pertelingkahan.

Bina satu model dbt

Model dbt adalah definisi hasil kanonik yang anda perjuangkan pada minggu ke-2. Hanya satu itu. Bukan lapisan metrik. Bukan pemfaktoran semula semantik. Satu model.

Namakannya fct_revenue_canonical atau apa sahaja konvensyen repositori anda. Tulis blok dokumentasi. Tambah ujian. Dapatkan semakan. Gabungkannya. Kemaskini papan pemuka minggu ke-5 anda untuk bersumber daripadanya.

Ini adalah saat "saya layak di sini." Kali pertama seseorang dalam mesyuarat berkata "tunggu, nombor hasil yang mana yang kita gunakan?" dan seorang rakan pasukan menjawab "yang kanonik, ia adalah model dbt yang [nama anda] hantar" - itulah saat anda berhenti menjadi Data Analyst baharu dan mula menjadi Data Analyst.

Jangan sekali-kali, dalam keadaan apa pun, cuba memfaktor semula semua gudang data pada bulan dua. Kuburan Data Analyst baharu dipenuhi dengan orang yang cuba "membina semula segala-galanya" pada minggu ke-6 dan merosakkan laporan board pada minggu ke-8. Hantar satu model. Teruskan.

Hari 61-90: Miliki satu metrik, kemukakan pelan

Bulan tiga adalah di mana anda berhenti diukur berdasarkan tiket yang ditutup dan mula diukur berdasarkan apa yang anda miliki.

Amalkan masa-untuk-mendapat-cerapan sebagai metrik anda

Pilih satu metrik peringkat pasukan dan miliki ia. Yang paling kukuh untuk Data Analyst adalah masa untuk mendapat cerapan: median jam dari "permintaan dihantar" kepada "jawapan data dihantar." Sesetengah pasukan menyebutnya masa-tindak-balas-pertama-kepada-soalan-data. Idea yang sama.

Ukurnya dari borang permohonan anda (anda sudah memilikinya sekarang). Tetapkan asas pada minggu ke-9. Tetapkan sasaran untuk minggu ke-12. Saya tetapkan: median 6 jam, sasaran di bawah 4.

Mengapa metrik ini dan bukan, katakanlah, "penggunaan papan pemuka" atau "pertanyaan dijalankan"? Kerana masa untuk mendapat cerapan adalah yang dirasai oleh pihak berkepentingan. Mereka tidak perasan apabila kadar penggunaan naik. Mereka perasan apabila soalan mereka dijawab sebelum makan tengah hari bukannya Selasa depan.

Laporkannya setiap minggu dalam standup pasukan anda. Tiga nombor: median, p90, kiraan. Itu sahaja.

Laporan 90 hari

Sekitar hari ke-85, tulis laporan satu halaman kepada pengurus anda. Empat bahagian, dalam urutan ini:

Disingkirkan. Bilangan papan pemuka yang diarkibkan, dengan senarai. Anggaran beban yang diselamatkan di gudang data jika anda boleh mengukurnya.

Dihantar. Satu papan pemuka. Satu model dbt. Borang permohonan dengan dua bulan data daya pemprosesan.

Rosak. Apa yang anda temui yang masih salah. Jadilah spesifik. "Model MRR-mengikut-segmen mengira dua kali penukaran percubaan di rantau EMEA. Mempengaruhi 4 papan pemuka. Pembaikan adalah projek 1 minggu." Jangan lembutkan. Pengurus anda mahukan senarai.

Seterusnya. Dua projek strategik, satu pelaburan platform, satu permintaan kakitangan jika berkaitan. Konkrit. Dengan anggaran jangka masa.

Satu halaman. Tidak lebih. Hantarnya sebagai dokumen, kemudian bincangkan dalam sesi 1:1 anda.

Pembentangan pelan H2

Laporan 90 hari adalah pemanasan. Pembentangan adalah apa yang datang seterusnya. Dalam sesi 1:1 yang sama, anda berkata: "Saya ingin memiliki pelan analitik H2. Ini bentuk kasarnya: dua projek strategik (X dan Y), satu pelaburan platform (lapisan metrik / ETL terbalik / rangka kerja eksperimen), dan satu keputusan kakitangan (adakah kita mengambil IC kedua atau senior untuk memimpin?). Saya akan ada dokumen penuh menjelang [tarikh]."

Ini adalah saat yang membezakan Data Analyst yang kekal IC selama lima tahun dari yang mengetuai pasukan dalam 18 bulan. Kebanyakan Data Analyst menunggu pengurus mereka merancang untuk mereka. Anda akan merancang untuk pengurus anda.

Anda akan mendapat tentangan. Pelan itu akan diedit. Dua projek anda akan dibunuh. Tidak mengapa. Pembentangan adalah tindakan, bukan artifak.

Perangkap (ini akan menggoda anda, jangan jatuh ke dalamnya)

Berkata ya kepada setiap ad hoc pada bulan 1. Saya katakan di bahagian awal, saya akan katakan lagi. Treadmill ad hoc adalah pintu sehala. Anda berkata ya pada minggu ke-1, anda masih berkata ya pada tahun ke-2.

Membina semula gudang data pada minggu ke-2. Anda belum memahami perniagaan lagi. Model yang "jelas rosak" adalah asas bagi seseorang yang belum anda temui. Audit dahulu.

Berdiam selama 60 hari, kemudian menjatuhkan audit 40 halaman. Tiada siapa meminta audit. Mereka meminta bukti bahawa anda wujud. Hantar senarai pembunuhan pada minggu ke-4. Terbitkan SLA pada minggu ke-6. Tunjukkan diri anda.

Menghantar papan pemuka dengan definisi hasil yang salah. Anda melangkau penyesuaian kewangan pada minggu ke-2. Kini papan pemuka anda bercanggah dengan board deck. Kepercayaan terbakar. Sukar untuk dibina semula. Jangan.

Templat yang akan anda benar-benar gunakan

Helaian kerja inventori papan pemuka. Enam lajur: nama, pemilik, dilihat terakhir (tarikh), disunting terakhir (tarikh), status (hidup/syak/mati), keputusan bunuh-atau-simpan. Satu baris bagi setiap papan pemuka. Susun mengikut dilihat-terakhir menaik, dan yang mati terapung ke atas.

Senarai soalan penyegerakan pihak berkepentingan. Lima soalan, dalam urutan: (1) Keputusan apa yang anda buat suku lepas yang anda harap anda mempunyai data yang lebih baik? (2) Nombor apa yang anda semak setiap pagi? (3) Papan pemuka apa yang sebenarnya anda gunakan, berbanding papan pemuka apa yang wujud untuk anda? (4) Soalan apa yang anda terus dapat dari bos anda yang tidak dapat anda jawab dengan cepat? (5) Jika saya boleh memberi anda satu pandangan baharu ke dalam perniagaan, apakah itu? Perhatikan tiada satu pun yang "apa yang anda perlukan daripada saya." Soalan itu mendapat anda senarai keinginan. Soalan-soalan ini mendapat anda kebenaran.

Borang permohonan ad hoc. Tiga ruang. Permintaan. Tarikh akhir. Keputusan yang ia memaklumkan. Itu sahaja.

Laporan 90 hari. Satu halaman. Disingkirkan. Dihantar. Rosak. Seterusnya. Poin, bukan perenggan.

Apa yang "berjaya" kelihatan pada hari ke-90

Menjelang hari ke-90, bilangan papan pemuka dalam alat BI anda adalah berkurang, bukan bertambah. Terdapat satu model dbt kanonik untuk metrik yang biasa diperdebatkan oleh syarikat anda. Pihak berkepentingan menggunakan borang permohonan bukannya menghantar DM kepada anda. Pengurus anda mempunyai pelan H2 bertulis daripada anda, bukan sebaliknya. Dan di suatu tempat pada televisyen syarikat, papan pemuka masih menunjukkan nombor yang sama pada hari Selasa seperti pada hari Jumaat.

Anda bukan Orang Pengeluaran Ad Hoc. Anda adalah Data Analyst.

Itulah pekerjaannya.

Ketahui Lebih Lanjut

• Deskripsi Kerja Data Analyst (JD yang dipasangkan dengan playbook ini)
• Sehari dalam Kehidupan Seorang Data Analyst
• SQL dan Pemodelan Data yang Boleh Dibesarkan
• Terjemahan Pihak Berkepentingan: Permintaan Samar kepada Analisis yang Boleh Dihantar
• Metrik Data Analyst: Masa-untuk-Mendapat-Cerapan, Penggunaan, Impak
• Perangkap Biasa Data Analyst