Analisis pohon masalah adalah metode visual untuk menjelajahi masalah utama, kemungkinan penyebab, dan konsekuensinya. Isu utama membentuk batang, penyebab membentuk akar, dan dampak membentuk cabang. Nilainya terletak pada diskusi dan investigasi yang disusunnya. Pohon yang sudah selesai tidak dengan sendirinya membuktikan penjelasan sebab-akibat.
Anda mungkin menjumpai metode ini dengan nama árbol de problemas dalam bahasa Spanyol atau arbre à problèmes dalam bahasa Prancis. Pembedaan intinya tetap sama: apa yang terjadi, apa yang mungkin menyebabkannya, dan apa akibatnya. Pisahkan ketiga tingkat ini sebelum membahas solusi.
Panduan perencanaan pohon masalah ODI menjelaskan struktur masalah utama, penyebab, dan konsekuensi. Label bukti, urutan lokakarya, dan contoh di bawah merupakan tambahan praktis untuk penggunaan tim.
Kapan sebaiknya menggunakan pohon masalah?
Gunakan pohon ketika ada beberapa penjelasan yang bersaing, masalah melintasi berbagai peran, atau solusi yang diusulkan menyasar bagian sistem yang berbeda. Pohon dapat membantu tim dukungan memeriksa eskalasi berulang atau tim pengiriman menyelidiki persetujuan yang terlambat.
Pilih metode lain bila keputusannya sudah jelas. Cacat kecil yang dipahami dengan baik mungkin cukup ditangani langsung dan diverifikasi. Insiden serius mungkin memerlukan linimasa formal dan proses insiden yang disetujui. Pohon dapat mendukung pekerjaan itu, tetapi tidak menggantikan pelestarian bukti atau investigasi spesialis.
Pohon juga bukan pengganti yang baik untuk bertanya kepada orang-orang yang terdampak. Sekelompok manajer dapat menghasilkan penjelasan yang masuk akal tentang masalah pengguna tanpa pernah memeriksa pengalaman pengguna tersebut. Sertakan perspektif mereka sebelum diagram dianggap berwenang.
Mulai dengan masalah utama yang berbatas jelas
Tuliskan satu masalah yang dapat diamati di tengah. “Proyeknya berantakan” terlalu luas. “Persetujuan konten untuk rilis saat ini berulang kali datang setelah implementasi dimulai” mengidentifikasi proses dan konteks.
Periksa apakah pernyataan tersebut memuat penyebab yang diasumsikan. “Keterlambatan persetujuan disebabkan pemangku kepentingan yang ceroboh” sudah memilih penjelasan. Hapus atribusi itu dan selidiki kondisinya.
Buat catatan di samping pohon tentang periode, kelompok terdampak, dan bukti yang tersedia. Jika peserta tidak sepakat apakah masalah utama itu ada, selesaikan perbedaan tersebut atau persempit cakupan sebelum menambahkan cabang.
Bangun pohon dalam lima langkah
- Jelaskan masalah utama. Gunakan satu kalimat dan catat batasannya.
- Tambahkan kemungkinan penyebab langsung di bawahnya. Tanyakan kondisi apa yang dapat menghasilkan masalah yang diamati.
- Telusuri penyebab dari kondisi tersebut. Berhenti ketika bukti habis atau diskusi keluar dari cakupan yang dipilih.
- Tambahkan dampak di atas masalah. Tanyakan perubahan apa yang dialami pengguna, rekan tim, atau organisasi ketika masalah terjadi.
- Periksa setiap hubungan. Jelaskan mengapa satu kartu dapat menyebabkan kartu berikutnya dan bukti apa yang dapat membantah hubungan itu.
Hindari aturan bahwa setiap akar harus memiliki jumlah tingkat yang sama. Tujuannya bukan diagram yang rapi. Satu cabang mungkin sudah dipahami, sementara cabang lain masih berupa pertanyaan.
Contoh lengkap: persetujuan konten rilis yang terlambat
Contoh hipotetis: tim produk melihat konten rilis sering berubah setelah implementasi dimulai. Mereka memilih satu rilis terbaru sebagai cakupan awal, bukan mengklaim bahwa masalah memengaruhi setiap proyek.
Pohon awal mereka terlihat seperti ini:
| Lapisan | Kartu | Bukti saat ini |
|---|---|---|
| Dampak | Implementasi harus direvisi | Riwayat perubahan menunjukkan dua revisi |
| Dampak | Dukungan menerima redaksi final terlambat | Tanggal serah terima dicatat dalam catatan rilis |
| Masalah utama | Persetujuan konten datang setelah implementasi dimulai | Tanggal dari rilis saat ini |
| Kemungkinan penyebab langsung | Tidak ada titik eksplisit untuk meminta persetujuan | Penelusuran proses; perlu dikonfirmasi |
| Kemungkinan penyebab langsung | Ketersediaan peninjau diasumsikan | Wawancara dengan dua peserta |
| Kemungkinan kondisi lebih dalam | Kepemilikan berubah menurut jenis konten | Instruksi yang bertentangan dalam dua dokumen |
Tim menolak menambahkan “peninjau tidak memprioritaskan pekerjaan” sebagai fakta. Itu mungkin salah satu penjelasan, tetapi bukti saat ini juga mendukung adanya ketidakjelasan tentang siapa yang harus meninjau dan kapan.
Mereka memilih menguji cabang kepemilikan terlebih dahulu. Investigasinya sederhana: bandingkan jalur persetujuan yang didokumentasikan dengan jalur sebenarnya untuk lima perubahan konten terbaru. Jika kepemilikannya jelas dalam kasus-kasus tersebut, mereka akan memperbarui pohon, bukan membela diagramnya.
Tambahkan label bukti pada kartu
Gunakan tiga label sederhana: teramati, interpretasi yang didukung, dan hipotesis yang belum diuji. Ini adalah label kerja, bukan skor kepastian ilmiah. Tambahkan tautan bukti atau catatan singkat yang menjelaskan label tersebut.
Untuk panah penting, catat mekanisme yang diusulkan. “Kepemilikan yang tidak jelas menyebabkan permintaan persetujuan terlambat” menjelaskan lebih banyak daripada sekadar meletakkan dua kartu berdekatan. Tanyakan apa lagi yang dapat menjelaskan pengamatan yang sama dan apakah ada pengecualian yang menantang hubungan tersebut.
Berhati-hatilah terutama dengan dampak yang dinyatakan sebagai uang atau kerugian pelanggan. Persetujuan yang terlambat dapat menimbulkan pengerjaan ulang, tetapi itu tidak membuktikan dampak pendapatan tertentu. Pisahkan klaim keuangan sampai seseorang dapat menunjukkan perhitungan dan asumsinya.
Selenggarakan lokakarya 50 menit
Gunakan sepuluh menit pertama untuk menyepakati cakupan dan bukti. Beri peserta tujuh menit untuk menulis penyebab dan dampak secara diam-diam, lalu gunakan lima belas menit untuk menata kartu dan menjelaskan hubungan. Sisihkan sepuluh menit untuk menantang bukti dan delapan menit untuk memilih investigasi.
Fasilitator sebaiknya bertanya, “Apa yang kita harapkan untuk diamati jika ini benar?” Pertanyaan itu mengubah pendapat yang terdengar yakin menjadi sesuatu yang dapat diuji tim.
Letakkan ide solusi di samping pohon. Jangan membuangnya, tetapi jangan biarkan “beli alat baru” menjadi akar masalah. Setelah pohon cukup dapat dipercaya untuk memandu tindakan, bandingkan tanggapan dengan kondisi yang dipilih.
Untuk kelompok yang sudah mengumpulkan pengamatan dalam retrospektif, bawa hanya tema terpilih ke lokakarya pohon. Memetakan semua kartu sekaligus akan menghasilkan hutan yang sulit dikelola.
Ubah pohon menjadi tindakan
Pilih cabang dengan tiga kriteria: kepentingannya bagi masalah utama, kekuatan bukti saat ini, dan kemampuan tim untuk menyelidiki atau memengaruhinya. Cabang yang sangat berpengaruh tetapi di luar kendali Anda mungkin perlu dieskalasikan; cabang yang lebih lemah tetapi dapat diuji mungkin menjadi eksperimen pertama yang tepat.
Catat kartu investigasi singkat:
- Hubungan yang diuji: hubungan sebab-akibat mana yang penting?
- Bukti yang dibutuhkan: pengamatan apa yang dapat mendukung atau menantangnya?
- Pemilik dan akses: siapa yang dapat memperoleh bukti itu dengan semestinya?
- Tanggal keputusan: kapan pohon akan diperbarui?
- Kemungkinan tindakan berikutnya: keputusan apa yang bergantung pada hasilnya?
Pohon tujuan nantinya dapat menyatakan kembali kondisi yang dipilih sebagai hasil yang diinginkan. Jangan berasumsi bahwa membalik redaksinya akan menghasilkan solusi yang dapat dijalankan. “Kepemilikan jelas” tetap membutuhkan mekanisme, orang yang memelihara aturan, dan cara untuk mendeteksi ketidakjelasan.
Gunakan ide retrospektif sederhana untuk percakapan tindak lanjut dan periksa apakah perubahan terpilih mengubah masalah awal. Panduan perbaikan kami menjelaskan cara menjaga pembelajaran tersebut tetap terlihat.
Pertanyaan yang sering diajukan
Apakah pohon masalah sama dengan diagram tulang ikan?
Keduanya dapat mengatur kemungkinan penyebab. Pohon masalah secara eksplisit menghubungkan isu utama dengan penyebab dan dampak; diagram tulang ikan biasanya mengelompokkan kemungkinan penyebab ke dalam kategori. Menampilkan hubungan saja tidak membuktikan sebab-akibat.
Berapa banyak akar penyebab yang sebaiknya ada dalam pohon masalah?
Tidak ada angka universal yang berguna. Sertakan cabang relevan yang didukung cakupan dan bukti, lalu prioritaskan investigasi alih-alih mencoba mengisi diagram simetris.
Bisakah pohon masalah memuat hasil positif?
Pertahankan fokus pohon awal pada masalah dan dampaknya. Anda dapat membuat tampilan tujuan terpisah setelahnya sambil tetap mencatat hubungan mana yang masih berupa asumsi.