Membangun aplikasi untuk bisnis biasanya berarti bekerja sama dengan pihak luar selama berbulan-bulan, kadang bertahun-tahun. Memilih software house yang kurang tepat jarang langsung terlihat akibatnya. Masalah baru muncul di bulan ketiga, ketika jadwal mundur, biaya bertambah, dan Anda sadar tidak punya akses ke kode aplikasi yang sudah dibayar.
Tulisan ini merangkum hal-hal yang perlu diperiksa sebelum memilih software house atau mitra pengembang, dari menyiapkan ruang lingkup sampai poin-poin yang sebaiknya ada di kontrak. Panduan ini berlaku untuk vendor mana pun, termasuk jika Anda membandingkan beberapa penawaran sekaligus.
Mulai dari ruang lingkup yang jelas
Penawaran harga hanya bisa dibandingkan jika semua vendor membaca kebutuhan yang sama. Sebelum menghubungi software house, tuliskan kebutuhan Anda dalam dokumen singkat. Siapa penggunanya, masalah apa yang ingin diselesaikan, proses apa yang sekarang berjalan manual, dan sistem apa saja yang harus terhubung.
Dokumen ini tidak perlu teknis. Untuk sebuah distributor, isinya bisa berupa alur dari pesanan sales di lapangan sampai faktur terkirim, beserta contoh formulir dan laporan yang dipakai sekarang. Untuk klinik, cukup gambarkan alur pasien dari pendaftaran sampai pembayaran.
Pisahkan juga mana yang wajib ada di versi pertama dan mana yang bisa menyusul. Software house yang baik biasanya akan membantu mempertajam daftar ini. Jika vendor langsung memberi harga pasti tanpa banyak bertanya, itu tanda mereka belum benar-benar memahami kebutuhan Anda.
Cara memilih software house lewat portofolio
Portofolio yang panjang belum tentu relevan. Yang perlu Anda cari adalah proyek dengan kemiripan masalah, misalnya sistem internal dengan banyak peran pengguna, aplikasi yang terhubung ke sistem pembayaran, atau integrasi dengan software akuntansi. Tampilan yang bagus di slide presentasi tidak banyak menjelaskan seberapa rapi sistem di belakangnya.
Minta vendor menjelaskan satu atau dua proyek secara mendalam. Masalah apa yang dihadapi klien, keputusan teknis apa yang diambil, apa yang tidak berjalan sesuai rencana, dan bagaimana sistem itu dirawat sekarang. Jika memungkinkan, minta izin untuk berbicara dengan salah satu klien mereka. Perhatikan juga apakah vendor punya pengalaman menjalankan sistem dalam jangka panjang, karena membangun dan merawat adalah dua keterampilan yang berbeda.
Proses kerja dan komunikasi
Banyak masalah proyek software sebenarnya masalah komunikasi. Tanyakan bagaimana vendor membagi pekerjaan, seberapa sering Anda akan melihat hasil kerja, dan siapa yang menjadi kontak utama Anda.
Pengerjaan bertahap dengan demo rutin, misalnya setiap dua minggu, memberi Anda kesempatan memberi masukan sebelum terlambat. Anda melihat aplikasi yang benar-benar bisa dicoba, dan perbedaan pemahaman ketahuan lebih awal. Pastikan juga ada cara yang jelas untuk menangani perubahan kebutuhan. Perubahan hampir pasti terjadi, dan yang penting adalah bagaimana dampaknya ke jadwal dan biaya dibicarakan secara terbuka.
Dari sisi Anda, tunjuk satu orang yang punya waktu dan wewenang untuk menjawab pertanyaan vendor. Proyek sering melambat karena vendor menunggu keputusan dari klien.
Kepemilikan kode dan akses
Ini bagian yang paling sering terlewat. Pastikan sejak awal bahwa kode sumber, desain, dan dokumentasi menjadi milik perusahaan Anda setelah pembayaran sesuai kesepakatan. Kode sebaiknya disimpan di repositori yang aksesnya Anda pegang. Jangan biarkan kode hanya tersimpan di akun pribadi developer.
Hal yang sama berlaku untuk akun cloud, domain, layanan email, dan akun toko aplikasi seperti Google Play dan App Store. Idealnya semua didaftarkan atas nama perusahaan Anda, dengan vendor diberi akses sebagai pengelola. Jika suatu hari kerja sama berakhir, Anda tetap memegang semuanya dan bisa melanjutkan dengan tim lain.
Minta juga dokumentasi teknis yang cukup agar developer lain bisa memahami sistemnya. Jika aplikasi menyimpan data pelanggan atau karyawan, tanyakan bagaimana vendor menjaga keamanan data tersebut. UU Pelindungan Data Pribadi (UU No. 27 Tahun 2022) membuat hal ini semakin perlu diperhatikan.
Dukungan setelah rilis dan isi kontrak
Aplikasi yang sudah rilis tetap butuh perawatan. Ada bug yang baru muncul saat dipakai banyak orang, pembaruan keamanan, penyesuaian dengan versi Android dan iOS terbaru, dan permintaan fitur kecil. Tanyakan bagaimana vendor menangani semua itu, berapa lama masa garansi, dan seperti apa skema dukungan setelahnya.
Beberapa poin yang sebaiknya tertulis di kontrak:
- Ruang lingkup pekerjaan dan daftar fitur per tahap, dengan lampiran dokumen kebutuhan.
- Jadwal dan tahapan pembayaran yang terkait dengan hasil kerja yang bisa diperiksa.
- Prosedur perubahan kebutuhan, termasuk cara menghitung tambahan biaya dan waktu.
- Kriteria serah terima, yaitu kapan sebuah tahap dianggap selesai.
- Kepemilikan kode sumber, desain, dokumentasi, dan semua akun terkait.
- Masa garansi perbaikan bug dan skema dukungan setelahnya.
- Kerahasiaan dan perlindungan data, serta apa yang terjadi jika kerja sama dihentikan.
Kontrak yang jelas melindungi kedua pihak. Vendor yang serius biasanya tidak keberatan membahas poin-poin ini secara rinci.
Pandangan kedua sebelum memutuskan
Jika Anda sedang membandingkan beberapa penawaran atau ragu apakah sebuah rencana teknis masuk akal, pandangan dari pihak yang independen bisa membantu sebelum anggaran terpakai. Tim Averoa menyediakan review arsitektur, analisis build vs buy, dan due diligence teknis berdasarkan pengalaman menjalankan produk SaaS sendiri. Selengkapnya ada di halaman layanan Konsultasi Teknologi.
