Sebagian besar proyek software yang biayanya membengkak sebenarnya sudah bermasalah sebelum satu baris kode pun ditulis. Kerusakannya terjadi di dokumen pertama, yaitu saat bisnis menjelaskan apa yang mereka butuhkan. Mempelajari cara menulis brief proyek software adalah asuransi proyek paling murah yang ada, dan hampir tidak ada yang mengajarkannya.

Saya sudah lebih dari satu dekade berada di sisi penerima brief semacam ini. Polanya konsisten: bisnis menulis terlalu sedikit ("kami butuh aplikasi seperti Gojek tapi untuk laundry, berapa biayanya?") atau menulis hal yang salah sepenuhnya, yaitu spesifikasi detail layar dan tombol untuk solusi yang sudah mereka bayangkan sendiri, tanpa penjelasan masalah apa yang sebenarnya ingin diselesaikan.

Kedua pola kegagalan ini menghasilkan hal yang sama: developer membangun apa yang tertulis, bisnis mendapatkan apa yang diminta, dan tidak ada satu pun yang cocok dengan apa yang sebenarnya dibutuhkan. Setelah itu muncul change request, dan change request adalah tempat di mana anggaran mati perlahan.

Jelaskan penyakitnya, bukan resepnya

Prinsip paling penting dalam cara menulis brief proyek software: jelaskan masalah dan hasil yang Anda butuhkan, lalu biarkan developer yang mengusulkan solusinya. Anda adalah ahli untuk bisnis Anda sendiri. Developer adalah ahli untuk menentukan bentuk software mana yang cocok untuk masalah tertentu. Brief yang baik menghormati pembagian peran ini.

Bandingkan dua versi permintaan yang sama:

  • Mendikte solusi: "Buatkan kami aplikasi mobile dengan halaman login, dashboard dengan 6 ikon menu, modul formulir, dan push notification."
  • Menjelaskan masalah: "30 teknisi lapangan kami melaporkan penyelesaian pekerjaan lewat foto WhatsApp. Staf kantor mengetik ulang laporan tersebut, yang memakan waktu dua jam setiap hari dan menghasilkan kesalahan yang berujung ke invoice. Kami butuh laporan pekerjaan masuk dalam format terstruktur, dan proses ketik ulang ini harus hilang."

Brief pertama mengunci developer pada tebakan Anda. Mungkin aplikasi memang solusi yang tepat, mungkin formulir web sederhana justru lebih cocok dan bisa selesai dalam waktu setengahnya, atau mungkin solusinya adalah alur kerja terintegrasi WhatsApp karena teknisi Anda akan menolak menginstal aplikasi apa pun. Developer yang membaca brief kedua bisa memberi tahu Anda mana yang tepat. Developer yang membaca brief pertama hanya bisa mengutip apa yang tertulis.

Mendikte solusi juga memindahkan risiko ke arah yang salah. Ketika Anda menentukan resepnya, developer akan mengirimkan resep itu meskipun tidak menyembuhkan apa pun, dan secara kontrak mereka benar. Ketika Anda menentukan penyakitnya, developer yang bertanggung jawab atas resepnya, dan Anda bisa menuntut mereka atas hasilnya.

Enam bagian yang wajib ada di setiap brief

Jaga brief tetap dua hingga tiga halaman. Panjang bukan berarti mendalam. Enam bagian berikut ini:

  1. Konteks bisnis. Tiga atau empat kalimat: bisnis Anda bergerak di bidang apa, ukurannya, dan bagaimana bagian operasional yang terdampak berjalan saat ini. Developer akan membuat puluhan asumsi kecil selama proses pembangunan; konteks membuat asumsi tersebut mendekati kenyataan.
  2. Masalahnya. Apa yang menyakitkan, siapa yang terdampak, seberapa sering, dan berapa biayanya. Angka lebih meyakinkan daripada kata sifat: "penghitungan stok salah sekitar 15 persen dari waktu, menyebabkan kerugian penjualan sekitar Rp 20 juta per bulan" memberi developer target sekaligus logika anggaran Anda.
  3. Penggunanya. Siapa yang akan benar-benar menggunakan sistem ini, seberapa nyaman mereka dengan teknologi, dan di mana mereka bekerja. "Staf gudang menggunakan Android bersama dengan sarung tangan, di area dengan wifi tidak stabil" mengubah total desain dibandingkan dengan "admin kantor menggunakan desktop." Detail lingkungan seperti konektivitas pernah menenggelamkan seluruh proyek, seperti pelajaran soal mode offline dalam studi kasus aplikasi lapangan multifinance ini.
  4. Metrik keberhasilan. Satu atau dua pernyataan terukur yang mendefinisikan "selesai dan berfungsi." "Proses ketik ulang hilang; laporan pekerjaan terlihat oleh kantor dalam 15 menit setelah selesai dikerjakan." Kalimat ini menjadi acceptance test Anda saat serah terima, sekaligus pembelaan Anda terhadap sistem yang secara teknis selesai tapi tidak dipakai siapa pun.
  5. Non-goals yang eksplisit. Apa yang sengaja tidak dimasukkan ke dalam proyek ini. Sering diremehkan dan biasanya tidak ada.
  6. Batasan dan konstrain. Rentang anggaran, tenggat waktu beserta alasannya, sistem yang harus terhubung dengan solusi ini, dan persyaratan regulasi atau kerahasiaan apa pun. Ya, sebutkan rentang anggarannya. Menyembunyikannya tidak membuat Anda mendapat harga lebih baik; itu justru menghasilkan proposal yang dirancang untuk anggaran yang tidak Anda miliki.

Non-goals: bagian yang menyelamatkan anggaran

Jika brief Anda hanya boleh punya satu kekuatan yang tidak biasa, jadikan ini. Mencantumkan apa yang di luar scope lebih efektif mencegah pembengkakan biaya dibandingkan segala hal lain digabungkan, karena scope creep tidak pernah datang dengan pemberitahuan. Ia muncul lewat serangkaian kalimat yang masing-masing terdengar masuk akal: "sekalian saja, bisa tidak kalau ditambah..."

Tulis non-goals secara konkret:

  • "Fase 1 hanya mencakup gudang Tangerang. Cabang lain di luar scope."
  • "Tidak ada integrasi dengan sistem akuntansi di fase ini; file ekspor bulanan sudah cukup."
  • "Hanya Bahasa Indonesia. Tidak ada antarmuka Bahasa Inggris."
  • "Tidak ada fitur yang menghadap pelanggan. Hanya untuk staf internal."

Setiap baris ini mematikan satu argumen di masa depan. Ketika momen "sekalian saja, bisa tidak" itu datang, dan pasti akan datang, percakapannya berubah menjadi "itu item fase 2, mari kita hitung harganya terpisah" yang tenang, bukan negosiasi tegang soal apa yang sebelumnya dianggap sudah termasuk. Non-goals melindungi developer dari kerja tanpa bayaran, dan melindungi Anda dari linimasa yang diam-diam membengkak dua kali lipat. Bagian ini adalah kalimat paling kolaboratif dalam seluruh dokumen.

Kerangka isian siap pakai

Salin ini dan ganti bagian dalam kurung:

Tentang kami: Kami adalah perusahaan [industri] dengan [jumlah staf / jumlah cabang / jumlah pelanggan]. Saat ini, [proses yang dimaksud] berjalan seperti ini: [2 sampai 3 kalimat].

Masalahnya: [Siapa] kesulitan dengan [apa], yang terjadi [seberapa sering] dan menyebabkan kerugian [waktu / uang / kesalahan / pelanggan].

Pengguna: Sistem ini akan digunakan oleh [peran], yang [tingkat kenyamanan dengan teknologi] dan bekerja di [lingkungan, perangkat, konektivitas].

Keberhasilan terlihat seperti: Setelah peluncuran, [hasil terukur 1]. Kami akan tahu ini berhasil ketika [hasil terukur 2].

Di luar scope: Proyek ini TIDAK mencakup [item], [item], atau [item].

Batasan: Rentang anggaran [X sampai Y]. Dibutuhkan sebelum [tanggal] karena [alasan]. Harus terhubung dengan [sistem yang sudah ada]. [Catatan kerahasiaan atau kepatuhan apa pun.]

Brief dengan bentuk seperti ini, diisi secara jujur, menempatkan Anda jauh di depan mayoritas brief pertama yang pernah saya terima. Ini juga menyaring vendor: developer yang membacanya dan langsung memberi harga tetap tanpa satu pun pertanyaan lanjutan berarti belum benar-benar memahami masalah Anda. Developer yang layak dipekerjakan akan kembali dengan pertanyaan, dan kemungkinan besar akan menantang sebagian dari kerangka berpikir Anda. Gesekan itu adalah bagian dari layanannya.

Kesimpulan

Cara menulis brief proyek software, diringkas: dua sampai tiga halaman, enam bagian, masalah dan hasil alih-alih layar dan fitur, satu definisi keberhasilan yang terukur, dan daftar non-goals yang benar-benar Anda tegakkan. Jelaskan penyakitnya dan biarkan developer meresepkan solusinya.

Satu jam yang Anda habiskan untuk menulisnya dengan benar adalah jam paling bernilai dalam seluruh proyek. Setiap ambiguitas yang Anda hilangkan di atas kertas tidak memakan biaya apa pun; ambiguitas yang sama jika baru ditemukan di bulan ketiga akan menghabiskan waktu berminggu-minggu dan uang sungguhan. Dan jika brief ini justru mengungkap bahwa Anda belum yakin masalah mana yang perlu diselesaikan lebih dulu, itu adalah pertanyaan strategi yang layak diselesaikan sebelum bicara dengan vendor mana pun, satu hal yang saya bahas di Why Your Business Needs a Technology Strategy, Not Just a Website. Jika Anda ingin menguji draf brief bersama seseorang yang sudah membaca ratusan brief semacam ini, saya terbuka untuk percakapan itu.