Jika Anda pernah membayar untuk perangkat lunak, Anda sudah tahu polanya: vendor mengatakan tiga bulan, butuh enam bulan, dan tidak ada yang bisa menjelaskan ke mana perginya waktu tersebut. Sangat menggoda untuk menyalahkan tim. Biasanya bukan itu alasannya. Memahami mengapa perkiraan perangkat lunak pada dasarnya salah akan menyelamatkan Anda dari lebih banyak kesedihan daripada janji apa pun yang dapat dibuat oleh vendor.

Ini adalah versi jujur ​​dari seseorang yang membuat perangkat lunak dan mengutipnya. Perkiraan adalah distribusi probabilitas yang diperas menjadi satu angka untuk membuat pembeli merasa nyaman. Saat itu menjadi sebuah kencan di slide, kebenaran telah dibuang. Itu bukan ketidakjujuran, ini adalah fisika membangun sesuatu yang belum pernah dibangun sebelumnya.

Kabar baiknya adalah Anda bisa mengatasinya. Anda tidak bisa menghilangkan ketidakpastian, tapi Anda bisa menyusun hubungan agar tidak merugikan Anda. Biar saya jelaskan mekanismenya, lalu perbaikannya.

Perkiraan Adalah Distribusi, Bukan Tanggal

Ketika seorang insinyur berpengalaman melihat suatu fitur, mereka sebenarnya tidak berpikir "dua minggu". Mereka berpikir sesuatu yang mendekati "mungkin dua minggu, tapi bisa jadi satu minggu jika API-nya bersih, atau lima minggu jika integrasi pihak ketiga menghalangi kita." Itu adalah rentang dengan bentuk. Nomor tunggal yang Anda kutip adalah satu poin yang diambil dari rentang tersebut, biasanya angka optimis.

Sekarang susun itu di seluruh proyek. Sebuah build memiliki lusinan tugas, masing-masing dengan jangkauannya sendiri. Dan inilah pembunuhnya: ketidakpastian semakin bertambah. Jika masing-masing sepuluh tugas mempunyai peluang untuk berjalan lama, kemungkinan sepuluh tugas tersebut mencapai angka optimisnya adalah kecil. Total proyek melayang ke arah akhir yang pesimistis bahkan ketika tebakan masing-masing individu masuk akal.

Inilah sebabnya mengapa "menjumlahkan kasus terbaik untuk setiap tugas" menghasilkan tanggal yang hampir tidak pernah terjadi. Matematika menentangnya sebelum ada orang yang menulis sebaris kode.

Yang Tidak Diketahui Adalah Biaya Sebenarnya

Tugas-tugas yang dapat dilihat dengan jelas oleh sebuah tim jarang sekali mengganggu jadwal. Ini adalah hal-hal yang tidak diketahui oleh siapa pun untuk ditanyakan:

  • Data klien yang ada ternyata lebih berantakan daripada yang diakui siapa pun, dan pembersihannya memerlukan waktu tiga minggu. Hal ini sangat umum sehingga saya menulis keseluruhan panduan bertahan hidup migrasi data lama tentangnya.
  • Integrasi "sederhana" dengan gateway pembayaran atau sistem pemerintah memiliki keunikan tidak terdokumentasi yang hanya muncul dalam pengujian.
  • Persyaratan yang dianggap telah dipenuhi oleh semua orang ternyata memiliki arti yang berbeda bagi dua pemangku kepentingan, dan pengerjaan ulang pun dimulai.
  • Sesuatu yang bekerja dengan sempurna di demo rusak di bawah beban nyata atau pengguna nyata, pola yang saya bahas di [mengapa demo perangkat lunak rusak dalam produksi] (/blog/staging-environment-why-demos-break).

Tak satu pun dari ini terlihat pada waktu kutipan. Itu adalah sesuatu yang tidak diketahui dan tidak diketahui, dan Anda tidak dapat memperkirakan apa yang tidak dapat Anda lihat. Semakin baru suatu proyek, semakin besar pula massa tersembunyinya, dan itulah sebabnya mengapa perangkat lunak yang dipesan lebih banyak jumlahnya dibandingkan dengan penyiapan siap pakai.

Tekanan Mengubah Perkiraan Menjadi Fiksi

Ada lapisan manusia di atas matematika. Ketika pembeli berusaha keras untuk berkencan, atau penjual ingin memenangkan kesepakatan, perkiraannya akan berkurang. Bukan dengan maksud jahat, hanya dengan optimisme. Tim merasakan tekanan dan mengutip angka yang menutup penjualan, bukan angka yang mereka yakini.

Hasilnya adalah sebuah fiksi yang semua orang setuju untuk menganggapnya nyata. Kemudian kenyataan datang sesuai jadwal, garis waktu meleset, dan kepercayaan terkikis di kedua sisi. Tragisnya adalah perkiraan yang jujur ​​dan lebih luas selama ini biasanya benar. Namun hal itu tidak bertahan dalam negosiasi.Jadi ketika Anda mendesak vendor untuk mendapatkan tanggal yang lebih ketat, pahamilah apa yang sebenarnya Anda beli: kebohongan yang lebih meyakinkan, bukan proyek yang lebih cepat.

Apa yang Sebenarnya Membantu

Anda tidak dapat membuat perkiraan secara pasti, namun Anda dapat membangun hubungan kerja yang menghormati ketidakpastian. Tiga gerakan mengubah segalanya:

  1. Mintalah kisarannya, bukan tanggalnya. Vendor yang serius akan memberi tahu Anda "empat hingga tujuh bulan" dan menjelaskan apa yang mendorongnya mencapai tujuan tersebut. Jika seseorang memberi Anda tanggal pasti untuk pembangunan yang rumit, perlakukan itu sebagai tanda peringatan, bukan kepastian.
  2. Mintalah irama pos pemeriksaan yang singkat. Setiap dua minggu, Anda akan melihat perangkat lunak yang berfungsi, bukan laporan status. Ritme berlari selama dua minggu mengubah enam bulan yang tidak diketahui dan menakutkan menjadi dua belas langkah kecil yang dapat diamati. Anda akan mengetahui sejak dini jika segala sesuatunya mengalami penurunan, sementara Anda masih dapat menyesuaikan ruang lingkup atau anggaran.
  3. Perhatikan perkiraan vendor, karena ini merupakan sinyal perekrutan. Cara vendor berbicara tentang ketidakpastian memberi tahu Anda lebih dari sekedar portofolio mereka. Apakah mereka menyebutkan asumsi mereka? Apakah mereka menandai adanya integrasi yang berisiko di awal? Apakah mereka menunda kencan Anda padahal itu tidak realistis? Vendor yang memperkirakan dengan jujur ​​di bawah tekanan adalah vendor yang Anda inginkan, justru karena mereka akan memberi tahu Anda kebenaran yang sebenarnya nanti ketika hal itu penting.

Poin ketiga itu adalah pelajaran yang tenang. Perkiraan itu sendiri hampir tidak ada gunanya sebagai prediksi. Namun perbincangan seputar hal itu adalah salah satu ujian terbaik apakah tim ini akan terus terang bersama Anda selama enam bulan ke depan.

Yang Dapat Dibawa Pulang

Perkiraan perangkat lunak salah karena mereka memampatkan serangkaian hal yang tidak diketahui menjadi satu tanggal, dan kemudian tekanan manusia membuat tanggal tersebut semakin berkurang. Melawan hal ini dengan tenggat waktu yang lebih ketat hanya akan memberi Anda fiksi yang lebih indah.

Bekerjalah dengan ketidakpastian. Tanyakan rentang waktu, mintalah perangkat lunak yang berfungsi selama dua minggu, dan nilailah vendor berdasarkan seberapa jujurnya mereka menangani hal-hal yang tidak diketahui, bukan seberapa percaya diri teman kencan mereka. Jika Anda menginginkan mitra teknis yang mengutip kisaran sebenarnya dan menunjukkan kemajuan Anda setiap dua minggu, itulah cara saya menjalankan keterlibatan sebagai mitra.