Cara Memilih Software House untuk Proyek Aplikasi Anda

Memilih software house lebih mirip merekrut tim daripada membeli produk. Aplikasi yang Anda terima sangat bergantung pada orang-orang yang membuatnya, cara mereka bekerja, dan apa yang terjadi setelah aplikasi live, dan sebagian besar hal itu tidak kelihatan dari portofolio atau harga. Proses seleksi yang terstruktur memang butuh beberapa minggu, tapi jauh lebih murah daripada baru sadar di tengah proyek bahwa partner yang dipilih tidak sanggup menyelesaikannya.

Software House, Freelancer, atau Tim Internal

Banyak perusahaan menggabungkan pilihan-pilihan ini. Software house membangun versi pertama sambil mentransfer pengetahuan, sementara perusahaan pelan-pelan membangun tim internal. Bisa juga tim dedicated dari software house bekerja sebagai perpanjangan tim internal.

Cek Pengalaman yang Relevan

Portofolio yang relevan lebih penting daripada portofolio yang banyak. Cari proyek dengan tingkat kerumitan, integrasi, atau industri yang mirip. Aplikasi dengan approval bertingkat, integrasi ERP, dan banyak jenis pengguna sangat berbeda dengan website company profile. Minta mereka menjelaskan satu atau dua proyek yang mirip dengan kebutuhan Anda, termasuk kendala yang terjadi dan bagaimana menanganinya. Tim yang bisa menjelaskan pertimbangan teknisnya dengan jelas biasanya memang memikirkan keputusannya dengan matang.

Kenali Orang yang Akan Mengerjakan

Orang yang hadir di rapat penawaran sering kali bukan orang yang akan membangun aplikasinya. Tanyakan siapa yang akan memimpin proyek dan pekerjaan teknisnya, seberapa berpengalaman mereka, dan berapa proyek lain yang mereka pegang di saat yang sama. Tanyakan juga apa yang terjadi kalau orang kunci keluar di tengah proyek. Partner yang mau memperkenalkan tim sebenarnya sebelum kontrak ditandatangani biasanya memang tidak menyembunyikan apa-apa.

Tanyakan Proses Engineering-nya

• Bagaimana kebutuhan dikumpulkan dan dikonfirmasi sebelum development dimulai?
• Apakah setiap perubahan kode dicek developer lain sebelum digabungkan?
• Test otomatis apa yang dibuat, dan siapa yang mengetes aplikasi sebelum setiap rilis?
• Apakah ada environment staging tempat Anda bisa mencoba fitur baru sebelum sampai ke pengguna?
• Bagaimana aplikasi di-deploy, dan apakah rilis yang bermasalah bisa dibatalkan dengan cepat?
• Dokumentasi apa saja yang akan Anda terima di akhir proyek?

Jawaban yang konkret dan disertai contoh adalah tanda yang baik. Jawaban yang mengambang seperti "kami selalu testing dengan teliti" tanpa penjelasan caranya biasanya berarti prosesnya bergantung pada kebiasaan masing-masing orang.

Pastikan Source Code Jadi Milik Anda

Kontrak harus menyebutkan bahwa source code dan hak kekayaan intelektual terkait menjadi milik perusahaan Anda setelah pembayaran yang disepakati lunas. Dalam praktiknya, minta repository dibuat di akun organisasi Anda, atau minta akses sejak minggu pertama, supaya Anda bisa melihat progres dan tidak pernah terkunci dari aplikasi sendiri. Hal yang sama berlaku untuk server, domain, dan akun layanan pihak ketiga: semuanya sebaiknya terdaftar atas nama perusahaan Anda.

Cek sederhana: tanyakan apakah Anda bisa mendapat akses baca ke repository sejak sprint pertama. Kalau partner terlihat ragu, itu gambaran bagaimana akhir proyeknya nanti.

Baca Kontrak: Scope, Perubahan, dan Garansi

• Scope: daftar fitur tertulis beserta apa saja yang tidak termasuk, supaya kedua pihak punya gambaran yang sama.
• Change request: bagaimana kebutuhan baru atau perubahan diestimasi, disetujui, dan ditagihkan.
• Termin pembayaran yang dikaitkan dengan hasil kerja yang bisa Anda tes, tidak hanya dengan tanggal.
• Garansi: berapa lama bug diperbaiki tanpa biaya tambahan setelah aplikasi live, dan apa saja yang termasuk bug.
• Pemutusan kontrak: apa yang Anda terima, termasuk kode dan dokumentasi, kalau proyek berhenti di tengah jalan.

Sepakati Komunikasi dan Support

Komunikasi yang rutin dan bisa diprediksi mencegah sebagian besar kejutan dalam proyek. Sepakati laporan progres mingguan, demo fitur yang sudah jadi setiap satu atau dua minggu, dan satu kontak utama dari masing-masing pihak. Untuk aplikasi yang jadi tumpuan bisnis, bahas juga support setelah masa garansi: waktu respons saat ada insiden, monitoring, update keamanan, dan cara menangani pengembangan lanjutan. Bisa bertemu langsung saat dibutuhkan, misalnya dengan partner di kota yang sama, juga sangat membantu saat pengumpulan kebutuhan dan uji terima.

Tanda Bahaya

• Harga jauh di bawah penawaran lain, tanpa penjelasan apa saja yang tidak termasuk.
• Harga pasti diberikan dari brief singkat, tanpa pertanyaan soal pengguna, integrasi, atau data.
• Janji semua fitur bisa selesai cepat, tanpa membahas konsekuensinya.
• Tidak ada akses ke kode maupun aplikasi yang sedang dibangun sampai pelunasan.
• Tidak ada pembahasan soal testing, code review, atau environment staging.
• Satu orang menangani penjualan, desain, development, dan support sekaligus.

Proses Seleksi yang Praktis

1. 1Tulis brief yang berisi masalah bisnis, pengguna, integrasi yang dibutuhkan, perkiraan skala, kisaran anggaran, dan target waktu.
2. 2Pilih tiga software house dengan pengalaman yang relevan, dan kirimkan brief yang sama ke semuanya.
3. 3Adakan sesi dengan masing-masing untuk membahas brief, berkenalan dengan tim yang diusulkan, dan menanyakan prosesnya.
4. 4Bandingkan proposalnya dari sisi scope, asumsi, proses, kepemilikan kode, garansi, dan support, baru kemudian harga.
5. 5Mulai dengan tahap discovery berbayar yang singkat atau milestone pertama yang kecil sebelum berkomitmen untuk seluruh proyek.