Proyek Software dengan Tim Eksternal: Panduan untuk UKM

Proyek Software dengan Tim Eksternal: Panduan untuk UKM

Kebanyakan pemilik bisnis menjalankan proyek software pertama mereka bersama tim eksternal seperti menjalankan renovasi rumah: sepakati harga, sepakati tanggal, lalu tunggu hasilnya. Software tidak bekerja seperti itu. Requirement bergeser begitu orang melihat sistemnya berjalan. Tanggal yang sudah ditetapkan tidak memberi tahu apa pun soal apakah yang dikirim itu memang yang dibutuhkan.

Berikut ini praktik-praktik kecil yang tetap menjaga kendali di tangan pemilik non-teknis. Bukan dengan membaca kode, tapi dengan mengendalikan apa yang diukur dan kapan uang berpindah.

"Tepat waktu, sesuai anggaran" adalah metrik utama yang keliru

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

Angka ini diulang-ulang selama tiga dekade tanpa banyak yang mempertanyakan bagaimana angka itu dihasilkan, sampai sebuah replikasi peer-reviewed melakukan itu. Eveleens dan Verhoef menerapkan definisi Standish sendiri ke 5.457 forecast nyata dari 1.211 proyek. Mereka menemukan definisi itu "misleading, one-sided, pervert the estimation practice, and result in meaningless figures". Organisasi dengan forecast yang benar-benar akurat cuma mendapat skor "success" 35–59% menurut metode Standish. Organisasi lain yang menggelembungkan anggarannya justru mendapat skor 67%. Saat dikonfrontasi soal metodologi ini, chairman 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.

Skeptisisme itu jadi lebih relevan begitu melihat risiko yang justru lebih terdokumentasi dengan baik. Analisis Flyvbjerg dan Budzier terhadap 1.471 proyek IT menemukan rata-rata cost overrun 27%. Tapi satu dari enam proyek adalah "Black Swan" dengan overrun biaya 200% dan overrun jadwal hampir 70%. Pola itu fat-tailed dan power-law, dikonfirmasi studi lanjutan terhadap 5.392 proyek. Kebanyakan proyek selesai mendekati rencana. Sebagian kecil meledak total. Struktur proyek yang baik menangkap minoritas itu lebih awal, bukan mengejar rata-rata.

Tulis scope sebagai outcome, bukan daftar fitur

"User authentication" adalah fitur. "Pelanggan lama bisa login pakai nomor HP dan menerima OTP dalam 10 detik di koneksi 3G" adalah outcome. Sesuatu yang bisa langsung ditonton dan diketahui benar atau tidak terjadi.

Daftar fitur bisa dibaca berbeda-beda oleh orang berbeda. Pernyataan outcome menutup ruang tafsir itu — dan data Standish sendiri soal kenapa proyek gagal menunjuk ke arah yang sama. Requirement yang tidak lengkap dan requirement yang berubah-ubah ada di puncak daftar penyebab kegagalan. Pernyataan requirement yang jelas (13,0% dari faktor sukses yang disebutkan) dan keterlibatan user (15,9%) ada di puncak daftar penyebab sukses. Checklist bisa saja "lengkap" dan tetap salah. Menuliskan outcome memaksa celah itu kelihatan sebelum satu baris kode pun ditulis.

Bayar berdasarkan milestone yang terikat acceptance criteria

Begitu scope ditulis sebagai outcome, skema pembayaran mengikuti dengan sendirinya. Tiap milestone terdiri dari deliverable, acceptance criteria-nya, dan deadline. Invoice cair begitu criteria-nya terverifikasi, bukan begitu tanggal di kalender tiba.

"Smaller project milestones" sendiri adalah faktor sukses keenam yang paling sering disebut dalam survei Standish. Memecah pekerjaan jadi potongan kecil memang insting yang benar — kesalahannya ada di ukuran potongannya. Milestone tiap tiga hari cuma jadi seremoni laporan status. Satu milestone di bulan ketiga menyembunyikan masalah sampai jadi mahal untuk diperbaiki. Dua sampai empat minggu biasanya ukuran yang pas untuk proyek skala UKM. Review window tetap tiga sampai lima hari kerja, supaya klien sempat menguji hasilnya terhadap acceptance criteria sebelum pembayaran jatuh tempo.

Ganti laporan status dengan demo mingguan

Laporan status adalah klaim. Demo adalah bukti. Scrum Guide resmi memposisikan Sprint Review sebagai "a working session," secara eksplisit bukan presentasi yang sudah disiapkan naskahnya. Standar delivery pemerintah Inggris sendiri menyebut praktik yang sama sebagai "show and tell". Tim menunjukkan apa yang sudah selesai, membahas apa yang dipelajari, dan menjawab pertanyaan.

Pemilik bisnis non-teknis tidak butuh paragraf yang mengklaim progress 80% kalau dia bisa menonton langsung alur login itu jalan atau tidak, dalam empat menit. Taruh ini di kalender tiap minggu di jam yang tetap. Anggap demo yang dibatalkan sebagai sinyal yang layak ditanyakan.

Satu aturan change-request, tidak lebih

Scope creep bukan hal langka. Survei global PMI terhadap ribuan praktisi menemukan rata-rata 52% proyek mengalaminya. 43% proyek membengkak anggarannya dan 48% molor jadwalnya.

Semua itu tidak butuh change-control board. Cukup satu aturan, diterapkan tanpa pengecualian: setiap penambahan ke scope dapat estimasi sendiri dan acceptance criteria sendiri, tidak ada yang numpang gratis ke milestone yang sedang berjalan. Aturan ini bisa cukup satu paragraf di dokumen bersama, tapi harus ada sebelum pekerjaan dimulai. Kalau tidak, "tambah satu field lagi saja" diam-diam jadi alasan seluruh proyek meleset dari jadwalnya.

Selesaikan urusan kepemilikan sebelum hari pertama

Dua pertanyaan menentukan apakah pemilik bisnis benar-benar memiliki apa yang sudah dibayar.

Siapa pemilik kode? Klausul "work made for hire" yang polos saja seringkali tidak cukup. Menurut hukum hak cipta AS, pekerjaan kontraktor baru dihitung work-for-hire kalau masuk ke salah satu dari sembilan kategori sempit yang diatur undang-undang. Kebanyakan custom software tidak masuk ke situ. Kontrak butuh bahasa present-tense: "agrees to assign, and hereby does assign...", karena pengadilan membaca janji untuk assign nanti sebagai tidak memberikan kepemilikan sekarang.

Lalu siapa yang memegang akun-akunnya? Daftarkan sendiri domain, hosting, dan analytics sejak hari pertama, dengan vendor ditambahkan sebagai kolaborator, bukan pemilik. Memiliki kode sendiri tidak menghapus kewajiban yang tetap melekat pada dependency-dependency-nya — pengecekan terpisah yang dibahas di apa yang sebenarnya diwajibkan lisensi open-source di software komersial.

Dokumen-dokumen yang benar-benar penting

Empat dokumen ini sejalan dengan apa yang data Standish sendiri kaitkan dengan kesuksesan — keterlibatan user, dukungan eksekutif, pernyataan requirement yang jelas. Tidak satu pun butuh binder PMBOK setebal itu:

1. Dokumen scope-as-outcomes satu halaman.
2. Jadwal milestone dan pembayaran, tiap milestone dengan acceptance criteria yang menempel.
3. Log change-request satu baris: tanggal, permintaan, estimasi baru, keputusan.
4. Klausul IP dan kepemilikan dengan bahasa assignment present-tense.

Itu saja sudah cukup. Risk register, RACI chart, rapat steering committee mingguan — proyek seukuran ini jarang butuh semua itu, seperti pada sistem manajemen hotel yang dibangun milestone demi milestone.

Apa yang didapat dari semua ini

Semua ini tidak mengharuskan satu baris kode pun dibaca. Yang dibutuhkan hanya menonton demo tiap minggu, mengecek acceptance criteria terhadap apa yang ada di layar. Lalu menolak apa pun masuk ke milestone yang belum diberi estimasi. Kendali yang dibangun dari bukti, bukan kepercayaan pada kata-kata vendor. Itu bedanya menangkap proyek yang mulai melenceng di minggu ketiga, dengan baru sadar saat invoice terakhir.