Agile atau Waterfall: Mana yang Cocok untuk Proyek Anda

Dua nama ini muncul di proposal dan terdengar seperti urusan internal tim developer. Untuk Anda yang membayar, bedanya sederhana: kapan Anda tahu software yang dibangun benar-benar cocok dengan cara kerja Anda.

Waterfall memutuskan semuanya di atas kertas dulu, lalu memperlihatkan hasilnya di akhir. Agile mengunci ruang lingkup satu tahap pendek, menyerahkan sesuatu yang bisa Anda buka, lalu membiarkan Anda mengubah tahap berikutnya. Yang perlu Anda nilai ada dua: seberapa sering Anda melihat software yang berjalan, dan seberapa sering Anda boleh berhenti.

Apa yang diminta masing-masing pendekatan dari Anda

Waterfall meminta semua keputusan di depan. Anda menghabiskan berminggu-minggu bersama tim mereka untuk menjelaskan proses Anda, menyetujui dokumen tebal, lalu menandatangani satu angka untuk seluruh proyek. Setelah itu Anda menunggu. Pertemuan berikutnya biasanya berupa laporan kemajuan dalam bentuk persentase, dan software yang bisa Anda buka sendiri datang menjelang akhir.

Agile meminta keputusan yang lebih kecil, tetapi lebih sering. Anda menentukan apa yang paling penting dikerjakan beberapa minggu ke depan, melihat hasilnya berjalan, lalu menentukan lagi apa berikutnya. Waktu Anda terpakai lebih rutin dengan porsi yang kecil. Yang sering membuat pemilik bisnis ragu, angka totalnya tidak diumumkan di awal.

Keduanya meminta porsi yang sama banyak dari Anda, hanya dengan jadwal yang berbeda. Yang benar-benar terasa adalah jarak antara saat Anda salah menjelaskan sesuatu dan saat kesalahan itu ketahuan. Latar belakang pemikiran agile untuk pemilik bisnis kami bahas lebih panjang di panduan agile dan lean.

Di mana waterfall masih masuk akal

Waterfall bekerja baik ketika hasil akhirnya sudah pasti sejak awal dan tidak akan bergeser.

Laporan yang formatnya ditentukan regulator termasuk di situ. Begitu juga proses yang sudah stabil bertahun-tahun dan tidak akan berubah dalam setahun ke depan, misalnya perhitungan yang aturannya tertulis dan jarang direvisi. Kasus paling jelas adalah penggantian sistem lama. Sistem yang sekarang berjalan sudah menjadi spesifikasinya, lengkap dengan semua perilaku anehnya, jadi tidak banyak yang perlu ditemukan di tengah jalan.

Terus terang saja, dokumen panjang juga memberi rasa tenang. Ia terlihat seperti kepastian, dan untuk orang yang akan menandatangani pengeluaran besar, rasa itu berharga. Masalahnya muncul ketika dokumennya menggambarkan proses yang masih berubah.

Di mana pendekatan ini gagal untuk bisnis yang sedang tumbuh

UKM biasanya memesan software custom justru karena prosesnya belum mapan. Pesanan dicatat di spreadsheet yang terus ditambah kolomnya, atau ada satu langkah yang aturannya hanya ada di kepala satu orang dan tidak pernah ditulis.

Proses seperti itu bergerak. Spesifikasi yang ditulis bulan pertama menggambarkan cara kerja yang sudah tidak ada lagi di bulan kelima, karena tim Anda sendiri sudah mengubahnya beberapa kali. Pemasok baru datang dengan syarat pembayaran berbeda, atau admin menemukan jalan pintas yang ternyata lebih baik.

Yang paling mahal adalah urutannya. Kalau software baru pertama kali Anda buka di akhir, maka saat itu juga pertama kalinya Anda bisa keberatan. Kepala operasional yang membuka layar pemesanan akan langsung bilang bahwa dua kolom itu tidak pernah diketahui saat pesanan dibuat. Mendengar itu di minggu kedua berarti memperbaiki satu layar. Mendengarnya setelah semuanya jadi berarti membongkar semua yang dibangun di atasnya, ditambah perdebatan soal siapa yang menanggung biayanya.

Dua pertanyaan yang menentukan pilihannya

Apa pun nama metodenya, Anda bisa menilai proposal dengan dua pertanyaan.

Seberapa sering Anda melihat software yang benar-benar berjalan? Maksudnya link yang bisa Anda buka di ponsel sendiri, bukan laporan kemajuan atau tangkapan layar desain. Jawaban "setiap minggu" dan jawaban "di akhir fase dua" menghasilkan proyek yang sangat berbeda, meski keduanya bisa saja menyebut dirinya agile.

Setelah titik mana Anda boleh berhenti tanpa perdebatan? Berhenti selalu mungkin secara hukum, tapi yang Anda cari adalah titik berhenti yang sudah disepakati sejak awal, lengkap dengan harga dan ruang lingkupnya. Kalau satu-satunya titik berhenti ada di akhir proyek, Anda sebenarnya hanya punya satu keputusan, dan keputusan itu sudah diambil waktu tanda tangan.

Gabungan yang sebenarnya dibutuhkan kebanyakan proyek UKM

Kekhawatiran di balik waterfall adalah biaya yang tidak jelas ujungnya. Kekhawatiran di balik agile adalah menunggu terlalu lama untuk tahu apakah uangnya terpakai dengan benar. Keduanya bisa dijawab sekaligus dengan memecah proyek menjadi tahap-tahap yang masing-masing punya harga tetap.

Begini cara kami menjalankannya. Ruang lingkup dan harga setiap tahap disepakati tertulis sebelum tahap itu dimulai. Jadi Anda bisa berhenti setelah tahap mana pun tanpa perdebatan, karena tahap berikutnya memang belum pernah Anda setujui. Komitmennya pendek seperti agile, angkanya pasti seperti waterfall.

Tahap pertama adalah discovery, memakan satu sampai dua minggu, dan hasilnya rencana tertulis beserta harga tetap. Dokumen itu milik Anda mau lanjut atau tidak, jadi Anda sudah tahu lebih dulu berapa biaya untuk mengukur besarnya pekerjaan ini. Selama pembangunan, ada software yang berjalan setiap minggu dan link preview privat sejak minggu pertama.

Risiko terlantar di tengah jalan ditutup dari sisi lain. Kode, server, domain, dan semua akun sudah atas nama Anda sejak hari pertama, bukan baru saat handover. Kalau Anda berhenti setelah tahap kedua, yang sudah dibangun tetap bisa dibuka, dibaca, dan dilanjutkan oleh siapa pun yang Anda pilih. Urutan tahapnya kami uraikan di pendekatan dari ide sampai peluncuran, dan cara memilih isi tahap pertama ada di tulisan tentang membangun versi kecil dulu.

Yang perlu Anda tanyakan ke vendor sebelum tanda tangan

Nama metode di halaman pertama proposal tidak memberi tahu banyak. Jawaban atas pertanyaan berikut memberi tahu hampir semuanya:

• Kapan saya pertama kali dapat link preview yang bisa saya buka sendiri, dan seberapa sering isinya diperbarui?
• Selama pembangunan, saya bicara dengan siapa? Orang yang menulis kodenya, atau orang yang menyampaikan pesan ke orang yang menulis kodenya?
• Nama siapa yang tercantum di server, domain, dan akun layanan pihak ketiga, mulai kapan?
• Kalau kami memutuskan berhenti setelah tahap kedua, apa yang saya pegang dan berapa yang masih harus dibayar?
• Ada bagian pekerjaan yang disubkontrakkan? Orang yang saya temui hari ini masih yang sama enam bulan lagi?

Di tempat kami, Anda bicara langsung dengan engineer yang membangunnya. Tidak ada yang disubkontrakkan dan tidak ada pergantian orang setelah tanda tangan. Pertanyaan yang sama layak Anda ajukan ke studio mana pun, dan kalau jawabannya berputar, Anda sudah dapat informasi yang Anda butuhkan. Pertimbangan lain sebelum memesan software custom kami kumpulkan di panduan memesan software custom.

Bawa proyeknya, kita tentukan bentuknya bersama

Daripada memilih metode dari namanya, ceritakan saja prosesnya. Obrolan pertamanya gratis dan tanpa deck. Kita lihat bersama seberapa stabil cara kerja Anda sekarang, lalu tentukan apakah proyeknya cocok dipecah per tahap atau memang sudah cukup pasti untuk dikerjakan sekaligus. Kalau yang Anda butuhkan ternyata sudah tersedia dalam bentuk alat yang tinggal dibeli, kami akan bilang begitu.

Kalau pekerjaannya jadi, discovery memberi Anda rencana tertulis dan harga tetap dalam satu sampai dua minggu, dan dokumen itu milik Anda apa pun keputusan Anda setelahnya. Gunakan formulir kontak yang membuka WhatsApp, atau kirim email ke hello@arktik.id.