Tahapan Pembuatan Aplikasi: Apa yang Terjadi Tiap Minggu dan Apa Peran Anda

Banyak klien yang baru pertama kali memesan aplikasi membayangkan prosesnya begini: kirim brief, tunggu tiga bulan, aplikasi jadi. Kenyataannya jarang seperti itu. Proyek software adalah rangkaian panjang keputusan kecil, dan cukup banyak di antaranya cuma bisa diputuskan oleh Anda. Di bawah ini urutan tahapan di proyek yang umum untuk usaha kecil dan menengah, berapa lama biasanya tiap tahap, dan apa saja yang akan diminta vendor dari Anda. Tahu ini sebelum tanda tangan kontrak adalah cara paling mudah supaya jadwal tidak molor.

SDLC Versi Lapangan

SDLC adalah singkatan dari Software Development Life Cycle, atau siklus hidup pengembangan software. Di buku teks, tahapannya biasanya ditulis perencanaan, analisis, desain, implementasi, testing, deployment, dan maintenance, sering digambar sebagai lingkaran yang rapi. Proyek sungguhan kira-kira mengikuti urutan yang sama, tapi tahapannya saling tumpang tindih dan namanya berbeda. Di proposal vendor dan meeting mingguan, yang akan Anda dengar adalah discovery, desain UI/UX, development, QA dan UAT, deploy, serah terima, dan maintenance.

Urutannya lebih penting daripada namanya. Keputusan di awal murah untuk diubah, dan makin mahal kalau diubah belakangan. Memindahkan tombol di desain Figma cuma butuh beberapa menit. Memindahkan tombol yang sama setelah backend, aplikasi, dan testing selesai bisa makan beberapa hari. Mengubah alur approval setelah sistem live bisa makan berminggu-minggu.

Waterfall, Agile, dan Model yang Dipakai Proyek Fixed Price

Waterfall menuntaskan satu tahap sebelum lanjut ke tahap berikutnya: semua kebutuhan dulu, lalu semua desain, lalu semua coding, baru testing. Anggarannya bisa diprediksi, tapi Anda baru melihat aplikasi yang jalan di akhir, dan kejutan muncul justru saat paling mahal untuk diperbaiki. Agile bekerja dalam siklus pendek bernama sprint, biasanya satu atau dua minggu, dan rencananya disusun ulang setiap selesai sprint. Aplikasinya kelihatan sejak awal, tapi scope-nya fleksibel dan biayanya umumnya dihitung per waktu. Bagian keuangan biasanya kurang suka model ini.

Kebanyakan proyek fixed price di Indonesia ada di tengah-tengah, termasuk proyek kami. Discovery dan desain dikerjakan di depan lalu disetujui, sehingga scope dan harga terkunci. Setelah itu development berjalan dalam sprint dengan demo di setiap akhir sprint, tetap di dalam scope tadi. Ide baru masuk change request, atau ditukar dengan fitur lain yang ukurannya mirip. Pendapat kami, model campuran ini paling cocok untuk proyek pertama. Keuangan dapat angka yang pasti, dan Anda bisa melihat serta mengoreksi aplikasinya jauh sebelum proyek selesai.

Tahapan, Durasi, dan Peran Anda

Tabel ini untuk proyek kecil sampai menengah, misalnya sistem internal dengan tiga atau empat role pengguna, atau portal pelanggan dengan payment gateway. Dari awal sampai live biasanya tiga sampai enam bulan. Durasinya mengasumsikan Anda merespons dengan cepat, dan asumsi inilah yang paling sering meleset.

Discovery dan Desain: Saat Waktu Anda Paling Berharga

Discovery biasanya berupa dua atau tiga workshop masing-masing sekitar dua jam, ditambah pertanyaan susulan. Vendor ingin tahu bagaimana pekerjaan dilakukan sekarang, termasuk pengecualian yang tidak pernah ditulis. Hadirkan orang yang benar-benar mengerjakannya, bukan cuma atasannya. Admin gudang bisa menjelaskan dalam lima menit bahwa barang retur dicatat di sheet terpisah, sesuatu yang belum tentu diketahui manajernya. Hasil discovery berupa dokumen scope dengan alur pengguna dan estimasi yang pasti.

Desain biasanya dimulai dari wireframe, lalu naik ke prototipe Figma yang bisa Anda coba klik di HP. Jatah revisi dua putaran itu umum. Manfaatkan. Ini kesempatan terakhir untuk berubah pikiran dengan biaya murah, dan saat ini juga semua orang yang punya hak veto harus ikut melihat, termasuk direktur yang dari awal belum sempat hadir.

Development per Sprint dengan Demo Tiap Satu atau Dua Minggu

Setiap sprint ditutup dengan demo fitur yang sudah jalan di server staging. Staging adalah salinan sistem di server terpisah yang bisa Anda buka di browser atau install di HP, berisi data uji, bukan data asli. Ikuti demonya, lalu coba sendiri fiturnya setelah meeting. Mengklik sendiri selama 20 menit biasanya menemukan lebih banyak masalah daripada menonton developer selama satu jam.

Pertanyaan pasti muncul di setiap sprint. Kalau pesanan dibatalkan, stoknya otomatis kembali atau tidak? Siapa yang boleh mengedit invoice yang sudah di-approve? Kalau jawabannya baru datang seminggu kemudian, developer terpaksa menunggu atau menebak, dan tebakan sering harus dikerjakan ulang. Integrasi juga perlu diurus sejak awal. Sandbox payment gateway seperti Midtrans cepat didapat, tapi akses API ke ERP, koneksi host-to-host dengan bank, atau sistem milik partner bisa butuh berminggu-minggu urusan administrasi di pihak mereka. Ajukan permintaannya di minggu pertama.

QA, UAT, dan Go-Live

QA adalah tester dari vendor yang mengecek sistem terhadap acceptance criteria yang sudah disepakati, di browser dan perangkat yang dipakai pengguna Anda, termasuk HP Android kelas menengah. UAT atau user acceptance testing adalah giliran Anda dan staf memakai sistem dengan skenario nyata, lalu memutuskan apakah sistemnya layak diterima. Siapkan bahannya: daftar produk asli, daftar pelanggan asli, dan transaksi bulan lalu dengan data pribadi yang sudah disamarkan. Pilih tiga sampai lima orang yang nanti memakai sistem setiap hari, dan beri mereka waktu khusus di luar pekerjaan rutin untuk menguji.

Proses deploy sendiri sering cuma beberapa hari: menyiapkan server production, mengarahkan domain, memindahkan data, lalu mengalihkan pengguna. Yang lebih menentukan adalah waktunya. Hindari tutup buku akhir bulan untuk sistem keuangan, hindari minggu-minggu menjelang Lebaran untuk sistem yang dipakai pelanggan, dan pilih Selasa pagi, bukan Jumat sore. Untuk sistem akuntansi atau stok, menjalankan proses lama dan baru secara paralel selama dua sampai empat minggu sepadan dengan repotnya.

Yang Harus Anda Siapkan, dan Kenapa Keterlambatan Sering Berawal dari Sini

Di bagian ini banyak proyek tergelincir. Dari pengalaman kami, jadwal lebih sering molor karena urusan di sisi klien daripada karena kodenya. Keputusan menunggu direktur yang sedang dinas ke luar kota. Foto produk baru datang dua bulan kemudian. Tim approval baru melihat aplikasinya pertama kali saat UAT lalu minta alur yang berbeda. Telat memberi masukan seminggu jarang berarti mundur seminggu saja, karena tim sudah pindah ke pekerjaan lain dan butuh waktu untuk kembali.

1. 1Tunjuk satu pengambil keputusan yang boleh menyetujui scope dan desain tanpa rapat komite, plus satu orang cadangan saat dia berhalangan.
2. 2Kosongkan dua sampai empat jam per minggu di kalender orang tersebut untuk demo, menjawab pertanyaan, dan review.
3. 3Sepakati satu jalur komunikasi untuk pertanyaan dan batas waktu jawabannya. Dua hari kerja itu target yang masuk akal.
4. 4Siapkan konten dari awal: teks, foto produk, daftar harga, template email dan pesan WhatsApp, halaman syarat dan kebijakan privasi.
5. 5Ajukan akses ke sistem yang sudah ada dan akun pihak ketiga di minggu pertama, misalnya API Accurate atau Jurnal, payment gateway, akun WhatsApp Business, dan akun cloud.
6. 6Siapkan data uji yang realistis dan tentukan siapa yang akan menjalankan UAT sebelum development selesai.
7. 7Libatkan semua orang yang punya hak veto di review desain, jangan baru di UAT.

Kalau dalam beberapa bulan ke depan Anda tidak bisa menyediakan pengambil keputusan selama beberapa jam per minggu, lebih baik proyeknya ditunda daripada dimulai. Lalu kalau yang Anda butuhkan cuma website company profile sederhana, sebagian besar proses ini berlebihan. Template yang bagus, konten dari Anda, dan dua sampai empat minggu biasanya cukup, dan untuk itu Anda tidak perlu software house.

Serah Terima, Garansi, dan Apa yang Perlu Diminta

Setelah live, masa garansi satu sampai tiga bulan itu umum. Garansi menutup bug terhadap scope yang disepakati, bukan fitur baru. Setelahnya ada kontrak maintenance, biasanya retainer bulanan untuk monitoring, update keamanan, dan perubahan kecil. Sebagai patokan awal, siapkan sekitar 15 sampai 20 persen dari biaya pembuatan per tahun. Sebelum pembayaran terakhir, pastikan Anda sudah memegang semua ini:

• Source code di repository Git milik perusahaan Anda di GitHub atau GitLab, dengan akses sejak sprint pertama, bukan file zip di akhir proyek.
• Akses akun cloud, domain dan DNS, akun Play Store dan App Store, payment gateway, WhatsApp Business, dan layanan email, semuanya terdaftar atas nama perusahaan Anda.
• Dokumentasi: cara setup dan deploy sistem, dokumentasi API, dan panduan pemakaian untuk admin.
• Server staging yang tetap jalan setelah live, supaya perubahan berikutnya diuji dulu sebelum sampai ke pengguna.
• Backup database yang proses restore-nya sudah pernah dicoba, dan file desain Figma.
• Berita acara UAT yang Anda tanda tangani, beserta daftar masalah yang masih tersisa kalau ada.

Tanda Proyek Mulai Melenceng

• Demo sering dilewati, atau isinya slide dan screenshot, bukan aplikasi yang jalan.
• Server staging tidak di-update selama beberapa minggu.
• Satu fitur statusnya "90 persen selesai" selama tiga sprint berturut-turut.
• Tidak ada yang bisa menjelaskan dengan jelas apa yang tersisa dan butuh berapa sprint lagi.
• Pertanyaan ke Anda menumpuk tanpa jawaban, atau sebaliknya pertanyaan Anda ke vendor.
• Developer baru muncul di tim tanpa serah terima, atau vendor enggan memberi akses repository.
• Jumlah bug saat UAT malah bertambah, bukan berkurang.

Aplikasi yang bisa dicoba di staging setiap dua minggu adalah satu-satunya laporan progres yang tidak bisa dipoles.

Di Salamun Teknologi, begini cara kami menjalankan proyek secara default: discovery dan desain dengan harga tetap, sprint dua minggu dengan demo di staging, kode di repository atas nama Anda sejak sprint pertama, dan masa garansi setelah live. Kalau ini pertama kalinya Anda memesan aplikasi, kami bisa menjelaskan seperti apa bulan pertama untuk proyek Anda.