Cara Menyusun Kebutuhan Aplikasi Sebelum Menghubungi Developer

Mengirim pesan “saya mau bikin aplikasi seperti sistem X, berapa biayanya?” biasanya menghasilkan jawaban awal yang sangat kasar. Developer belum tahu siapa yang akan memakai aplikasi, proses apa yang ingin diubah, jumlah transaksi, atau apakah sistem perlu mengambil data dari software lain. Jawaban harga yang terlalu cepat bisa memberi rasa pasti padahal banyak asumsi belum diperiksa.

Brief awal tidak harus berupa dokumen puluhan halaman. Satu sampai tiga halaman yang berisi proses dan keputusan penting sering lebih berguna daripada daftar menu panjang tanpa konteks.

1. Jelaskan masalah yang ingin diselesaikan

Mulai dari kejadian yang bisa diamati. Contohnya, “admin memasukkan order dari WhatsApp ke spreadsheet, lalu staf gudang mengetik ulang detail yang sama sehingga jumlah barang kadang berbeda.” Hindari berhenti pada solusi, seperti “kami butuh aplikasi order”. Jelaskan apa yang salah atau lambat pada proses sekarang dan akibatnya bagi bisnis.

Jika memungkinkan, catat frekuensi masalah selama beberapa minggu: berapa order perlu dikoreksi, berapa lama laporan dibuat, atau di tahap mana pelanggan paling sering menunggu. Angka awal tidak harus sempurna, tetapi harus dapat ditelusuri. Discovery yang baik mencari tahu masalah, konteks pengguna, batasan, dan biaya dari kondisi saat ini sebelum membangun solusi (GOV.UK, How the discovery phase works).

2. Sebutkan siapa yang menggunakan aplikasi

Daftar peran, bukan hanya nama jabatan. Seorang admin bisa membuat order; supervisor mengubah harga dengan persetujuan; petugas gudang memproses barang; pemilik melihat laporan. Untuk tiap peran, jelaskan informasi yang perlu dilihat, tindakan yang boleh dilakukan, dan keputusan yang harus disetujui pihak lain.

Pembagian ini akan memengaruhi layar, hak akses, dan alur persetujuan. Jika semua pengguna diberi akses sama, data sensitif mungkin terlihat oleh orang yang tidak membutuhkannya. Sebaliknya, aturan yang terlalu ketat dapat membuat staf kembali ke spreadsheet untuk menyelesaikan pekerjaan.

3. Gambarkan proses sekarang dari awal sampai akhir

Gunakan langkah bernomor atau bagan sederhana. Misalnya: pelanggan mengirim pesanan, admin memeriksa stok, pelanggan menyetujui penawaran, pembayaran diverifikasi, gudang menyiapkan barang, lalu keuangan menerbitkan invoice. Tandai di mana data dicatat, siapa yang memindahkannya, dan berapa lama proses biasanya berlangsung.

Jangan hanya mencatat jalur ideal. Tambahkan keadaan yang sering terjadi: stok tidak tersedia, pelanggan mengubah jumlah, pembayaran kurang, barang diretur, atau koneksi sistem gagal. Developer perlu mengetahui aturan apa yang harus dilakukan pada kasus tersebut agar estimasi tidak hanya mencakup skenario mulus.

4. Tentukan kebutuhan wajib dan fitur yang bisa menunggu

Kelompokkan permintaan dengan metode yang mudah dibicarakan. Metode MoSCoW membagi kebutuhan menjadi Must have, Should have, Could have, dan Won't have for now. Panduan dari Washington State menggunakan metode ini untuk memperjelas prioritas dan menekankan bahwa kategori “must have” harus dibatasi pada hal yang benar-benar tidak bisa ditinggalkan (MoSCoW Method).

Sebagai contoh, pencatatan order dan status pemenuhan mungkin wajib untuk versi pertama, sedangkan dashboard analitik lanjutan dapat menunggu. Jangan masukkan semua permintaan ke kategori wajib hanya untuk memastikan fitur tersebut tidak dilupakan. Jika semuanya menjadi prioritas tertinggi, tim tidak memiliki dasar untuk mengatur urutan pengerjaan.

5. Catat data dan sistem yang sudah dipakai

Sebutkan spreadsheet, software akuntansi, marketplace, sistem pembayaran, atau database yang saat ini menjadi sumber data. Sertakan contoh format data jika boleh dibagikan, jumlah perkiraan baris, dan masalah kualitas yang sudah diketahui seperti kode ganda atau kolom kosong. Jangan mengirim kata sandi atau kredensial melalui brief.

Untuk integrasi, jelaskan tujuan bisnisnya, bukan hanya nama API. Apakah aplikasi perlu membaca saldo stok, mengirim invoice, mengambil status pembayaran, atau sinkronisasi pelanggan? Developer kemudian bisa memeriksa ketersediaan API dan aksesnya. Biaya integrasi tidak dapat dinilai hanya dari nama layanan yang disebutkan.

6. Tentukan hasil yang menandakan proyek berhasil

Tulis ukuran sebelum pengembangan dimulai. Misalnya, waktu untuk membuat laporan turun dari rata-rata dua hari menjadi satu hari, setiap order memiliki ID, atau seluruh perubahan stok punya riwayat pengguna dan waktu. Target spesifik lebih berguna daripada janji “aplikasi harus efisien”. Jangan memilih ukuran yang mudah terlihat tetapi tidak mencerminkan masalah utama.

Jika baseline belum tersedia, masukkan kegiatan pengukuran ke pekerjaan awal. GOV.UK juga menekankan pentingnya memahami kebutuhan pengguna dan menggunakan data untuk menguji asumsi, bukan mengandalkan intuisi saja (Understand user needs).

7. Bicarakan batasan bisnis sejak awal

Informasikan kisaran anggaran, target tanggal jika memang terikat kebutuhan tertentu, kondisi perangkat, kualitas jaringan, kebijakan keamanan internal, dan ketersediaan orang yang akan memberikan keputusan. Anggaran membantu tim menyusun trade-off, bukan berarti vendor harus menghabiskan semua anggaran. Target peluncuran pun perlu dibahas sebagai kendala yang bisa memengaruhi ruang lingkup dan risiko.

Minta vendor menuliskan asumsi yang masih perlu dibuktikan dan keputusan yang perlu dibuat oleh pihak bisnis. Jika estimasi sangat tidak pasti, pertimbangkan tahap discovery atau prototipe untuk mengurangi ketidakpastian sebelum berkomitmen pada seluruh proyek.

Format brief satu halaman

Anda bisa menyusun ringkasan dengan urutan berikut:

• Masalah: apa yang sekarang sering salah, lambat, mahal, atau sulit dilacak.
• Pengguna: peran yang menggunakan sistem dan tugas mereka.
• Alur saat ini: langkah dari awal sampai akhir serta pengecualiannya.
• Hasil yang diinginkan: perubahan yang bisa diukur.
• Kebutuhan wajib: fungsi yang harus ada untuk alur utama berjalan.
• Data dan integrasi: sumber data, sistem terkait, dan format yang tersedia.
• Batasan: anggaran, waktu, perangkat, keamanan, dan kebijakan.
• Pertanyaan terbuka: hal yang perlu dipelajari sebelum biaya dapat dipastikan.

Brief yang baik tidak mengunci Anda pada satu desain teknis. Ia membantu developer memeriksa apakah ide awal memang menyelesaikan masalah, fitur mana yang perlu dibuat lebih dulu, dan risiko mana yang harus dibahas sebelum penawaran final.

Sebelum mengirim brief, minta orang yang menjalankan proses membaca dokumen tersebut. Jika mereka tidak mengenali cara kerja sehari-hari di dalamnya, developer kemungkinan juga akan menerima gambaran yang kurang tepat. Dengan versi brief yang sudah diperiksa bersama, konsultasi dengan digitalisasi.app atau penyedia lain dapat berfokus pada pilihan solusi, bukan menghabiskan waktu menebak masalah dasarnya.

Referensi

• GOV.UK Service Manual, How the discovery phase works
• GOV.UK Service Manual, Understand user needs
• Washington State, MoSCoW Method

Referensi diakses 25 Oktober 2026.