23.1 Dari Menerima Task ke Membentuk Masalah
Bayangkan Anda duduk di meja kerja. Tiba-tiba seorang product manager menghampiri dengan wajah setengah panik. "Kita perlu fitur ini dalam dua minggu. Ini urgent. Bisnis minta." Ia memberikan secarik kertas berisi tiga baris deskripsi yang sangat kabur. Anda membaca: "Buat dashboard untuk tim sales. Tampilkan data penjualan. Harus real-time."
Diagram berikut memperlihatkan dua jalur yang bisa diambil saat menerima permintaan kabur.
Apa yang Anda lakukan?
Jika Anda langsung mengangguk, membuka editor, dan mulai membuat API, Anda sedang berada dalam pola kerja penerima task. Anda menerima permintaan mentah-mentah, menerjemahkannya langsung ke kode, dan berharap hasilnya sesuai harapan. Pola ini terlihat produktif. Tapi sebenarnya Anda sedang mengambil risiko besar. Anda belum tahu data penjualan yang mana, untuk siapa tepatnya, seberapa real-time yang dimaksud, dan bagaimana dashboard ini akan dipakai. Anda baru mendapat tiga baris kalimat, bukan pemahaman.
Di era AI, pola ini semakin berbahaya. AI bisa menerima task mentah dan menghasilkan kode lebih cepat dari Anda. Kalau pekerjaan Anda hanya menerjemahkan permintaan ke kode, Anda sedang berlomba dengan mesin yang tidak perlu tidur, tidak perlu rapat, dan tidak pernah mengeluh. Tapi AI tidak bisa melakukan satu hal yang justru paling berharga: membentuk ulang masalah sebelum solusi ditulis.
Orang strategis tidak menerima permintaan sebagai perintah. Ia menerimanya sebagai undangan untuk menyelidiki. Ia tidak bertanya "berapa lama?", tetapi "apa yang sebenarnya kita coba selesaikan?" Ia mengubah percakapan dari eksekusi ke pemahaman.
Inilah pergeseran dari sekadar menerima task menjadi membentuk masalah dengan lebih jelas. Seorang problem shaper tidak menjawab pertanyaan yang salah. Ia membantu memperbaiki pertanyaannya dulu. Ia sadar bahwa permintaan yang datang sering kali sudah mengandung asumsi yang keliru, scope yang meluas, atau solusi yang dipaksakan. Tugasnya bukan menjalankan asumsi itu, tetapi mengungkapnya.
Coba lihat lagi contoh dashboard tadi. Seorang problem shaper akan merespon dengan pertanyaan: "Siapa yang akan memakai dashboard ini? Keputusan apa yang akan mereka buat dari data itu? Apa yang terjadi kalau data tidak real-time? Data penjualan dari sistem mana? Apakah tim sales sudah punya cara sendiri untuk melihat data ini?" Pertanyaan-pertanyaan ini bukan untuk mempersulit. Ini untuk memastikan bahwa energi tim tidak terbuang pada hal yang salah.
Perubahan ini tidak mudah. Banyak engineer terbiasa dihargai karena kecepatan mengeksekusi. Semakin cepat Anda mengerjakan task, semakin produktif Anda terlihat. Tapi produktivitas semu itu berbahaya. Anda bisa menyelesaikan fitur dalam tiga hari, lalu menghabiskan dua minggu berikutnya memperbaiki karena ternyata yang diminta bukan yang dibutuhkan. Atau lebih buruk: fitur selesai tepat waktu, tapi tidak dipakai karena tidak menjawab masalah sebenarnya.
Problem shaper justru terlihat lambat di awal. Ia menghabiskan waktu untuk bertanya, menggambar, dan memvalidasi asumsi. Tapi kecepatan sejati bukanlah seberapa cepat Anda mulai mengetik. Kecepatan sejati adalah seberapa cepat Anda mencapai hasil yang benar. Dan hasil yang benar hanya bisa dicapai jika masalahnya sudah terbentuk dengan baik.
Di organisasi mana pun, orang yang bisa membentuk masalah akan lebih dipercaya daripada orang yang hanya menjalankan perintah. Mengapa? Karena ia mengurangi risiko. Ia membuat keputusan lebih mudah diambil. Ia tidak menambah kebingungan, ia membersihkannya. Dan di era AI, ketika eksekusi teknis semakin murah, kemampuan ini justru semakin langka dan semakin berharga.
Jadi, lain kali seseorang datang dengan permintaan mentah, jangan langsung bertanya "kapan deadlinenya?" Tanyakan dulu: "Apa masalah yang sebenarnya ingin kita selesaikan?" Dari sana, perjalanan Anda sebagai orang yang mampu membentuk masalah baru dimulai.
