Standar Software: Penyelamat Proyek atau Sekadar Teater Dokumen?

Standar software sering dipatuhi hanya di atas kertas. Benarkah dokumen rapi menjamin kualitas, atau sekadar teater?

Coba tanya tim developer mana saja, "Punya standar coding dan prosedur QA?" Hampir pasti dijawab, "Punya." Lalu tanya lagi, "Terakhir kali dokumennya dibuka kapan?" Biasanya hening.

Sejak bangku kuliah kita diajari rumus sederhana: standar sama dengan kualitas. Padahal sejumlah riset lama dan baru menunjukkan jarak yang lebar antara standar yang tertulis dan praktik yang benar-benar terjadi. Artikel ini membahas sisi yang jarang muncul di slide kuliah.

Prosesnya Rapi, tapi Itu Ceritanya

Parnas dan Clements (1986) menulis sesuatu yang jujur sampai terasa nyeleneh. Menurut mereka, proses desain software yang benar-benar rasional tidak akan pernah ada. Kebutuhan pelanggan jarang jelas di awal, dan banyak detail baru ketahuan saat kode ditulis. Solusi mereka adalah berpura-pura: tulis dokumentasi seolah-olah proses ideal itu diikuti. Mereka menganggap itu berguna, dan memang berguna. Tapi konsekuensinya jelas: dokumen yang rapi belum tentu menggambarkan apa yang sebenarnya terjadi di ruang kerja.

Dipegang, Belum Tentu Dipakai

Fitzgerald (1998) menyurvei praktisi dan menemukan bahwa 60% responden tidak memakai metodologi pengembangan. Hanya 6% yang mengikutinya secara ketat, dan 79% dari yang tidak memakai bahkan tidak berniat mengadopsinya. Datanya memang dari akhir 1990-an, jadi bacalah sebagai sinyal, bukan vonis. Tapi polanya terus muncul di riset-riset berikutnya.

Nandhakumar dan Avison (1999), dalam studi lapangan berjudul The Fiction of Methodological Development, menyimpulkan hal yang lebih tajam. Metodologi lebih sering berfungsi sebagai fiksi yang dibutuhkan untuk menampilkan citra terkendali atau memberi status simbolik. Bagi pekerjaan harian para pengembang, metodologi itu terlalu mekanistis untuk benar-benar berguna. Artinya, standar bisa berubah dari alat kerja menjadi properti panggung.

Ketika Semua Tanda Tangan Lengkap

Contoh paling mahal ada di dunia penerbangan. Dua pesawat Boeing 737 MAX jatuh pada 2018 dan 2019, termasuk Lion Air yang lepas landas dari Jakarta. Herkert, Borenstein, dan Miller (2020) merangkum penjelasannya: cacat desain pada software kendali penerbangan, tekanan bersaing dengan Airbus, kurangnya transparansi Boeing soal software itu, dan pengawasan FAA yang kurang memadai selama sertifikasi.

Perhatikan polanya. Pesawat itu melewati proses sertifikasi, tetapi yang gagal adalah keterbukaan dan keberanian manusia di dalam prosesnya. Para peneliti sampai menekankan perlunya memperkuat suara para insinyur di dalam organisasi besar. Aturan ada, dan ternyata itu belum cukup.

Pendapat yang Tidak Populer

Ini bukan ajakan membuang standar. Tim tanpa aturan sama sekali jelas bukan solusi. Tapi ada pendapat yang jarang diucapkan di kelas: sertifikat tidak menulis unit test, dan audit tidak membaca kode kita jam dua pagi.

Ini argumen penulis, bukan hasil riset. Tim yang punya kebiasaan saling review dan berani bilang "ini belum aman, rilis ditunda" bisa lebih andal daripada tim bersertifikat yang takut mengecewakan tenggat. Karena itu, pertanyaan yang lebih jujur bukan lagi "Apakah proyek ini sudah sesuai standar?", melainkan:

"Kalau semua dokumen standar kita hilang besok, apakah tim ini tetap mengerjakan hal-hal yang benar?"

Kalau jawabannya ragu, mungkin kita tidak sedang membangun kualitas, melainkan hanya memproduksi bukti bahwa kita sudah berusaha.

Referensi

Fitzgerald, B. (1998). An empirical investigation into the adoption of systems development methodologies. Information & Management, 34(6), 317–328.

Herkert, J., Borenstein, J., & Miller, K. (2020). The Boeing 737 MAX: Lessons for engineering ethics. Science and Engineering Ethics, 26(6), 2957–2974. https://doi.org/10.1007/s11948-020-00252-y

Nandhakumar, J., & Avison, D. E. (1999). The fiction of methodological development: A field study of information systems development. Information Technology & People, 12(2), 176–191.

Parnas, D. L., & Clements, P. C. (1986). A rational design process: How and why to fake it. IEEE Transactions on Software Engineering, SE-12(2), 251–257.