Proyek Perangkat Lunak UKM: Cara Mengendalikan Tim Eksternal

Pemilik UKM bisa mengendalikan proyek perangkat lunak tanpa membaca kode. Sepakati hasil kerja yang bisa diuji, bagi proyek menjadi tahap kecil, dan minta demonstrasi rutin. Hubungkan pembayaran dengan syarat penerimaan yang tertulis. Setiap perubahan kebutuhan harus punya dampak biaya dan jadwal yang disetujui. Urus pula kepemilikan kode, akun, serta serah terima sejak awal.

Apa yang perlu disepakati sebelum pekerjaan dimulai?

Tuliskan lingkup pekerjaan melalui hasil yang dapat Anda lihat dan uji. Daftar nama fitur saja belum cukup untuk menyamakan harapan. “Pelanggan bisa masuk akun” belum menjelaskan bagaimana pelanggan melakukannya, atau apa yang terjadi saat pengiriman kode gagal.

Contoh hasil: pelanggan lama bisa masuk memakai nomor HP dan kode sekali pakai (OTP). Tambahkan kondisi uji yang disepakati, misalnya jenis koneksi dan batas waktu tunggu. Angka contoh harus diuji bersama vendor; jangan menjadikannya janji sebelum kemampuan penyedia pesan diketahui.

Daftar fitur bisa ditafsirkan berbeda oleh tim dan pemilik usaha. Contoh yang dapat diuji membantu menutup celah itu sebelum kode ditulis.

Kapan pembayaran per tahap dilakukan?

Bagi proyek menjadi tahap kerja dengan sasaran yang jelas. Tiap tahap perlu hasil yang akan diserahkan, tenggat, dan syarat penerimaan (acceptance criteria). Pembayaran mengikuti ketentuan kontrak dan hasil pemeriksaan, bukan hanya tanggal di kalender.

Untuk proyek UKM, tahap dua sampai empat minggu bisa menjadi titik awal. Sesuaikan dengan pekerjaan dan ketersediaan penguji. Beri waktu pemeriksaan yang jelas, misalnya tiga sampai lima hari kerja, lalu catat hasilnya: diterima, perlu diperbaiki, atau menunggu penjelasan.

Apa yang harus ditunjukkan saat demonstrasi mingguan?

Minta vendor menjalankan alur kerja nyata, memakai contoh data yang aman. Contohnya: buat pesanan, terima pembayaran uji, lalu periksa laporan. Libatkan staf yang kelak memakai sistem. Mereka sering menemukan langkah yang tidak terlihat dalam proposal.

Scrum Guide resmi menyebut pemeriksaan hasil sebagai sesi kerja bersama. Panduan pemerintah Inggris juga menjelaskan praktik menunjukkan hasil dan membahasnya. Keduanya berguna sebagai acuan; Anda tidak harus memakai seluruh metode mereka.

Jadwalkan demonstrasi pada waktu tetap setiap minggu. Jika demonstrasi dibatalkan, minta penjelasan dan tanggal pengganti. Klaim “80% selesai” belum menjawab apakah proses yang dibutuhkan staf sudah berjalan.

Bagaimana menangani tambahan permintaan?

Tambahan kebutuhan bukan kejadian aneh. Survei global PMI pada 2018 melaporkan 52% proyek mengalami perluasan lingkup; 43% melewati anggaran dan 48% melewati jadwal. Angka itu lintas proyek, bukan perkiraan khusus UKM Indonesia.

Simpan setiap perubahan dalam satu catatan yang berisi tanggal, permintaan, dampak biaya dan jadwal, serta keputusan. Sebelum tambahan masuk ke tahap yang berjalan, sepakati dampaknya secara tertulis. Permintaan kecil boleh dikerjakan tanpa biaya tambahan jika kedua pihak setuju; keputusan itu tetap dicatat.

Siapa yang memiliki kode dan akun sistem?

Pisahkan hak atas kode dari kendali akun. Kontrak perlu menjelaskan hak atas kode buatan khusus, komponen milik vendor sebelumnya, dan komponen pihak ketiga. Minta peninjauan hukum sesuai hukum yang dipilih dalam kontrak, terutama jika klien atau vendor berada di negara lain.

Contoh dari Amerika Serikat menunjukkan kenapa istilah kontrak tidak boleh disalin begitu saja. Di sana, aturan work made for hire untuk pekerjaan pesanan dibatasi sembilan kategori dalam undang-undang, seperti dijelaskan U.S. Copyright Office. Uraian praktik kontrak AS membedakan janji mengalihkan hak nanti dengan pengalihan hak yang berlaku sekarang. Contoh ini khusus hukum AS; rumusan itu bukan aturan otomatis untuk kontrak Indonesia.

Untuk akun, daftarkan domain, hosting, dan analitik atas kendali bisnis Anda sejak awal. Beri vendor akses yang diperlukan. Hak atas kode sendiri tidak menghapus kewajiban lisensi komponen lain; periksa juga lisensi sumber terbuka di perangkat lunak komersial.

Dokumen apa yang perlu diminta pemilik UKM?

Mulai dengan empat dokumen yang bisa dipakai sehari-hari:

1. Satu halaman berisi hasil kerja, kondisi uji, dan batas pekerjaan.
2. Jadwal tiap tahap, syarat penerimaan, dan pembayaran.
3. Catatan perubahan kebutuhan beserta keputusan biaya dan jadwal.
4. Ketentuan hak kode, kepemilikan akun, dukungan, dan serah terima.

Tambah dokumen risiko bila proyek menyentuh pembayaran, data sensitif, atau keselamatan. Jumlah dokumen mengikuti risiko, bukan ukuran tim saja. Pada pembangunan sistem manajemen hotel, pembagian tahap membantu memeriksa alur kerja satu per satu.

Apa kata riset tentang risiko proyek?

Angka berikut menjelaskan latar risikonya, bukan ramalan untuk proyek UKM Anda. Sampel dan definisi keberhasilan tiap studi berbeda.

Salah satu angka yang sering dikutip berasal dari laporan CHAOS Standish Group 1994: hanya 16,2% proyek yang tepat waktu, sesuai anggaran, dan sesuai lingkup. 52,7% "challenged" dan rata-rata membengkak 189% dari estimasi biaya awal. 31,1% dibatalkan sama sekali.

Selama tiga dekade, angka ini sering diulang tanpa membahas metodologinya. Eveleens dan Verhoef kemudian menguji definisi Standish dalam studi yang ditinjau oleh sejawat, memakai 5.457 perkiraan nyata dari 1.211 proyek. Mereka menemukan definisi itu "misleading, one-sided, pervert the estimation practice, and result in meaningless figures". Organisasi dengan perkiraan akurat hanya mendapat skor "success" 35–59% menurut metode Standish. Organisasi lain yang menggelembungkan anggarannya justru mendapat skor 67%. Saat dikonfrontasi soal metodologi ini, ketua Standish sendiri menjawab bahwa laporan-laporan itu "should be considered Standish opinion and the reader bears all risk in the use of this opinion." Kalimat itu tidak pernah muncul di laporan aslinya.

Keterbatasan tersebut perlu dibaca bersama riset risiko proyek lain yang memiliki dasar lebih jelas. Analisis Flyvbjerg dan Budzier terhadap 1.471 proyek IT menemukan rata-rata pembengkakan biaya 27%. Tapi satu dari enam proyek adalah "Black Swan" dengan pembengkakan biaya 200% dan pembengkakan jadwal hampir 70%. Pola itu fat-tailed dan power-law, dikonfirmasi studi lanjutan terhadap 5.392 proyek. Istilah tersebut menggambarkan sebaran risiko yang menyisakan sebagian kecil proyek dengan pembengkakan biaya besar. Banyak proyek selesai mendekati rencana, sementara sebagian kecil mengalami pembengkakan besar. Tahap kerja, pengujian hasil, dan catatan perubahan membantu mengenali proyek yang menyimpang sebelum dampaknya meluas.

Apa yang perlu Anda lakukan berikutnya?

Sebelum menerima penawaran, pilih satu proses bisnis dan minta vendor menjelaskan cara mengujinya. Cocokkan jawaban itu dengan jadwal, pembayaran, dan dokumen serah terima. Jika jawabannya masih berupa nama fitur, perjelas dulu hasilnya.

Jika proyek sudah berjalan, mulai dari demonstrasi berikutnya. Catat hasil yang bisa dipakai staf, perbaikan yang belum selesai, dan perubahan yang menunggu keputusan. Hasil pemeriksaan tersebut menjadi dasar penilaian kemajuan, meski Anda tidak membaca kode.