Proyek software jarang bersengketa soal harga — harga disepakati di awal saat semua orang masih bersemangat. Yang bersengketa adalah apakah sesuatu termasuk di dalamnya, dan pertanyaan itu selalu muncul ketika tenggat sudah dekat.
Kontrak yang baik untuk proyek software bukan kontrak yang panjang. Ia adalah kontrak yang menjawab tiga hal dengan jelas: apa yang termasuk, apa yang terjadi ketika kebutuhan berubah, dan kapan pekerjaan dianggap selesai.
Lingkup: tulis yang tidak termasuk
Hampir semua kontrak memuat daftar fitur. Yang membedakan kontrak yang bertahan adalah daftar yang secara tegas dinyatakan tidak termasuk.
Contoh yang berulang: aplikasi disepakati punya laporan penjualan. Enam minggu kemudian client mengharapkan laporan itu bisa diekspor ke format tertentu dan dijadwalkan otomatis lewat surel. Keduanya masuk akal sebagai harapan, keduanya tidak pernah disebut, dan keduanya butuh waktu kerja yang nyata. Tanpa daftar yang tidak termasuk, perdebatan ini hanya bisa diselesaikan dengan salah satu pihak mengalah.
Cantumkan juga asumsi yang mendasari perkiraan: jumlah peran pengguna, jumlah integrasi pihak ketiga, ketersediaan dokumentasi sistem lama, dan siapa yang menyediakan data untuk pengujian. Ketika asumsi itu meleset, kontrak sudah menyediakan pijakan untuk membicarakan penyesuaian — tanpa siapa pun harus terlihat mengingkari kesepakatan.
Perubahan: sediakan jalurnya, bukan larangannya
Kebutuhan akan berubah. Kontrak yang berpura-pura sebaliknya menghasilkan salah satu dari dua hal: perubahan dikerjakan diam-diam tanpa tambahan waktu sampai jadwal berantakan, atau setiap permintaan berubah menjadi negosiasi yang menghentikan pekerjaan.
Jalur yang bekerja di lapangan biasanya sederhana:
- Permintaan diajukan tertulis, sekalipun hanya beberapa kalimat.
- Vendor menilai dampaknya terhadap waktu dan biaya dalam tenggat yang disepakati — dua hari kerja sudah memadai untuk sebagian besar permintaan.
- Client menyetujui atau menolak secara tertulis sebelum pekerjaan dimulai.
- Perubahan yang disetujui memperbarui jadwal secara terbuka, bukan diserap diam-diam.
Yang sering dilupakan: sediakan juga jatah perubahan kecil tanpa prosedur. Menjalankan proses formal untuk penggantian teks tombol membuat semua orang berhenti memakai prosesnya, dan perubahan besar ikut mengalir lewat jalur tidak resmi yang sama.
Pembayaran yang terikat pada bukti, bukan pada kalender
Termin berdasarkan tanggal membuat kedua pihak berkepentingan pada tanggal, bukan pada hasil. Termin yang terikat pada penyerahan yang bisa diperiksa — modul tertentu berjalan di lingkungan uji dan diterima — membuat kemajuan proyek terlihat sejak awal.
Sertakan tenggat penerimaan: bila client tidak memberikan tanggapan dalam jangka waktu tertentu setelah penyerahan, hasil dianggap diterima. Tanpa ini, proyek bisa berhenti bukan karena pekerjaannya belum selesai, melainkan karena tidak ada yang sempat memeriksa.
Serah terima: yang diserahkan selain aplikasinya
Aplikasi yang berjalan adalah bagian yang paling terlihat dan bukan bagian yang paling menentukan setahun kemudian.
- Kode sumber beserta riwayatnya di repositori milik client, bukan salinan akhir dalam bentuk arsip.
- Kepemilikan layanan pihak ketiga — nama domain, penyedia server, layanan surel, gerbang pembayaran. Semuanya atas nama client sejak awal jauh lebih mudah daripada dipindahkan kemudian.
- Dokumentasi penyiapan yang cukup bagi developer lain untuk menjalankan sistem di mesin baru tanpa bertanya.
- Skema basis data dan cara migrasinya.
- Catatan keputusan teknis yang penting — mengapa sesuatu dibuat seperti itu. Ini yang menyelamatkan penerus berikutnya dari mengulang kesalahan yang sudah pernah dihindari.
Garansi dan pemeliharaan adalah dua hal berbeda
Garansi menutup cacat: perilaku yang tidak sesuai dengan yang disepakati. Pemeliharaan menutup kelangsungan: pembaruan keamanan, penyesuaian terhadap perubahan layanan pihak ketiga, dan penambahan kecil. Menggabungkan keduanya dalam satu istilah membuat setiap permintaan setelah peluncuran menjadi perdebatan tentang apakah itu masih gratis.
Tetapkan masa garansi yang wajar dengan batas yang jelas, lalu sepakati bentuk pemeliharaan sesudahnya sejak sebelum peluncuran. Membicarakannya setelah proyek selesai selalu lebih sulit, karena pada saat itu satu pihak sudah membayar penuh dan pihak lain sudah memindahkan timnya.
Pertanyaan yang Sering Diajukan
Apa yang harus ada dalam lingkup pekerjaan agar tidak menjadi sengketa?
Bukan hanya daftar fitur, tetapi juga daftar yang secara tegas tidak termasuk, asumsi yang mendasari perkiraan, dan kriteria penerimaan per fitur. Bagian yang tidak termasuk justru yang paling sering menyelamatkan kedua pihak.
Bagaimana menangani permintaan perubahan tanpa menghambat proyek?
Sediakan jalur perubahan yang ringan: setiap permintaan dinilai dampak waktu dan biayanya dalam hitungan hari, bukan minggu, lalu disetujui tertulis sebelum dikerjakan. Yang memperlambat proyek bukan adanya prosedur perubahan, melainkan tidak adanya.
Berapa lama masa garansi yang wajar setelah serah terima?
Umumnya satu sampai tiga bulan untuk perbaikan cacat, dengan batas yang jelas bahwa garansi mencakup perbaikan perilaku yang tidak sesuai kesepakatan, bukan penambahan kemampuan baru.
Apa yang harus diserahkan selain aplikasi yang berjalan?
Kode sumber beserta riwayatnya, dokumentasi penyiapan lingkungan, kredensial dan kepemilikan seluruh layanan pihak ketiga, skema basis data, serta catatan keputusan teknis yang penting. Aplikasi yang berjalan tanpa ini adalah aplikasi yang hanya bisa dirawat oleh pembuatnya.
Butuh tim yang mengerjakan ini untuk Anda?
Javaman Digieco menyediakan dedicated team, staff augmentation, dan pengembangan software custom untuk perusahaan di Jakarta, Medan, dan seluruh Indonesia.
Hubungi Kami Sekarang