2.1 Bukan Sekadar "Buatkan Fitur Ini"
Pagi itu, seorang product manager masuk ke ruang tim dengan semangat. "Kita perlu fitur export laporan ke PDF," katanya sambil meletakkan laptop. "Klien minta. Deadline minggu depan." Tim mengangguk, lalu mulai membahas tata letak, warna tombol, dan format halaman. Tidak ada yang bertanya kenapa klien minta PDF, apa yang akan dilakukan dengan file itu, atau apakah ada cara lain yang lebih sederhana.
Situasi seperti ini terjadi setiap hari di banyak perusahaan. Seseorang datang dengan permintaan yang terdengar jelas: "buatkan fitur ini", "tambahkan tombol itu", "ubah warna di sini". Permintaan itu lalu langsung diterjemahkan menjadi tugas teknis. Tim mengerjakan. Selesai. Tapi seringkali hasilnya tidak dipakai, atau malah menimbulkan masalah baru.
Masalahnya bukan pada orang yang meminta. Masalahnya adalah kita terlalu cepat menerima permintaan sebagai kebutuhan.
Kebutuhan sejati jarang datang dalam bentuk yang rapi. Ia bisa muncul sebagai keluhan di ruang meeting: "proses persetujuan lama banget." Bisa juga sebagai chat singkat di grup: "kenapa data saya tidak muncul?" Atau sebagai contoh aplikasi lain: "buat kayak punya Shopee dong." Bahkan audit finding, pekerjaan berulang yang terasa membosankan, atau proses yang terasa lambat tanpa alasan jelas—semua itu adalah bentuk awal dari kebutuhan.
Seorang arsitek yang baik tidak langsung menulis kode atau menggambar layar ketika mendengar permintaan. Ia berhenti sejenak. Ia membedakan tiga hal: ide, permintaan, dan kebutuhan.
Ide adalah gagasan tentang solusi. "Buat tombol export PDF" adalah ide. Permintaan adalah ungkapan bahwa seseorang ingin sesuatu terjadi. "Saya mau data ini bisa dibawa ke rapat" adalah permintaan. Kebutuhan adalah alasan di balik itu semua. "Saya perlu menyajikan data penjualan bulanan di rapat direksi, dan selama ini saya harus copy-paste manual dari lima layar berbeda" adalah kebutuhan.
Perhatikan perbedaannya. Ide dan permintaan sudah berbentuk solusi. Kebutuhan masih berbentuk masalah. Jika tim langsung mengerjakan ide, mereka bisa saja membuat tombol export PDF yang sempurna—tapi tidak menyelesaikan masalah sebenarnya. Mungkin yang lebih dibutuhkan adalah dashboard yang bisa diakses dari laptop pribadi, atau notifikasi mingguan yang dikirim otomatis ke email.
Tabel berikut menunjukkan beberapa contoh permintaan umum beserta kebutuhan tersembunyi dan solusi alternatif yang mungkin lebih tepat.
Diagram berikut memperjelas perbedaan antara ide, permintaan, dan kebutuhan.
Di era AI, kemampuan membedakan ini menjadi semakin penting. AI bisa menulis kode dengan cepat. Ia bisa membuat tombol, halaman, bahkan seluruh aplikasi dalam hitungan menit. Tapi AI tidak bisa bertanya: "apa yang sebenarnya Anda butuhkan?" Pertanyaan itu hanya bisa diajukan oleh manusia yang paham konteks.
Maka langkah pertama untuk berpikir seperti arsitek bukanlah belajar diagram atau framework. Langkah pertama adalah belajar mendengar. Mendengar apa yang dikatakan, dan lebih penting lagi, apa yang tidak dikatakan. Mendengar keluhan sebagai petunjuk, bukan sebagai gangguan. Mendengar permintaan sebagai undangan untuk menggali lebih dalam, bukan sebagai perintah yang harus dijalankan.
Subbab selanjutnya akan membahas bagaimana mengubah permintaan yang berbentuk solusi menjadi pernyataan masalah yang jelas. Tapi sebelum itu, coba ingat-ingat: kapan terakhir kali Anda menerima permintaan "buatkan fitur ini" tanpa bertanya kenapa? Mungkin sekarang saatnya mengubah kebiasaan itu.