Problem ağacı analizi, temel bir problemi, olası nedenlerini ve sonuçlarını incelemek için kullanılan görsel bir yöntemdir. Merkezi sorun gövdeyi, nedenler kökleri, etkiler dalları oluşturur. Değeri, düzenlediği tartışma ve incelemeden gelir. Tamamlanmış bir ağaç tek başına nedensel bir açıklamayı kanıtlamaz.
Yöntemi İspanyolcada árbol de problemas, Fransızcada arbre à problèmes adıyla görebilirsiniz. Temel ayrım aynı kalır: ne oluyor, ne buna yol açıyor olabilir ve ardından ne geliyor? Çözümleri konuşmadan önce bu üç düzeyi ayrı tutun.
ODI'nin problem ağacı planlama rehberi temel problem, nedenler ve sonuçlardan oluşan yapıyı açıklar. Aşağıdaki kanıt etiketleri, atölye sırası ve örnek, ekiplerin kullanımı için pratik eklemelerdir.
Problem ağacını ne zaman kullanmalısınız?
Birden fazla açıklama yarışıyorsa, problem farklı rollere yayılıyorsa veya önerilen çözümler sistemin farklı kısımlarını ele alıyorsa ağaç kullanın. Destek ekibinin yinelenen eskalasyonları incelemesine veya teslimat ekibinin geciken onayları araştırmasına yardımcı olabilir.
Karar zaten açıksa başka bir yöntem seçin. Küçük ve iyi anlaşılan bir hata için doğrudan düzeltme ve doğrulama yeterli olabilir. Ciddi bir olay resmi zaman çizelgesi ve onaylanmış olay süreci gerektirebilir. Ağaç bu çalışmaya destek olur, ancak kanıtları korumanın veya uzman incelemesinin yerini tutmaz.
Ağaç, etkilenen kişilere soru sormanın da zayıf bir alternatifidir. Bir yönetici grubu, kullanıcının deneyimini hiç kontrol etmeden kullanıcı problemine tutarlı bir açıklama üretebilir. Diyagramı yetkili kabul etmeden önce bu bakış açılarını ekleyin.
Sınırları belirli bir temel problemle başlayın
Ortaya gözlemlenebilir tek bir sorun yazın. “Proje tam bir karmaşa” fazla geniştir. “Mevcut sürümün içerik onayları uygulama başladıktan sonra tekrar tekrar geliyor” ifadesi bir süreç ve bağlam tanımlar.
İfadenin varsayılan bir neden içerip içermediğini kontrol edin. “Onaylar dikkatsiz paydaşlar yüzünden gecikiyor” daha baştan bir açıklama seçer. Atfı kaldırın ve koşulları araştırın.
Ağacın yanına dönem, etkilenen grup ve mevcut kanıtlar hakkında not ekleyin. Katılımcılar temel problemin var olup olmadığı konusunda anlaşamıyorsa daha fazla dal oluşturmadan önce bu anlaşmazlığı çözün veya kapsamı daraltın.
Ağacı beş adımda oluşturun
- Temel problemi tanımlayın. Tek cümle kullanın ve sınırlarını kaydedin.
- Olası doğrudan nedenleri altına ekleyin. Gözlemlenen soruna hangi koşulun yol açabileceğini sorun.
- Bu koşulların nedenlerini araştırın. Kanıt bittiğinde veya tartışma seçilen kapsamın dışına çıktığında durun.
- Problemin üstüne etkileri ekleyin. Sorun yaşandığında kullanıcılar, ekip arkadaşları veya kuruluş için neyin değiştiğini sorun.
- Her bağlantıyı inceleyin. Bir kartın sonraki karta neden yol açabileceğini ve hangi kanıtın bu ilişkiye karşı çıkacağını açıklayın.
Her kökün aynı sayıda düzeyi olması gerektiğine dair bir kural koymayın. Amaç düzenli bir diyagram değildir. Bir dal iyi anlaşılmışken diğeri soru olarak kalabilir.
Uygulamalı örnek: sürüm içeriğinin geç onaylanması
Varsayımsal örnek: Bir ürün ekibi, uygulama başladıktan sonra sürüm içeriğinin sık sık değiştiğini fark ediyor. Problemin tüm projeleri etkilediğini iddia etmek yerine, başlangıç kapsamı olarak yakın tarihli bir sürümü seçiyor.
İlk ağaçları şöyle görünüyor:
| Katman | Kart | Mevcut kanıt |
|---|---|---|
| Etki | Uygulamanın yeniden düzenlenmesi gerekiyor | Değişiklik geçmişinde iki revizyon var |
| Etki | Destek ekibi son metni geç alıyor | Devir tarihi sürüm notlarında kayıtlı |
| Temel problem | İçerik onayı, uygulama başladıktan sonra geliyor | Mevcut sürümün tarihleri |
| Olası doğrudan neden | Onay istemek için açık bir nokta yok | Sürecin üzerinden geçildi; doğrulanmalı |
| Olası doğrudan neden | İnceleyenin uygun olduğu varsayılıyor | İki katılımcıyla görüşmeler |
| Olası daha derin koşul | İçerik türüne göre sahiplik değişiyor | İki belgede çelişen talimatlar |
Ekip “inceleyenler işi önceliklendirmiyor” ifadesini gerçek olarak eklemekten kaçınıyor. Bu bir açıklama olabilir, ancak mevcut kanıtlar kimin ne zaman inceleme yapması gerektiğinin belirsiz olduğunu da destekliyor.
Önce sahiplik dalını test etmeyi seçiyorlar. İnceleme sınırlı: yakın tarihli beş içerik değişikliğinde belgelenmiş onay yolunu gerçek süreçle karşılaştırıyorlar. Bu vakalarda sahiplik açıksa diyagramı savunmak yerine ağacı güncelleyecekler.
Kartlara kanıt etiketleri ekleyin
Üç basit etiket kullanın: gözlemlendi, kanıtla desteklenen yorum ve sınanmamış hipotez. Bunlar çalışma etiketleridir, bilimsel kesinlik puanları değildir. Etiketi açıklayan bir kanıt bağlantısı veya kısa not ekleyin.
Önemli oklar için önerilen mekanizmayı kaydedin. “Belirsiz sahiplik geç onay isteğine yol açıyor” demek, iki kartı yan yana koymaktan fazlasını açıklar. Aynı gözlemi başka neyin açıklayabileceğini ve bir istisnanın bu ilişkiye karşı çıkıp çıkmadığını sorun.
Para veya müşteri kaybı olarak ifade edilen etkilere özellikle dikkat edin. Geç onay yeniden iş yaratabilir, ancak bu belirli bir gelir etkisini kanıtlamaz. Birisi hesabı ve varsayımlarını gösterene kadar finansal iddiaları ayrı tutun.
50 dakikalık bir atölye yürütün
İlk on dakikayı kapsam ve kanıtlar konusunda anlaşmaya ayırın. Katılımcılara nedenleri ve etkileri sessizce yazmaları için yedi dakika verin, ardından kartları düzenleyip ilişkileri açıklamak için on beş dakika kullanın. Kanıtları sorgulamaya on, bir inceleme seçmeye sekiz dakika ayırın.
Kolaylaştırıcı “Bu doğru olsaydı ne gözlemlemeyi beklerdik?” diye sormalı. Bu soru, kendinden emin bir görüşü ekibin sınayabileceği bir şeye dönüştürür.
Çözüm fikirlerini ağacın yanına park edin. Onları atmayın, ancak “yeni bir araç satın almayı” kök nedene dönüştürmeyin. Ağaç eyleme yön verecek kadar güvenilir hâle geldiğinde yanıtları seçilen koşulla karşılaştırın.
Zaten bir retrospektifte gözlem toplayan bir grup için ağaca yalnızca seçilen temayı getirin. Her kartı aynı anda haritalamaya çalışmak, yönetilemeyen bir orman yaratır.
Ağacı eyleme dönüştürün
Bir dalı üç ölçüte göre seçin: temel problem açısından önemi, mevcut kanıtın gücü ve ekibin bunu araştırma veya etkileme kapasitesi. Çok etkili ama kontrolünüz dışındaki bir dalı üst makama taşımak gerekebilir; daha zayıf ama sınanabilir bir dal ilk deney için uygun olabilir.
Kısa bir inceleme kartı kaydedin:
- Sınanacak ilişki: Hangi neden-sonuç bağlantısı önemli?
- Gerekli kanıt: Hangi gözlem bu ilişkiyi destekleyebilir veya sorgulayabilir?
- Sorumlu kişi ve erişim: Kanıtı uygun biçimde kim elde edebilir?
- Karar tarihi: Ağaç ne zaman güncellenecek?
- Olası sonraki eylem: Sonuca bağlı olan karar hangisi?
Bir hedef ağacı daha sonra seçilen koşulları istenen sonuçlar olarak yeniden ifade edebilir. Sözcükleri ters çevirmenin uygulanabilir bir çözüm oluşturduğunu varsaymayın. “Sahiplik açık” ifadesi bile bir mekanizma, kuralı sürdürecek bir kişi ve belirsizliği fark etme yolu gerektirir.
Takip konuşması için basit bir retrospektif fikri kullanın ve seçilen değişikliğin ilk problemi değiştirip değiştirmediğini inceleyin. İyileştirme rehberimiz bu öğrenmenin görünür kalmasına yardımcı olur.
Sık sorulan sorular
Problem ağacı balık kılçığı diyagramıyla aynı mıdır?
İkisi de olası nedenleri düzenleyebilir. Problem ağacı temel sorunu nedenlere ve etkilere açıkça bağlar; balık kılçığı genellikle olası nedenleri kategorilere ayırır. İkisi de ilişkileri göstermekle nedenselliği kanıtlamaz.
Problem ağacında kaç kök neden olmalı?
Evrensel olarak işe yarayan bir sayı yoktur. Kapsam ve kanıtlarla desteklenen ilgili dalları ekleyin, ardından simetrik bir diyagram doldurmaya çalışmak yerine incelemeyi önceliklendirin.
Problem ağacı olumlu sonuçlar içerebilir mi?
İlk ağacı probleme ve etkilerine odaklayın. Hangi ilişkilerin varsayım olarak kaldığını koruyarak daha sonra ayrı bir hedef görünümü oluşturabilirsiniz.