Problem statement di industri

Banyak proyek gagal bukan karena kode buruk. Proyek gagal karena miskomunikasi saat meeting.

Saya sering melihat pola ini:
 Requirement berubah setelah development selesai.
 User merasa fitur tidak sesuai ekspektasi.
 Engineer merasa sudah mengerjakan sesuai dokumen.
 Timeline molor karena revisi berulang.

Masalahnya bukan pada teknologi. Masalahnya pada cara engineer memposisikan diri saat meeting.

Meeting dengan user sering dianggap rutinitas administratif. Padahal di sanalah arsitektur keputusan dibentuk.

Jika Anda salah memahami konteks bisnis di awal, Anda akan mengoptimalkan hal yang salah selama berbulan bulan.

Kenapa banyak engineer salah approach

Ada beberapa kesalahan umum.

Pertama. Engineer terlalu fokus pada solusi, bukan masalah.
 User baru menjelaskan gejala. Engineer sudah menawarkan desain database.

Kedua. Engineer defensif.
 Saat user mengkritik fitur, engineer menjelaskan kenapa sistem sudah benar. Bukan mencari akar miskomunikasi.

Ketiga. Engineer tidak mengklarifikasi asumsi.
 Kalimat seperti “iya nanti kita buatkan” muncul sebelum ruang lingkup jelas.

Keempat. Engineer tidak menulis ulang pemahaman.
 Mereka tidak melakukan restatement. Mereka tidak menguji apakah interpretasi mereka akurat.

Kelima. Engineer tidak memisahkan problem bisnis dan constraint teknis.
 Semua permintaan langsung diterjemahkan menjadi task development.

Mindset ini muncul karena banyak engineer tumbuh sebagai problem solver teknis. Mereka jarang dilatih menjadi problem framer.

Framework berpikir yang benar

Anda perlu framework sederhana saat masuk meeting.

Gunakan empat lapisan ini.

Lapisan satu. Klarifikasi tujuan bisnis.
 Tanya: metrik apa yang ingin berubah. Proses mana yang ingin dipercepat. Risiko apa yang ingin dikurangi.

Lapisan dua. Definisikan masalah secara eksplisit.
 Ulangi dengan kalimat Anda sendiri.
 “Jadi masalah utamanya adalah approval terlambat karena data tidak lengkap, benar?”

Lapisan tiga. Identifikasi constraint.
 Budget. Timeline. Regulasi. Integrasi sistem lama.
 Tanpa ini, solusi Anda akan tidak realistis.

Lapisan empat. Validasi skenario ekstrem.
 Apa yang terjadi jika user salah input.
 Apa yang terjadi jika volume naik dua kali lipat.
 Apa yang terjadi jika integrasi gagal.

Meeting bukan sesi menerima perintah. Meeting adalah sesi membentuk definisi masalah.

Anda harus keluar dari meeting dengan tiga hal tertulis.
 Problem statement.
 Success metric.
 Scope yang disepakati.

Tanpa tiga ini, Anda sedang berjudi.

Contoh kasus nyata

Saya pernah terlibat dalam pengembangan modul approval untuk departemen operasional.

User meminta fitur auto approval jika nilai transaksi di bawah nominal tertentu.

Tim langsung mendesain rule engine sederhana.
 Kondisi if. Nominal di bawah limit. Status approved.

Setelah rilis, muncul kasus fraud.
 Ternyata beberapa transaksi kecil bisa dipecah menjadi beberapa transaksi untuk menghindari approval manual.

Masalahnya bukan pada kode.
 Masalahnya pada framing di meeting awal.

Tidak ada pertanyaan tentang risiko manipulasi.
 Tidak ada diskusi tentang pola transaksi historis.
 Tidak ada validasi dengan tim risk.

Jika saat itu engineer bertanya:
 Apakah ada kemungkinan transaksi dipecah.
 Apakah ada histori penyalahgunaan.
 Apakah ada kontrol tambahan selain nominal.

Arsitektur akan berbeda.
 Kami mungkin menambahkan agregasi transaksi per hari.
 Kami mungkin menambahkan threshold kumulatif.
 Kami mungkin menambahkan audit flag.

Satu pertanyaan yang tidak ditanyakan bisa mengubah desain sistem.

Insight dan refleksi pribadi

Saya dulu juga salah.

Saya merasa nilai saya ada pada kecepatan menulis kode.
 Saya bangga jika bisa langsung memberikan solusi di meeting.

Lama kelamaan saya sadar.
 Solusi cepat tanpa framing yang tepat hanya mempercepat kesalahan.

Sejak itu saya mengubah pendekatan.
 Saya lebih banyak bertanya daripada menjelaskan.
 Saya mencatat kata kunci bisnis.
 Saya menolak membahas solusi sebelum problem statement jelas.

Hasilnya berbeda.
 Scope lebih stabil.
 Revisi berkurang.
 Kepercayaan lintas departemen meningkat.

User tidak membutuhkan engineer yang paling pintar.
 User membutuhkan engineer yang paling jelas cara berpikirnya.

Penutup yang kuat

Meeting dengan user adalah bagian dari engineering.
 Itu bukan aktivitas tambahan.

Di ruang meeting, Anda tidak sedang membela teknologi.
 Anda sedang membentuk keputusan bisnis melalui sistem.

Jika Anda ingin naik level sebagai engineer, latih kemampuan framing masalah.
 Latih kemampuan mendengar.
 Latih kemampuan menyederhanakan kompleksitas.

Kode bisa direfactor.
 Arsitektur bisa diubah.
 Keputusan yang salah di awal jarang murah untuk diperbaiki.

Jika Anda masuk meeting tanpa framework, Anda sedang menyerahkan arah sistem kepada asumsi.

Dan asumsi adalah sumber bug paling mahal dalam industri ini.