Kenapa Proyek Software Gagal: Enam Pola yang Paling Sering

Proyek software jarang gagal di akhir. Ia gagal di minggu kedua, lalu butuh enam bulan lagi untuk kelihatan gagal. Ketika akhirnya diakui — anggaran habis, tenggat lewat, sistemnya tidak dipakai — semua orang menunjuk kejadian di bulan terakhir, padahal penyebabnya sudah duduk di ruangan sejak rapat pertama.

Enam pola berikut adalah yang paling sering kami temui dalam 5+ tahun dan 50+ proyek. Semuanya punya tanda awal yang bisa dikenali, dan semuanya bisa diputus tanpa mengganti siapa pun.

Ruang lingkup yang tidak pernah dibekukan

Ini pola yang paling banyak dibicarakan dan paling sedikit ditangani, karena penyebabnya justru niat baik. Seseorang punya ide bagus di tengah jalan, dan menolak ide bagus terasa seperti menghalangi kemajuan.

Tandanya muncul lebih awal dari yang orang kira. Kalau setelah dua atau tiga rapat masih ada fitur baru yang muncul untuk pertama kali, ruang lingkupnya belum pernah benar-benar ditutup. Tanda lain: kesepakatan awal berbentuk daftar fitur tanpa keterangan apa yang tidak termasuk.

Yang membuatnya mematikan bukan penambahannya, melainkan efek berantainya. Satu fitur tambahan di tengah jalan menyentuh rancangan data, menggeser urutan pengerjaan, dan membatalkan pengujian yang sudah dilakukan. Biaya sebenarnya selalu berlipat dari biaya yang terlihat.

Tanda paling jelas

Tidak ada satu pun dokumen yang memuat kalimat "berikut yang tidak dikerjakan di tahap ini". Kalau daftar itu tidak ada, ruang lingkup Anda terbuka.

Pengambil keputusan yang tidak pernah hadir

Tim proyek bertemu rutin, semua berjalan lancar, dan keputusan-keputusan penting diambil oleh orang yang hadir. Lalu di bulan keempat, orang yang sebenarnya berwenang melihat hasilnya untuk pertama kali dan tidak setuju dengan asumsi dasar yang dipakai sejak awal.

Kerugiannya bukan sekadar mengulang. Yang lebih merusak adalah tim kehilangan kepercayaan pada keputusan mana pun setelah itu, dan mulai menunda pekerjaan sambil menunggu kepastian yang tidak kunjung datang.

Bentuk lain dari pola yang sama: keputusan diambil oleh komite tanpa satu pemilik. Setiap pertanyaan dijawab "nanti dibahas dulu", dan setiap pembahasan menghasilkan pertanyaan baru. Proyek tidak berhenti, ia hanya bergerak sangat pelan sampai anggarannya habis.

Tanda paling jelas

Ada pertanyaan yang sudah diajukan lebih dari sepuluh hari kerja dan belum terjawab, dan tidak ada satu nama pun yang bisa Anda sebut sebagai orang yang harusnya menjawabnya.

Testing yang ditunda ke akhir

Rencananya selalu terdengar rapi: bangun dulu semuanya, uji setelah lengkap. Masalahnya, pengujian di akhir bukan pengujian, melainkan penemuan.

Kesalahan rancangan yang ditemukan di minggu kedua adalah perubahan kecil. Kesalahan yang sama ditemukan di minggu kedua puluh sudah punya belasan bagian lain yang bergantung padanya. Biaya perbaikan naik seiring waktu, dan naiknya tidak linear.

Ada versi yang lebih halus dari pola ini: pengujian dilakukan, tapi hanya oleh yang membuat, dan hanya dengan data yang rapi. Sistem lulus semua uji lalu langsung patah di hari pertama dipakai orang sungguhan, karena orang sungguhan mengetik nama dengan spasi ganda, menekan tombol dua kali, dan menutup halaman di tengah proses.

Tanda paling jelas

Belum ada satu pun calon pengguna nyata yang menyentuh sistem, padahal sebagian besar anggaran sudah terpakai.

Data lama yang tidak pernah dibersihkan

Ini pembunuh yang paling sering diremehkan, karena ia terlihat seperti pekerjaan administratif, bukan pekerjaan teknis.

Sistem baru dibangun rapi, lalu tiba waktunya memasukkan data lama. Ternyata satu pelanggan tercatat dengan lima ejaan berbeda. Tanggal tersimpan dalam tiga format. Ada baris tanpa nomor identitas. Ada kolom yang isinya berubah arti sejak tahun lalu tanpa dicatat siapa pun.

Pilihan yang tersedia saat itu semuanya buruk: menunda peluncuran untuk membersihkan, memasukkan apa adanya dan mewarisi kekacauannya, atau mulai dari kosong dan kehilangan riwayat. Ketiganya memakan biaya yang tidak pernah masuk anggaran.

Tanda paling jelas

Tidak ada seorang pun yang pernah membuka data lama dan menghitung berapa baris yang bermasalah. Kalau pertanyaan "berapa persen data pelanggan yang punya nomor telepon valid" tidak bisa dijawab minggu ini, migrasi Anda akan mengejutkan.

Serah terima tanpa dokumentasi

Sistem selesai, dipakai, dan berjalan. Enam bulan kemudian ada yang perlu diubah. Orang yang membangunnya sudah tidak di sana, dan tidak ada yang tahu kenapa satu bagian dibuat dengan cara yang tampak aneh itu.

Yang hilang di serah terima biasanya bukan kode. Kode masih ada. Yang hilang adalah alasan: kenapa aturan ini dibuat pengecualian, kenapa modul itu tidak jadi dipakai, apa yang pernah dicoba dan gagal. Tanpa itu, perubahan kecil pun jadi berisiko, dan orang memilih tidak mengubah apa pun. Sistem membeku, lalu perlahan tidak lagi cocok dengan cara kerja perusahaan, lalu ditinggalkan.

Ukuran yang jujur untuk kualitas serah terima cuma satu: berapa lama orang baru butuh waktu sampai bisa membuat perubahan kecil dengan aman.

Tanda paling jelas

Dokumentasi yang diserahkan berisi cara memakai sistem, tapi tidak berisi cara mengubahnya dan alasan di balik keputusan rancangannya.

Cara memutus tiap pola

Enam pola di atas punya penawar yang tidak mahal, asal dikerjakan di awal. Semuanya bisa Anda minta sebagai syarat sebelum proyek berjalan, dari vendor mana pun.

Untuk ruang lingkup

Minta dua daftar, bukan satu: daftar yang dikerjakan dan daftar yang tidak dikerjakan di tahap ini. Sepakati juga satu prosedur untuk permintaan baru — masuk ke antrean tahap berikutnya secara bawaan, kecuali ada yang bersedia menukarnya dengan sesuatu yang sudah ada di daftar. Menukar jauh lebih sehat daripada menambah.

Untuk keputusan

Tunjuk satu nama yang berwenang memutuskan, dan sepakati batas waktu jawaban. Tulis juga apa yang terjadi kalau lewat batas — misalnya tim mengambil asumsi yang dicatat dan lanjut jalan. Ini terdengar keras, tapi ia memindahkan biaya keterlambatan ke tempat yang benar.

Untuk pengujian

Bagi proyek menjadi potongan yang masing-masing bisa dipakai orang sungguhan, dan pastikan potongan pertama sampai ke tangan pengguna dalam hitungan minggu. Bukan demo, tapi dipakai untuk pekerjaan nyata. Satu jam pemakaian nyata menghasilkan temuan lebih banyak daripada sepuluh jam rapat.

Untuk data

Minta satu contoh nyata sebelum menyepakati apa pun: ambil seratus baris acak dari data lama, tampilkan apa adanya di layar, dan periksa bersama. Sepuluh menit melihat data asli mengubah percakapan lebih banyak daripada sepuluh halaman rencana migrasi, dan hampir selalu menghasilkan satu kejutan yang lebih baik ditemukan sekarang.

Jadikan pemeriksaan data lama sebagai pekerjaan minggu pertama, bukan minggu terakhir. Hitung jumlah baris, jumlah duplikat, jumlah kolom kosong, dan jumlah format yang tidak konsisten. Hasilnya menentukan jadwal dan anggaran, jadi ia harus diketahui sebelum keduanya ditetapkan.

Untuk serah terima

Mulai mengumpulkan catatan alasan sejak minggu pertama, bukan di akhir. Setiap kali sebuah keputusan rancangan diambil menyimpang dari yang wajar, tulis satu paragraf: apa yang dipilih, apa alternatifnya, dan kenapa alternatif itu ditolak. Kumpulan paragraf pendek ini lebih berharga daripada dokumen tebal yang disusun terburu-buru di minggu terakhir, karena ia ditulis saat alasannya masih segar dan lengkap.

Sepakati ujinya di depan: orang dari pihak Anda harus bisa melakukan satu perubahan kecil sendiri, didampingi, sebelum proyek dinyatakan selesai. Kalau itu tidak bisa dilakukan, dokumentasinya belum cukup — tidak peduli setebal apa.

Dan satu pola ketujuh: proyeknya memang tidak perlu ada

Sebagian proyek gagal bukan karena dikerjakan buruk, melainkan karena tidak seharusnya dimulai. Tandanya cukup konsisten: kebutuhannya bisa diselesaikan aplikasi jadi yang dilanggan bulanan; prosesnya masih berubah tiap bulan sehingga aturan apa pun akan basi; volumenya terlalu kecil sehingga penghematannya tidak akan pernah menutup biaya perawatan; atau tidak ada satu orang pun di perusahaan yang akan memiliki sistem itu setelah selesai. Kalau salah satu dari empat kondisi ini benar, pekerjaan yang tepat adalah menunda, bukan mencari vendor yang lebih murah.

Dan satu hal yang tidak bisa dibeli

Semua penawar di atas hanya bekerja kalau kabar buruk boleh disampaikan lebih awal. Proyek yang di dalamnya orang takut melaporkan keterlambatan akan menyembunyikannya sampai tidak bisa disembunyikan lagi, dan pada titik itu semua pilihan sudah mahal. Kalau di rapat proyek Anda semua laporan selalu hijau, itu bukan tanda sehat. Itu tanda tidak ada yang berani jadi orang pertama yang bilang merah.

Kami tidak akan mengklaim semua proyek kami mulus. Yang bisa kami klaim adalah pola-pola ini sudah cukup sering terlihat sehingga jadi bagian dari cara kami memulai pekerjaan. Bentuk kerjanya diuraikan di halaman jasa pembuatan aplikasi, hasil pekerjaan sebelumnya bisa dilihat di portofolio, dan kalau Anda sedang menimbang proyek yang mulai menunjukkan salah satu tanda di atas, bahas dulu lewat halaman kontak sebelum menambah anggaran.