Cara Menyiapkan Brief Proyek Software agar Biaya Jelas

Pertanyaan pertama yang sering diajukan pemilik usaha ke developer adalah 'berapa biaya bikin aplikasi seperti ini?'. Jawaban jujurnya hampir selalu 'tergantung'. Tergantung siapa penggunanya, fitur apa yang wajib ada, sistem apa yang harus tersambung, dan data apa yang sudah tersedia. Brief proyek adalah dokumen singkat yang menjawab hal-hal itu sebelum diskusi harga dimulai.

Brief tidak harus panjang atau teknis. Dua sampai empat halaman dengan bahasa sehari-hari sudah cukup. Yang penting, brief membuat Anda dan developer membayangkan hal yang sama.

Mengapa brief menentukan waktu dan biaya

Developer menghitung waktu dan biaya dari lingkup pekerjaan. Bila lingkupnya kabur, ada dua kemungkinan: penawaran dibuat besar untuk menutup risiko, atau dibuat kecil lalu membengkak di tengah jalan karena muncul 'oh, ternyata perlu ini juga'. Keduanya merugikan Anda. Brief yang jelas memberi dasar yang sama untuk membandingkan penawaran dari beberapa developer, dan menjadi pegangan saat ada permintaan perubahan.

Isi brief yang perlu Anda siapkan

1. Tujuan bisnis. Masalah apa yang ingin diselesaikan, dalam satu atau dua kalimat. Contoh: 'Calon siswa bisa mendaftar dan membayar tanpa menunggu admin membalas chat.'
2. Pengguna. Siapa saja yang akan memakai sistem: pelanggan, admin, staf lapangan, pemilik. Tiap kelompok biasanya butuh tampilan dan hak akses berbeda.
3. Alur utama. Ceritakan langkah demi langkah apa yang dilakukan pengguna, dari membuka website sampai urusan selesai.
4. Fitur wajib dan fitur nanti. Pisahkan yang harus ada saat peluncuran dari yang bisa menyusul.
5. Integrasi. Sistem lain yang harus tersambung, misalnya payment gateway, email, WhatsApp, Google Sheets, atau aplikasi akuntansi.
6. Data. Data apa yang sudah ada, di mana disimpan, dan apakah perlu dipindahkan ke sistem baru.
7. Ukuran keberhasilan. Bagaimana Anda tahu proyek ini berhasil enam bulan setelah dipakai.
8. Batasan. Tenggat yang nyata, rentang anggaran, dan siapa yang berwenang menyetujui hasil.

Untuk ukuran keberhasilan, pilih sesuatu yang bisa diamati, misalnya 'admin tidak lagi mencocokkan transfer secara manual' atau 'semua prospek tercatat di satu tempat'. Ukuran seperti ini membantu developer memahami apa yang paling penting bagi Anda, sekaligus membantu Anda menilai hasil akhirnya.

Pisahkan 'wajib' dan 'nanti'

Daftar keinginan cenderung terus bertambah. Cara paling efektif menjaga biaya adalah bertanya untuk setiap fitur: kalau fitur ini belum ada di hari peluncuran, apakah bisnis tetap bisa berjalan? Bila jawabannya ya, fitur itu masuk daftar 'nanti'.

Misalnya untuk sistem pendaftaran kursus, form pendaftaran, tabel harga, dan pembayaran mungkin wajib. Kode promo, laporan bulanan otomatis, dan aplikasi mobile bisa menunggu versi berikutnya. Versi pertama yang lebih kecil juga lebih cepat dipakai, sehingga Anda segera mendapat masukan dari pengguna sungguhan. Daftar 'nanti' bukan daftar yang dibuang; simpan baik-baik sebagai bahan tahap pengembangan berikutnya.

Integrasi, data, dan konten: bagian yang sering terlupa

Integrasi sering menjadi sumber kejutan biaya. Sebutkan setiap layanan yang harus tersambung, dan siapa pemilik akunnya. Akun payment gateway, domain, email, dan Google sebaiknya atas nama usaha Anda, bukan atas nama developer.

Untuk data, jelaskan apa yang sudah ada dan dalam bentuk apa: spreadsheet, aplikasi kasir, atau catatan kertas. Bila sistem menyimpan data pribadi pelanggan, sampaikan sejak awal agar keamanan dan hak akses ikut dirancang. Pelajari juga UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi dan konsultasikan dengan profesional bila perlu.

Konten juga perlu disiapkan: foto produk, harga, deskripsi, dan teks kebijakan. Di website klien kami, Devans Egg, ada pemeriksaan otomatis yang menahan rilis produksi selama masih ada isian kosong seperti harga. Pemeriksaan semacam ini berguna, tetapi lebih baik lagi bila konten sudah dikumpulkan sejak brief, sehingga peluncuran tidak tertunda menunggu bahan.

Pertanyaan yang perlu Anda ajukan ke developer

• Bagian mana dari brief yang menurut Anda paling berisiko atau paling mahal, dan mengapa?
• Apa saja yang termasuk dan tidak termasuk dalam penawaran ini?
• Bagaimana proses jika saya ingin menambah atau mengubah fitur di tengah proyek?
• Kapan saya bisa mencoba versi awal, dan seberapa sering ada pembaruan progres?
• Siapa pemilik kode, akun, dan data setelah proyek selesai?
• Berapa biaya rutin setelah peluncuran, misalnya hosting, domain, layanan pihak ketiga, dan pemeliharaan?
• Bagaimana data dicadangkan, dan apa yang terjadi bila ada gangguan?

Langkah berikutnya

1. Tulis tujuan bisnis proyek dalam satu kalimat, lalu minta satu orang di tim membacanya dan menjelaskan ulang dengan kata-katanya sendiri.
2. Gambar alur utama pengguna di kertas, sesederhana apa pun.
3. Susun daftar fitur, lalu tandai mana yang wajib dan mana yang nanti.
4. Kumpulkan daftar integrasi, data yang sudah ada, dan bahan konten.
5. Kirim brief yang sama ke setiap developer yang Anda pertimbangkan, supaya penawarannya bisa dibandingkan dengan adil.