Saya telah menghabiskan sebagian besar waktu lima belas tahun dipanggil setelah sebuah bangunan mengalami masalah. Fitur pembayaran yang terlambat tiga bulan. Sistem inventaris yang sebenarnya tidak dapat digunakan oleh siapa pun. Pembangunan kembali yang diam-diam menghabiskan 400 juta rupiah dan tidak menghasilkan apa pun. Ketika orang bertanya kepada saya mengapa proyek perangkat lunak gagal, mereka mengharapkan saya berbicara tentang kerangka kerja atau kode yang buruk. Kenyataannya tidak terlalu dramatis dan lebih bermanfaat: kegagalan hampir selalu diputuskan sebelum baris kode pertama, dalam cara proyek disiapkan.
Alasan mengapa proyek perangkat lunak gagal jarang sekali bersifat teknis. Ini bersifat organisasional. Kepemilikan tidak jelas, ruang lingkup terus bergerak, dan tidak ada yang menyampaikan berita buruk sampai tenggat waktu tiba dan tidak ada yang bisa ditunjukkan. Bagian baiknya adalah kegagalan inilah yang dapat dicegah oleh pembeli non-teknis, tanpa mengetahui cara membuat kode, menggunakan tiga kontrol yang dapat Anda terapkan dalam kontrak apa pun.
Apakah Kegagalan Proyek Itu Masalah Proses atau Masalah Kode?
Kegagalan proyek perangkat lunak jauh lebih sering merupakan masalah proses ketimbang masalah kode. Ketika sebuah bangunan runtuh, pemeriksaan mayat biasanya menemukan bentuk yang sama. Klien berasumsi vendor akan mengisi rinciannya. Vendor berasumsi klien akan mengklarifikasinya. Persyaratan berubah setiap minggu karena lima orang mempunyai pendapat dan tidak ada yang mempunyai wewenang. Dan karena tim hanya menunjukkan kemajuan melalui laporan status, semua orang percaya bahwa segala sesuatunya berjalan sesuai rencana hingga ternyata ternyata tidak.
Perhatikan bahwa semua ini bukan tentang bakat. Saya telah menyaksikan para insinyur yang kuat menghasilkan bencana dan tim rata-rata menghasilkan sistem yang solid. Perbedaannya adalah disiplin pengoperasian di sekitar mereka. Hal ini menggembirakan, karena disiplin adalah sesuatu yang Anda perlukan sebagai pembeli meskipun Anda tidak dapat mengevaluasi kodenya sendiri.
Kenapa Demo Mingguan Perangkat Lunak yang Berfungsi Begitu Penting?
Demo mingguan perangkat lunak yang berfungsi penting karena inilah upaya perlindungan paling ampuh yang bisa Anda terapkan: menolak menerima laporan kemajuan sebagai bukti kemajuan. Slide yang mengatakan "backend 70 persen selesai" tidak berarti apa-apa. Layar berfungsi yang dapat Anda klik berarti segalanya.
Jadi tuliskan dalam perjanjian: setiap minggu, tim mendemonstrasikan sesuatu yang sedang berjalan, di lingkungan nyata, yang dapat Anda sentuh. Bukan maket, bukan panduan kode, tapi perangkat lunak yang melakukan sesuatu.
- Jika mereka dapat melakukan demo setiap minggu, proyek tersebut benar-benar hidup.
- Jika demo tergelincir selama dua minggu berturut-turut, Anda telah menemukan masalah sejak dini, padahal perbaikannya masih murah.
- Jika mereka menolak demo sepenuhnya, itulah jawaban Anda mengenai bagaimana enam bulan ke depan akan berjalan.
Demo mingguan mengubah risiko yang tidak jelas menjadi risiko yang terlihat. Anda berhenti menemukan masalah pada tenggat waktu dan mulai menemukannya selagi masih ada waktu dan anggaran untuk merespons. Ini adalah naluri yang sama di balik [mempersiapkan sistem Anda untuk lonjakan permintaan musiman] (/blog/preparing-systems-seasonal-traffic-spikes): Anda ingin melihat ketegangan sebelum momen yang penting, bukan selama momen tersebut.
Pengendalian 2: Satu pengambil keputusan di setiap pihak
Sebagian besar kekacauan cakupan terjadi karena terlalu banyak orang yang dapat mengatakan "bisakah kita menambahkan juga". Pemimpin pemasaran menginginkan satu hal, kepala operasi menginginkan hal lain, pemilik mengubah arah setelah pesaing meluncurkan sesuatu. Setiap permintaan terdengar kecil. Bersama-sama mereka menyusun jadwal.
Perbaikannya tidak menarik tetapi tegas. Sebutkan satu orang di pihak Anda yang memiliki keputusan produk, dan minta vendor menyebutkan satu rekannya. Setiap permintaan perubahan mengalir melalui dua orang tersebut. Semua orang bisa menyarankan, tapi hanya pengambil keputusan yang menyetujuinya.Ini melakukan dua hal. Ini menghentikan ruang lingkup diam-diam yang menjadikan proyek tiga bulan menjadi delapan bulan. Dan hal ini memberikan vendor satu suara yang bertanggung jawab, yang menghilangkan alasan favorit mereka yaitu "kami sedang menunggu keputusan". Ketika seseorang bernama manusia memiliki panggilan tersebut, keputusan sebenarnya dapat dibuat, dan keputusan tersebut dibuat lebih cepat.
Pengendalian 3: Pembayaran bertahap terkait dengan perangkat lunak yang berfungsi
Cara Anda menyusun pembayaran membentuk perilaku lebih dari klausul apa pun tentang kualitas. Bayar semuanya di muka dan Anda telah menyerahkan semua leverage Anda. Bayar murni berdasarkan waktu dan insentifnya adalah membutuhkan lebih banyak waktu.
Sebaliknya, bagi proyek menjadi beberapa tahap, dan kaitkan setiap pembayaran dengan hasil kerja yang dapat dibuktikan dan telah Anda terima.
| Tahap | Pemicu pembayaran |
|---|---|
| Pembukaan | Rencana yang ditandatangani dan pengaturan lingkungan |
| Tonggak Sejarah 1 | Fitur inti didemonstrasikan dan diterima |
| Tonggak Pencapaian 2 | Kumpulan fitur kedua berfungsi ujung ke ujung |
| Peluncuran | Sistem hidup dan berjalan dalam produksi |
| Stabilisasi | Periode yang disepakati tanpa masalah kritis |
Intinya jangan menekan vendor. Vendor yang adil akan menyambut baik hal ini, karena ini berarti mereka akan dibayar terus-menerus untuk kemajuan nyata dibandingkan memperebutkan sejumlah uang pada akhirnya. Ini menyelaraskan kedua sisi pada hal yang sama: perangkat lunak yang berfungsi, dirilis dalam beberapa bagian yang dapat Anda verifikasi.
Seperti Apa Bentuknya dalam Praktik?
Ketiga kontrol ini dalam praktik terlihat seperti pengalaman sebuah perusahaan distribusi yang saya sarankan, yang sebelumnya telah membakar satu vendor dan hampir menandatangani kontrak dengan vendor kedua dengan persyaratan jabat tangan yang sama. Kami hampir tidak mengubah apa pun tentang rencana teknis. Kami menambahkan tiga kontrol: demo mingguan, satu pemilik produk di pihak mereka, melakukan pembayaran berdasarkan pencapaian yang diterima.
Bangunan kedua tidak sempurna. Dua fitur datang terlambat dan satu fitur diam-diam dihapus karena tidak diperlukan. Namun perusahaan mengetahui setiap masalah tersebut dalam waktu seminggu setelah masalah tersebut terjadi, menelepon setiap kali masalah tersebut terjadi, dan hanya membayar sesuai dengan apa yang mereka terima. Proyek ini berhasil dilaksanakan, sesuai anggaran, dan masih berjalan. Itulah definisi sukses yang realistis: bukan tanpa masalah, tapi tanpa kejutan pada tenggat waktunya.
Jika Anda menginginkan versi yang lebih dalam dari pemikiran ini, perbedaan antara menyewa vendor bengkel dan memilih mitra yang bertanggung jawab sangat penting di sini. Saya menulis tentang hal itu di mengapa Anda harus berhenti mempekerjakan vendor dan mulai memilih mitra teknologi.
Kesimpulan praktis
Anda tidak perlu membaca kode untuk melindungi proyek perangkat lunak. Anda perlu menerapkan tiga hal yang akan diterima oleh tim jujur mana pun dan ditolak oleh tim lemah mana pun:
- Demo mingguan perangkat lunak yang berfungsi. Kemajuan yang dapat Anda klik, bukan slide yang harus Anda percayai.
- Satu pengambil keputusan di setiap sisi. Membunuh scope creep dengan mengarahkan setiap perubahan melalui pemilik yang disebutkan.
- Pembayaran bertahap terhadap hasil yang diterima. Pertahankan leverage dan tetap berikan insentif pada perangkat lunak yang berfungsi.
Masukkan ini ke dalam kontrak sebelum proyek dimulai. Di situlah alasan mengapa proyek perangkat lunak gagal biasanya ditulis, dan di situlah Anda bisa menulis akhir yang berbeda. Jika Anda lebih suka seseorang memegang disiplin tersebut bersama Anda, keterlibatan seperti itulah yang saya lakukan sebagai mitra teknologi.
