Hampir setiap perselisihan yang kami lihat dalam proyek aplikasi, baik di pihak kami sendiri maupun cerita dari klien tentang vendor sebelumnya, berpangkal pada hal yang sama: kalimat kebutuhan yang bisa dibaca dengan dua cara berbeda, dan masing-masing pihak membacanya sesuai kepentingannya.
Yang menarik, biasanya tidak ada pihak yang berniat curang. Keduanya benar-benar mengira sudah sepakat.
Contoh kalimat yang menipu
Perhatikan kalimat ini, yang terdengar sangat wajar dalam dokumen kebutuhan:
> "Sistem harus dapat menampilkan laporan bulanan."
Terlihat jelas, padahal menyimpan setidaknya lima pertanyaan yang belum terjawab. Laporan berisi data apa saja? Bisa disaring berdasarkan apa? Perlu diekspor ke format apa? Siapa saja yang boleh membukanya? Laporan bulan berjalan dihitung sampai tanggal berapa?
Vendor akan menjawab pertanyaan itu sendiri saat membangun, memilih yang paling sederhana, dan secara teknis tetap memenuhi kalimat di dokumen. Klien lalu merasa hasilnya jauh dari yang dibayangkan. Keduanya benar menurut dokumen yang sama.
Ubah kalimat menjadi cerita
Cara paling ampuh yang kami temukan bukan menulis kebutuhan sebagai daftar fitur, melainkan sebagai cerita tentang siapa melakukan apa dan untuk keperluan apa.
Kalimat tadi bisa ditulis ulang menjadi:
> "Kepala bidang membuka laporan bulanan pada awal bulan untuk mengetahui berapa permohonan yang masuk, selesai, dan masih tertunda di tiap seksi. Laporan disaring berdasarkan periode dan seksi, dapat diekspor ke Excel, dan hanya bisa dibuka oleh kepala bidang serta admin."
Lebih panjang, memang. Tapi hampir tidak ada ruang untuk salah tafsir, dan yang lebih penting, alasannya ikut tertulis. Ketika vendor tahu alasannya, mereka bisa mengusulkan cara yang lebih baik alih-alih sekadar menuruti bunyi kalimat.
Empat kata yang sebaiknya dihindari
Ada beberapa kata yang hampir selalu menjadi sumber masalah karena maknanya bergantung pada siapa yang membaca:
- "Mudah digunakan". Mudah menurut siapa? Ganti dengan hal yang bisa diukur, misalnya "petugas loket dapat menyelesaikan pendaftaran satu pemohon dalam maksimal tiga layar".
- "Cepat". Ganti dengan angka. Berapa detik yang masih dianggap wajar untuk membuka daftar berisi sepuluh ribu baris?
- "Fleksibel". Fleksibel di bagian mana? Biasanya yang dimaksud adalah beberapa hal tertentu yang bisa diubah sendiri tanpa bantuan vendor. Sebutkan hal-hal itu.
- "Seperti sistem X". Ini yang paling berbahaya, karena sistem X punya ratusan perilaku dan tidak ada yang tahu bagian mana yang dimaksud.
Sebutkan juga yang tidak termasuk
Bagian ini sering dilewati, padahal justru paling menghemat perselisihan. Dokumen kebutuhan sebaiknya memuat daftar hal yang secara sadar tidak dikerjakan pada tahap ini.
Contohnya: "Pada tahap pertama, sistem belum terhubung dengan aplikasi kepegawaian. Penambahan data pegawai dilakukan lewat impor Excel."
Menuliskan batas dengan jelas bukan berarti mengurangi lingkup, melainkan membuat lingkup itu terlihat. Klien jadi tahu persis apa yang akan diterima, dan kalau ternyata integrasi itu penting, pembahasannya terjadi sekarang saat masih murah, bukan setelah sistem jadi.
Sertakan contoh keluaran, bukan hanya deskripsi
Untuk apa pun yang berbentuk laporan, dokumen, atau cetakan, cara paling efektif adalah melampirkan contoh nyatanya. Ambil laporan yang selama ini dipakai, tandai bagian mana yang harus muncul otomatis dan bagian mana yang boleh berubah.
Satu lampiran contoh laporan biasanya menggantikan tiga halaman penjelasan, dan hampir tidak mungkin ditafsirkan salah. Hal yang sama berlaku untuk format nomor surat, tata letak invoice, atau susunan kolom rekap.
Siapa yang menulis
Idealnya dokumen kebutuhan disusun bersama, dengan vendor sebagai penulis dan pengguna sebagai pemberi isi. Alasannya, vendor tahu pertanyaan apa saja yang harus dijawab agar sistem bisa dibangun, sedangkan pengguna tahu jawabannya.
Yang perlu dihindari adalah dokumen kebutuhan yang ditulis sepenuhnya oleh satu pihak lalu sekadar dimintakan tanda tangan. Kalau ditulis vendor sendiri, isinya cenderung mengikuti apa yang mudah dibangun. Kalau ditulis pengguna sendiri, isinya sering melewatkan hal yang secara teknis harus diputuskan.
Dokumen hidup, bukan dokumen arsip
Terakhir, kebutuhan hampir pasti berubah di tengah jalan, dan itu wajar. Yang penting bukan membekukan dokumen, melainkan memastikan setiap perubahan tercatat beserta dampaknya terhadap jadwal dan biaya.
Perubahan yang disepakati secara lisan lalu tidak dicatat adalah sumber perselisihan paling umum di akhir proyek, ketika kedua pihak mengingat percakapan yang sama dengan cara yang berbeda.