Cara Memilih Software House: Kriteria, Pertanyaan, dan Tanda Bahaya

Portofolio yang menarik bisa menjadi alasan untuk mulai berbicara dengan sebuah software house, tetapi belum cukup untuk memutuskan. Tampilan aplikasi tidak memperlihatkan cara tim menangani transaksi gagal, data yang tidak lengkap, hak akses, proses pengujian, atau serah terima. Untuk memilih mitra pengembangan, Anda perlu melihat bagaimana mereka bekerja, bukan hanya apa yang mereka tampilkan.

Mulai dari brief yang sama untuk semua vendor

Sebelum menghubungi vendor, tulis satu halaman tentang masalah bisnis, pengguna, proses yang ingin diperbaiki, sistem yang digunakan saat ini, dan hasil yang ingin diukur. Tidak semua detail harus sudah final, tetapi vendor perlu menerima konteks yang sama agar proposal bisa dibandingkan dengan adil.

Jika salah satu vendor mengusulkan solusi berbeda, minta mereka menjelaskan alasan, konsekuensi, dan asumsi yang mendasarinya. Rekomendasi yang berbeda tidak selalu buruk. Justru kemampuan menantang asumsi dengan alasan yang jelas dapat menunjukkan bahwa tim mencoba memahami kebutuhan, bukan sekadar menyetujui semua permintaan.

Kriteria yang layak diperiksa

Pengalaman yang relevan, bukan hanya jumlah proyek

Minta contoh aplikasi yang memiliki persoalan mirip, seperti persediaan multi-gudang, alur persetujuan, pelaporan keuangan, atau integrasi dengan sistem lama. Tanyakan bagian mana yang benar-benar dikerjakan tim tersebut dan bagaimana sistem digunakan setelah peluncuran. Jika diizinkan, mintalah referensi klien atau demo produk yang aktif. Pastikan contoh itu relevan dengan kebutuhan Anda, bukan hanya menarik secara visual.

Cara mereka menggali kebutuhan

Tim yang baik akan bertanya tentang peran pengguna, pengecualian, volume transaksi, sumber data, serta indikator keberhasilan. Mereka perlu memahami apa yang terjadi ketika proses normal gagal, misalnya pembayaran ditolak, barang tidak tersedia, atau sinkronisasi data terhenti. Jika estimasi final diberikan sebelum hal-hal dasar ini dibahas, tanyakan asumsi yang dipakai.

GOV.UK menyarankan pemahaman masalah dan pengguna sebelum berkomitmen membangun layanan, termasuk memeriksa batasan dan biaya dari masalah yang hendak diselesaikan (How the discovery phase works). Anda tidak harus mengikuti proses pemerintah secara persis, tetapi prinsip discovery dapat membantu mengurangi salah pengertian antara pemilik bisnis dan pengembang.

Estimasi, ruang lingkup, dan perubahan

Proposal sebaiknya merinci hasil kerja, fitur yang termasuk, pengecualian, asumsi, dependensi, jadwal, serta tanggung jawab masing-masing pihak. Cari tahu bagaimana permintaan baru dinilai dan apakah pekerjaan tambahan perlu disetujui sebelum dilakukan. Jadwal yang realistis perlu mempertimbangkan pengujian, review pengguna, migrasi data, serta persetujuan dari pihak bisnis.

NASA Software Engineering Handbook menyarankan estimasi perangkat lunak didasarkan pada ruang lingkup, ukuran, kompleksitas, risiko, dan seluruh siklus hidup, bukan pada satu angka tanpa dasar (Cost Estimation). Tidak semua software house harus memakai metode NASA, tetapi alasan di balik estimasi tetap perlu dapat dijelaskan.

Pengujian dan keamanan

Tanyakan bagaimana tim menguji fungsi, hak akses, integrasi, performa, dan kondisi gagal. Siapa yang menjalankan pengujian penerimaan? Apakah bug dicatat dan diprioritaskan? Bagaimana backup dibuat dan diuji? Bagaimana akses ke data produksi dibatasi? Jawaban yang baik harus merujuk pada praktik kerja yang dapat dijelaskan, bukan sekadar menyebut “aplikasi aman”.

Kepemilikan, dokumentasi, dan dukungan

Perjelas hak atas source code, data, dokumentasi, akun hosting, domain, dan layanan pihak ketiga. Jelaskan pula siapa yang mengelola kredensial, cara akses dipindahkan, apa yang diserahkan saat proyek selesai, serta bagaimana dukungan setelah peluncuran dihitung. Jika perusahaan suatu saat mengganti vendor, sistem harus memiliki jalur serah terima yang jelas.

Pertanyaan yang sebaiknya diajukan saat konsultasi

Gunakan pertanyaan berikut pada setiap vendor supaya jawabannya bisa dibandingkan:

1. Apa saja yang termasuk dan tidak termasuk dalam harga penawaran?
2. Bagaimana tim memetakan kebutuhan dan memvalidasi asumsi sebelum coding?
3. Siapa yang akan mengerjakan proyek dan bagaimana komunikasi harian dilakukan?
4. Kriteria apa yang menentukan fitur dianggap selesai dan diterima?
5. Bagaimana perubahan ruang lingkup memengaruhi biaya serta jadwal?
6. Bagaimana migrasi data, pengujian, backup, dan pemulihan gangguan ditangani?
7. Siapa yang memiliki source code, data, dan akun setelah pembayaran?
8. Biaya apa yang tetap berjalan setelah aplikasi diluncurkan?
9. Apakah tim dapat menunjukkan contoh pekerjaan serupa atau memberi referensi klien?

Jawaban yang spesifik lebih berharga daripada janji “cepat”, “fleksibel”, atau “berpengalaman”. Minta contoh dokumen atau artefak yang memang bisa dibagikan, seperti contoh struktur sprint, format laporan bug, atau template kriteria penerimaan. Vendor tentu tidak harus membuka informasi rahasia klien lain, tetapi seharusnya mampu menjelaskan proses kerjanya.

Tanda bahaya dalam proses penawaran

Waspadai harga tetap yang diberikan tanpa pembahasan kebutuhan, ketidakjelasan tentang siapa yang mengerjakan proyek, keberatan saat ditanya tentang kepemilikan data dan source code, serta janji bahwa seluruh hal bisa dilakukan tanpa menjelaskan trade-off. Tanda lainnya adalah proposal yang tidak menyebut pengujian, migrasi, atau dukungan, tetapi menganggap aplikasi akan siap digunakan begitu coding selesai.

Satu tanda belum tentu berarti vendor tidak layak. Gunakan sebagai alasan untuk meminta klarifikasi. Jika jawaban terus kabur atau berubah-ubah, risiko kontrak dan pelaksanaan akan sulit diprediksi.

Cara membandingkan proposal

Jangan hanya membuat tabel harga. Beri skor berdasarkan kesesuaian ruang lingkup, kualitas discovery, kemampuan teknis yang relevan, rencana pengujian, kejelasan kontrak, biaya berulang, dan komunikasi. Tentukan bobot berdasarkan risiko proyek. Untuk aplikasi yang mengelola pembayaran, keamanan dan rekonsiliasi mungkin lebih penting daripada kecepatan membuat tampilan. Untuk prototipe internal, waktu menuju uji coba mungkin lebih menentukan.

Pilih mitra yang bersedia menjelaskan batasan dan risiko, termasuk ketika kebutuhan awal perlu diubah. Sebelum menyetujui pengembangan penuh, sepakati dokumen ruang lingkup dan kriteria penerimaan. Bila masalahnya belum jelas, diskusikan tahap pemetaan kebutuhan lebih dulu dengan digitalisasi.app atau vendor lain, lalu gunakan hasilnya untuk membuat keputusan yang lebih terukur.

Referensi

• GOV.UK Service Manual, How the discovery phase works
• GOV.UK Service Manual, Choosing technology
• NASA Software Engineering Handbook, Cost Estimation

Referensi diakses 25 Oktober 2026.