Setiap pemilik bisnis yang pernah memesan pembuatan software custom punya cerita yang dimulai dengan tenang dan berakhir buruk. Kegagalan proyek software biasanya dianggap sebagai nasib sial, vendor yang kebetulan tidak jujur, atau tim yang kebetulan lambat. Setelah lima belas tahun membangun dan menyelamatkan sistem, saya menemukan hal sebaliknya: hampir semua kisah horor bermula dari satu keputusan spesifik yang bisa dicegah, dibuat di awal, dan diabaikan sampai terlambat untuk diperbaiki dengan murah.
Berikut tiga kasus dari lapangan (identitas disamarkan), masing-masing dengan satu kebiasaan yang seharusnya bisa mencegahnya.
Vendor yang menghilang bersama source code
Sebuah perusahaan trading (nama dirahasiakan, detail diubah untuk menjaga kerahasiaan) menyewa sebuah rumah pengembangan kecil untuk membangun sistem manajemen inventori dan pesanan mereka. Pengerjaan memakan waktu delapan bulan, biayanya wajar, dan sistemnya berjalan cukup baik saat diluncurkan. Delapan belas bulan kemudian, perusahaan ingin menambahkan sebuah fitur. Mereka menghubungi vendor. Nomornya sudah tidak aktif. Emailnya bouncing. Vendor tersebut sudah tutup, diam-diam, tanpa pemberitahuan.
Kodenya hanya ada di komputer milik vendor dan sebuah repository privat yang tidak pernah bisa diakses oleh perusahaan. Tidak ada klausul source code escrow, tidak ada serah terima kode di titik mana pun selama kerja sama berlangsung, tidak ada apa-apa. Perusahaan tersebut ditinggalkan dengan sistem yang berjalan tapi tidak bisa mereka ubah, tidak bisa mereka tambal, dan tidak bisa mereka migrasikan tanpa membangun ulang dari nol, yang akhirnya mereka bayar, dengan biaya hampir dua kali lipat dari biaya awal, karena sekarang mereka harus mereplikasi perilaku persis dari sistem produksi yang sedang berjalan tanpa dokumentasi apa pun.
Pelajarannya: dapatkan akses tulis ke repository bersama yang tercatat aksesnya sejak hari pertama pembangunan, bukan di akhir proyek. Ini bukan soal ketidakpercayaan terhadap vendor, ini soal kontinuitas bisnis yang sama sekali tidak ada hubungannya dengan kejujuran vendor. Saya membahas ini dan perlindungan kontrak lainnya di negosiasi kontrak software.
Rewrite yang tak pernah selesai
Sebuah perusahaan logistik memutuskan sistem lama mereka butuh rewrite total. Keputusan yang masuk akal, sistem lamanya memang sudah reyot. Rewrite ini dirancang dengan semangat "kali ini kita benahi dengan benar", tanpa tenggat waktu pasti, tanpa rilis bertahap, dan daftar fitur baru yang terus bertambah di atas rewrite tersebut seiring berjalannya waktu, karena "toh kita sedang membangun ulang."
Dua tahun berjalan, belum ada satu pun yang rilis. Sistem lama tetap berjalan, ditambal lebih jauh melampaui usia yang seharusnya, sementara sistem baru terus membengkak cakupannya setiap kuartal karena para stakeholder terus menambahkan requirement ke proyek yang tidak punya garis finish untuk dipertahankan. Tim yang membangunnya kelelahan dan separuhnya keluar. Rewrite tersebut akhirnya rilis, tiga tahun setelah dimulai, dengan biaya yang tidak pernah dianggarkan siapa pun sejak awal, dan hasilnya kurang lebih sama dengan apa yang bisa dihasilkan proyek enam bulan yang dirancang dengan baik, seandainya dirilis secara bertahap.
Pelajarannya: rewrite tanpa rilis pertama yang sempit dan pasti bukanlah proyek, itu komitmen tanpa batas dengan tidak ada akhir yang alami. Rilis versi terkecil yang menggantikan bagian paling berisiko dari sistem lama terlebih dahulu, jadikan live, baru kemudian iterasi. Apa pun yang dirancang dengan semangat "kali ini kita benahi dengan benar" tanpa tenggat waktu adalah magnet scope creep yang menunggu waktu untuk meledak.
Go-live yang menghapus data produksi
Sebuah jaringan ritel yang bermigrasi ke sistem point-of-sale dan inventori baru menjadwalkan go-live mereka di akhir pekan, keputusan yang masuk akal, trafik rendah. Script migrasi yang memindahkan data transaksi historis dari sistem lama ke sistem baru punya bug: alih-alih menyalin data, dalam kondisi tertentu ia menghapus data sumber sebelum konfirmasi bahwa penyalinan berhasil. Tidak ada yang menguji migrasi ini terhadap salinan penuh data produksi, hanya sampel kecil yang tidak pernah memicu edge case tersebut.
Bug tersebut terpicu di tengah proses migrasi. Beberapa bulan riwayat transaksi lenyap, tidak bisa dipulihkan, karena tidak ada backup segar yang diambil tepat sebelum migrasi dijalankan (backup terakhir berasal dari empat hari sebelumnya, sesuai jadwal rutin, yang tidak terpikir oleh siapa pun untuk di-override demi sebuah event berisiko tinggi). Toko tersebut menghabiskan sebulan berikutnya merekonstruksi data parsial dari struk kertas dan rekening koran bank.
Pelajarannya: migrasi atau go-live apa pun yang menyentuh data produksi membutuhkan backup segar dan terverifikasi yang diambil tepat sebelum operasi dijalankan, diuji pada salinan data nyata berukuran penuh (bukan sampel kecil yang bersih), dengan rencana rollback yang jelas dan sudah dilatih. "Kami punya backup" hanya berlaku jika backup-nya baru dan proses restore-nya benar-benar sudah diuji, bukan sekadar diasumsikan berfungsi.
Pola di balik ketiganya
Setiap kisah terlihat berbeda di permukaan (legal, scope, teknis) tapi berbagi satu akar penyebab yang sama: sebuah risiko yang tadinya terlihat jelas dan murah untuk diatasi di awal, berubah menjadi tak terlihat dan mahal untuk diatasi begitu proyek sudah berjalan. Tak satu pun pihak dalam kisah-kisah ini yang tidak kompeten. Mereka sibuk, optimis, dan percaya bahwa mode kegagalan yang paling jelas tidak akan menimpa mereka.
Jika Anda sedang memulai sebuah proyek software sekarang, jalankan latihan lima menit ini sebelum kickoff: daftar tiga hal terburuk yang bisa terjadi (vendor menghilang, proyek tak pernah selesai, data hancur), dan untuk masing-masing, sebutkan satu hal murah yang bisa mencegahnya. Hampir selalu jauh lebih murah dibanding kisah-kisah di atas. Untuk pembahasan lebih luas soal mengurangi risiko semacam ini sebelum dimulai, lihat mengapa bisnis Anda butuh strategi teknologi.
Intinya
Kisah kegagalan proyek software menghibur karena dramatis, tapi pencegahannya sengaja dibuat membosankan: dapatkan akses kode sejak awal, rilis dalam fase-fase kecil dengan tenggat waktu nyata, dan ambil backup segar yang teruji sebelum apa pun menyentuh data produksi. Tidak satu pun dari ini yang mahal. Ketiga kisah horor di atas menghabiskan berbulan-bulan waktu perusahaan-perusahaan tersebut, dan dalam dua kasus, uang sungguhan yang bisa dihindari sepenuhnya dengan satu kebiasaan yang membosankan.