Penawaran dari vendor software hanya sebaik informasi yang mereka terima. Jika kebutuhan disampaikan lewat obrolan singkat atau satu pesan WhatsApp, tiap vendor akan mengisi kekosongan dengan asumsinya sendiri. Hasilnya penawaran yang sulit dibandingkan dan proyek yang berubah arah di tengah jalan. Brief proyek software yang disusun dengan baik mencegah sebagian besar masalah ini.
Brief tidak harus berupa dokumen teknis. Isinya penjelasan tentang bisnis Anda, masalah yang ingin diselesaikan, dan batasan yang perlu diketahui vendor. Tulisan ini membahas apa saja yang perlu ada di dalamnya, lengkap dengan kerangka yang bisa Anda pakai langsung.
Fungsi brief dalam proyek software
Brief punya tiga kegunaan. Ia membantu tim Anda sendiri menyepakati apa yang sebenarnya dibutuhkan, sebelum vendor mana pun dilibatkan. Ia membuat semua vendor membaca kebutuhan yang sama, sehingga penawaran bisa dibandingkan secara adil. Ia juga menjadi titik awal tahap discovery, sehingga waktu pertemuan dipakai untuk membahas detail, tidak lagi untuk menjelaskan dasar-dasar bisnis Anda.
Brief yang baik biasanya cukup beberapa halaman. Lebih penting jelas dan jujur daripada panjang.
Siapa yang menulisnya juga berpengaruh. Biasanya cukup satu orang yang paham operasional sehari-hari, misalnya manajer operasional atau kepala admin. Setelah itu draf dibaca ulang oleh pemilik usaha dan satu atau dua calon pengguna. Proses ini sering memunculkan perbedaan pendapat di internal, dan lebih baik perbedaan itu muncul sekarang daripada setelah vendor mulai bekerja.
Isi utama brief proyek software
Tujuan bisnis
Mulailah dari alasan proyek ini ada. Tuliskan masalah yang ingin diselesaikan dan seperti apa kondisi yang dianggap berhasil. Contohnya, perusahaan jasa kebersihan yang ingin jadwal petugas dan laporan kunjungan tidak lagi direkap manual dari grup WhatsApp setiap akhir minggu. Tujuan seperti ini membantu vendor memprioritaskan fitur.
Pengguna dan perannya
Sebutkan siapa saja yang akan memakai aplikasi dan apa yang mereka kerjakan. Admin kantor, petugas lapangan, supervisor, pelanggan, dan pemilik usaha punya kebutuhan yang berbeda. Perkirakan juga jumlahnya secara kasar, dan perangkat yang mereka pakai, misalnya ponsel Android di lapangan dan laptop di kantor.
Proses yang berjalan sekarang
Jelaskan alur kerja saat ini langkah demi langkah, termasuk bagian yang masih memakai kertas, spreadsheet, atau chat. Di kantor notaris, misalnya, alurnya bisa dimulai dari klien menyerahkan dokumen, staf memeriksa kelengkapan, sampai akta selesai dan diarsipkan. Lampirkan contoh formulir dan laporan yang dipakai. Bagian ini sering menjadi bahan paling berguna bagi vendor.
Wajib ada dan bisa menyusul
Tidak semua keinginan perlu masuk ke versi pertama. Pisahkan kebutuhan menjadi dua kelompok. Kebutuhan wajib adalah hal yang tanpanya aplikasi tidak bisa dipakai untuk pekerjaan inti. Kebutuhan yang bisa menyusul adalah hal yang berguna, tetapi pekerjaan tetap bisa berjalan tanpanya untuk sementara.
Untuk sebuah EO, pendaftaran peserta dan check-in di lokasi mungkin wajib, sedangkan laporan analitik dan integrasi ke software akuntansi bisa menyusul. Pemisahan ini membantu vendor menyusun tahapan kerja dan membantu Anda mengendalikan anggaran. Jika semuanya ditandai wajib, vendor tidak punya dasar untuk menyarankan versi pertama yang lebih ramping.
Integrasi, data, dan batasan
Daftar sistem yang sudah dipakai dan perlu terhubung, misalnya software akuntansi, payment gateway, marketplace, atau WhatsApp. Jika tahu, sebutkan apakah sistem itu punya API. Informasi ini sangat memengaruhi besarnya pekerjaan.
Jelaskan juga data yang ada sekarang. Di mana disimpan, kira-kira seberapa banyak, dan apakah perlu dipindahkan ke sistem baru. Jika aplikasi akan menyimpan data pribadi pelanggan, pasien, atau karyawan, tuliskan hal itu dengan jelas. UU Pelindungan Data Pribadi (UU No. 27 Tahun 2022) membuat kebutuhan keamanan ini perlu dibahas sejak awal.
Terakhir, tuliskan batasan yang perlu diketahui vendor. Rentang anggaran, target waktu yang terkait dengan kejadian tertentu seperti pembukaan cabang, kebijakan internal soal penyimpanan data, atau keharusan memakai layanan cloud tertentu. Menyebutkan rentang anggaran membantu vendor mengusulkan ruang lingkup yang realistis.
Kerangka brief yang bisa Anda pakai
Berikut kerangka sederhana yang bisa disalin dan diisi:
- Latar belakang perusahaan, berupa bidang usaha, jumlah cabang atau tim, dan cara kerja secara umum.
- Masalah yang ingin diselesaikan dan tanda keberhasilannya.
- Pengguna, peran masing-masing, perkiraan jumlah, dan perangkat yang dipakai.
- Alur kerja saat ini, dengan lampiran contoh formulir, laporan, atau tangkapan layar.
- Kebutuhan wajib untuk versi pertama.
- Kebutuhan yang bisa menyusul.
- Sistem yang harus terhubung dan informasi API jika ada.
- Data yang ada sekarang, rencana migrasi, dan jenis data pribadi yang akan disimpan.
- Batasan berupa rentang anggaran, target waktu, dan kebijakan internal.
- Kontak penanggung jawab di sisi Anda yang bisa mengambil keputusan.
Tidak semua bagian harus terisi sempurna. Menuliskan "belum tahu" pada bagian tertentu tetap lebih baik daripada mengosongkannya, karena vendor jadi tahu hal itu perlu dibahas.
Langkah setelah brief selesai
Brief yang sudah jadi bisa langsung dikirim ke beberapa vendor, atau dibahas lebih dulu dengan pihak independen untuk menilai apakah rencananya masuk akal. Tim Averoa menyediakan review arsitektur, analisis build vs buy, dan penyusunan roadmap teknologi sebelum anggaran terpakai. Penjelasannya ada di halaman Konsultasi Teknologi.
