23.2 Dari Permintaan Kabur ke Problem Statement

Setelah tahu bahwa permintaan mentah perlu dibentuk ulang, langkah berikutnya adalah membuat bentuknya eksplisit. Kita lanjutkan contoh yang sama: permintaan dashboard untuk tim sales.

Kalimat "dashboard real-time" terdengar jelas karena kata-katanya familiar. Namun di baliknya ada banyak kemungkinan: data penjualan bisa berarti revenue, jumlah unit, margin, atau jalur pemrosesan deal. Real-time bisa berarti detik, menit, atau cukup diperbarui setiap jam. Pengguna akhirnya juga belum tentu seluruh tim sales; bisa jadi hanya manajer regional yang perlu mengambil keputusan harian.

Inilah jebakan permintaan kabur. Kita merasa sudah paham karena istilahnya umum, padahal definisinya belum disepakati.

Seorang arsitek tidak bekerja seperti itu. Ia mengubah permintaan kabur menjadi problem statement yang terstruktur. Problem statement adalah pernyataan singkat yang menjelaskan: siapa yang mengalami masalah, apa masalahnya, dalam konteks apa, dan mengapa masalah ini perlu diselesaikan sekarang.

Mari kita bedah tekniknya. Ada tiga langkah sederhana.

Berikut diagram alir tiga langkah tersebut:

flowchart TD A[Mulai: Permintaan Kabur] --> B[Langkah 1: Tanya siapa dan untuk apa] B --> C[Output: Konteks dan Pengguna Akhir] C --> D[Langkah 2: Cari Batasan dan Definisi] D --> E[Output: Definisi Operasional] E --> F[Langkah 3: Tanya Mengapa Sekarang] F --> G[Output: Urgensi dan Dampak] G --> H[Problem Statement Terstruktur] H --> I[Tim punya pijakan sama]

Pertama, tanyakan "siapa" dan "untuk apa". Jangan langsung bertanya detail teknis. Tanyakan siapa pengguna akhirnya dan apa yang ingin mereka capai. Dalam kasus dashboard sales, mungkin jawabannya adalah: "Manajer regional butuh tahu performa timnya setiap pagi untuk menentukan produk mana yang perlu didorong hari ini." Sekarang Anda punya konteks. Bukan sekadar "dashboard", tetapi alat keputusan harian untuk manajer regional.

Kedua, cari batasan dan definisi. Kata-kata seperti "real-time", "cepat", "mudah", "lengkap" adalah jebakan. Setiap orang punya interpretasi berbeda. Tanyakan: "Apa arti real-time bagi manajer regional itu?" Mungkin jawabannya: "Data yang diperbarui setiap jam sudah cukup, karena keputusan diambil setiap pagi." Sekarang Anda punya batasan yang jelas. Bukan real-time dalam arti milidetik, tetapi cukup segar untuk rapat pagi.

Ketiga, tanyakan "mengapa sekarang". Ini pertanyaan paling penting. Kenapa permintaan ini muncul sekarang? Mungkin ada masalah yang sudah lama tidak terselesaikan, atau ada tekanan dari atasan, atau ada perubahan pasar. Jawaban atas pertanyaan ini akan memberitahu Anda seberapa urgent dan seberapa besar dampak yang diharapkan.

Dari tiga langkah itu, Anda bisa menyusun problem statement seperti ini:

Perhatikan perbedaan antara dua contoh berikut:

// Permintaan kabur (jangan seperti ini)
"Buat dashboard real-time untuk tim sales."

// Problem statement terstruktur (inilah yang benar)
"Manajer regional butuh data revenue per produk setiap pagi pukul 7,
 dengan data maksimal berusia 1 jam, agar bisa menentukan produk
 yang perlu didorong hari itu. Saat ini laporan baru keluar siang,
 sehingga keputusan promosi sering terlambat."

"Manajer regional sales perlu mengetahui performa timnya per produk setiap pagi, dengan data yang tidak lebih dari satu jam, agar bisa memutuskan produk mana yang perlu mendapat dorongan promosi hari itu. Saat ini mereka harus menunggu laporan dari tim finance yang baru keluar siang hari, sehingga keputusan promosi sering terlambat."

Lihat perbedaannya? Dari "bikin dashboard real-time" yang kabur, Anda sekarang punya pernyataan masalah yang jelas. Tim punya pijakan yang sama. Engineer tahu apa yang perlu dibangun. Product manager bisa memvalidasi apakah solusi yang diusulkan benar-benar menjawab masalah.

Ini bukan soal menunda pekerjaan. Ini soal memastikan bahwa energi tim tidak terbuang untuk membangun sesuatu yang salah. Dengan problem statement yang baik, Anda juga memudahkan semua orang untuk berkontribusi. Manajer regional bisa mengonfirmasi: "Ya, itu masalah saya." Tim finance bisa berkata: "Kami bisa menyediakan data lebih awal jika formatnya diubah." Semua pihak jadi punya peran dalam membentuk solusi.

Setelah problem statement jelas, langkah selanjutnya bukan langsung memutuskan satu solusi. Sebagai arsitek, Anda perlu menyusun beberapa opsi, lengkap dengan trade-off masing-masing. Dari sana, pembahasan berlanjut ke subbab berikutnya.