Rating 2.9 di Play Store itu seperti nilai rapor yang bikin Anda tidak berani pulang ke rumah.
Ketika saya pertama kali memimpin development website dan aplikasi Indopaket — platform logistik di bawah ekosistem Indomaret — angka itu yang menyambut saya. Dan jujur, reaksi pertama saya bukan panik. Tapi penasaran.
Plot Twist: Masalahnya Bukan di Sistem
Ketika Anda engineer dan lihat rating jelek, insting pertama pasti: "Bug di mana? UI-nya jelek ya? Loading lambat?"
Tapi begitu saya baca satu per satu review di Play Store, kenyataannya berbeda. Mayoritas komplain bukan soal aplikasi. Melainkan soal paket yang lama sampai, tracking yang membingungkan, dan pengalaman operasional yang tidak sesuai ekspektasi.
Komplain soal sistem? Ada. Tapi proporsinya kecil.
Ini momen penting yang mengubah cara saya melihat peran software engineering: kita bukan hanya membangun sistem — kita membangun pengalaman. Dan pengalaman itu melibatkan orang, proses, dan budaya kerja yang jauh lebih luas dari sekadar kode.
Software Engineering Itu Soal People
Ada satu miskonsepsi yang sering saya temui di kalangan engineer: bahwa tugas kita selesai di titik deploy. Kode jalan, pipeline hijau, fitur live — selesai.
Tapi siapa yang pakai fitur itu? Siapa yang terdampak kalau flow-nya membingungkan? Siapa yang teriak di Play Store kalau ada yang tidak beres?
User.
Dan di balik user, ada tim operasional yang menjalankan prosesnya setiap hari. Kalau kita hanya peduli pada sistem tanpa peduli pada orang yang menggunakannya, kita sedang membangun rumah yang bagus tapi tidak bisa ditinggali.
Langkah Pertama: Bangun Tim Dulu, Baru Bangun Sistem
Sebelum ngomongin arsitektur dan tech stack, hal pertama yang saya lakukan adalah membangun kultur kolaborasi.
Kenapa? Karena project yang melibatkan banyak stakeholder tidak bisa jalan kalau timnya bekerja dalam silo. Engineering bikin fitur sendiri, operasional jalan sendiri, marketing teriak sendiri — hasilnya kacau.
Kami mulai dari hal sederhana: duduk bareng. Bukan meeting formal dengan slide 30 halaman, tapi sesi-sesi kecil dimana setiap tim bisa cerita: "Ini yang kami hadapi setiap hari."
Dari situ baru kelihatan — ternyata banyak masalah operasional yang bisa di-solve dengan penyesuaian kecil di sistem. Dan sebaliknya, banyak fitur yang kami bangun ternyata tidak relevan dengan kebutuhan lapangan.
Culture ini yang kami jaga terus sampai sekarang. Bukan cuma di awal project, tapi secara kontinu.
Jadi Lead yang Dipercaya User, Bukan Cuma Dipercaya Tim
Ada satu peran yang menurut saya sering diabaikan oleh engineering lead: menjadi jembatan antara user dan sistem.
Kebanyakan lead fokus ke dalam — manage tim, review kode, pastikan sprint jalan. Itu penting. Tapi kalau kita tidak pernah keluar dari bubble engineering, kita kehilangan konteks yang paling krusial: apa yang sebenarnya user butuhkan.
Saya memilih untuk proaktif. Bukan menunggu user komplain, tapi mengusulkan bagaimana sistem bisa mendorong operasional lebih baik. Misalnya, daripada hanya menampilkan status tracking, bagaimana kalau sistem juga memberikan estimasi yang lebih akurat berdasarkan data historis? Daripada menunggu laporan masalah, bagaimana kalau sistem bisa mendeteksi anomali lebih awal?
Ketika user melihat bahwa tim engineering tidak hanya memperbaiki bug tapi juga memikirkan cara kerja mereka, trust itu terbangun secara natural.
Survey: Penting, Tapi Jangan Jadi Budak Angka
Salah satu fitur yang kami implementasikan adalah in-app survey — mekanisme dimana user bisa menilai dan memberikan feedback langsung tentang aplikasi.
Ini penting. Sangat penting. Tapi ada jebakan di sini.
Kalau kita terlalu user-oriented, kita akan terjebak dalam siklus reaktif: user minta A, kita buat A, user minta B, kita buat B. Tanpa arah, tanpa fondasi.
Pendekatan kami: user feedback dan system review jadi pondasi, bukan pengemudi. Feedback memberi kita sinyal. Tapi keputusan teknis tetap didasarkan pada analisa menyeluruh — apakah ini scalable? Apakah ini solve root cause atau cuma symptom? Apakah ini align dengan roadmap jangka panjang?
Kombinasi mendengarkan user dan berpikir secara engineering — itulah yang membangun struktur yang solid.
Melibatkan Semua Orang, Bukan Cuma IT
Hal terakhir yang saya rasa paling berdampak: kami tidak pernah membuat keputusan produk hanya dari perspektif IT.
Setiap fitur besar, kami minta input dari tiga sisi:
Apakah ini masuk akal di lapangan?
Apakah ini bisa dikomunikasikan ke user dengan baik?
Apakah ini feasible dan maintainable?
Ini bukan demokrasi dimana semua orang vote. Ini tentang mengumpulkan perspektif supaya keputusan yang diambil punya landasan yang lebih kuat.
Hasilnya? Fitur yang kami launch lebih relevan, adopsi lebih tinggi, dan komplain lebih sedikit. Bukan karena kami lebih pintar, tapi karena kami lebih banyak mendengar.
Dari 2.9 ke 4.1 — dan Masih Naik
Rating Play Store Indopaket sekarang ada di 4.2. Bukan angka yang datang dalam semalam, dan bukan hasil dari satu fitur heroik.
Itu hasil dari keputusan kecil yang konsisten: duduk bareng tim operasional, baca review user setiap minggu, proaktif mengusulkan improvement, dan membangun culture dimana semua orang merasa punya andil dalam kualitas produk.
Kalau ada satu hal yang saya pelajari dari proses ini: rating bukan KPI engineering — rating adalah refleksi dari seberapa baik kita berkolaborasi sebagai satu tim.
Teknologi tanpa empati menghasilkan sistem yang canggih tapi tidak dipakai. Empati tanpa teknologi menghasilkan niat baik tapi tidak scalable. Gabungkan keduanya, dan Anda punya produk yang benar-benar bekerja untuk user-nya.
Saya percaya bahwa engineering leader terbaik bukan yang paling jago coding, tapi yang paling bisa menghubungkan teknologi dengan kebutuhan manusia. Bagaimana pengalaman Anda?