Pernyataan masalah yang berguna menjelaskan kesenjangan yang diamati antara hal yang perlu dicapai orang dan yang terjadi saat ini. Sertakan kelompok terdampak, tugas atau proses, kondisi saat kesenjangan muncul, serta konsekuensinya. Pisahkan solusi pilihan dan penyebab yang belum diverifikasi dari pernyataan agar keduanya tetap terbuka untuk penyelidikan.
Tidak ada satu format pernyataan masalah yang wajib untuk setiap organisasi. Format di bawah ini merupakan alat bantu menulis yang praktis. Format ini dapat digunakan untuk discovery produk, proposal proyek, atau masalah berulang yang ditemukan dalam retrospektif tim.
Prinsip untuk memahami masalah sebelum berkomitmen pada solusi juga muncul dalam panduan discovery GOV.UK. Contoh dan lokakarya dalam artikel ini adalah ilustrasi hipotetis orisinal, bukan hasil pelanggan yang dilaporkan.
Format pernyataan masalah siap salin
Gunakan ini sebagai kalimat awal:
Ketika [konteks], [kelompok terdampak] perlu [tugas atau hasil yang diinginkan], tetapi [kesenjangan yang diamati]. Bukti dari [sumber dan periode] menunjukkan [cakupan atau frekuensi, jika diketahui], yang menimbulkan [konsekuensi yang didukung bukti].
Lalu tambahkan catatan singkat tentang bukti:
- Diketahui: pengamatan yang mendukung pernyataan.
- Belum diketahui: pertanyaan yang dapat mengubah interpretasi.
- Di luar cakupan: masalah terkait yang tidak akan ditangani oleh upaya ini.
- Sinyal keberhasilan: perubahan yang dapat diamati dan dianggap penting.
Jangan memaksakan angka ke setiap bagian yang kosong. “Frekuensi belum diukur” lebih dapat dipercaya daripada dasar awal yang dikarang. Jika sumber mencakup sampel kecil atau tidak biasa, sebutkan batasannya. Pernyataan seharusnya menjadi lebih tepat seiring membaiknya bukti.
Apa yang harus dicantumkan dalam pernyataan?
| Elemen | Redaksi yang berguna | Redaksi yang perlu dipertanyakan |
|---|---|---|
| Orang terdampak | Administrator akun baru | Semua orang |
| Tugas | Mengundang rekan kerja dan mengonfirmasi akses | Gunakan produk kami dengan lebih baik |
| Kesenjangan yang diamati | Tidak dapat membedakan undangan yang tertunda dari yang diterima | Perlu dasbor |
| Konteks | Setelah mengirim beberapa undangan | Selalu |
| Konsekuensi | Menghubungi dukungan untuk mengonfirmasi status | Kehilangan jutaan produktivitas |
| Bukti | Kasus yang ditinjau dari periode yang disebutkan | Sudah jelas |
Konsekuensi dapat bersifat kualitatif. Misalnya, pengguna yang membutuhkan bantuan untuk tugas mandiri tetap bermakna bahkan sebelum biaya finansialnya diketahui. Jangan mengubah setiap ketidaknyamanan menjadi kehilangan pendapatan tanpa metode yang dapat dipertanggungjawabkan.
Contoh lengkap: dari permintaan ke masalah
Contoh hipotetis: sebuah proyek dimulai dengan permintaan, “Buat dasbor undangan.” Itu adalah usulan solusi. Tim dapat membangunnya dengan benar tetapi tetap menyelesaikan masalah yang keliru.
Dalam discovery, tim meninjau dua belas percakapan dukungan dari satu bulan tertentu dan mengamati empat administrator menyelesaikan tugas undangan. Beberapa bertanya apakah undangan sudah terkirim atau diterima. Pengamatan tersebut menunjukkan masalah yang layak diselidiki, tetapi tidak menetapkan seberapa umum masalah itu pada semua pelanggan.
Pernyataan yang lebih baik:
Setelah mengundang beberapa rekan kerja, administrator akun perlu memastikan siapa yang dapat mengakses ruang kerja, tetapi layar undangan tidak membedakan undangan yang tertunda dan yang diterima. Percakapan dukungan dan empat sesi yang diamati menunjukkan bahwa administrator mencari konfirmasi di tempat lain, sehingga ada pemeriksaan manual tambahan dalam proses onboarding.
Tim mencatat dua hal yang belum diketahui: apakah ketidakpastian terjadi di luar jenis akun yang diamati, dan apakah kegagalan pengiriman turut menyebabkannya. Tanggapan yang mungkin kini mencakup label status yang lebih jelas, pesan konfirmasi, tampilan aktivitas, atau perubahan pada proses undangan. Pernyataan tersebut tidak memilih salah satunya terlalu dini.
Tiga format umum dan kapan menggunakannya
Pernyataan keputusan singkat: gunakan dua atau tiga kalimat dalam ringkasan proyek ketika pembaca perlu memahami masalah dengan cepat. Sertakan tautan ke bukti alih-alih melampirkan seluruh catatan riset.
Kondisi saat ini, kondisi yang diinginkan, kesenjangan: gunakan ketika proses memiliki ekspektasi yang jelas. Jelaskan keadaan saat ini, kondisi yang diperlukan, dan perbedaannya. Pastikan kondisi yang diinginkan memang dibutuhkan, bukan hanya preferensi manajer.
Pengguna, tugas, hambatan, konsekuensi: gunakan ketika masalah produk atau layanan berawal dari pengalaman seseorang. Sertakan batasan operasional agar pernyataan tidak menyiratkan bahwa perubahan layar saja dapat memperbaiki proses yang lebih luas.
Ini adalah struktur penulisan, bukan metodologi yang saling bersaing. Pilih format paling sederhana yang memperjelas keputusan Anda. Jika satu kalimat sulit dibaca, gunakan paragraf dan tabel pendukung.
Selenggarakan lokakarya perumusan masalah 35 menit
Undang orang yang mengalami masalah dan orang yang dapat menafsirkan buktinya. Sertakan seseorang yang dapat menantang solusi yang diasumsikan. Kirim bahan sumber sebelumnya dan jelaskan klaim mana yang masih belum pasti.
- Lima menit: membaca dalam diam. Setiap peserta menandai pengamatan, interpretasi, dan usulan solusi dengan cara berbeda.
- Delapan menit: menulis pernyataan terpisah. Minta semua orang menjelaskan kesenjangan tanpa menyebut produk, alat, atau implementasi.
- Sepuluh menit: membandingkan batasan. Bahas siapa yang terdampak, konteks mana yang penting, dan apa yang tidak termasuk dalam upaya ini.
- Tujuh menit: menulis satu versi bersama. Simpan klaim yang diperdebatkan dalam catatan ketidakpastian.
- Lima menit: memilih langkah bukti berikutnya. Sebutkan pemiliknya dan keputusan yang akan dibantu oleh bukti tersebut.
Tujuannya bukan kesepakatan penuh tentang tingkat keyakinan. Tujuannya adalah pernyataan yang dapat diperiksa dan menunjukkan batas keyakinan. Jika kelompok tidak dapat menyepakati populasi yang terdampak, tugas berikutnya mungkin riset, bukan lokakarya solusi.
Periksa solusi tersembunyi dan penyebab yang tidak didukung
“Pelanggan membutuhkan asisten AI” menetapkan teknologi. Tanyakan tugas apa yang sulit dan hasil apa yang ingin dicapai. Teknologi dapat tetap ada dalam daftar opsi tanpa menjadi definisi kebutuhan.
“Permintaan terlambat karena tim tidak peduli” menegaskan motivasi tanpa bukti. Ganti dengan kondisi yang dapat diamati, misalnya permintaan tetap belum ditugaskan setelah serah terima, lalu selidiki alasan kondisi itu terjadi.
“Komunikasi buruk” terlalu luas untuk memandu tindakan. Tentukan informasi apa, di antara siapa, pada titik keputusan yang mana, dan dengan konsekuensi apa. Jawabannya mungkin menunjukkan beberapa masalah terpisah. Pisahkan masalah tersebut alih-alih membuat pernyataan yang tidak dapat dimiliki siapa pun.
Salah satu cara menemukan kesenjangan berulang dalam pekerjaan tim adalah retrospektif. Gunakan format papan sederhana untuk mengumpulkan pengamatan, lalu bawa masalah terpilih ke proses perumusan masalah ini.
Tentukan apakah pernyataan sudah siap
Minta rekan kerja yang tidak mengenal proyek untuk membacanya. Dapatkah mereka mengenali orang yang terdampak, menjelaskan apa yang salah, dan menyarankan dua tanggapan berbeda? Jika mereka hanya dapat mengulang solusi pilihan Anda, revisi pernyataannya.
Lalu periksa keterlacakan: setiap klaim faktual harus terhubung dengan bukti, dan setiap asumsi harus diberi label. Sepakati kapan pernyataan akan ditinjau kembali. Bukti baru dapat mempersempit masalah, mengungkap penyebab lain, atau menunjukkan bahwa masalah tersebut tidak layak mendapat upaya lebih lanjut.
Setelah perubahan diuji, tinjau melalui proses peningkatan retrospektif. Menyelesaikan implementasi tidak sama dengan menutup kesenjangan yang diamati.
Pertanyaan yang sering diajukan
Seberapa panjang seharusnya pernyataan masalah?
Biasanya satu paragraf singkat sudah cukup untuk pernyataan itu sendiri. Simpan bukti, asumsi, dan batasan dalam catatan pendukung agar pernyataan utama tidak sulit dibaca karena terlalu rinci.
Haruskah pernyataan masalah mencakup solusi?
Pisahkan solusi kecuali konteks secara eksplisit mengharuskan implementasi yang dibatasi. Meski demikian, jelaskan masalah secara terpisah agar pembaca dapat menilai apakah tanggapan yang dipilih mengatasinya.
Bagaimana jika kami belum memiliki bukti kuantitatif?
Gunakan pengamatan kualitatif yang konkret dan jelaskan batasannya. Catat pengukuran yang belum tersedia sebagai langkah berikutnya alih-alih mengarang frekuensi, biaya, atau manfaat yang diharapkan.