Kök Neden Analizi: Beş Neden Zinciri Nerede Biter?
Bir problemin görünen yüzü çoğu zaman kendisi değildir. Robot durdu, form gönderilmedi, sipariş iki kez düştü: bunlar belirti. Kök neden analizi belirtiden geriye doğru yürüyüp zincirin başladığı yeri arar, Beş Neden de bu yürüyüşün en ucuz aracıdır. Ucuz olması her zaman işe yaradığı anlamına gelmiyor, çünkü zincirin nerede biteceğine tekniğin kendisi karar vermez.
Belirti ile neden arasındaki fark
Belirti ölçülebilen şeydir: hata sayısı, terk oranı, duran makine. Neden ise ölçülenin arkasındaki mekanizmadır ve genellikle ölçüm setinizde yoktur. Bir e-ticaret sitesinde ödeme adımındaki terk oranının yükselmesi belirtidir; kargo ücretinin kullanıcıya ilk kez o adımda görünmesi nedendir. İkincisi hiçbir analitik ekranında satır olarak durmaz. Birinin sepeti kendi eliyle doldurup adım adım ilerlemesi gerekir.
Design Thinking bu adıma birincil immersiyon diyor, ama isminden bağımsız olarak yaptığı şey basit: veriyi üreten ortama girmek. Veri nereye bakacağınızı söyler, ne olduğunu değil.
Beş Neden zinciri nerede biter
Tekniğin klasik örneği Toyota fabrikasından gelir ve hep aynı şekilde anlatılır:
- Robot durdu. Neden?
- Sigorta attı. Neden?
- Rulmanlar kilitlendi. Neden?
- Yeterli yağlama yoktu. Neden?
- Pompa tıkalıydı. Neden?
- Pompada filtre yoktu.
Zincir burada bitmiş görünür. Bitmez. "Pompa neden filtresiz?" diye sormaya devam edebilirsiniz: satın alma şartnamesinde filtre kalemi yoktu, şartnameyi yazan kişi bakım ekibine danışmamıştı, iki ekip aynı toplantıya hiç girmiyordu. Beşinci adımda durmanın matematiksel bir gerekçesi yok. Beş, çoğu vakada yeterli çıktığı için tutunmuş bir alışkanlık, bir eşik değil.
Durma kararını veren şey şudur: zincirde kendi yetkinizdeki ilk halkaya geldiğinizde durursunuz. Filtre takabiliyorsanız orada durursunuz. Şartnameyi değiştirebiliyorsanız bir adım daha gidersiniz. Yani "kök neden" problemin bir özelliği değil, sizin müdahale alanınızın sınırı. Bunu kabul etmek analizi zayıflatmaz, tersine dürüstleştirir: raporun sonuna "kök neden" yerine "buradan sonrası bizim dışımızda" yazmak, altı ay sonra aynı arıza döndüğünde nereden devam edeceğinizi bilmenizi sağlar.
Aynı problemden iki farklı kök çıkar
Tekniğin en az konuşulan zayıflığı tekrarlanabilirlik. Her "neden" sorusunun cevabını soruyu soran kişi seçer ve herkes önce kendi alanını görür. Yavaş açılan bir sayfa için geliştirici "sorgu N+1 üretiyor" der, tasarımcı "hero görseli 4 MB" der, sistem tarafındaki kişi "cache warmup deploy sırasında çalışmamış" der. Üçü de aynı anda doğru olabilir ve üçü bambaşka zincirler kurar. Teknik sizden tek bir çizgi çekmenizi ister, gerçek arıza ise ağaç yapısındadır.
Pratik çıkış yolu zinciri tek başına yürümemek. İki kişi ayrı ayrı kendi zincirini kurup sonra kağıtları yan yana koyduğunda, ayrıştıkları ilk halka genellikle asıl tartışılması gereken yerdir. Ortak toplantıda beraber kurulan zincir bu bilgiyi vermez, çünkü ilk konuşan kişi diğerlerinin cevabını şekillendirir.
Nitel ve nicel veri farklı işler yapar
Zinciri besleyen şey veridir ve iki tür verinin görevi ayrıdır. Görüşme, gözlem, kullanıcı günlüğü gibi nitel yöntemler bir sonraki "neden"in cevabını üretir. Anket, olay kaydı, huni raporu gibi nicel yöntemler ise kurduğunuz zincirin kaç kullanıcıyı kapsadığını söyler. Sırayı karıştırmak yaygın hatadır: elinizde neden hipotezi yokken anket yazarsanız, yalnızca kendi aklınıza gelmiş şıkları ölçersiniz.
Doğru sıra önce birkaç görüşme, sonra ölçüm. Jakob Nielsen'in çok bilinen beş kullanıcı yeter iddiası da buradan gelir: küçük bir grupla yapılan gözlem, kullanılabilirlik sorunlarının büyük kısmını görünür kılar. Ama bu iddia sorunları saptamak için geçerlidir, hangisinin yaygın olduğunu söylemek için değil. Beş kişi size sorulacak soruları verir; kaç kişinin o sorunu yaşadığını ancak ölçüm söyler.
Zinciri yazılı tutun
Kök neden analizinin verdiği şey kesinlik değil, tartışmayı doğru yere taşıması. Bunun kalıcı olması için zincirin yazılı kalması gerekir: hangi soruya kim ne cevap verdi, nerede durduk, durma sebebi bilgi eksikliği miydi yoksa yetki sınırı mı. Aynı arıza altı ay sonra döndüğünde bu not, süreci baştan başlatmak yerine bir halka daha ilerlemenizi sağlar. Çoğu ekipte kaybolan şey analizin kendisi değil, geçen sefer nerede durulduğunun kaydıdır.