Problem Çözme: Bir Sorunu Adım Adım Daraltmanın Yöntemi

Bir sorunla karşılaştığımızda çoğunlukla iki uçtan birine savruluruz: ya hemen bir çözüm denemeye girişiriz ya da sorunun büyüklüğü karşısında hiçbir şey yapmadan bekleriz. İkisi de aynı yerden kaynaklanır; sorunu tanımlamadan çözmeye çalışmaktan. Oysa problem çözme, zekâdan çok yöntem işidir. Karmaşık bir arıza karşısında sakin kalabilen bir teknisyenle paniğe kapılan biri arasındaki fark genellikle bilgi değil, izlenen sıradır.

Bu yazıda bir sorunun nasıl tanımlanacağını, olasılıkların nasıl daraltılacağını, denemelerin nasıl düzenleneceğini ve çözüm bulunduktan sonra ne yapılacağını adım adım ele alıyoruz. Yöntem, bir cihaz arızasından bir iş sorununa kadar hemen her alanda aynıdır.

Önce sorunu doğru cümleye dökmek

Çözüme giden yolun en verimli adımı, sorunu tek bir cümleyle yazmaktır. "İşler kötü gidiyor" bir sorun tanımı değildir. "Son üç haftada teslimatların yarısı iki gün gecikti" ise üzerinde çalışılabilir bir tanımdır. Fark, ölçülebilirlik ve sınırlılıktır.

İyi bir tanım üç şeyi içerir: ne oluyor, ne zaman başladı, hangi koşullarda ortaya çıkıyor. Bu üçünü netleştirmek çoğu zaman çözümün yarısını halleder; çünkü sorunu daraltmak, olası nedenleri de daraltır.

Değişen tek şeyi bulmak

Daha önce düzgün çalışan bir şey bozulduysa, arada bir şey değişmiştir. Bu, teknik sorunlarda olduğu kadar insan ilişkilerinde de geçerlidir. "Ne zaman başladı" sorusunun cevabı, "o tarihte ne değişti" sorusuna götürür.

Bilgisayarın yavaşlaması bunun tipik bir örneğidir. Cihaz bir anda değil, genellikle bir kurulumdan, bir güncellemeden ya da dolan bir diskten sonra ağırlaşır; bilgisayarın yavaşlama nedenleri incelendiğinde sorunun tek bir değişiklikten kaynaklandığı sıkça görülür. Aynı mantık her alanda çalışır: önce zaman çizgisini kurun, sonra o çizgi üzerindeki değişiklikleri arayın.

Belirtiyle nedeni ayırmak

Gördüğümüz şey genellikle sorunun kendisi değil, sonucudur. Sürekli geciken teslimat bir belirtidir; nedeni stok yönetimi, iletişim eksikliği ya da gerçekçi olmayan bir takvim olabilir. Belirtiyi çözmek kısa vadeli rahatlama sağlar ama sorun kısa süre sonra başka bir yerden geri döner.

Bunu ayırt etmenin pratik yolu, "neden" sorusunu üst üste birkaç kez sormaktır. Her cevabın ardından tekrar neden diye sormak, yüzeydeki belirtiden alttaki yapısal nedene doğru iner. Genellikle dördüncü ya da beşinci soruda gerçek neden ortaya çıkar.

Olasılıkları ikiye bölerek daraltmak

Nedeni bilinmeyen bir sorunda tüm ihtimalleri tek tek denemek zaman kaybıdır. Daha verimli yöntem, olasılık kümesini her adımda ikiye bölmektir. Sorun burada mı, değil mi? Bu koşulda oluyor mu, oluşmuyor mu? Her cevap, kalan alanı yarıya indirir.

Bu yaklaşım özellikle çok bileşenli sistemlerde etkilidir. Bir parçayı devre dışı bırakıp sorunun sürüp sürmediğine bakmak, o parçayı listeden çıkarır ya da doğrudan işaret eder. Rastgele denemelerle geçen saatler, birkaç bilinçli bölmeyle dakikalara iner.

Tek değişkenle denemek

Çözüm ararken aynı anda üç şeyi birden değiştirmek sık yapılan bir hatadır. Sorun düzelse bile hangisinin işe yaradığı bilinmez; düzelmezse hangisinin durumu kötüleştirdiği anlaşılmaz. Her denemede tek bir şeyi değiştirmek, yavaş görünse de sonuca daha hızlı ulaştırır.

Denemeleri kaydetmek de aynı ölçüde önemlidir. Ne denendi, ne oldu, geri alındı mı? Bu üç sütunluk basit bir kayıt, uzun süren sorunlarda aynı şeyi ikinci kez denemenizi engeller.

Geri alınabilir adımları önceleyin

Deneme yaparken maliyet ve geri dönülebilirlik hesaba katılmalıdır. Kolay geri alınabilen, ucuz ve hızlı denemeler her zaman öncelikli olmalıdır. Kalıcı sonuç doğuran, pahalı ya da geri dönüşü olmayan adımlar en sona bırakılır.

Ayrıca büyük bir değişiklik yapmadan önce mevcut durumun bir yedeğini almak, sadece dijital dünyada değil her alanda geçerli bir prensiptir. Bir düzenlemeye başlamadan önce eski halin kaydını tutmak, işler kötüye giderse başlangıç noktasına dönmeyi mümkün kılar.

Sorunu yeniden çerçevelemek yerine bölmek

Bazı sorunlar tek parça halinde bakıldığında çözümsüz görünür. Böyle durumlarda soruyu değiştirmek yerine parçalamak işe yarar. "Bu projeyi nasıl yetiştiririm" sorusu ağırdır; "hangi üç iş çıkarılırsa proje yetişir" sorusu ise cevaplanabilir.

Parçalama aynı zamanda ilerlemeyi görünür kılar. Çözülemeyen büyük bir sorunun içinde, hemen bugün halledilebilecek küçük bir parça neredeyse her zaman bulunur. Bu parçayı bitirmek hem bilgi hem de moral üretir.

Kısıtları avantaja çevirmek

Zaman, bütçe ya da yetki kısıtları çoğunlukla engel gibi görülür; oysa iyi tanımlanmış bir kısıt seçenekleri azaltarak kararı kolaylaştırır. Sınırsız seçenek karşısında karar vermek, dar bir alanda karar vermekten çok daha zordur.

Bu yüzden çözüm ararken kısıtları baştan yazmak yararlıdır: elimde ne kadar süre var, ne kadar kaynak var, neyi değiştiremem. Bu liste, gerçekçi olmayan çözümleri daha ilk aşamada eler.

Yardım istemenin doğru zamanı

Bir soruna gereğinden uzun süre tek başına takılmak yaygın bir durumdur. Pratik bir kural, kendinize bir süre sınırı koymaktır: belirlenen süre dolduğunda, o ana kadar denenenleri yazılı olarak toparlayıp birine sormak.

Bu toparlama işleminin ilginç bir yan etkisi vardır: sorunu başkasına anlatmak için düzenlerken çözüm sık sık kendiliğinden görünür hale gelir. Anlatmak, dağınık bilgiyi sıraya sokmayı zorunlu kıldığı için düşünceyi netleştirir.

Çözümden sonra kapatmak

Sorun çözüldüğünde iş bitmiş sayılmaz. İki kısa adım daha vardır: neyin işe yaradığını not etmek ve aynı sorunun tekrarını önleyecek bir önlem düşünmek. Bu ikinci adım atlandığında, aynı sorunla birkaç ay sonra yeniden karşılaşmak neredeyse kesindir.

Zamanla bu notlar kişisel bir bilgi birikimine dönüşür. Deneyimli insanları hızlı yapan şey, her sorunu ilk kez çözüyor olmaları değil; benzerlerini daha önce çözmüş ve kaydetmiş olmalarıdır. Problem çözme becerisi de böyle büyür: yöntemli denemeler ve tutulan kayıtlarla.