Checklist: Apa yang Perlu Disiapkan Sebelum Konsultasi Pertama dengan Developer

Konsultasi pertama dengan developer sering habis untuk hal-hal dasar: sebenarnya mau bikin apa, siapa yang akan memakai, dan kira-kira berapa dana yang tersedia. Semua itu wajar dibahas, tapi kalau kamu datang dengan jawabannya, waktu yang sama bisa dipakai untuk hal yang lebih berharga: menilai pilihan, menimbang risiko, dan menyusun prioritas.

Artikel ini berisi tujuh hal yang layak disiapkan, ditambah template singkat yang bisa langsung disalin. Ini kebalikan dari artikel "5 Pertanyaan yang Harus Ditanyakan Sebelum Pakai Jasa Developer Freelance": di sana soal apa yang perlu kamu tanyakan ke developer, di sini soal apa yang perlu kamu siapkan sebelum bicara. Tidak ada yang wajib sempurna; persiapan setengah jadi pun jauh lebih baik daripada datang dengan tangan kosong.

1. Tuliskan Masalahnya, Bukan Solusinya

"Saya mau bikin aplikasi" adalah solusi. "Staf gudang butuh dua hari tiap akhir bulan untuk merekap stok dari tiga file Excel" adalah masalah. Developer justru butuh yang kedua, karena dari situ ia bisa menilai apakah yang kamu perlukan memang aplikasi, cukup perbaikan alur kerja, atau sistem yang jauh lebih sederhana dari bayanganmu.

Coba tulis dalam satu atau dua kalimat: siapa yang kesulitan, apa yang sulit, dan seberapa sering terjadi. Kalau bisa, sertakan akibatnya, misalnya waktu terbuang, data yang selisih, atau pelanggan yang harus menunggu.

2. Sebutkan Jenisnya, Tapi Tidak Apa-apa Kalau Belum Yakin

Developer perlu tahu bentuk produknya: website company profile, toko online, aplikasi mobile, dashboard, atau sistem internal untuk operasional. Pilihan ini ikut menentukan arah teknologi dan biaya. Kalau kamu belum yakin, jangan ditebak. Cukup jelaskan siapa yang akan memakainya dan dari perangkat apa: staf lapangan lewat HP, tim kantor lewat laptop, atau pelanggan umum.

Dari situ pilihan antara web app, aplikasi mobile, atau PWA bisa dibahas bersama. Perbedaan ketiganya sudah saya bahas di artikel "Perbedaan Web App, Mobile App, dan PWA".

3. Daftar Tiga sampai Lima Kebutuhan yang Konkret

Hindari kata sifat yang tidak bisa diuji seperti "modern", "mudah", atau "lengkap". Pakai kalimat yang menyebut siapa melakukan apa: "staf bisa memindai barcode barang lewat HP", "laporan penjualan terkirim ke email pemilik tiap Senin pagi", "pelanggan bisa membayar lewat QRIS dan statusnya berubah otomatis". Kebutuhan yang konkret bisa langsung dihitung usahanya; yang abstrak hanya menghasilkan perkiraan kasar.

Setelah daftarnya jadi, tandai mana yang wajib ada di versi pertama dan mana yang bagus kalau ada. Pemisahan ini sangat berguna kalau anggaran ternyata lebih kecil dari estimasi: fitur inti dikerjakan dulu, sisanya jadi opsi tahap berikutnya, tanpa harus membuang hal yang benar-benar kamu butuhkan.

4. Kumpulkan Contoh dan Berkas yang Sudah Ada

Satu foto sering lebih jelas daripada satu halaman penjelasan. Foto formulir kertas yang dipakai sekarang, tangkapan layar file Excel, sketsa tangan di kertas, atau aplikasi lain yang menurutmu "kira-kira seperti itu", semuanya sangat membantu. Jangan khawatir kalau berantakan; coretan tangan pun sudah menghemat banyak pertanyaan. Di chat Zannah, kamu bahkan bisa melampirkan foto, PDF, atau CSV supaya kebutuhannya terbaca langsung.

Kalau ada data lama yang nanti perlu dipindahkan ke sistem baru, sebutkan juga bentuknya (Excel, buku catatan, atau sistem lain) dan perkiraan jumlahnya. Pemindahan data kadang jadi bagian yang paling banyak memakan waktu, dan lebih baik ketahuan sejak awal.

5. Perkirakan Siapa yang Memakai dan Seberapa Banyak

Jumlah dan kondisi pemakai memengaruhi rancangan lebih dari yang orang kira. Sistem yang dipakai tiga orang admin berbeda kebutuhannya dengan sistem yang diakses ratusan pelanggan bersamaan. Yang berguna disebutkan: kira-kira berapa pengguna, apakah mereka memakainya bersamaan, dari mana mereka bekerja, dan apakah ada lokasi dengan sinyal buruk seperti gudang atau area basement. Jawaban terakhir menentukan perlu tidaknya mode offline, yang jelas memengaruhi rancangan dan biaya.

Perkiraan ini juga menentukan apakah pendekatan hemat biaya seperti Google Apps Script cukup untuk saat ini, dan kapan sebaiknya pindah ke server sendiri, seperti yang saya bahas di artikel soal tanda-tanda waktunya migrasi.

6. Jujur soal Target Waktu dan Kisaran Anggaran

Ini bagian yang paling sering dihindari, padahal paling berpengaruh. Developer menanyakan kisaran anggaran bukan untuk menghabiskannya, tapi supaya bisa menyusun prioritas yang realistis: apa yang masuk versi pertama dan apa yang ditunda. Tanpa angka sama sekali, usulan bisa meleset jauh ke dua arah, terlalu mewah atau terlalu minimalis.

Kalau belum punya angka, tidak apa-apa. Sebutkan saja "belum tahu" dan minta gambaran rentang untuk proyek sejenis. Hal yang sama berlaku untuk waktu: kalau ada tanggal yang tidak bisa digeser, seperti peluncuran, event, atau awal tahun ajaran, sebutkan dari awal. Rincian soal lamanya proses ada di artikel "Berapa Lama Bikin Website/Aplikasi untuk Bisnis Kecil", dan alasan harga antar-proposal bisa berbeda jauh ada di artikel "Kenapa Harga Proposal Development Bisa Beda-beda".

7. Siapkan Bagianmu: Materi, Akses, dan Pengambil Keputusan

Proyek sering tertahan bukan karena proses coding-nya, tapi karena menunggu bahan dari sisi klien. Beberapa hal yang sebaiknya sudah jelas siapa pemegangnya: materi seperti logo, teks, dan foto; data awal yang harus dimasukkan; akses ke akun yang diperlukan seperti domain, akun Google, atau akun payment gateway; dan siapa yang berhak memutuskan kalau ada pilihan yang harus diambil.

Itu sebabnya proposal yang disusun lewat DevRAB memuat bagian prasyarat klien, yaitu daftar data atau materi yang harus disiapkan sebelum pengerjaan dimulai. Kalau kamu sudah memikirkannya dari awal, bagian itu tinggal dicentang.

Yang Tidak Perlu Kamu Siapkan

Kamu tidak perlu menguasai istilah teknis, memilih bahasa pemrograman atau database, atau punya desain final. Itu bagian developer. Kalau ada developer yang membuatmu merasa harus menguasai jargon dulu supaya dianggap serius, anggap itu informasi tentang developernya.

Template Singkat yang Bisa Disalin

Kalau mau praktis, salin kerangka di bawah ini dan isi sebisanya:

Kerangka yang sama bisa kamu tempel langsung ke chat Zannah di situs ini. Sebelum menawarkan tombol "Buatkan RAB", Zannah memang menggali tiga hal dari daftar tadi: jenis produknya, minimal dua sampai tiga kebutuhan konkret, dan indikasi target waktu atau anggaran. Makin lengkap jawabanmu di awal, makin cepat sampai ke proposal yang bisa kamu baca dan revisi. Kalau persiapanmu belum lengkap pun tidak masalah; justru untuk itu diskusi awal ada.