Sebuah perusahaan distribusi skala menengah di Tangerang datang ke saya dengan keinginan yang umum: satu aplikasi yang dipakai semua driver untuk segalanya. Enam bulan kemudian, separuh fitur yang sudah mereka bayar jadi beban mati, dan satu fitur kecil justru diam-diam menjadi tak tergantikan. Studi kasus aplikasi driver logistik ini sebenarnya tentang satu pelajaran yang terus berulang dalam software lapangan.
Fitur yang bertahan adalah fitur yang memberi sesuatu balik ke driver. Fitur yang mati adalah fitur yang dirancang di ruang rapat oleh orang yang tidak pernah merasakan satu shift pun di jalan. Jarak antara niat kantor pusat dan realita lapangan itulah tempat sebagian besar software operasional berakhir mati.
Saya ingin membedah persis apa yang berhasil, apa yang gagal, dan perubahan cara kami membangun yang membalikkan keadaan proyek ini.
Latar Belakang
Perusahaan ini menjalankan sekitar 40 driver untuk pengiriman last-mile dan antar-gudang di wilayah Jabodetabek. Sebelum ada aplikasi, semua berjalan di atas kertas: surat jalan cetak, tanda tangan tulis tangan, dan grup WhatsApp tempat driver mengirim foto saat pelanggan komplain. Rekonsiliasi akhir hari menghabiskan waktu dua staf admin hampir semalaman.
Briefnya ambisius. Kantor pusat menginginkan optimasi rute, pelacakan GPS langsung, chat dalam aplikasi, bukti pengiriman digital, pencatatan bahan bakar, dan dashboard performa driver. Di atas kertas, ini terlihat seperti menara kontrol. Dalam praktiknya, kami akan belajar fitur mana yang benar-benar akan dibuka driver jam 2 siang di tengah macet dengan mesin motor menyala.
Kami merilis versi pertama dengan semua fitur sekaligus. Itu kesalahannya, dan itu pula yang mengajari kami paling banyak.
Yang Berhasil
Dua fitur langsung mendapat tempatnya hampir seketika, dan keduanya punya satu kesamaan: menghemat waktu driver atau melindungi driver dari kesalahan yang dituduhkan ke mereka.
- Foto bukti pengiriman dengan cap waktu otomatis dan cap GPS. Driver mengadopsi ini dalam hitungan hari tanpa pelatihan. Kenapa? Karena ini melindungi mereka. Ketika pelanggan mengklaim paket tidak pernah sampai, driver punya foto berstempel, bukan sekadar argumen. Fitur ini melayani orang yang memegang ponsel, bukan sekadar kantor pusat.
- Update status satu-ketuk (tiba, terkirim, gagal). Tiga tombol besar, tanpa perlu mengetik. Ini menggantikan grup WhatsApp dan memangkas rekonsiliasi akhir hari dari semalaman jadi sekitar 20 menit. Admin menyukainya, tapi yang lebih penting, driver merasa ini lebih cepat daripada mengetik pesan.
Polanya jelas. Kedua fitur pemenang ini mengurangi friksi bagi pengguna lapangan. Tak satu pun meminta driver mengerjakan hal ekstra demi dashboard orang lain.
Yang Gagal
Fitur optimasi rute adalah mahkota dari brief itu, dan itu pula kegagalan terbesarnya. Kantor pusat membayangkan aplikasi memberi tahu driver urutan pemberhentian yang paling efisien. Driver mengabaikannya sepenuhnya.
Berikut alasannya, dan ini bukan soal keras kepala:
- Pengetahuan lokal mengalahkan algoritma. Driver tahu gang mana yang macet pada jam-jam tertentu, pelanggan mana yang hanya bisa menerima barang setelah makan siang, dan gang mana yang tidak bisa dilewati truk. Optimizer tidak tahu semua itu dan terus menyarankan urutan yang justru membuang waktu.
- Menambah langkah tanpa imbalan. Untuk memakainya, driver harus memasukkan semua titik pemberhentian di pagi hari, yang memakan waktu 10 menit yang tidak mereka miliki. Imbalannya adalah rute yang sering mereka tidak setujui.
- Tanpa kepercayaan, tanpa adopsi. Setelah optimizer mengarahkan dua driver ke jalan yang tutup karena ada pasar kaget, seluruh fitur ini kehilangan kredibilitas. Pengguna lapangan tidak akan memaafkan apa pun yang membuat mereka terlihat buruk di depan pelanggan.
Chat dalam aplikasi juga mati diam-diam. Driver sudah punya WhatsApp, sudah terbiasa, dan tidak akan pindah aplikasi chat demi pekerjaan. Kami sudah membangun ulang sesuatu yang lebih buruk dari alat gratis yang sudah mereka pakai.
Berikut skor jujur dari rilis pertama itu:
| Fitur | Prioritas kantor pusat | Penggunaan nyata oleh driver |
|---|---|---|
| Foto bukti pengiriman | Sedang | Sangat tinggi |
| Update status satu-ketuk | Rendah | Sangat tinggi |
| Optimasi rute | Tertinggi | Nyaris nol |
| Chat dalam aplikasi | Tinggi | Nyaris nol |
| Pencatatan bahan bakar | Sedang | Rendah, sporadis |
Solusinya: Bangun Bersama Driver, Rilis dalam Potongan Mingguan
Perubahan arah ini bukan soal engineering yang cerdik. Ini soal siapa yang ada di ruangan. Kami mengajak dua driver berpengalaman untuk panggilan singkat setiap Jumat dan menanyakan satu pertanyaan: apa yang membuang waktumu minggu ini?
Itu me-reset roadmap kami. Kami menghapus optimasi rute dan chat. Kami fokus penuh pada dua fitur pemenang: pengambilan foto yang lebih cepat, dukungan offline untuk area tanpa sinyal, dan pemilih alasan gagal-kirim sederhana yang memang dibutuhkan admin untuk tindak lanjut.
Kami juga beralih ke rilis dalam potongan mingguan, bukan rilis besar per kuartal. Setiap minggu kami merilis satu perubahan kecil, memantau angka penggunaannya, dan membiarkan driver "memilih" lewat jempol mereka. Fitur yang tidak dibuka dalam dua minggu langsung dicoret. Ini disiplin yang sama yang saya bahas dalam merancang cakupan MVP yang benar-benar rilis: bangun hal terkecil yang benar-benar dipakai pengguna nyata, lalu biarkan bukti yang mengarahkan potongan berikutnya.
Dalam dua bulan, penggunaan aktif harian di kalangan driver naik dari sekitar 55 persen menjadi lebih dari 90 persen. Aplikasi ini menjadi lebih kecil sekaligus lebih banyak dipakai di saat yang sama, yang menunjukkan bahwa cakupan awal itulah masalahnya, bukan teknologinya.
Pelajaran yang Bisa Diambil
Software lapangan hidup atau mati berdasarkan adopsi oleh orang di lapangan, bukan berdasarkan ambisi brief. Kalau sebuah fitur tidak menghemat waktu driver atau melindungi mereka dari kesalahan yang dituduhkan, mereka akan mencari jalan memutar, dan tidak ada mandat dari kantor pusat yang bisa mengubah itu dalam jangka panjang.
Kalau Anda sedang membangun aplikasi operasional apa pun, terapkan tiga aturan ini. Libatkan pengguna akhir yang sesungguhnya di ruang desain sejak hari pertama. Rilis dalam potongan kecil yang cukup untuk mengukur adopsi minggu demi minggu. Dan berani mencoret fitur favorit Anda sendiri saat data penggunaan bilang tidak ada yang mau memakainya.
Item paling mahal dalam rilis pertama itu justru fitur yang paling dibanggakan semua orang. Itulah jebakannya. Untuk lebih jauh soal kenapa orang yang membangun sistem bisa melihat celah yang tidak terlihat oleh konsultan murni, lihat consultants vs builders. Dan kalau Anda mencari mitra teknis yang merancang software di sekitar orang-orang yang benar-benar memakainya, itulah jenis pekerjaan yang saya ambil lewat partnership.