Setiap pemilik berasumsi bahwa proyek perangkat lunak mereka terlambat karena pengembangnya lambat, atau perkiraannya salah, atau teknologinya lebih sulit dari yang diharapkan. Setelah duduk di kedua sisi ini, sebagai vendor yang melakukan pengiriman dan sebagai mitra teknis yang meninjau jadwal vendor lain, saya dapat mengatakan dengan jelas: mengapa proyek perangkat lunak terlambat hampir tidak pernah bergantung pada kecepatan mengetik. Hal ini tergantung pada keputusan, ruang lingkup, dan data, dalam urutan itu.
Saya telah menyaksikan proyek enam minggu yang diperpanjang hingga lima bulan tanpa satu baris pun kode "keras" yang menjadi penyebabnya. Penundaan sepenuhnya terjadi di bagian hulu dan hilir dari pengkodean itu sendiri. Jika Anda seorang pemilik yang mencoba mencari tahu ke mana arah proyek Anda, lihatlah tiga area ini sebelum Anda menyalahkan para insinyur.
Latensi keputusan adalah sumber penundaan terbesar
Setiap proyek perangkat lunak memiliki poin keputusan: menyetujui desain ini, memilih antara opsi A dan B, mengonfirmasi aturan bisnis ini, menandatangani UI ini. Masing-masing adalah jeda kecil. Gabungkan dua puluh di antaranya dengan waktu respons 3-5 hari, bukan di hari yang sama, dan Anda telah menambahkan bulan, bukan hari.
Saya telah melihat sebuah proyek di mana satu persetujuan pada aturan perhitungan diskon tidak terjawab selama tiga minggu karena pengambil keputusan sedang bepergian dan belum mendelegasikannya. Benar sekali, tim pengembangan tidak membangun sebelum aturan bisnis yang belum dikonfirmasi, karena membangun logika yang salah memerlukan biaya yang lebih besar untuk bersantai daripada menunggu. Satu celah tersebut menghabiskan lebih banyak waktu kalender dibandingkan seluruh modul autentikasi.
Artinya secara praktis:
- Nominasikan satu pengambil keputusan per proyek, dengan nama cadangan jika mereka tidak dapat dijangkau.
- Tetapkan SLA internal untuk pengambilan keputusan (24-48 jam) dan perlakukan dengan keseriusan yang sama seperti tenggat waktu pembayaran.
- Jika Anda tidak dapat mengambil keputusan dengan cepat, beri tahu vendor "lanjutkan rekomendasi Anda" daripada membiarkannya terbuka. Keputusan yang salah namun dapat diubah yang diambil saat ini mengalahkan keputusan tepat yang diambil dalam tiga minggu.
Cakupan tumbuh secara perlahan, tidak secara dramatis
Tidak ada seorang pun yang duduk dalam rapat dan berkata "mari kita gandakan cakupannya". Ini terjadi satu permintaan kecil dalam satu waktu: "bisakah kami juga menambahkan filter di sini", "sebenarnya kami memerlukan ini untuk mendukung banyak cabang", "oh, dan kami lupa tim keuangan memerlukan ekspor." Setiap penambahan terdengar sepele jika dilakukan sendiri-sendiri. Tak satu pun dari mereka yang melalui permintaan perubahan formal, jadi tidak ada yang melacak efek kumulatifnya.
Pada saat proyek berjalan selama tiga bulan, biasanya ditemukan bahwa rangkaian fitur yang dikirimkan 40-60% lebih besar dari cakupan awalnya, tanpa ada penyesuaian terhadap jadwal atau anggaran yang dibahas. Inilah jebakan yang tercakup dalam [Negosiasi Kontrak Perangkat Lunak: Apa yang Vendor Harap Anda Lewatkan] (/blog/negotiating-software-contracts-guide): disiplin cakupan harus berupa mekanisme kontrak, bukan perjanjian niat baik, atau akan secara diam-diam mengikis garis waktu dan hubungan vendor.
Solusi praktisnya bukanlah "katakan tidak pada segalanya". Itu:
- Catat setiap penambahan, meskipun kecil, terhadap dokumen cakupan asli.
- Tanyakan “apakah ini menggantikan sesuatu yang telah kita sepakati, atau malah menambahnya?” sebelum menyetujui.
- Jika bertambah, cantumkan nomornya (hari, rupiah, atau kedua-duanya) sebelum tim mulai membangunnya, bukan sesudahnya.
Integrasi dan kejutan dataSumber penundaan besar ketiga adalah sumber yang jarang diantisipasi oleh pemilik: data nyata dan sistem pihak ketiga nyata yang harus dihubungkan dengan perangkat lunak. Perkiraan dibuat berdasarkan asumsi tentang seperti apa database yang ada, apa yang sebenarnya dapat dilakukan oleh API sistem akuntansi, atau seberapa bersih data master pelanggan. Kenyataan sering kali tidak sejalan.
Sebuah perusahaan multifinance tempat saya bekerja berasumsi bahwa data cabang mereka konsisten di 30 lokasi. Ternyata tidak. Kode cabang dimasukkan secara manual selama bertahun-tahun dengan kesalahan ketik, duplikat, dan tiga konvensi penamaan berbeda untuk kota yang sama. Pekerjaan integrasi mengasumsikan data bersih; dua minggu terbuang hanya untuk rekonsiliasi data yang belum tercakup oleh siapa pun karena tidak ada yang benar-benar melihatnya.
Inilah sebabnya mengapa akses awal terhadap data produksi riil (bahkan ekspor yang sudah disanitasi) perlu dilakukan sebelum pengembangan dimulai, bukan setelahnya. Terkait dengan ini: lihat Integrasi API: Membuat Alat Bisnis Anda Berbicara untuk mengetahui apa yang sebenarnya rusak ketika sistem yang tidak pernah dirancang untuk berbicara satu sama lain tiba-tiba harus melakukannya.
Apa yang sebenarnya dikontrol oleh pemilik
Pemilik sering kali merasa tidak berdaya saat proyek terlambat, seolah-olah perbaikan sepenuhnya ada di pihak vendor. Tidak. Tiga tuas berada tepat di samping klien:
| Tuas | Pekerjaan pemilik | Efek pada garis waktu |
|---|---|---|
| Kecepatan pengambilan keputusan | Nominasikan satu pengambil keputusan, terapkan SLA tanggapan | Menghilangkan kesenjangan multi-minggu yang senyap |
| Stabilitas ruang lingkup | Catat setiap penambahan terhadap cakupan asli, beri harga secara eksplisit | Mencegah 40%+ cakupan creep tidak terlacak |
| Kesiapan data | Menyediakan data nyata (disanitasi) dan akses sistem sejak dini | Munculkan kejutan integrasi sebelum, bukan selama, build |
Semua ini tidak memerlukan pengetahuan teknis. Hal ini memerlukan disiplin organisasi, yang biasanya merupakan kesenjangan aktual, bukan kemampuan rekayasa.
Kesimpulan praktis
Jika nanti suatu proyek terlambat, tahan refleks untuk mengaudit basis kode terlebih dahulu. Audit log keputusan, dokumen cakupan, dan asumsi data. Jika Anda menginginkan pendapat kedua tentang apakah penundaan merupakan masalah vendor atau masalah proses sebelum Anda melakukan eskalasi atau melakukan negosiasi ulang, tinjauan kesenjangan seperti itulah yang layak dilakukan kepada mitra daripada menebak-nebak secara internal.