“Ini cuma bug kecil kan? Paling 5 menit selesai.”
Pernah denger kalimat ini? Atau mungkin variasinya: “Tinggal ganti satu baris doang, kan?”, “Kok bisa seharian cuma buat fix ini?”
Kalau kamu developer, hampir pasti pernah. Dan kalimat itu biasanya datang dari atasan, project manager, atau client — orang yang tidak perlu tahu apa itu N+1 query, tapi perlu tahu kenapa sesuatu yang terlihat simpel memakan waktu yang tidak simpel.
Ini bukan tentang menyalahkan siapa. Ini tentang kenapa gap komunikasi ini terjadi dan bagaimana menutupinya.
Anatomi “1 Bug = 3 Hari” #
Ceritanya begini. Ada bug: data laporan tidak muncul di dashboard. Di surface, terlihat simpel — tinggal fix tampilannya, kan?
Ternyata, setelah diperiksa:
- Datanya tidak ada — bukan masalah tampilan, tapi query yang seharusnya menyimpan data ke database tidak berjalan di kondisi tertentu
- Query-nya bermasalah — ada kondisi race condition yang muncul saat 2 user mengakses bersamaan
- Skema database perlu diubah — untuk menangani race condition itu, perlu tambah constraint baru
- Data existing harus di-migrasi — perubahan skema berarti data yang sudah ada harus disesuaikan
- Harus di-test — dan bukan cuma test case baru, tapi juga memastikan fitur lama tidak break
Jadi, yang terlihat “data tidak muncul” sebenarnya adalah: bug di query → race condition → perubahan skema → migrasi data → testing end-to-end. Dari “ganti satu baris” menjadi “sentuh 4 layer sistem”.
Analogi Rumah Bocor #
Bayangkan kamu lapor ke pemilik rumah: “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 sambungan sudah berkarat
- Sambungan berkarat karena ventilasi di atap tersumbat, jadi uap air menumpuk
- Untuk fix semuanya, harus buka atap dulu, baru ganti pipa, baru cat ulang dinding
Pemilik rumah melihat noda. Tukang melihat pipa, sambungan, ventilasi, dan atap. Keduanya melihat masalah yang sama, tapi tingkat kedalaman yang berbeda.
Ini yang terjadi antara atasan dan developer.
Tiga Langkah Menjelaskan Masalah Teknis #
Setelah beberapa kali mengalami miskomunikasi (dan belajar dari kesalahan), saya menemukan pola yang konsisten membantu. Saya sebut Terjemah, Visualkan, Kaitkan.
1. Terjemah: Dari Bahasa Teknis ke Bahasa Risiko #
Kesalahan paling umum: menjelaskan masalah teknis dengan istilah teknis.
Tidak 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.”
Atasan tidak peduli berapa query-nya. Yang dia pedulikan: dampaknya ke bisnis apa?
Lebih efektif:
“Sistem sekarang mengambil data satu per satu, padahal datanya bisa ratusan. Jadi semakin banyak data, semakin lambat. Kalau dibiarkan, saat user mencapai seribu, halaman laporan bisa load sampai 30 detik — user akan berpikir sistemnya error dan meninggalkan aplikasi.”
Perhatikan pergeserannya:
| Bahasa Developer | Bahasa Bisnis |
|---|---|
| N+1 query | Semakin banyak data, semakin lambat |
| 1001 query | Load sampai 30 detik |
| Perlu refactor | Kalau dibiarkan, user akan pergi |
Bukan berarti kamu menyederhanakan — kamu menterjemahkan konsekuensinya.
2. Visualkan: Pakai Analogi, Bukan Diagram Arsitektur #
Diagram arsitektur bagus untuk sesama developer. Untuk non-teknis, analogi jauh lebih kuat.
Beberapa analogi yang sering saya pakai:
- Refactoring = merenovasi rumah yang sudah berdiri. Tidak bisa cuma ganti lantai tanpa cek fondasinya dulu.
- Technical debt = utang bank. Bisa ambil jalan pintas sekarang (utang), tapi suatu saat harus dibayar — dengan bunga.
- Testing = sabuk pengaman. Tidak membuat mobil jadi lebih cepat, tapi membuat kecelakaan tidak menjadi bencana.
- Race condition = dua orang mau masuk pintu yang sama dari arah berlawanan. Kalau tidak ada aturan siapa dulu, bisa saling menghalangi.
- Deployment = ganti ban mobil saat jalan. Harus hati-hati supaya penumpang tidak merasakan.
Kuncinya: analogi harus dari dunia yang familiar bagi pendengar. Kalau atasanmu dari dunia keuangan, pakai analogi investasi. Kalau dari dunia marketing, pakai analogi campaign.
3. Kaitkan ke Prioritas Mereka #
Atasan punya prioritas yang berbeda dengan developer. Prioritas kita: kode bersih, maintainable, scalable. Prioritas mereka: deadline, budget, risiko.
Jadi saat menjelaskan, kaitkan ke prioritas mereka:
- “Kalau kita fix sekarang dengan 2 hari, kita mencegah downtime yang bisa 10x lebih mahal nanti.”
- “Ini bukan tentang membuat fitur baru — ini tentang memastikan fitur yang sudah jalan tidak tiba-tiba berhenti.”
- “Risikonya: kalau tidak ditangani, data laporan bisa tidak akurat. Dan data laporan itu yang dipakai untuk keputusan bisnis.”
Kalimat “technical debt” mungkin tidak menggerakkan atasan. Tapi “kalau tidak ditangani sekarang, kita bisa kehilangan data transaksi” — itu baru didengar.
Template Praktis #
Saat 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 optimistis)
Apa rencananya? (langkah-langkah besar, tanpa detail teknis)
Apa risikonya kalau ditunda? (ini yang sering membuat keputusan 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 bisa makin banyak yang hilang, dan perbaikannya makin lama karena jumlah data yang harus disesuaikan makin besar.
Singkat, jelas, dan — yang paling penting — tidak ada istilah teknis.
Komunikasi Itu Skill #
Banyak developer — termasuk saya dulu — berpikir bahwa kalau kode sudah bagus, kerjaan sudah selesai. Tapi kenyataannya, kalau tidak bisa dijelaskan, tidak akan didukung. Dan tanpa dukungan — baik itu waktu, resource, atau kepercayaan — kode terbaik pun tidak akan pernah deploy.
Komunikasi bukan bakat. Ini skill yang bisa dilatih, persis seperti menulis kode. Setiap kali kamu menjelaskan masalah teknis ke non-teknis, kamu sharpen skill itu. Awalnya mungkin canggung. Tapi lama-lama, jadi refleks.
Dan refleks itu sangat berguna — bukan cuma di dunia kerja, tapi juga saat mengajar. Karena mengajar, pada dasarnya, adalah menjelaskan hal kompleks dengan cara yang accessible.
Kalau kamu tertarik dengan topik teaching dan komunikasi teknik, atau punya pengalaman serupa yang ingin didiskusikan, hubungi saya.
Tag: communication · soft-skill · teaching