Pertanyaan pertama yang hampir selalu muncul saat perusahaan ingin membuat aplikasi adalah soal waktu. Pemilik usaha perlu tahu kapan sistem baru bisa dipakai, karena ada target penjualan, musim ramai, atau tahun buku yang harus dikejar. Jawaban jujur untuk berapa lama membuat aplikasi bisnis memang bergantung pada banyak hal, dan vendor yang menyebut angka pasti di pertemuan pertama biasanya belum melihat kebutuhan Anda secara utuh.
Tulisan ini menjelaskan tahapan yang dilalui sebuah proyek aplikasi, hal yang mempercepat dan memperlambatnya, serta bagaimana pendekatan MVP membantu Anda mulai memakai aplikasi lebih awal.
Kenapa tidak ada angka standar
Dua aplikasi yang terdengar mirip bisa sangat berbeda isinya. Aplikasi pemesanan untuk satu toko roti dengan satu cabang tentu lebih sederhana daripada sistem pemesanan untuk distributor dengan puluhan sales, beberapa gudang, harga khusus per pelanggan, dan integrasi ke software akuntansi. Keduanya sama-sama disebut aplikasi pemesanan.
Yang menentukan durasi adalah jumlah alur kerja, jumlah peran pengguna, aturan bisnis yang perlu dimasukkan, sistem lain yang harus terhubung, dan seberapa cepat keputusan diambil di sisi Anda. Karena itu estimasi yang masuk akal baru bisa dibuat setelah tahap discovery, saat kebutuhan sudah dipetakan bersama.
Hal yang sama berlaku untuk tampilan dan platform. Aplikasi internal yang hanya dipakai beberapa admin bisa memakai desain sederhana di browser. Aplikasi untuk pelanggan biasanya butuh perhatian lebih pada kemudahan pakai, tampilan di berbagai ukuran layar, dan kadang versi Android serta iOS sekaligus. Setiap pilihan seperti ini menambah atau mengurangi pekerjaan, jadi sebaiknya dibicarakan sejak awal.
Tahapan dalam membuat aplikasi bisnis
Hampir semua proyek aplikasi melewati lima tahap berikut. Panjang tiap tahap berbeda dari proyek ke proyek, tetapi urutannya relatif sama.
- Discovery. Tim memetakan masalah, pengguna, alur kerja saat ini, data yang terlibat, dan sistem yang sudah dipakai. Hasilnya berupa daftar kebutuhan yang disepakati dan prioritasnya.
- Desain. Alur layar dan tampilan dirancang, lalu diuji ke beberapa calon pengguna. Perubahan di tahap ini jauh lebih murah daripada setelah kode ditulis.
- Pengembangan. Aplikasi dibangun bertahap. Setiap beberapa waktu ada demo bagian yang sudah jadi, sehingga Anda bisa mencoba dan memberi masukan.
- Pengujian. Fitur diuji dengan data dan skenario nyata, termasuk kasus yang jarang terjadi seperti retur sebagian atau pembayaran yang gagal. Pengguna kunci ikut mencoba sebelum rilis.
- Peluncuran. Data awal dipindahkan, staf dilatih, dan aplikasi mulai dipakai. Untuk aplikasi mobile, ada juga proses peninjauan dari Google Play dan App Store yang waktunya tidak sepenuhnya bisa dikendalikan.
Setelah peluncuran, biasanya ada masa pendampingan saat bug kecil dan penyesuaian pertama ditangani. Masa ini sebaiknya ikut dihitung dalam rencana Anda.
Hal yang membuat proyek lebih cepat
Beberapa faktor ada di tangan Anda, dan pengaruhnya cukup besar. Kebutuhan yang tertulis jelas sebelum proyek dimulai menghemat banyak waktu di tahap discovery. Contoh dokumen nyata, seperti format faktur, laporan mingguan, atau daftar harga, membantu tim memahami aturan bisnis tanpa harus menebak.
Satu penanggung jawab di sisi klien yang bisa memutuskan dengan cepat juga sangat membantu. Di sebuah klinik, misalnya, pertanyaan soal siapa yang boleh mengubah jadwal dokter bisa selesai dalam satu pesan jika ada orang yang berwenang. Tanpa itu, pertanyaan yang sama bisa tertahan berhari-hari.
Memakai komponen yang sudah tersedia juga mempercepat pekerjaan. Login, pembayaran, notifikasi, dan pengiriman email tidak perlu dibangun dari nol jika ada layanan yang andal.
Hal yang membuat proyek melambat
Penyebab keterlambatan yang paling sering adalah perubahan kebutuhan di tengah jalan tanpa penyesuaian rencana. Perubahan itu wajar, karena banyak hal baru terlihat setelah aplikasi bisa dicoba. Masalah muncul ketika fitur terus ditambahkan, tetapi jadwal dan prioritas tidak dibahas ulang.
Integrasi dengan sistem lain juga sering memakan waktu lebih lama dari dugaan. Software akuntansi lama mungkin tidak punya API yang lengkap, atau dokumentasinya sudah tidak sesuai. Data lama yang berantakan, misalnya daftar pelanggan dengan banyak duplikat, perlu dibersihkan sebelum bisa dipindahkan.
Keterlambatan umpan balik dari klien juga berpengaruh. Jika demo dijadwalkan rutin tetapi tidak ada yang sempat mencoba, masalah baru ketahuan menjelang rilis, saat perbaikannya paling mahal.
Berapa lama membuat aplikasi dengan pendekatan MVP
Cara paling realistis untuk memperpendek waktu sampai aplikasi bisa dipakai adalah memulai dari MVP (minimum viable product). MVP adalah versi paling sederhana yang sudah bisa menangani pekerjaan nyata. Isinya satu atau dua alur utama, dengan fitur pendukung menyusul.
Sebuah EO, misalnya, bisa memulai dengan pendaftaran peserta dan check-in, lalu menambahkan laporan dan integrasi pembayaran di tahap berikutnya. Distributor bisa memulai dari pencatatan pesanan oleh sales, sebelum menghubungkannya ke gudang dan akuntansi.
Dengan MVP, Anda mendapat umpan balik dari pengguna sungguhan lebih cepat. Keputusan tentang fitur berikutnya diambil berdasarkan cara staf benar-benar bekerja, dan rencana tahap lanjutan menjadi lebih akurat. Durasi total tetap bergantung pada ruang lingkup, tetapi Anda tidak perlu menunggu semuanya selesai untuk mulai merasakan manfaatnya.
Merencanakan jadwal bersama tim pengembang
Estimasi yang baik lahir dari discovery yang serius dan rencana rilis bertahap yang bisa Anda pantau. Tim Averoa di Yogyakarta mengerjakan aplikasi web, mobile, sistem internal, dan API dengan pola rilis bertahap dan demo rutin. Penjelasannya ada di halaman Pengembangan Software Kustom.
