Prioritization in Ambiguity: Lessons from the Field as a Software Engineer
Planning is essential. But reality rarely follows the plan.
The Illusion of Perfect Planning
Every software project starts with a roadmap. Sprint planning, backlog grooming, stakeholder alignment — semua dilakukan dengan asumsi bahwa variabel-variabel di luar kendali tim sudah settled.
Tapi di lapangan, yang sering terjadi adalah:
- Stakeholder key sedang cuti atau baru onboarding
- Keputusan bisnis yang harusnya jadi acuan belum final
- Tim lintas divisi punya prioritas dan domain yang berbeda
- Designer sudah siap jalan, tapi arahnya belum jelas
Inilah yang tidak diajarkan di textbook engineering — bagaimana tetap bergerak di tengah ketidakpastian.
Case: Decision Bottleneck di Project Nyata
Di sebuah project pengembangan platform, kami dihadapkan pada dua workstream paralel:
1. Model bisnis affiliator
Butuh keputusan dari tim Marketing sebelum bisa dieksekusi secara teknis.
2. Authentication flow
Login, register, forgot password — komponen standard yang tidak bergantung pada keputusan bisnis apapun.
Masalah muncul ketika stakeholder utama di Marketing sedang tidak available. Project terancam stuck menunggu satu keputusan yang belum turun.
Ditambah lagi, ada godaan untuk "melempar semua sekaligus" ke tim Marketing begitu mereka kembali — model bisnis, UI design, auth flow — dengan asumsi makin banyak yang di-share makin cepat selesai.
Ini justru kontraproduktif. Overwhelming stakeholder dengan semua hal sekaligus hanya membuat keputusan makin lambat.
Apa yang Saya Pelajari
1. Identifikasi Blockers vs Independent Tasks
Tidak semua task punya dependency yang sama. Pertanyaan kuncinya:
"Apakah task ini akan berubah tergantung keputusan yang belum ada?"
Ya. Jika model multi-tier vs single-tier, flow dan UI bisa berbeda signifikan. Ini true blocker.
Tidak. Login, register, forgot password adalah standard — tidak terpengaruh apapun keputusan model bisnisnya. Ini independent task.
Kesimpulannya: designer bisa full gas mengerjakan auth tanpa menunggu. Progress tetap jalan.
2. Jangan Overwhelm Stakeholder
Ketika stakeholder kembali setelah tidak available, ada tendensi untuk "dump semua" sekaligus — semua pending items, semua pertanyaan, semua deliverable.
Ini justru membuat keputusan makin lambat karena:
- Stakeholder perlu effort besar untuk menyortir mana yang urgent
- Item penting bisa tenggelam di antara yang tidak terlalu penting
- Kesan pertama yang terbentuk bisa negatif
Yang lebih efektif: masuk dengan satu hal yang paling butuh keputusan, framing yang jelas, dan biarkan yang lain menyusul secara terstruktur.
3. Framing Menentukan Kecepatan Keputusan
Cara menyampaikan sesuatu ke stakeholder sangat menentukan seberapa cepat keputusan bisa diambil.
| Bukan begini | Tapi begini |
|---|---|
| "Pak, gimana update model bisnis affiliatornya?" | "Pak, designer sudah mulai jalan. Supaya arahnya tepat, bisa kita konfirmasi dulu model bisnisnya? Ini akan menentukan beberapa bagian UI yang sedang dikerjakan." |
Perbedaannya: yang kedua memberikan konteks urgensi yang logis — bukan mengejar, tapi protecting resource tim.
4. Pahami Domain Masing-masing Divisi
Marketing bukan IT. IT bukan Marketing. Ketika berkolaborasi lintas divisi, penting untuk tahu apa yang relevan bagi mereka dan apa yang tidak.
Membawa auth flow ke tim Marketing untuk direview bisa jadi culture di beberapa perusahaan — tapi membawa detail teknis implementasi backend adalah noise bagi mereka.
Semakin kita bisa menyajikan informasi yang tepat ke orang yang tepat, semakin efisien kolaborasi lintas divisi berjalan.
Framework Sederhana: BICA
Ketika menghadapi ambiguitas di project, saya menggunakan pendekatan ini:
Task ini blocking karena keputusan yang belum ada?
Ada task lain yang bisa jalan tanpa menunggu?
Siapa yang perlu dihubungi, kapan, dan dengan framing seperti apa?
Setelah keputusan turun, apa yang perlu disesuaikan?
Penutup
Software engineering bukan hanya soal menulis kode yang bersih dan arsitektur yang scalable. Di dunia nyata, engineer yang efektif adalah yang bisa navigate ambiguity — tahu mana yang harus ditunggu, mana yang bisa jalan, dan bagaimana menggerakkan keputusan yang stuck.
Planning tetap penting. Tapi kemampuan beradaptasi ketika plan bertemu realita — itulah yang membedakan engineer yang survive dari yang thriving.
Navigate the ambiguity. Keep the progress moving.
Ditulis berdasarkan pengalaman nyata di lapangan. Nama dan detail spesifik disamarkan.