“Ini cuma bug kecil kan? Paling 5 menit selesai.”
Pernah denger kalimat ini? Atau variasinya: “Tinggal ganti satu baris doang, kan?” dan “Kok bisa seharian cuma buat fix ini?”
Kalau kamu developer, kemungkinan besar pernah dengar dari atasan, project manager, atau client. Saya sendiri sudah beberapa kali, dan jujur reaksi pertama saya dulu cuma senyum kecut hehe. Padahal mereka memang tidak wajib tahu apa itu N+1 query. Yang perlu mereka tahu cuma kenapa sesuatu yang kelihatannya sepele bisa lama.
Nah, mari saya ceritakan apa saja yang bisa terjadi di balik bug yang kelihatannya sepele itu, lalu cara saya menjelaskannya.
Anatomi “1 Bug = 3 Hari” #
Misalnya ada bug: data laporan tidak muncul di dashboard. Sekilas kelihatan gampang, tinggal benerin tampilannya, kan?
Ternyata setelah diperiksa:
- Datanya memang tidak ada: bukan soal tampilan. Query yang harusnya menyimpan data ke database tidak jalan di kondisi tertentu.
- Query-nya bermasalah: ada race condition yang muncul kalau 2 user mengakses bersamaan.
- Skema database perlu diubah: untuk menangani race condition tadi, perlu tambah constraint baru.
- Data yang sudah ada harus dimigrasi: skema berubah, jadi data lama ikut disesuaikan.
- Harus di-test: bukan cuma test case baru, tapi juga memastikan fitur lama tidak ikut rusak.
Jadi yang tadinya kelihatan “data tidak muncul” ternyata rantainya begini: bug di query → race condition → perubahan skema → migrasi data → testing end-to-end. Dari “ganti satu baris” jadi menyentuh 4 layer sistem. Ya… lumayan juga hahaha.
Analogi Rumah Bocor #
Bayangkan kamu lapor ke pemilik rumah: “Pak, ada noda di dinding.”
Pemilik rumah pikir: “Ah, tinggal cat ulang. 30 menit beres.”
Tapi setelah diperiksa ternyata:
- Noda di dinding karena pipa di balik tembok bocor
- Pipa bocor karena sambungannya sudah berkarat
- Sambungan berkarat karena ventilasi di atap tersumbat, jadi uap air menumpuk
- Untuk memperbaiki semuanya, atap harus dibuka dulu, baru ganti pipa, baru cat ulang dinding
Pemilik rumah melihat noda. Tukang melihat pipa, sambungan, ventilasi, dan atap. Masalahnya sama, tapi yang kelihatan oleh masing-masing beda.
Begitu juga kalau atasan dan developer ngobrolin bug.
Tiga Langkah Menjelaskan Masalah Teknis #
Setelah beberapa kali salah paham (dan sempat kesal sendiri), saya menemukan pola yang lumayan membantu: Terjemah, Visualkan, Kaitkan. Namanya saya karang sendiri ya, jangan dicari di buku mana pun.
1. Terjemah: Dari Bahasa Teknis ke Bahasa Risiko #
Jangan berhenti di istilah teknis. Jelaskan dampaknya.
Kurang efektif:
“Ada N+1 query di endpoint laporan. Setiap kali load, dia query satu-satu ke database. Kalau datanya 1000 row, berarti 1001 query. Makanya lambat.”
Daripada cuma menyebut jumlah query, ceritakan dampaknya ke bisnis.
Lebih efektif:
“Sistem sekarang mengambil data satu per satu, padahal datanya bisa ratusan. Jadi makin banyak data, makin lambat. Kalau dibiarkan, saat user mencapai seribu, halaman laporan bisa load sampai 30 detik. User akan mengira sistemnya error lalu pergi.”
Contohnya:
| Bahasa Developer | Bahasa Bisnis |
|---|---|
| N+1 query | Makin banyak data, makin lambat |
| 1001 query | Load sampai 30 detik |
| Perlu refactor | Kalau dibiarkan, user akan pergi |
Kamu bukan sedang menyederhanakan masalah, tapi menerjemahkan konsekuensinya.
2. Visualkan: Pakai Analogi, Bukan Diagram Arsitektur #
Kalau pendengar tidak akrab dengan diagram arsitektur (dan jujur, kebanyakan memang tidak), analogi sehari-hari jauh lebih membantu.
Beberapa analogi yang sering saya pakai:
- Refactoring = merenovasi rumah yang sudah berdiri. Tidak bisa asal ganti lantai tanpa cek fondasinya dulu.
- Technical debt = utang bank. Bisa ambil jalan pintas sekarang, tapi suatu saat harus dibayar, plus bunga.
- Testing = sabuk pengaman. Mobil tidak jadi lebih cepat, tapi kecelakaan tidak berubah jadi bencana.
- Race condition = dua orang mau masuk lewat pintu yang sama dari arah berlawanan. Kalau tidak ada aturan siapa duluan, ya saling halang.
- Deployment = ganti ban mobil sambil jalan. Harus hati-hati supaya penumpang tidak merasa.
Kuncinya: analogi harus dari dunia yang familiar buat pendengarnya. Kalau atasanmu orang keuangan, pakai analogi investasi. Kalau orang marketing, pakai analogi campaign.
3. Kaitkan ke Prioritas Mereka #
Hubungkan penjelasanmu dengan hal yang perlu mereka putuskan, seperti deadline, budget, dan risiko:
- “Kalau kita fix sekarang dengan 2 hari, kita mencegah downtime yang bisa 10x lebih mahal nanti.”
- “Ini bukan soal bikin fitur baru, tapi memastikan fitur yang sudah jalan tidak tiba-tiba mati.”
- “Risikonya: kalau tidak ditangani, data laporan bisa tidak akurat. Padahal data laporan itu yang dipakai untuk keputusan bisnis.”
Template Praktis #
Kalau harus menjelaskan masalah teknis ke non-teknis, saya pakai template singkat ini:
Apa yang terjadi? (1-2 kalimat, tanpa jargon)
Apa dampaknya? (ke user / ke bisnis / ke timeline)
Berapa lama untuk fix? (estimasi realistis, bukan yang optimistis)
Apa rencananya? (langkah besarnya saja, tanpa detail teknis)
Apa risikonya kalau ditunda? (ini yang sering bikin keputusan jadi lebih cepat)
Contoh:
Apa yang terjadi? Laporan bulanan tidak menampilkan data yang diinput setelah tanggal 15.
Apa dampaknya? Manajer tidak bisa lihat data lengkap untuk keputusan bulan ini.
Berapa lama? 2-3 hari.
Rencananya? Perbaiki cara sistem menyimpan data, sesuaikan data yang sudah ada, dan pastikan fitur lain tidak terpengaruh.
Risiko kalau ditunda? Data yang hilang bisa makin banyak, dan perbaikannya makin lama karena data yang harus disesuaikan makin banyak.
Dari Bug ke Dampak #
Dua contoh laporan tadi kira-kira menunjukkan caranya: mulai dari data yang tidak muncul, lalu sampaikan dampak dan rencana perbaikannya. Kalau kamu punya pengalaman serupa waktu menjelaskan masalah teknis, hubungi saya. Siapa tahu bisa saling curhat hehe.
Tag: communication · soft-skill · teaching