Menyusun Rencana Analisis

Rumusan masalah, metrik keberhasilan, dan data yang sudah dipahami kini menumpuk sebagai catatan — dan catatan belum bisa dikerjakan. Yang mengubahnya menjadi pekerjaan adalah rencana: urutan tahap yang menyebut apa yang akan diuji, bukti seperti apa yang dipakai, dan keputusan apa yang mengikuti setiap hasil. Rencana yang baik menjawab dua pertanyaan sekaligus: untuk diri sendiri, supaya setiap pagi tahu langkah berikutnya tanpa menebak; untuk tim dan stakeholder, supaya mereka tahu kapan hasil datang dan bentuknya apa. Pada chapter ini kita menyusun rencana bertahap dengan pola hipotesis → bukti → keputusan, lalu melihat bagaimana rencana bisa dimulai dari versi paling kecil yang sudah berguna.

Pola Tiga Lapis: Hipotesis, Bukti, Keputusan #

Setiap tahap rencana dinyatakan dalam tiga lapis. Hipotesis adalah pernyataan yang bisa salah — “retensi 30 hari pelanggan kita di bawah 50%”, “kunjungan menurun dua bulan sebelum pelanggan pergi”. Bukti adalah data atau pengujian yang memutuskan hipotesis itu — kohort yang dihitung, perbandingan dua periode, data uji terpisah. Keputusan adalah tindakan yang mengikuti dua kemungkinan hasil: hipotesis terbukti, atau hipotesis ditolak buktinya.

Mengapa harus lewat hipotesis, bukan sekadar daftar pekerjaan? Karena hipotesis memaksa kita menyebut dugaan secara terbuka. Dugaan yang tertulis bisa salah secara jujur — bukti menolaknya, tahap dihentikan, proyek belajar — dan kegagalan semacam itu adalah kemajuan. Sebaliknya, daftar pekerjaan tanpa hipotesis hanya bisa “selesai” atau “belum selesai”; tidak ada tempat bagi hasil yang menyatakan “arahnya keliru sejak awal”. Pemetaan pertanyaan analitik pada chapter Merumuskan Pertanyaan Analisis menjadi bahan baku langsung bagi lapis hipotesis ini.

Rencana Proyek Churn Toko Kopi Kita #

Kita terapkan polanya pada proyek retensi pelanggan Toko Kopi Kita. Empat tahap berikut disusun agar setiap tahap hanya berjalan bila tahap sebelumnya membenarkannya — proyek bisa berhenti di titik mana pun dengan keputusan yang sudah disiapkan, bukan berhenti karena kehabisan semangat.

rencana = [
    {
        "tahap": "Ukur retensi saat ini",
        "hipotesis": "retensi 30 hari pelanggan aktif Desember di bawah 50%",
        "bukti": "kohort pelanggan aktif Desember 2025, diikuti sampai akhir Januari 2026",
        "jika_terbukti": "lanjut ke tahap pencarian pola",
        "jika_gagal": "hentikan proyek: retensi sudah sehat",
    },
    {
        "tahap": "Cari pola pelanggan yang pergi",
        "hipotesis": "frekuensi kunjungan menurun dua bulan sebelum pelanggan pergi",
        "bukti": "bandingkan frekuensi 60 hari terakhir pelanggan yang pergi vs yang bertahan",
        "jika_terbukti": "jadikan penurunan frekuensi fitur utama",
        "jika_gagal": "periksa data lain: keluhan, menu favorit, metode bayar",
    },
    {
        "tahap": "Uji model prediksi sederhana",
        "hipotesis": "regresi logistik mengungguli aturan sederhana frekuensi rendah",
        "bukti": "bandingkan recall keduanya pada data uji yang dipisahkan sejak awal",
        "jika_terbukti": "pakai model untuk menyusun daftar prioritas",
        "jika_gagal": "pakai aturan sederhana; kecanggihan tidak dibayar kebingungan",
    },
    {
        "tahap": "Uji dampak intervensi",
        "hipotesis": "penawaran personal menahan minimal 25% pelanggan berisiko",
        "bukti": "uji terbatas pada 30 pelanggan selama dua pekan, dibanding kelompok tanpa penawaran",
        "jika_terbukti": "naikkan skala bertahap dengan pemantauan biaya",
        "jika_gagal": "hentikan program; selamatkan anggaran untuk masalah lain",
    },
]

for nomor, r in enumerate(rencana, start=1):
    print(f"Tahap {nomor}: {r['tahap']}")
    print(f"  hipotesis     : {r['hipotesis']}")
    print(f"  bukti         : {r['bukti']}")
    print(f"  jika terbukti : {r['jika_terbukti']}")
    print(f"  jika gagal    : {r['jika_gagal']}")

Output yang Dihasilkan:

Tahap 1: Ukur retensi saat ini
  hipotesis     : retensi 30 hari pelanggan aktif Desember di bawah 50%
  bukti         : kohort pelanggan aktif Desember 2025, diikuti sampai akhir Januari 2026
  jika terbukti : lanjut ke tahap pencarian pola
  jika gagal    : hentikan proyek: retensi sudah sehat
Tahap 2: Cari pola pelanggan yang pergi
  hipotesis     : frekuensi kunjungan menurun dua bulan sebelum pelanggan pergi
  bukti         : bandingkan frekuensi 60 hari terakhir pelanggan yang pergi vs yang bertahan
  jika terbukti : jadikan penurunan frekuensi fitur utama
  jika gagal    : periksa data lain: keluhan, menu favorit, metode bayar
Tahap 3: Uji model prediksi sederhana
  hipotesis     : regresi logistik mengungguli aturan sederhana frekuensi rendah
  bukti         : bandingkan recall keduanya pada data uji yang dipisahkan sejak awal
  jika terbukti : pakai model untuk menyusun daftar prioritas
  jika gagal    : pakai aturan sederhana; kecanggihan tidak dibayar kebingungan
Tahap 4: Uji dampak intervensi
  hipotesis     : penawaran personal menahan minimal 25% pelanggan berisiko
  bukti         : uji terbatas pada 30 pelanggan selama dua pekan, dibanding kelompok tanpa penawaran
  jika terbukti : naikkan skala bertahap dengan pemantauan biaya
  jika gagal    : hentikan program; selamatkan anggaran untuk masalah lain

Mari kita baca susunan rencana tersebut:

1. Setiap tahap punya dua pintu keluar — jika_terbukti dan jika_gagal keduanya tertulis sebelum pekerjaan dimulai. Inilah yang membuat rencana tahan banting: bila bukti menolak hipotesis tahap satu karena retensi ternyata 68%, proyek berhenti dengan keputusan yang sudah disepakati, bukan dengan perdebatan.
2. Bukti disebut operasional — “bandingkan recall pada data uji yang dipisahkan sejak awal”, bukan sekadar “uji modelnya”. Cara mengukur ditetapkan sebelum hasil terlihat, menutup pintu mengukur ulang dengan cara yang menguntungkan dugaan sendiri.
3. Tahap disusun dari murah ke mahal: menghitung kohort adalah pekerjaan sehari; melatih model beberapa hari; uji intervensi memakan anggaran dua pekan. Rencana yang memulai dari tahap termahal membakar sumber daya sebelum tahu masalahnya sungguh ada.
4. Empat tahap ini juga jadwal komunikasi: stakeholder tahu hasil tahap pertama datang dalam seminggu berbentuk satu angka retensi, dan keputusan lanjut atau berhenti menyertainya. Ekspektasi semacam ini yang mencegah proyek dituduh diam padahal sedang bekerja.

Mulai dari MVP Analitik #

Seperti produk perangkat lunak, analisis punya versi paling kecil yang sudah menghasilkan keputusan — sebut saja MVP analitik. Untuk proyek retensi ini, MVP-nya bukan model: cukup satu angka retensi 30 hari plus daftar pelanggan yang sudah 45 hari tidak muncul. Kasir bisa mulai menghubungi nama-nama di daftar itu minggu ini juga, sementara tahap model baru menyusul. Nilai keputusan datang lebih awal, dan umpan balik lapangan memperkaya tahap berikutnya.

MVP bukan versi malas — MVP adalah cara membeli informasi termurah lebih dulu. Angka retensi dari MVP bahkan bisa langsung menggugurkan tahap-tahap berikutnya bila ternyata sehat; itulah penghematan terbesar yang bisa diberikan sebuah rencana.

Rencana yang Hidup #

Rencana yang baik berubah, dan itu bukan kekalahan. Bukti tahap dua mungkin menunjukkan pola yang menuntut data baru; hasil uji intervensi mungkin memaksa ambang 25% ditinjau ulang bersama stakeholder. Yang penting adalah perubahannya tercatat: versi rencana mana berlaku kapan, dan apa alasan perubahannya. Kebiasaan mencatat versi ini akan kita rawat terus di chapter Eksperimen dan Pencatatan dan Version Control untuk Data — keduanya tumbuh langsung dari kebutuhan ini.

Rangkuman #

• Rencana analisis menyusun setiap tahap dalam tiga lapis: hipotesis yang bisa salah, bukti yang memutuskan, dan keputusan untuk kedua kemungkinan hasil.
• Hipotesis tertulis membuat proyek bisa gagal secara jujur dan belajar; daftar pekerjaan biasa tidak punya tempat bagi hasil yang membalik arah.
• Tahap disusun dari murah ke mahal, sehingga proyek bisa berhenti dini dengan keputusan yang sudah disepakati sejak awal.
• MVP analitik — versi terkecil yang sudah menghasilkan keputusan — membeli informasi termurah lebih dulu dan menghadirkan umpan balik lapangan lebih awal.
• Rencana berubah seiring bukti; yang wajib adalah perubahan tercatat, bukan rencana yang beku.

Rencana tertulis kini memuat tahap-tahap yang berulang: menghitung, membersihkan, membentuk fitur, mengevaluasi. Begitu langkah-langkah itu mulai diulang dari pekan ke pekan, menyalin-tempel kode menjadi jebakan — satu perubahan kecil harus disalin ke banyak tempat, dan tempat yang terlewat merusak hasil diam-diam. Saatnya merangkai langkah-langkah itu menjadi pipeline: pembahasan chapter berikutnya, Membangun Pipeline Pemrosesan .