Tujuh Tanda Proyek Perangkat Lunak Bermasalah

Proyek perangkat lunak yang mulai bermasalah sering terlihat dari demo yang tertunda, laporan kemajuan yang kabur, atau biaya yang berubah tanpa catatan. Pemilik bisnis bisa memeriksa tanda-tanda ini tanpa membaca kode. Satu tanda perlu ditanyakan; beberapa tanda berulang perlu ditinjau bersama vendor dan, bila perlu, penilai teknis independen.

CHAOS Report dari Standish Group memberi angka pasti soal ini sejak 1994. Hanya 16,2% proyek perangkat lunak selesai tepat waktu, sesuai anggaran, dengan fitur lengkap seperti yang dijanjikan. Angka ini sudah puluhan tahun dan memang diperdebatkan. Standish tidak pernah mempublikasikan data mentah samplingnya, dan reanalisis akademik menyebut kategorisasi sukses/gagalnya bias sebelah.

Namun pola dasarnya tetap sama sampai sekarang. Survei Pulse of the Profession 2018 dari PMI adalah data yang lebih baru dan lebih terdokumentasi. Survei ini, terhadap lebih dari 4.000 profesional manajemen proyek, menemukan penambahan pekerjaan tanpa persetujuan — lingkup kerja yang diam-diam terus melebar tanpa tambahan biaya atau waktu — saja terjadi pada 52% proyek. Sekitar separuh proyek meleset dari tanggal pengiriman.

Anda dapat mengenali tanda-tanda berikut tanpa membaca kode. Bandingkan laporan vendor dengan bukti pekerjaan dan kesepakatan yang sudah dibuat.

1. Demonstrasi hasil kerja terus tertunda

Sepakati bukti kemajuan yang sesuai tahap pekerjaan: demo fitur, hasil migrasi data, prototipe, atau laporan uji integrasi. Jika jadwal bukti itu terus meleset, minta penjelasan hambatan dan rencana pemulihan. Tidak adanya layar yang bisa diklik pada minggu ketiga saja belum membuktikan tim tidak bekerja.

Panduan yang ditulis untuk founder nonteknis menandai pola ini: demo yang berulang kali ditunda — "sebentar lagi selesai," "environment-nya lagi down hari ini." Apalagi kalau sudah tiga kali berturut. Itu tanda paling jelas perangkat lunaknya memang belum berfungsi, atau tim sedang menyembunyikan kondisi sebenarnya.

Cara murah memperbaikinya: masukkan ke kontrak kewajiban demo yang jalan tiap satu sampai dua minggu sejak minggu pertama, sekasar apa pun tampilannya. Demo yang bisa diklik, walau belum rapi, jauh lebih berarti daripada email status yang rapi.

2. Laporan kemajuan tanpa bukti yang jelas

"Sudah 90%" selama empat minggu berturut-turut bukan laporan status. Itu angka tanpa definisi bersama di baliknya. Panduan untuk mengenali proyek outsourcing yang mandek menyebut pola ini langsung sebagai salah satu tanda paling jelas proyek sudah keluar jalur. Jargon teknis yang dipakai untuk menutupi ketiadaan bukti nyata — gejalanya sama.

Persentase kemajuan sulit dinilai jika kedua pihak belum menyepakati arti selesai untuk setiap fitur.

Langkah perbaikan: ganti laporan persentase dengan papan tugas yang dapat dilihat kedua pihak; lembar kerja bersama pun cukup. Catat pekerjaan yang sudah dirilis, sedang dikerjakan, dan belum dimulai. Sertakan bukti serta kriteria penerimaan untuk setiap tugas.

3. Satu orang menguasai semua pengetahuan kritis

Tanyakan siapa lagi di pihak vendor yang bisa menjelaskan arsitekturnya. Keheningan panjang itu sendiri sudah jadi jawaban. Ini yang di dunia rekayasa perangkat lunak disebut "bus factor": jumlah orang yang harus menghilang sebelum sebuah proyek benar-benar macet. Ibaratnya tim sepak bola yang hanya punya satu pemain jago — begitu ia cedera, permainan berhenti.

Studi 2016 terhadap 133 proyek populer di GitHub menemukan 65% proyek punya bus factor dua atau kurang. Artinya kehilangan satu atau dua orang saja bisa memacetkan seluruh basis kode. Studi ini membahas proyek sumber terbuka populer. Hasilnya menjadi alasan untuk memeriksa pemusatan pengetahuan pada tim vendor kecil, bukan angka kegagalan terukur bagi tim tersebut.

Cara murah memperbaikinya: minta dokumen README atau serah terima sebelum menandatangani apa pun. Tanyakan langsung: "selain orang ini, siapa yang bisa menjelaskan kode ini?" Kalau tidak ada jawaban yang meyakinkan, jangan tanda tangan dulu.

4. Pekerjaan bertambah tanpa catatan persetujuan

Permintaan fitur di pesan chat. Perubahan yang disepakati lewat telepon. "Oke, bisa kok kami tambahkan" tanpa email susulan. Masing-masing terasa kecil.

Namun digabung semuanya, anggaran tetap diam-diam berubah jadi anggaran tanpa batas — mekanisme di balik angka penambahan pekerjaan tanpa persetujuan 52% yang disebut di atas. Yang menjatuhkan proyek jarang satu perubahan besar. Biasanya puluhan perubahan kecil yang tidak pernah tercatat.

Cara murah memperbaikinya: wajibkan setiap perubahan lingkup kerja, sekecil apa pun, mendapat adendum tertulis satu paragraf yang menyebutkan tambahan biaya dan waktu sebelum pekerjaannya dimulai. Vendor yang enggan menuliskannya sedang mengirim sinyal sendiri.

5. Tagihan tidak mengikuti hasil yang disepakati

Begitu vendor sudah dibayar, insentif mereka untuk menyelesaikan pekerjaan bergeser, sekalipun niat kedua pihak baik. Panduan menyusun pembayaran tahap pencapaian mendokumentasikan kasus seorang founder yang membayar 50% kontrak di muka. Di minggu keenam ia baru sadar pekerjaan pengembangannya baru selesai 30% sementara 70% anggaran sudah habis.

Pola pembayaran seperti ini tidak selalu menunjukkan penipuan. Masalahnya dapat berupa jadwal pembayaran yang tidak lagi mengikuti bukti kemajuan.

Cara murah memperbaikinya: sepakati uang muka sesuai biaya awal dan risiko kedua pihak. Angka 20–30% dapat menjadi contoh negosiasi, bukan aturan universal. Kaitkan setiap pembayaran berikutnya dengan tahap pencapaian yang sudah didemokan dan diterima. Sepakati bagian pembayaran terakhir yang ditahan sampai ada persetujuan resmi untuk perangkat lunak yang sudah berfungsi.

6. Tidak punya akses ke repositori atau server sendiri

Jika Anda tidak bisa mengakses repositori proyek, akun hosting, atau pengelola domain, Anda mungkin tidak dapat mengoperasikan dan memelihara sistem secara mandiri. Hak kepemilikan serta akses perlu disepakati secara tertulis.

Panduan penitipan kode sumber (source-code escrow) mencatat apa yang terjadi kalau vendor itu tiba-tiba tidak bisa dihubungi. Klien menghadapi downtime yang mahal, tidak bisa memasang perbaikan keamanan, dan tidak ada jalan untuk melanjutkan sendiri.

Cara murah memperbaikinya: taruh semua akun repositori, domain, hosting, dan DNS di bawah organisasi sendiri sejak hari pertama. Kalau vendor bersikeras memegang semua kredensial, minta penitipan kode sumber (source-code escrow) dicantumkan di kontrak.

7. Pengujian ditunda sampai "di akhir"

"Nanti testing-nya menyusul" kedengarannya efisien. Kenyataannya kebalikan. Studi yang dipesan NIST memperkirakan biaya tahunan di AS akibat infrastruktur pengujian perangkat lunak yang tidak memadai mencapai $59,5 miliar, dengan potensi pengurangan biaya $22,2 miliar melalui perbaikan yang layak. Ini estimasi historis dari 2002. Lebih dari separuhnya ditanggung pengguna yang berurusan dengan kesalahan program yang sudah terlanjur rilis, sisanya oleh pengembang yang menjalankan pengujian tambahan setelahnya.

Kesalahan yang ditemukan selama pengembangan biasanya lebih mudah dibatasi dampaknya. Setelah rilis, perbaikan juga dapat melibatkan pemulihan data, layanan pelanggan, dan gangguan operasi.

Cara murah memperbaikinya: jadikan pengujian kualitas hasil kerja yang berjalan paralel sejak minggu pertama, bukan fase terakhir. Cantumkan di kontrak dengan bobot yang sama seperti fitur itu sendiri.

Kapan harus benar-benar berhenti sejenak

Satu tanda cukup menjadi alasan untuk meminta penjelasan dan bukti. Keterlambatan menyiapkan lingkungan demonstrasi, misalnya, masih perlu dinilai bersama tahap pekerjaan dan hambatan yang dihadapi.

Beberapa tanda dapat muncul bersamaan. Laporan kemajuan yang kabur dan perubahan lingkup tanpa catatan, misalnya, sama-sama menunjukkan kurangnya acuan bersama tentang janji serta hasil yang sudah diserahkan.

Disiplin yang sama menjaga proyek sistem manajemen hotel tetap di jalur di tengah selusin permintaan pihak yang berkepentingan yang bersaing: lingkup kerja tertulis, papan tugas, demo rutin. Disiplin itu juga yang menangkap proyek perangkat lunak mana pun sebelum jadi mahal.

Jika dua atau lebih tanda terus muncul, tinjau kondisi proyek sebelum menambah pengeluaran. Penilai independen dapat membantu memeriksa hasil yang sudah berjalan dan pilihan pemulihannya. Gunakan penilaian itu untuk memutuskan apakah kerja sama perlu diperbaiki atau diakhiri.