Belajar Technical Product Manager - Technical Estimation & Planning

#Pendahuluan

Setelah di episode 11 kita menyusun migration one-pager untuk settlement event-driven — lengkap dengan milestone M1-M5 dan rollback per fase — muncul pertanyaan pertama manajemen saat membacanya: "berapa lama?". Episode ini membahas cara menjawab pertanyaan itu secara jujur dan tetap profesional.

Estimasi adalah area di mana TPM paling sering kehilangan kredibilitas, bukan karena angkanya salah, tapi karena bentuk jawabannya salah: satu tanggal pasti untuk pekerjaan yang penuh ketidakpastian. Tujuan episode ini bukan membuat kalian pandai menebak, melainkan pandai mengelola ketidakpastian.

#Kenapa Estimasi Sulit Secara Fundamental

Dua alasan struktural yang wajib kalian internalisasi:

Cone of uncertainty: di awal proyek, rentang estimasi realistis bisa 4x lipat (dari 2 bulan sampai 8 bulan untuk pekerjaan sama). Rentang menyempit seiring discovery dan implementasi berjalan. Menuntut angka presisi di awal sama dengan meminta ramalan; yang bisa diminta adalah rentang plus rencana mengecilkannya.

Unknown unknowns: pekerjaan software jarang gagal karena hal yang diketahui sulit; ia meleset karena hal tak terduga — dependency vendor ternyata punya bug, data produksi punya bentuk aneh, regulasi berubah. Migrasi settlement NusaPay misalnya: risiko terbesarnya bukan menulis consumer baru, melainkan bentuk-bentuk aneh data historis ledger.

Implikasinya bagi TPM: tugas kalian bukan menghilangkan ketidakpastian (mustahil), tapi memperkecilnya lebih cepat (discovery, spike) dan mengomunikasikannya dengan benar (rentang, bukan titik).

#Teknik Estimasi Praktis

#T-Shirt Sizing

Ukuran XS/S/M/L/XL tanpa jam. Cocok untuk roadmap Now-Next-Later: cukup untuk urutan prioritas, belum untuk janji tanggal. Aturannya sederhana: kalau sebuah item diperkirakan XL, pecah sebelum dipercayakan — item XL hampir selalu menyembunyikan dua proyek.

#Three-Point Estimation

Untuk item penting, minta engineer memberi tiga angka:

Optimis   (semua mulus):        3 minggu
Realistis (normal):              5 minggu
Pesimis   (paritas bermasalah): 10 minggu
 
E = (O + 4R + P) / 6 = (3 + 20 + 10) / 6 = 5.5 minggu
Rentang lapor: 4-8 minggu (confidence ~80%)

Formula ini (PERT) menghasilkan ekspektasi tertimbang, tetapi nilai terbesarnya justru prosesnya: meminta kasus pesimis memaksa tim mengucapkan risiko yang selama ini disimpan diam-diam. Daftar pesimis itu sendiri adalah daftar mitigasi gratis.

#Story Points dan Velocity

Story points mengukur relatif kompleksitas (fibonacci: 1, 2, 3, 5, 8); velocity adalah jumlah point yang selesai per sprint secara historis. Kegunaannya: forecasting dari data, bukan harapan — "velocity 3 bulan terakhir rata-rata 32 point/sprint, backlog tersisa 128 point, maka ±4 sprint". Syaratnya data velocity yang stabil dan backlog yang sudah direfinement; gunakan hanya untuk horizon dekat.

#Sequencing: Dependency dan Critical Path

Estimasi total bukan penjumlahan semua task; ia ditentukan jalur terpanjang dependensi. Untuk migrasi settlement:

Jalur kritis: A → B/C → D ≈ 12 minggu; dashboard observability (jalur lain) tidak menambah total asal selesai sebelum routing naik. Implikasi manajerialnya kuat: engineer tambahan di jalur non-kritis tidak mempercepat migrasi; yang mempercepat adalah memecah dependency jalur kritis (misal mulai dual-write lebih awal dengan scope event terbatas).

Saat menyusun sequence, TPM berkontribusi pada dua hal: mendeteksi dependency lintas squad (ledger milik tim lain!) dan melindungi urutan dari permintaan "selipkan dulu ini doang".

#Milestone, Buffer, dan Confidence Band

Tiga aturan penyusunan timeline yang tahan realitas:

1. Milestone = momen verifikasi, bukan sekadar tanggal: tiap fase migrasi punya kriteria lolos (episode 11); tanggal mengikuti verifikasi, bukan sebaliknya.
2. Buffer eksplisit, tidak disembunyikan: tambahkan 20-30% sebagai baris "buffer integrasi & risiko" yang terlihat. Buffer tersembunyi akan dimakan unknown unknowns dan tetap terlihat seperti meleset.
3. Laporkan confidence band: "80% yakin rilis antara 4-8 minggu; untuk menyempitkan, spike paritas data selesai pekan depan." Band plus rencana mengecilkan band = jawaban dewasa atas pertanyaan "kapan?".

Bandingkan dengan jawaban rapuh "5 minggu, pak": begitu jadi 7 minggu, setiap laporan berikutnya didiskon oleh stakeholder.

#Praktik: Estimate Plan Migration Settlement

Susun estimate plan satu halaman: tabel fase M1-M5 dengan three-point per fase, hitung E per formula, identifikasi critical path dan satu ide pemecah dependency, lalu tulis pernyataan confidence band siap-lapor untuk manajemen. Simpan di 04-roadmap/estimate-plan.md.

#Anti-Pattern Estimasi

Empat kebiasaan yang meruntuhkan kredibilitas estimasi tim:

1. Estimasi ditegaskan oleh manajemen: "5 minggu terdengar lambat, 3 minggu saja" — angka yang dinego tanpa perubahan scope adalah kebohongan yang dijadwalkan.
2. Buffer disembunyikan di tiap task: tiap engineer menambah kusut sendiri-sendiri; hasilnya timeline bengkak tapi tidak ada buffer eksplisit yang bisa dipertanggungjawabkan atau dipangkas sadar.
3. Velocity dibandingkan antar tim: point adalah bahasa lokal tim; membandingkannya lintas squad sama dengan membandingkan dua mata uang berbeda.
4. Rencana tidak pernah dikoreksi: saat asumsi runtuh (dependency vendor molor), tanggal dipertahankan dan quality diam-diam dikorbankan. Koreksi terbuka lebih murah daripada kualitas yang hilang senyap.

#Penutup

Inti yang harus dibawa pulang:

• Cone of uncertainty dan unknown unknowns membuat estimasi titik tunggal tidak ilmiah — kelola dan komunikasikan ketidakpastian, jangan sembunyikan.
• T-shirt untuk roadmap, three-point (OPT-real-pesimis) untuk item besar, story points + velocity untuk forecast jangka dekat — jangan campur adukkan.
• Timeline ditentukan critical path; engineer tambahan di luar jalur kritis tidak mempercepat apa pun — pecah dependency-nya.
• Milestone berbasis verifikasi, buffer eksplisit sebagai baris terlihat, dan laporkan confidence band beserta rencana mengecilnya.

Di episode 13 selanjutnya kita bicara Reliability & SLO as Product — SLI/SLO/SLA, error budget dan kebijakannya, trade-off reliability vs velocity, dan bagaimana menjual investasi reliability ke bisnis lewat biaya downtime. Sampai jumpa!