- Estimasi durasi proyek perangkat lunak secara akurat itu mustahil, dan sebagian besar pekerjaan didominasi oleh ‘hal-hal yang tidak diketahui’ yang tak dapat diprediksi
- Estimasi digunakan sebagai alat politik manajemen, bukan alat bagi engineer, untuk menentukan prioritas proyek dan alokasi pendanaan
- Dalam praktiknya, estimasilah yang mendefinisikan pekerjaan, dan tim bekerja dengan mencari pendekatan teknis yang memungkinkan dalam jangka waktu yang diberikan
- Untuk membuat estimasi yang efektif, engineer perlu fokus pada memahami konteks politik, menilai risiko dari hal-hal yang belum diketahui, dan menyajikan beberapa skenario eksekusi
- Pendekatan ini menekankan kepercayaan dan kolaborasi yang realistis, bukan akurasi, serta kemampuan engineering untuk memahami struktur pengambilan keputusan di dalam organisasi
Fiksi tentang estimasi perangkat lunak
- Di industri ada ‘fiksi yang sopan’ bahwa tim yang terampil bisa memprediksi jadwal secara akurat dengan usaha yang cukup
- Kenyataannya, sebagian besar engineer menyadari bahwa prediksi akurat itu mustahil
- Beberapa tim memakai metode ukuran kaus, tetapi pada akhirnya tetap dikonversi ke satuan waktu dan disampaikan ke lapisan manajemen
- Heuristik yang tidak realistis seperti “kalikan dua estimasi awal lalu tambahkan 20%” juga kadang digunakan
Mengapa estimasi itu mustahil
- Pekerjaan kecil dan jelas bisa diprediksi, tetapi sebagian besar proyek dikerjakan dalam sistem yang tidak pasti dan kompleks
- Contoh: mengubah teks tautan sederhana mungkin bisa diperkirakan 45 menit, tetapi perubahan sistem berskala besar tidak bisa
- Sebagian besar pemrograman adalah aktivitas riset yang eksploratif, sehingga pekerjaan yang dibutuhkan tidak bisa diketahui hanya lewat perencanaan awal
- Pendekatan desain arsitektur terpusat di masa lalu telah gagal, dan keputusan harus dibuat oleh developer yang menangani kode nyata
- Akibatnya, pekerjaan yang diketahui hanya sekitar 10% dari keseluruhan, sementara 90% sisanya tak bisa diestimasi karena berada di wilayah yang belum diketahui
Estimasi adalah alat manajemen, bukan alat engineer
- Estimasi tidak berkaitan dengan peningkatan produktivitas tim, dan banyak tim yang efisien bekerja tanpa estimasi
- Manajemen cenderung menyesuaikan estimasi agar cocok dengan hasil yang mereka inginkan; jadwal panjang ditekan untuk dipersingkat, jadwal pendek diminta menambah buffer
- Hanya proyek yang secara teknis mustahil yang sesekali bisa memunculkan penilaian yang realistis
- Di area yang kurang mendapat perhatian dalam organisasi, prosedur formal kadang tetap dipertahankan begitu saja
- Karena itu, estimasi berfungsi sebagai sarana politik bagi non-engineer untuk memilih atau membatalkan proyek
Estimasi mendefinisikan pekerjaan
- Berlawanan dengan anggapan umum, bukan pekerjaan yang ditentukan lebih dulu, melainkan estimasinya, lalu pendekatan teknis ditetapkan agar sesuai
- Contoh: pendekatan untuk membuat fitur “berdialog dengan PDF” dalam 6 bulan dan dalam 1 hari akan sepenuhnya berbeda
- Batas waktu menentukan kedalaman dan kualitas desain kode, dan engineer memilih solusi yang mungkin dalam jangka waktu yang diberikan
Cara melakukan estimasi dalam praktik
- Pertama, pahami konteks politiknya untuk mengetahui pentingnya proyek dan ekspektasi jadwalnya
- Setelah itu, telusuri pendekatan yang mungkin berdasarkan jangka waktu yang pada dasarnya sudah ditentukan
- Semakin banyak hal yang belum diketahui (unknowns), semakin besar estimasinya, dan semakin sempit cakupan pendekatan yang perlu diambil
- Pada akhirnya, yang disajikan bukan durasi yang presisi, melainkan evaluasi risiko dan beberapa skenario eksekusi
- Contoh: menyelesaikan semua elemen sendiri, mengakali sebagian, atau meminta dukungan tim lain
- Peran engineer bukan menjawab “berapa lama ini akan memakan waktu”, melainkan “metode apa yang mungkin dilakukan dalam waktu yang diberikan”
Keberatan dan tanggapan
- Sebagian engineer menghindari estimasi dalam kondisi yang tidak pasti, tetapi itu justru membuat orang nonteknis yang akan mengestimasi sebagai gantinya
- Tidak mau bekerja sama dengan manajemen dan selalu bersikap konfrontatif adalah hal yang tidak produktif serta melemahkan kepercayaan
- Tim yang tidak merasa tertekan mungkin hanya berada di area yang di luar perhatian organisasi
Kesimpulan
- Dalam praktiknya, manajer datang ke tim dengan jangka waktu yang sudah mereka bayangkan, lalu tim mencari solusi teknis yang memungkinkan di dalamnya
- Estimasi adalah alat negosiasi antarmanajemen, dan hanya proyek yang mustahil yang sesekali dapat menjadi sarana untuk menyampaikan realitas
- Estimasi yang benar seharusnya tidak berisi angka yang akurat, melainkan penyajian risiko dan pilihan yang tersedia
- Estimasi pekerjaan perangkat lunak secara akurat itu mustahil, dan estimasi yang berhasil bergantung pada kemampuan mengenali serta mengelola risiko dari hal-hal yang belum diketahui
2 komentar
> Pertama, pahami konteks politis untuk memahami tingkat kepentingan proyek dan jadwal yang diharapkan
> Setelah itu, telusuri pendekatan yang memungkinkan berdasarkan jangka waktu yang sudah ditetapkan
Oho
Komentar Hacker News
Membagikan patokan estimasi proyek saya yang setengah bercanda
Untuk proyek internal (mis. migrasi vendor, dll. tanpa dampak ke pengguna), saya menetapkan durasi selama itu masih bisa dijustifikasi ke atasan
Untuk proyek yang berdampak ke pengguna (mis. penambahan fitur baru), proyek dikerjakan selama ROI tetap positif
Untuk proyek yang membutuhkan kolaborasi dengan mitra eksternal, tim sales menentukan tenggat, dan tim engineering sedikit menyesuaikan definisi MVP agar cocok dengan jadwal itu
Saya heran kenapa tidak ada yang membahas planning poker atau story point
Memang tidak sempurna, tapi ini metode yang cukup bagus. Semua pekerjaan harus selesai dalam sprint, dan kalau terlalu besar harus dipecah
Seluruh anggota tim harus menyepakati poinnya, dan dalam proses itu muncul nilai dari diskusi yang sebenarnya
Setelah beberapa bulan, kecepatan tim menjadi stabil sehingga bisa diprediksi dengan akurasi sekitar ±10%
Ini bukan sihir, tapi membantu terus memberikan nilai dan meninjau ulang manfaat dibanding biaya di setiap sprint
Orang yang baru bergabung bisa membutuhkan waktu lebih dari 2x lebih lama untuk tiket yang sama
Selain itu, organisasi membuat aturan seperti review PR harus selesai dalam 24 jam, jadi ada jarak dengan kenyataan
Developer dan QA bersama-sama membandingkan kompleksitas saat mengestimasi, dan QA menilai tingkat kesulitan pengujian atau kemungkinan otomatisasi
Karena itu, metrik kecepatan pengembangan stabil dan estimasi per versi juga cukup akurat
Itu hanya bermakna kalau seluruh tim punya pemahaman bersama tentang unit terkecil, dan bisa mengonversinya ke waktu
Pada akhirnya, kalau sudah begitu lebih baik langsung memakai waktu, jadi poinnya sendiri tidak perlu
Saya melakukan estimasi berbasis confidence interval dengan bertanya dalam satuan “2 jam, 2 hari, 2 minggu, 2 bulan, 2 tahun”
Kalau rentangnya terlalu lebar, saya pecah lagi, dan kalau tidak memungkinkan saya menilai apakah layak menghabiskan waktu untuk mengumpulkan informasi
Kalau tidak, proyeknya dibatalkan
Jika hasilnya didefinisikan dengan jelas dan idenya dipecah menjadi langkah-langkah rinci, estimasi realistis jadi memungkinkan
Jika belum bisa dipecah ke tingkat harian atau mingguan, berarti perencanaannya masih kurang matang
Dalam kasus seperti ini, kita terus mencoba pendekatan berbeda sambil belajar, jadi menurut saya sulit untuk diestimasi
Itu membuat kita berpikir dengan fokus pada tindakan, bukan sekadar memperkirakan panjang durasi
Dulu saya mengira migrasi sederhana password dari plaintext ke hash bisa selesai dalam satu sprint, tapi kenyataannya butuh 6 bulan
Saya baru tahu karena pelanggan menunjukkan lewat video bahwa mereka memakai password tanpa membedakan huruf besar dan kecil
Ditambah lagi image PHP dihapus sehingga terjadi build failure
Estimasi memang selalu jadi petualangan yang menyenangkan
Buku itu menunjukkan statistik pembengkakan anggaran berdasarkan data proyek nyata
Proyek IT rata-rata meleset 73%, terburuk setelah penyimpanan limbah nuklir, Olimpiade, dan pembangkit listrik tenaga air
Sebanyak 18% proyek IT meleset lebih dari 50%, dan rata-rata pembengkakan pada kelompok itu mencapai 447%
Pada akhirnya ini menunjukkan bahwa di sebagian besar industri, estimasi secara struktural cenderung terlalu optimistis
Menarik bahwa banyak engineer dan manajer tidak melakukan estimasi berdasarkan metrik proyek-proyek sebelumnya
Kalau melihat data throughput tim, kita bisa menghitung perkiraan durasi dan confidence interval (mis. 90%, 70%, 50%)
Dengan begitu, kita juga bisa memberi konteks probabilistik kepada para pemangku kepentingan eksternal
Tapi banyak engineer menganggap ini sebagai beban administratif
Praktik yang baik adalah memakai estimasi rentang, dengan memodelkan tiga kemungkinan seperti pada metode PERT: terbaik, perkiraan, dan terburuk
Semakin hebat teknisinya, semakin cenderung mereka terlalu percaya diri pada estimasi waktunya sendiri
Cara setiap orang membuat estimasi lalu menambahkan koreksi 20% ternyata cukup cocok
Jika manajemen memaksakan jadwal, kita harus menjelaskan ruang lingkup yang mungkin dalam waktu itu atau menyarankan estimasi ulang setelah scope diperjelas
Referensi: PMI PMP, Lessons Learned Repository di PMBOK
Prediction belajar dari kesalahan, sedangkan prescription justru berujung pada tekanan produktivitas
Saya melihat estimasi sebagai proses negosiasi
Seperti trim mobil, saya menawarkan tiga opsi: Economy, Mid-tier, Luxury
Bisnis selalu menginginkan fungsionalitas nomor 3 dengan anggaran nomor 1, jadi pada akhirnya saya menyesuaikan sesuai situasi
Dengan menyiapkan rencana #1, kita bisa cepat beralih saat krisis dan memvisualisasikan harga dari jalan pintas selama negosiasi
Karena itu, saya beberapa kali bisa menghindari keputusan tidak rasional dari PM atau eksekutif yang sedang panik
Saya menangani sistem terdistribusi skala besar kelas FAANG, dan di sini estimasi akurat hampir mustahil
Terlalu banyak unknown-unknowns, dan bahkan untuk prototipe saja dibutuhkan data dan waktu yang sangat besar
Karena itu, fokusnya bukan pada estimasi melainkan pengelolaan ketidakpastian
Metode yang paling bisa diandalkan adalah membandingkan dengan proyek serupa
Seperti, “ini 20% lebih kompleks daripada proyek X, jadi akan memakan waktu 20% lebih lama”
Namun, untuk itu kita harus terus mencatat data durasi aktual dari proyek-proyek sebelumnya
Awalnya saya ingin menentang klaim bahwa “estimasi itu mustahil”, tapi akhirnya saya sadar bahwa peran dalam organisasi justru lebih penting
Bahkan jika tim menilai kapasitasnya tidak cukup dibanding estimasi, jadwal tetap tidak berubah
Pada akhirnya semuanya disesuaikan lewat pengurangan scope atau kompromi kualitas
Jadi mungkin lebih tepat mengatakan bahwa “estimasi itu tidak berguna”
Saya merasa inti dari estimasi adalah ambiguitas
Ada banyak pekerjaan yang tampak kecil seperti penyesuaian UI, tapi sebenarnya baru dipahami sambil dikerjakan
Sebaliknya, perubahan besar pun bisa cepat selesai jika definisinya jelas
Di era LLM, bukan besarnya perubahan melainkan tingkat ketidakpastian yang akan menentukan waktu pengerjaan