2.2 Dari Permintaan ke Alasan
Setelah kita tahu bahwa kebutuhan datang dalam berbagai bentuk, langkah selanjutnya adalah mengubah permintaan mentah itu menjadi alasan yang jelas kenapa perubahan diperlukan.
Bayangkan Anda menerima chat dari kepala divisi operasional: "Buatkan dashboard monitoring pengiriman." Permintaan ini terdengar masuk akal. Tim pun mulai membahas warna grafik, jumlah kartu informasi, dan apakah pakai tabel atau diagram batang. Tapi tunggu. Sebelum membuka figma atau menyentuh kode, ada satu pertanyaan yang lebih penting: kenapa dashboard ini diperlukan? Apa yang ingin dicapai dengan adanya dashboard itu?
Permintaan seperti "buatkan fitur ini" atau "kita perlu aplikasi seperti X" adalah permintaan yang sudah berbentuk solusi. Seseorang telah melompat langsung ke jawaban tanpa melalui proses memahami masalah. Tugas Anda bukan langsung mengeksekusi, tetapi mundur selangkah dan mencari alasan di balik permintaan itu.
Mulailah dengan tiga pertanyaan sederhana. Pertama, kenapa ini penting sekarang? Mungkin ada laporan yang telat dikirim setiap akhir bulan. Mungkin atasan meminta data real-time karena keputusan sering terlambat. Atau mungkin ada audit yang menemukan celah karena data tidak terpantau. Kedua, apa yang ingin dicapai? Apakah pengiriman harus sampai lebih cepat? Apakah tingkat kesalahan pengiriman harus turun? Atau apakah yang dibutuhkan adalah notifikasi otomatis saat terjadi keterlambatan? Ketiga, bagaimana kita tahu ini berhasil? Ukuran apa yang bisa dipakai? Persentase pengiriman tepat waktu? Waktu rata-rata dari order sampai tiba? Jumlah keluhan pelanggan yang turun?
Berikut contoh penerapan tiga pertanyaan tersebut dalam sebuah dialog singkat.
Permintaan: "Buatkan dashboard monitoring pengiriman."
Pertanyaan 1 (Kenapa penting sekarang?):
"Karena laporan keterlambatan baru ketahuan seminggu setelahnya."
Pertanyaan 2 (Apa yang ingin dicapai?):
"Notifikasi real-time saat pengiriman terlambat lebih dari 2 jam."
Pertanyaan 3 (Ukuran keberhasilan?):
"Persentase pengiriman tepat waktu naik 10% dalam 1 bulan."
Proses ini dapat divisualisasikan dalam diagram alir berikut.
Ketika Anda menanyakan tiga hal ini, Anda sedang mengubah permintaan menjadi pernyataan masalah. Bukan "buatkan dashboard", tetapi "kami tidak tahu status pengiriman secara real-time sehingga keputusan sering terlambat dan pelanggan komplain". Bukan "buatkan tombol export", tetapi "data laporan butuh waktu dua jam untuk dirapikan sebelum bisa dikirim ke atasan". Bukan "kita perlu aplikasi mobile", tetapi "sales di lapangan tidak bisa mengakses harga terbaru saat negosiasi dengan pelanggan".
Perhatikan perbedaannya. Permintaan asli adalah solusi. Pernyataan masalah adalah alasan. Dan dari alasan itulah Anda bisa mulai merancang solusi yang tepat, bukan asal membuat.
AI bisa membantu proses ini. Anda bisa mengetikkan chat atau email berisi permintaan, lalu minta AI membantu merumuskan kemungkinan masalah di baliknya. "Berdasarkan permintaan ini, apa saja kemungkinan masalah yang ingin dipecahkan?" Atau "Bantu aku menyusun tiga pertanyaan klarifikasi untuk memahami alasan di balik permintaan ini." Tapi ingat, AI hanya membantu merapikan dan mempercepat. Anda tetap perlu berbicara dengan pengguna, mendengar sendiri apa yang mereka keluhkan, dan memvalidasi apakah rumusan masalah Anda tepat.
Satu hal yang perlu diwaspadai: jangan puas dengan satu jawaban. Kadang alasan pertama hanyalah alasan permukaan. Orang bilang "butuh dashboard" karena atasan minta. Tapi kenapa atasan minta? Karena ada meeting bulanan yang selalu kekurangan data. Kenapa data kurang? Karena laporan diolah manual dan sering terlambat. Nah, baru di sini Anda menemukan masalah sebenarnya: proses pelaporan manual yang lambat, bukan kurangnya dashboard.
Setelah Anda punya pernyataan masalah yang solid, Anda sudah siap melangkah ke tahap berikutnya: memahami siapa yang sebenarnya akan menggunakan solusi ini. Karena masalah yang sama bisa dirasakan berbeda oleh orang yang berbeda. Tapi itu akan kita bahas di subbab selanjutnya.
