Cara Bikin Brief Aplikasi untuk Developer Biar Nggak Revisi Terus (Isi + Contoh)

Kamu sudah bayar DP. Tiga minggu kemudian developer kirim link, kamu buka, dan reaksi pertamamu: "lho, kok bukan gini?" Dia nggak curang. Dia mengerjakan persis yang dia tangkap dari obrolan WhatsApp kalian. Yang nggak pernah pindah cuma satu: gambar yang ada di kepalamu.

Habis itu masuk babak revisi. Ronde satu masih ramah. Ronde tiga mulai muncul kalimat "itu di luar scope ya, Pak". Ronde lima kamu bayar lagi. Yang bikin mahal bukan sifat developernya, tapi karena dari awal nggak ada satu dokumen pun yang bisa dipakai memutuskan siapa yang benar.

Brief aplikasi untuk developer itu dokumen yang menutup celah tadi. Isi panduan ini ada tiga: daftar bagian yang harus ada dan bisa kamu salin, satu contoh brief yang sudah jadi, dan daftar kalimat yang paling sering jadi bibit revisi tanpa ujung beserta gantinya.

Kenapa revisinya nggak berhenti-berhenti

Revisi beranak-pinak hampir selalu berasal dari satu hal: nggak pernah ada kesepakatan tertulis soal kapan sebuah fitur boleh disebut selesai. Selama "selesai" masih soal rasa, dua orang yang sama-sama jujur bisa punya jawaban yang beda, dan yang menang biasanya yang punya dokumen.

Contohnya kata "laporan penjualan". Di kepalamu: bisa disaring per tanggal, ada total per kasir, bisa diunduh ke Excel buat dikirim ke akuntan. Di kepala developer: satu tabel berisi daftar transaksi. Waktu kamu minta saringan tanggal, buat kamu itu kekurangan yang harus dibenerin. Buat dia itu pekerjaan baru yang belum dihitung.

Coba cek kesepakatanmu: ada batasan jumlah ronde revisi nggak di situ? Kalau ada, setiap salah paham yang tadinya cuma beda tafsir langsung berubah jadi angka di tagihan berikutnya. Kalau nggak ada, developernya yang menanggung, dan biasanya dia menanggungnya dengan cara memelan-pelankan pekerjaanmu.

Brief itu bukan chat WhatsApp yang panjang

Chat itu urut waktu, bukan urut topik. Waktu ada perselisihan, dua pihak sama-sama scroll ke atas mencari pesan yang mendukung versinya masing-masing, dan dua-duanya ketemu. Ada pesan kamu bulan lalu yang bilang begini, ada balasan dia minggu lalu yang bilang begitu. Nggak ada yang bisa dipakai memutus.

Brief itu satu berkas, satu versi, yang dua-duanya sepakati sebelum kerja mulai. Kalau ada yang berubah, briefnya yang diperbarui, bukan ditambal di chat. Nama formalnya bermacam-macam: scope of work, dokumen kebutuhan, atau PRD. Isinya sama saja.

Ada untung kedua yang sering kelewat: brief bikin penawaran harga jadi bisa dibandingkan. Kirim berkas yang sama ke tiga vendor, angka yang balik baru setara. Tanpa itu, yang termurah biasanya cuma yang paling sedikit menebak, dan sisanya menyusul jadi biaya tambahan di tengah jalan.

Isi brief aplikasi: bagian yang wajib ada

Sepuluh bagian di bawah cukup buat proyek kecil sampai menengah. Tulis pakai bahasa sehari-hari. Nggak usah pakai istilah teknis yang kamu sendiri nggak paham, karena nanti kamu juga yang nggak bisa mengecek hasilnya.

1. Masalah yang mau dibereskan, dan bagaimana kondisinya sekarang tanpa aplikasi.
2. Siapa yang pakai. Berapa orang, kerjanya apa, seberapa terbiasa mereka pakai HP atau komputer.
3. Daftar fitur yang dipisah dua: wajib ada di versi pertama, dan boleh menyusul nanti.
4. Alur tiap fitur wajib, ditulis langkah demi langkah dari layar pertama sampai selesai.
5. Aturan dan batasan. Mana yang wajib diisi, siapa boleh lihat apa, apa yang terjadi kalau isinya salah.
6. Data. Apa saja yang disimpan, contoh isinya, dan data lama mau dipindah atau mulai dari nol.
7. Perangkat dan tampilan. Dibuka dari HP atau laptop, browser apa, ada contoh tampilan yang kamu suka atau tidak.
8. Sambungan ke luar. WhatsApp, pembayaran, printer struk, spreadsheet, atau memang tidak ada sama sekali.
9. Yang sengaja di luar lingkup. Hal-hal yang kamu putuskan tidak dikerjakan di versi ini.
10. Serah terima. Apa saja yang kamu terima di akhir, dan siapa pemilik akun serta kode sumbernya.

Bagian sembilan dan sepuluh itu yang paling sering hilang, dan justru dua-duanya yang paling sering jadi sumber ribut. Nanti dibahas lagi di bawah.

Contoh brief yang sudah jadi

Kerangka kosong gampang dibaca, susah diisi. Jadi ini versi yang sudah terisi buat satu usaha laundry kiloan. Angka dan namanya karangan, tinggal ganti sesuai punyamu, tapi tingkat detailnya segini yang bikin developer berhenti menebak.

BRIEF APLIKASI PENCATATAN ORDER LAUNDRY (contoh)

1. MASALAH
Order dicatat di buku tulis. Pelanggan sering nanya lewat WA "cucian
saya sudah selesai belum", kasir harus bolak-balik buka buku. Rekap
harian dikerjakan malam dan sering selisih sama uang di laci.

2. YANG PAKAI
- Kasir, 2 orang, shift pagi dan sore. Pakai HP Android. Terbiasa
  WhatsApp, tidak terbiasa Excel.
- Pemilik, 1 orang. Buka dari laptop, cuma lihat rekap.

3. FITUR WAJIB DI VERSI PERTAMA
a. Catat order masuk: nama, nomor HP, berat (kg), jenis layanan,
   tanggal masuk, perkiraan selesai.
b. Ubah status order: Diterima > Dicuci > Selesai > Diambil.
c. Cari order pakai nama atau nomor HP.
d. Rekap harian: jumlah order, total kg, total rupiah, per shift.

   FITUR YANG BOLEH MENYUSUL (bukan versi pertama)
e. Kirim WA otomatis waktu status berubah jadi Selesai.
f. Laporan bulanan berbentuk grafik.

4. ALUR "CATAT ORDER MASUK"
1) Kasir buka halaman Order Baru.
2) Isi nama dan nomor HP. Kalau nomornya pernah masuk, namanya
   terisi otomatis.
3) Isi berat, pilih layanan. Total harga muncul sendiri.
4) Tekan Simpan. Order langsung muncul di daftar Hari Ini dengan
   status Diterima.
5) Form balik kosong, siap buat order berikutnya.

5. ATURAN
- Nama, nomor HP, berat, dan layanan wajib diisi. Order tidak bisa
  disimpan kalau ada yang kosong.
- Harga per kg: cuci setrika 7.000, cuci saja 5.000, setrika saja
  5.000. Harga disimpan di satu tempat yang bisa diubah pemilik
  sendiri tanpa minta tolong developer.
- Berat di bawah 1 kg tetap dihitung 1 kg.
- Kasir tidak boleh menghapus order. Kalau salah, statusnya diubah
  jadi Batal dan wajib mengisi alasan.
- Halaman rekap cuma bisa dibuka pemilik.

6. DATA
- Disimpan: pelanggan (nama, nomor HP) dan order (nomor order, berat,
  layanan, harga, status, waktu tiap perubahan status, nama kasir
  yang input).
- Catatan lama di buku tulis TIDAK dipindah. Mulai dari nol per
  tanggal aplikasi dipakai.

7. PERANGKAT
- Kasir: Chrome di HP Android layar 6 inci. Tombol harus cukup besar
  buat dipencet sambil berdiri.
- Pemilik: Chrome di laptop.
- Wifi toko kadang putus. Kalau koneksi hilang waktu menyimpan, harus
  muncul peringatan jelas, bukan gagal diam-diam.

8. SAMBUNGAN KE LUAR
Versi pertama tidak ada. Tanpa WhatsApp, tanpa printer struk, tanpa
pembayaran online.

9. DI LUAR LINGKUP VERSI INI
- Tidak ada aplikasi yang diunduh dari Play Store. Cukup dibuka lewat
  browser.
- Tidak ada multi cabang.
- Tidak ada absensi dan hitung gaji karyawan.

10. SERAH TERIMA
- Kode sumber diserahkan ke akun GitHub milik pemilik.
- Semua akun (hosting, domain, database) didaftarkan pakai email
  pemilik, bukan email developer.
- Panduan pakai 1 halaman, plus rekaman layar 5 menit buat kasir.
- Perbaikan bug gratis 30 hari setelah serah terima.

11. "SELESAI" ARTINYA
Fitur disebut selesai kalau kasir bisa melakukan ini sendiri dari HP
nya, tanpa dibantu developer:
- Mencatat 1 order baru sampai muncul di daftar Hari Ini.
- Mengubah status order itu sampai Diambil.
- Menemukan order itu lewat pencarian nomor HP.
- Pemilik buka rekap hari itu, angkanya cocok dengan order tadi.

Panjangnya kira-kira dua halaman. Bukan dokumen tebal, tapi hampir semua pertanyaan yang biasanya muncul di tengah pengerjaan sudah dijawab di depan, waktu jawabannya masih gratis.

Kalimat yang bikin kamu bayar dua kali

Ini bagian yang paling menentukan. Kalimat kabur kelihatan nggak berbahaya waktu ditulis, dan baru menagih ongkosnya dua bulan kemudian. Kiri yang bikin repot, kanan gantinya.

• "Bikin yang simpel dan gampang dipakai." Ganti: "Kasir bisa menyimpan satu order baru dari satu halaman saja, tanpa scroll, tanpa pindah menu."
• "Tampilannya yang modern dan enak dilihat." Ganti: "Ikuti tampilan situs ini (kirim tautannya). Warna utama kode ini. Kalau mau beda, kirim gambarnya dulu sebelum dikerjakan."
• "Nanti ada laporannya juga." Ganti: "Satu halaman rekap: pilih rentang tanggal, keluar jumlah order, total kg, dan total rupiah, dengan tombol unduh ke Excel."
• "Datanya otomatis masuk." Ganti: "Begitu kasir menekan Simpan, barisnya nambah di file spreadsheet yang saya sebutkan paling lambat 5 detik. Kalau gagal, muncul tulisan merah 'gagal simpan, coba lagi'."
• "Pokoknya mirip aplikasi yang itu." Ganti: "Dari aplikasi itu saya cuma mau dua hal: cara mencari lewat satu kotak pencarian, dan daftar yang bisa digeser. Sisanya nggak usah ditiru."
• "Yang penting cepat." Ganti: "Halaman daftar order kebuka di bawah 3 detik pakai internet HP, dengan 500 order di dalamnya."
• "Bisa dipakai banyak orang barengan." Ganti: "5 kasir bisa buka bersamaan. Kalau dua orang menyimpan di detik yang sama, dua-duanya masuk dan tidak ada yang ketimpa."
• "Segitu dulu, nanti kita tambah kalau perlu." Ganti: "Yang di luar daftar fitur wajib dihitung sebagai tambahan. Setiap tambahan ditulis terpisah, ada harga dan tanggalnya sendiri, dan disetujui tertulis sebelum dikerjakan."
• "Bebas, terserah kamu aja yang penting bagus." Ganti: "Kalau ada yang belum saya sebut, tanya dulu ke saya. Jangan diputuskan sendiri."

Perhatikan polanya. Yang berbahaya itu kata rasa: simpel, modern, bagus, cepat, rapi. Rasa nggak bisa diadu di meja. Waktu kamu bilang belum simpel dan dia bilang sudah simpel, nggak ada wasit.

Kata kedua yang mahal adalah "otomatis". Kata itu menyembunyikan tiga pertanyaan sekaligus: dipicu oleh apa, hasilnya masuk ke mana, dan apa yang terjadi kalau gagal. Yang ketiga hampir nggak pernah ditanya orang, padahal justru situ tempat bug-nya nanti muncul.

Terakhir, kata jumlah tanpa angka. "Banyak data", "beberapa pengguna", "file besar". Buat kamu banyak itu 500 baris, buat developer bisa 5 juta, dan cara membuatnya beda jauh.

Sepakati arti "selesai" sebelum kerja dimulai

Bagian nomor 11 di contoh tadi bentuknya daftar tes, bukan pendapat. Isinya hal-hal yang bisa kamu coba sendiri, dan hasilnya cuma dua: jalan atau nggak jalan. Susunnya dari sudut pandang orang yang nanti memakai, bukan dari sudut pandang mesin.

Cara menyusun daftar semacam ini dibahas lebih rinci di panduan user story dan acceptance criteria. Kalau proyeknya cukup besar, memecah fitur jadi tugas-tugas kecil bikin kamu bisa mengecek per potongan, bukan menunggu tiga bulan lalu kaget di akhir.

Sambungkan daftar tes itu ke termin pembayaran. Bayar per potongan yang sudah lulus tes, bukan per minggu berlalu. Dengan begitu "sudah 80 persen, Pak" berhenti jadi kalimat yang bisa diulang tiap minggu.

Bagian di luar fitur yang paling sering bikin ribut

Hal-hal ini nggak enak dibahas waktu hubungan masih mesra. Tapi kalau dibahas belakangan, posisimu selalu lebih lemah, karena aplikasinya sudah jalan dan kunci-kuncinya ada di tangan orang lain.

• Kode sumbernya milik siapa setelah lunas, dan diserahkan lewat apa. Kalau ini nggak ditulis, kamu bisa punya aplikasi yang cuma bisa diutak-atik oleh satu orang di dunia.
• Akun hosting, domain, dan database didaftarkan pakai email siapa. Jawaban yang aman: emailmu, sejak hari pertama.
• Biaya bulanan setelah jadi berapa, dan siapa yang bayar. Minta perkiraannya tertulis, jangan cuma "kecil kok, Pak".
• Perbaikan bug gratis sampai kapan, dan apa bedanya bug dengan permintaan baru. Sepakati contohnya sekalian, biar nggak jadi debat nanti.
• Apa yang kamu terima di hari serah terima selain aplikasinya. Panduan pakai, rekaman layar, dan cara menaikkan versi baru kalau nanti ganti orang.

Waktu membandingkan penawaran, vendor yang balik bertanya banyak setelah baca briefmu biasanya lebih aman daripada yang langsung jawab "bisa, dua minggu jadi". Pertanyaan itu tanda dia benar-benar membacanya. Kalau ternyata semua penawaran di luar anggaran, jalan lain masih ada: mengerjakan versi pertama sendiri sampai kelihatan bentuknya, baru menyewa orang buat versi seriusnya.

Kesalahan yang bikin brief bagus jadi percuma

• Brief dikirim tapi nggak dilampirkan ke kesepakatan kerja. Kalau nggak dirujuk di surat perjanjian atau invoice, statusnya cuma bahan obrolan.
• Perubahan disepakati lewat telepon, lalu nggak ada yang memperbarui briefnya. Dua minggu kemudian nggak ada yang ingat versi mana yang berlaku.
• Nambah fitur di tengah jalan tanpa menyentuh jadwal dan harga. Ini terasa kecil buat kamu dan berat buat dia, dan biasanya dibayar diam-diam pakai kualitas.
• Brief ditulis pakai istilah teknis hasil menyontek dari internet. Kalau kamu nggak paham istilahnya, kamu juga nggak akan bisa mengecek apakah hasilnya sesuai.

Brief nggak bikin proyekmu kebal masalah. Yang dia lakukan cuma satu: memindahkan semua perdebatan ke depan, waktu belum ada uang yang keluar dan belum ada kode yang harus dibongkar.

Satu catatan penutup: dokumen yang sama juga kepakai kalau nanti kamu memutuskan sebagian pekerjaannya dikerjakan pakai AI. Cara menyusunnya sedikit beda, dan itu dibahas terpisah di cara menjelaskan ide aplikasi ke AI.

Kalau sekarang kamu lagi menunggu penawaran dari seseorang, coba buka catatanmu dan tulis bagian sembilan duluan: apa saja yang sengaja nggak dikerjakan di versi ini. Lima belas menit. Bagian itu yang paling jarang ditulis orang, dan paling sering jadi alasan tagihan kedua datang.