Berapa lama sebenarnya membangun aplikasi web?

Hampir setiap vendor akan mengatakan tiga bulan. Hampir setiap proyek selesai dalam enam sampai sembilan bulan.

Bukan karena semuanya pembohong. Karena tiga bulan adalah jawaban untuk pekerjaan yang berbeda dari yang akhirnya dikerjakan — dan tidak ada yang menghitung selisihnya di awal.

Artikel ini memberi angka yang jujur, alasan di baliknya, dan cara memeriksa apakah jadwal yang Anda terima masuk akal.

Lima hal yang paling sering membuat proyek molor

Perhatikan: tidak satu pun di bawah ini soal menulis kode lebih lambat. Kode hampir selalu selesai sesuai perkiraan. Yang molor adalah hal-hal di sekitarnya.

• Keputusan yang menunggu. Satu orang yang harus menyetujui desain layar tertentu, tetapi sedang dinas luar selama dua minggu. Proyek berhenti, bukan karena teknis, tetapi karena tidak ada yang memutuskan.
• Data lama yang kacau. Rencananya memindahkan data dari sistem lama. Setelah diperiksa, ternyata ada empat versi nomor pelanggan yang berbeda dan tidak ada yang tahu mana yang benar. Pembersihannya sendiri bisa memakan sebulan.
• Kebutuhan yang baru muncul setelah melihat hasilnya. Ini normal dan sehat. Yang tidak sehat adalah tidak menganggarkannya sejak awal.
• Integrasi pihak ketiga. Payment gateway, layanan ongkir, atau sistem keuangan lama. Setiap pihak ketiga punya dokumentasi yang umurnya berbeda-beda, dan sebagian dokumentasinya salah.
• Uji coba yang berubah menjadi permintaan tambahan. Pengguna mencoba, menemukan hal yang tidak mereka pikirkan sebelumnya, dan daftar permintaan bertambah cepat.

Empat dari lima hal di atas bukan pekerjaan pengembang. Itu keputusan bisnis dan kesiapan data. Artinya, sebagian besar keterlambatan tidak bisa diperbaiki dengan menambah jumlah programmer.

Angka yang realistis, berdasarkan jenis pekerjaan

Rentang berikut adalah pengalaman umum untuk pekerjaan yang dikerjakan dengan saksama, bukan janji. Proyek yang jauh lebih cepat biasanya melewatkan salah satu hal di daftar atas, dan itu akan terasa kemudian.

• Satu alur, satu tujuan, tanpa integrasi: 3 sampai 6 minggu. Contoh: formulir pendaftaran daring dengan panel admin sederhana.
• Aplikasi internal satu modul, dengan login dan hak akses: 2 sampai 3 bulan. Contoh: pencatatan aset dengan kode QR.
• Aplikasi dengan dua sampai tiga modul, satu integrasi: 3 sampai 5 bulan. Contoh: kasir plus stok plus laporan penjualan, terhubung ke payment gateway.
• Sistem dengan banyak peran, banyak cabang, dan alur persetujuan: 6 sampai 12 bulan. Bukan karena kodenya banyak, tetapi karena keputusan yang harus diambil juga banyak.

Perhatikan polanya: waktu bertambah bukan sebanding dengan jumlah fitur, melainkan sebanding dengan jumlah orang yang harus menyetujui sesuatu.

Cara memeriksa jadwal yang Anda terima

Kalau seorang vendor memberi Anda satu angka tunggal untuk seluruh proyek, minta perinciannya. Jadwal yang bisa dipercaya hampir selalu berbentuk bertahap, dengan hasil yang bisa dipakai di setiap tahap.

• Minta jadwal per tahap, bukan satu tanggal akhir. Tanyakan: apa yang bisa saya pakai setelah minggu keempat?
• Tanyakan berapa lama waktu yang dialokasikan untuk menunggu keputusan Anda. Kalau angkanya nol, jadwal itu tidak realistis.
• Tanyakan apa yang terjadi kalau satu integrasi pihak ketiga ternyata lebih rumit. Vendor yang baik sudah memikirkan ini dan punya rencana cadangan.
• Tanyakan bagaimana cara menghentikan proyek di tengah jalan. Bukan karena Anda berencana berhenti, tetapi karena vendor yang tidak punya jawaban untuk ini biasanya juga tidak punya rencana yang jelas.

Cara kami menyusun jadwal

Kami menulis jadwal per tahap dengan hasil yang bisa Anda uji di setiap tahap, bukan satu tanggal akhir yang jauh. Tahap pertama biasanya dua sampai empat minggu dan menghasilkan sesuatu yang benar-benar bisa dipakai, walaupun belum lengkap.

Kami juga menuliskan perkiraan waktu tunggu keputusan Anda secara terpisah dari waktu pengerjaan. Itu sering membuat total jadwal terlihat lebih panjang — dan memang lebih panjang. Tetapi jadwal yang mengaku tidak perlu menunggu keputusan siapa pun adalah jadwal yang akan meleset.

Kalau setelah percakapan awal kami menilai tenggat Anda tidak mungkin dicapai, kami akan mengatakannya sebelum Anda membayar apa pun.

Langkah berikutnya

Kalau Anda punya tenggat tertentu — peluncuran produk, musim ramai, atau keharusan dari kantor pusat — sampaikan tenggat itu beserta tanggalnya. Kami akan menjawab dengan dua hal: apakah mungkin, dan apa yang harus dikorbankan bila dipaksakan.

Kami lebih memilih memberi tahu Anda sekarang bahwa tenggatnya tidak realistis, daripada memberi jadwal yang menyenangkan hari ini lalu menghilang di bulan ketiga.