Tanda-Tanda Proyek Software Mulai Menuju Kehancuran

Tanda-Tanda Proyek Software Mulai Menuju Kehancuran

Tidak perlu membaca satu baris kode pun untuk melihat proyek software menuju kehancuran. Tandanya muncul di thread email, catatan standup, dan invoice — berminggu-minggu sebelum ada pihak yang mengucapkan kata "gagal." Tujuh tanda di bawah ini yang saya periksa tiap kali diminta mereview proyek yang sudah dimulai vendor lain.

CHAOS Report dari Standish Group memberi angka pasti soal ini sejak 1994. Hanya 16,2% proyek software 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.

Tapi 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 scope creep — lingkup kerja yang diam-diam terus melebar tanpa tambahan biaya atau waktu — saja terjadi pada 52% proyek. Sekitar separuh proyek meleset dari tanggal pengiriman.

Semua ini bisa dikenali tanpa audit teknis. Yang dibutuhkan cuma tahu apa yang harus diperhatikan.

1. Tidak ada demo yang jalan setelah berminggu-minggu

Proyek yang benar-benar dikerjakan menghasilkan sesuatu yang bisa diklik hampir sejak awal, sekalipun tampilannya masih kasar. Kalau minggu ketiga tiba dan yang ada cuma deskripsi soal "sedang dikerjakan," tanpa ada yang bisa dilihat, salah satu dari dua hal ini benar. Belum ada sesuatu yang nyata dibangun, atau ada yang macet dan tidak ada yang mau mengakuinya.

Panduan yang ditulis untuk founder non-teknis 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 software-nya 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 progres samar, macet di angka bulat

"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 memancing drift semacam ini justru karena tidak pernah ada kesepakatan tertulis soal apa arti "selesai" untuk suatu fitur.

Cara murah memperbaikinya: ganti update persentase dengan task board yang bisa dilihat siapa saja — spreadsheet bersama pun cukup. Task board itu menunjukkan persis apa yang sudah rilis, apa yang sedang dikerjakan, dan apa yang belum disentuh. Sebuah task itu bisa didemokan atau tidak. Tidak ada 90% yang jujur.

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 software engineering disebut "bus factor": jumlah orang yang harus menghilang sebelum sebuah proyek benar-benar macet. Ibaratnya tim sepak bola yang cuma 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 codebase. Kalau ini terjadi pada proyek open-source yang terawat baik dengan puluhan kontributor, hal serupa hampir pasti terjadi juga pada tim vendor kecil. Apalagi kalau di situ cuma satu developer yang menulis semuanya.

Cara murah memperbaikinya: minta dokumen README atau handover 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. Scope terus membesar tapi tidak ada yang dicatat

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

Tapi digabung semuanya, anggaran tetap diam-diam berubah jadi anggaran tanpa batas — mekanisme di balik angka scope creep 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 scope, 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. Invoice datang mendahului milestone yang selesai

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

Ini jarang soal penipuan. Ini cuma yang terjadi kalau pembayaran dan progres berhenti saling terikat.

Cara murah memperbaikinya: batasi pembayaran di muka maksimal 20-30%. Kaitkan setiap pembayaran berikutnya dengan milestone yang sudah didemokan dan diterima. Tahan 20-30% terakhir sampai ada sign-off resmi untuk build yang sudah jalan.

6. Tidak punya akses ke repository atau server sendiri

Kalau organisasi GitHub, akun hosting, dan registrar domainnya sendiri saja tidak bisa diakses, proyek itu sebenarnya bukan milik sendiri. Itu cuma akses yang disewa dari vendor.

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

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

7. Testing ditunda sampai "di akhir"

"Nanti testing-nya menyusul" kedengarannya efisien. Kenyataannya kebalikan. Studi yang dipesan NIST memperkirakan biaya tahunan di AS akibat infrastruktur testing software yang tidak memadai mencapai $22,2 sampai $59,5 miliar. Lebih dari separuhnya ditanggung pengguna yang berurusan dengan bug yang sudah terlanjur rilis, sisanya oleh developer yang menjalankan testing tambahan setelahnya.

Bug yang ditemukan saat development murah untuk diperbaiki. Bug yang sama, yang baru ditemukan setelah rilis oleh pelanggan, tidak murah.

Cara murah memperbaikinya: jadikan QA deliverable 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 red flag saja di daftar ini cukup jadi alasan untuk bertanya tajam, belum tentu untuk panik. Vendor yang baru pertama kali kerja sama bisa saja memang lambat menyiapkan environment demo.

Tapi red flag-red flag ini cenderung menumpuk. Tim yang bersembunyi di balik update 90% yang samar jauh lebih mungkin juga menyimpan perubahan scope yang tidak tercatat. Keduanya berakar dari masalah yang sama: tidak ada catatan bersama soal apa yang dijanjikan dan apa yang sudah diserahkan.

Disiplin yang sama menjaga proyek sistem manajemen hotel tetap di jalur di tengah selusin permintaan stakeholder yang bersaing: scope tertulis, task board, demo rutin. Disiplin itu juga yang menangkap proyek software mana pun sebelum jadi mahal.

Dua atau lebih red flag yang muncul bersamaan adalah sinyal untuk berhenti. Libatkan seseorang yang tidak berkepentingan untuk melihat kondisi build yang sebenarnya. Putuskan apakah memperbaiki kerja sama ini atau mengakhirinya, sebelum sisa anggaran yang masih ada ikut hilang.