Cara Membuat Dokumen Kebutuhan Aplikasi Sebelum Minta Penawaran ke Vendor

Kirim permintaan dua paragraf yang sama ke empat software house, dan penawaran yang kembali bisa berkisar dari Rp80 juta sampai Rp400 juta. Belum tentu ada yang curang. Setiap vendor mengisi bagian yang kosong di permintaan Anda dengan asumsinya sendiri, dan yang Anda bandingkan sebenarnya adalah asumsi-asumsi itu. Brief yang baik menutup sebagian besar celah tersebut sebelum ada yang menghitung. Brief tidak perlu tebal, dan Anda tidak perlu paham teknis untuk menulisnya. Di bawah ini isi yang perlu ada, yang sebaiknya tidak ditulis, dan bagaimana brief itu nanti berubah jadi scope di kontrak.

Kenapa Penawaran Bisa Beda Lima Kali Lipat

Ambil contoh kalimat "kami butuh aplikasi untuk tim sales mencatat kunjungan ke toko". Vendor pertama membacanya sebagai form sederhana dengan check-in GPS dan upload foto, kira-kira enam minggu kerja. Vendor kedua mengasumsikan mode offline untuk daerah tanpa sinyal, dashboard untuk area manager, perencanaan rute, dan sinkron ke sistem akuntansi. Dua-duanya bacaan yang wajar. Hanya saja sistemnya berbeda, dan harga mengikuti sistemnya.

Permintaan yang kabur juga membuat vendor main aman. Vendor yang hati-hati menambahkan buffer 30 sampai 50 persen untuk hal yang belum jelas. Vendor yang sedang butuh proyek memasang harga rendah, lalu berharap untung dari change request belakangan. Dua angka itu sama-sama kurang berguna untuk Anda. Dari pengalaman kami, kalau brief-nya spesifik, penawaran dari vendor yang serius jauh lebih berdekatan. Selisih yang tersisa menyangkut tim, kualitas, dan dukungan setelah rilis, dan itulah yang memang perlu Anda bandingkan.

SRS Formal Biasanya Belum Perlu

SRS adalah singkatan dari Software Requirements Specification. Versi formalnya mengikuti standar seperti IEEE 830, yang sekarang sudah digantikan ISO/IEC/IEEE 29148, lengkap dengan bab kebutuhan fungsional, antarmuka, batasan, dan penomoran supaya setiap kebutuhan bisa ditelusuri. Bank, tender pemerintah, dan proyek korporasi besar sering mewajibkannya, dan di sana dokumen seperti itu memang ada gunanya.

Pendapat kami, untuk kebanyakan UMKM dan perusahaan menengah, SRS formal itu berlebihan. Menulis 40 halaman butuh berminggu-minggu, jarang ada yang membacanya sampai habis, dan dokumennya memberi kesan semua sudah diputuskan padahal belum. Brief empat sampai delapan halaman dengan bagian yang tepat jauh lebih berguna. Penawarannya jadi bisa dibandingkan, dan vendor yang Anda pilih toh akan mengubahnya jadi spesifikasi detail di tahap discovery. Kalau tendernya mensyaratkan format tertentu, ikuti saja. Selain itu, mulai dari yang ringkas.

Isi Brief yang Berguna, Lengkap dengan Contoh

Bagian-bagian berikut cukup untuk hampir semua sistem bisnis yang pernah kami hitung, dari aplikasi internal sampai portal pelanggan. Contohnya memakai distributor fiktif dengan beberapa cabang.

Untuk alur utama, format user story enak dipakai karena memaksa Anda menyebut siapa melakukan apa dan untuk apa: "Sebagai [role], saya ingin [melakukan sesuatu] supaya [alasan]". Kalau terasa kaku, tulis saja skenario pendek dengan kalimat biasa. Yang penting, kondisi tidak normal juga ikut ditulis. Stok tidak cukup, area manager sedang cuti, pembayaran gagal di tengah jalan. Justru di kasus-kasus seperti ini estimasi antarvendor paling jauh bedanya.

Kebutuhan non-fungsional perlu angka. "Harus cepat" dan "harus aman" tidak bisa dihitung. Dua puluh pengguna di jam kantor dan 5.000 pelanggan saat flash sale Harbolnas itu dua sistem yang berbeda. Begitu juga soal ketersediaan: aktif di jam kerja hari biasa itu murah, sedangkan 24 jam dengan uptime 99,9 persen tidak. Kalau usaha Anda di sektor yang diatur seperti perbankan atau fintech, OJK dan Bank Indonesia punya aturan soal lokasi pemrosesan dan penyimpanan data, jadi sebutkan di brief. Untuk usaha lain, cukup tulis bahwa sistem akan menyimpan data pribadi yang tunduk pada UU PDP, dan apakah Anda ingin server di Jakarta atau tidak keberatan di Singapura.

Acceptance Criteria dengan Bahasa Sehari-hari

Acceptance criteria adalah kalimat yang bisa dijawab "ya" atau "tidak" saat pengujian. "Laporan harus mudah dipakai" tidak bisa diuji. "Area manager bisa memfilter laporan stok per cabang dan rentang tanggal, mengekspornya ke Excel, dan laporan berisi 5.000 baris terbuka dalam waktu kurang dari lima detik" bisa diuji. Pakai pola "kalau ini terjadi, maka sistem melakukan itu", dan sebagian besar pekerjaannya sudah beres.

Dua atau tiga kriteria per user story biasanya cukup. Tidak semua fitur harus punya kriteria sebelum Anda minta penawaran. Untuk lima alur terpenting saja, tebak-tebakan vendor sudah berkurang banyak. Simpan baik-baik, karena kalimat yang sama nanti jadi daftar cek saat UAT di akhir proyek.

Yang Sebaiknya Tidak Ditulis

• Desain database. Tabel dan kolom itu urusan vendor. Ceritakan informasi apa yang harus dicatat dan dilaporkan, biar mereka yang memodelkannya.
• Pilihan framework atau bahasa pemrograman. Menentukan Laravel atau Go dari awal hanya mempersempit pilihan Anda, kecuali memang ada alasan nyata di baliknya.
• Daftar 80 fitur "kalau bisa ada". Setiap baris ikut dihitung, jadi daftar keinginan yang panjang membuat semua penawaran membengkak dan menutupi apa yang sebenarnya Anda butuhkan.
• Kata sifat tanpa angka, seperti user-friendly, scalable, modern, atau aman.
• Instruksi seperti "bikin seperti Gojek". Sebutkan layar atau perilaku spesifik yang Anda suka, dan alasannya.

Batasan nyata lain cerita, dan justru harus masuk brief. "Tim IT kami hanya menguasai PHP dan akan meneruskan maintenance setelah serah terima" atau "sistem harus jalan di server kami yang sudah ada di IDCloudHost" adalah fakta yang perlu diketahui vendor, bukan keputusan desain yang Anda paksakan.

Menentukan Prioritas dengan Metode MoSCoW

MoSCoW membagi fitur ke empat kelompok. Must have: tanpa fitur ini sistemnya tidak berguna. Should have: penting, tapi untuk sementara masih ada cara lain. Could have: enak kalau ada, dan yang pertama dicoret kalau anggaran mepet. Won't have this time: disepakati dan ditulis sebagai di luar scope untuk sekarang. Metode DSDM, asal-usul MoSCoW, menyarankan porsi Must tidak lebih dari sekitar 60 persen effort, supaya masih ada ruang kalau muncul kejutan.

Di bagian ini banyak brief keliru. Kalau semua ditandai Must, labelnya tidak ada artinya lagi dan vendor kembali menebak. Cara mengujinya sederhana: apakah Anda rela go-live ditunda demi fitur ini? Kalau tidak, berarti fitur itu bukan Must. Minta vendor menghitung kelompok Must dan Should secara terpisah, supaya biaya fase pertama yang sebenarnya kelihatan.

Wireframe Cukup dari Sketsa

Anda tidak perlu desainer untuk menunjukkan maksud Anda. Foto coretan tangan, layout kasar di Excalidraw, atau beberapa frame di Figma versi gratis sudah cukup. Gambar tiga sampai lima layar yang paling penting, misalnya form input yang dipakai staf seharian dan laporan yang dicek direktur setiap pagi. Desain yang rapi nanti dikerjakan desainer dari vendor.

Materi yang sudah ada sering lebih berguna daripada gambar baru. Lampirkan file Excel yang dipakai tim sekarang, foto formulir kertas, contoh laporan, dan screenshot grup WhatsApp tempat pesanan biasanya di-approve. Dari situ vendor melihat field yang sebenarnya, pengecualian yang sebenarnya, dan volume yang sebenarnya, sesuatu yang sulit ditangkap dari deskripsi.

Langkah Menyusun Brief

1. 1Tulis masalah dan tujuan dalam setengah halaman, termasuk satu atau dua angka yang ingin diubah, misalnya jam kerja per minggu atau tingkat kesalahan input.
2. 2Daftar role dan jumlah orang di tiap role. Ajak ngobrol satu orang dari setiap role selama 30 menit dan catat apa yang benar-benar mereka kerjakan hari ini.
3. 3Tulis 5 sampai 15 user story atau skenario untuk alur utama, plus apa yang harus terjadi kalau ada masalah.
4. 4Kumpulkan materi yang ada: spreadsheet, formulir kertas, laporan, screenshot, dan dokumentasi API dari sistem seperti Accurate atau payment gateway yang Anda pakai.
5. 5Tambahkan kebutuhan non-fungsional lengkap dengan angka, kisaran anggaran, tenggat, dan mana yang lebih kaku.
6. 6Kelompokkan fitur dengan MoSCoW, lalu tulis acceptance criteria untuk semua yang Must.
7. 7Buat sketsa layar yang paling penting.
8. 8Minta rekan yang tidak terlibat membacanya. Kalau dia bisa menjelaskan ulang sistemnya ke Anda, brief siap dikirim.

Kalau dua vendor membaca brief Anda dan membayangkan sistem yang sama, brief itu sudah menjalankan tugasnya.

Dari Brief ke Scope Kontrak

Setelah vendor dipilih, brief tidak dibuang. Isinya dipertajam jadi spesifikasi, biasanya di tahap discovery, lalu spesifikasi itu dilampirkan di kontrak sebagai scope pekerjaan. Apa pun di luar itu masuk change request: Anda menulis perubahannya, vendor menghitung dalam hari kerja dan Rupiah, dan pekerjaan baru dimulai setelah Anda setuju. Brief yang jelas membuat change request lebih jarang, dan yang tersisa tidak berubah jadi debat soal fitur yang "harusnya sudah termasuk".

Kalau Anda tidak sempat menulis brief, atau prosesnya terlalu rumit untuk diuraikan sendiri, tahap discovery berbayar bisa jadi pilihan. Vendor mengadakan workshop dengan tim Anda selama dua sampai empat minggu, lalu menyerahkan peta proses, wireframe, spesifikasi, dan estimasi yang pasti. Harganya bervariasi, tapi sekitar 5 sampai 10 persen dari perkiraan biaya pembuatan itu umum. Pastikan hasilnya jadi milik Anda dan boleh dibawa ke vendor lain. Kadang discovery berakhir dengan kesimpulan bahwa Anda tidak perlu aplikasi custom sama sekali, karena Accurate atau Jurnal ditambah integrasi kecil sudah cukup. Uang untuk discovery seperti itu tetap tidak sia-sia.

Di Salamun Teknologi kami menerima brief dalam berbagai bentuk, dari voice note WhatsApp sampai dokumen tender 60 halaman. Kalau brief Anda masih kasar, kami bisa membacanya bersama dan menunjukkan bagian yang bakal membuat penawaran melenceng, sebelum Anda kirim ke vendor mana pun, termasuk ke kami.