Kesin teşhis sanatı: Çözmek için sorunu nasıl formüle etmeli

Doğru tanımlanmış bir sorun, görevin %80'inin çözülmüş olması demektir. İyi bir sorun tanımı somut, ölçülebilir olmalı; mevcut durum ile hedeflenen durum arasındaki farkı açıklamalı ve hareketsiz kalmanın sonuçlarını belirtmelidir. Soyut şikayetler yerine "Gerçek — Beklenti — Fark" yapısını kullanın. Bu, tahminlerde kaybolmak yerine doğrudan nedenleri aramaya geçmenizi sağlar.

Projelerdeki ve kişisel girişimlerindeki başarısızlıkların çoğu, çözüm eksikliğinden değil, semptomları tedavi edip hastalığı görmezden gelmemizden kaynaklanır. Kaynak harcıyorsanız ama durum değişmiyorsa, büyük olasılıkla sorun yanlış tanımlanmıştır.

Neden ifadelerin %90'ı hatalıdır

Kontrol listesini uygulamadan önce, genellikle nerede hata yaptığımızı anlamak önemlidir. Yanlış görev tanımı, "serçe vurmak için top atmak"a veya daha kötüsü, var olmayan bir sorunu çözmeye yol açar.

Düşünce tuzakları

1. Sorunu çözümle değiştirmek.
   • Hata: "CRM sistemi kurmamız gerekiyor."
   • Gerçek: Bu zaten bir çözümdür. Sorun şöyle ifade edilebilir: "Yöneticiler, iletişim karmaşası nedeniyle potansiyel müşterilerin %30'unu kaybediyor." Belki de CRM'e değil, yeni bir satış senaryosuna veya bir asistan işe almaya ihtiyacınız vardır.
2. Belirsizlik ve soyutluk.
   • Hata: "Çalışanlar kötü çalışıyor."
   • Gerçek: "Kötü" kavramı özneldir. Tam olarak ne kötü? Hız mı? Kalite mi? İletişim mi? Sayılar ve gerçekler olmadan bu "sorun" düzeltilemez.
3. Analiz yerine suçlama.
   • Hata: "İvanov teslim tarihlerini kaçırıyor."
   • Gerçek: Bu bir çatışma tespiti olup iş sorunu değildir. Sorun şudur: "Tasarım onay süreci planlanan 2 gün yerine 5 gün sürüyor ve bu da lansmanı geciktiriyor."

İdeal sorun tanımının 5 kriteri

Sorununuzun çözüme hazır olup olmadığını kontrol etmek için bu beş kriterden oluşan filtreden geçirin.

1. Somutluk (Specific)

Sorun zaman, mekan ve nesne açısından lokalize edilmelidir.

• Kötü: "Site yavaşlıyor."
• İyi: "iOS yüklü mobil cihazlarda ödeme sayfası 5 saniyeden uzun sürede yükleniyor."

2. Ölçülebilirlik (Measurable)

Sorunun büyüklüğünü nicel olarak değerlendirebilmelisiniz. Bir sorun ölçülemezse, onu çözüp çözmediğinizi anlayamazsınız.

• Araç: Sayıları, yüzdeleri, parayı ve zamanı kullanın.

3. Farkın Tanımı (Gap Analysis)

Net bir tanım her zaman iki durumu içerir:

• A Noktası (Mevcut Durum): Şu anki hali.
• B Noktası (Hedeflenen Durum): Olması gereken hali.
• Fark: Asıl sorun budur.

4. Önem Derecesi (Impact)

Neden şu anda önemli olduğunu açıklayın. Hareketsiz kalmanın bedeli nedir?

• Örnek: "Gecikmeler nedeniyle her ay müşterilerimizin %15'ini kaybediyoruz, bu da 300.000 ruble kayıp fırsata eşdeğer."

5. Çözüm Bağımsızlığı

Tanım, görevin nasıl çözüleceğine dair ipuçları içermemelidir. Sadece neyin bozulduğunu kaydeder.

Sorunu belirleme adım adım algoritması

Karmaşık ve karışık bir durumla karşılaştığınızda bu yöntemi kullanın.

Adım 1. Gerçekleri toplama (Ne oluyor?)

Duyguları verilerden ayırın. Gözlemlenen tüm semptomları yazın.

• Eylem: Katılımcılarla görüşün, logları inceleyin, istatistikleri analiz edin.
• Sonuç: Ham gözlem listesi ("Müşteriler arayıp şikayet ediyor", "Sunucular geceleri çöküyor").

Adım 2. Sapmayı belirleme (Ne olması gerekiyordu?)

Standardı, planı veya beklentiyi hatırlayın.

• Eylem: Yönetmeliği, KPI'ları veya ilk gereksinimi bulun.
• Sonuç: Norm tanımı ("Sunucu, %99,9 çalışma süresi ile 7/24 çalışmalıdır").

Adım 3. Lokalizasyon (Nerede ve ne zaman?)

Arama alanını daraltın.

• Eylem: 5W1H yöntemini kullanın (Who, What, Where, When, Why, How - Kim, Ne, Nerede, Ne Zaman, Neden, Nasıl).
• Sonuç: "Çökmeler sadece saat 20:00 ile 22:00 arasında, kullanıcı sayısı 1000'i aştığında gerçekleşiyor."

Adım 4. Sonuçların değerlendirilmesi (Neden çözülmeli?)

Zararları veya riskleri hesaplayın.

• Eylem: Rahatsızlıkları para veya zamana çevirin.
• Sonuç: "Her çökme, tazminatlar ve teknik destek çalışmaları için 50.000 rubleye mal oluyor."

Adım 5. Tanımın nihai oluşturulması

Verileri tek bir öz cümlede birleştirin.

Kontrol Listesi: Talebiniz işleme hazır mı?

Görevi uygulayıcılara, ekibe devretmeden veya beyin fırtınasına başlamadan önce bu listeden geçin. Her maddeyi işaretleyin.

• [ ] Tanımda hazır bir çözüm var mı? (Eğer "yapmak/satın almak/kurmak gerekiyor" gibi ifadeler varsa — yeniden yazın).
• [ ] Somut rakamlar var mı? (Yüzdeler, tutarlar, saatler, vaka sayıları).
• [ ] Zıtlık tanımlandı mı? ("Şu an" ile "olması gereken"in farkı anlaşılıyor mu?).
• [ ] Lokalizasyon net mi? (Sorunun tam olarak nerede ortaya çıktığı anlaşılıyor mu: hangi departmanda, hangi aşamada, hangi müşteri grubunda?).
• [ ] Önem derecesi değerlendirildi mi? (Bununla neden şimdi uğraşılması gerektiği, altı ay sonra değil, anlaşılıyor mu?).
• [ ] Neden-sonuç ilişkisi kontrol edildi mi? (Bunun bir sorun olduğundan ve daha derin başka bir sorunun sonucu olmadığından emin misiniz?).
• [ ] Tanım yabancı biri tarafından anlaşılıyor mu? (Metni alanınız dışındaki birine gösterdiğinizde, zorluğun özünü anlayacak mı?).

En az bir soruya "Hayır" cevabını verdiyseniz, gerçekleri toplama aşamasına geri dönün.

Karmaşık sorunların ayrıştırılmasında sık yapılan hatalar

Doğru formüle edilmiş küresel bir sorun bile genellikle "tek hamlede" çözülemez. Onu parçalara ayırmak gerekir. Burada da gizli tehlikeler vardır.

1. Süreçlere göre değil, departmanlara göre ayrıştırma.
   • Hata: "Pazarlama sorunu" ve "Satış sorunu".
   • Doğrusu: "Pazarlamadan satışa potansiyel müşteri aktarım sorunu". Sorunlar genellikle sorumluluk alanlarının kesişim noktalarında yaşar.
2. Sistemsel kısıtlamaların göz ardı edilmesi.
   • Başvuru işleme hızı sorununu, sorun insanların sayısıyla hızlanmayan yavaş yazılımda iken, yeni operatörler işe alarak çözmeye çalışmak.
3. "Ortalama sıcaklık" tuzağı.
   • Ortalama göstergelerin analizi, sorunların keskin zirvelerini gizler. Ortalama yanıt süresinin 2 dakika olması, müşterilerin %90'ının 10 saniyede yanıt aldığı, %10'unun ise bir saat beklediği anlamına gelebilir. Çözülmesi gereken sorun "ortalama 2 dakika" değil, "bir saatlik bekleme" sorunudur.

SSS: Sorun formülasyonu hakkında sorular

S: Sorunu ölçmek için veri yoksa ne yapılmalı? C: Önce veri toplama görevi belirleyin. Bu durumda sorun tanımı şöyledir: "[Parametre] izleme sistemi eksikliği nedeniyle [süreç] etkinliğini değerlendiremiyor ve [risk] üzerinde kontrolü kaybediyoruz."

S: Neden ile sorun nasıl ayırt edilir? C: Sorun, gördüğümüz olumsuz etkidir. Neden, buna yol açandır.

• Sorun: Araba çalışmıyor.
• Neden: Akü bitmiş. Sorunu, nedeni ortadan kaldırarak çözeriz. Ancak önce semptomu (sorunu) doğru tanımlamak gerekir.

S: Çözüm sürecinde sorun tanımı değiştirilebilir mi? C: Değiştirilmelidir. Analiz sırasında often gerçek sorunun daha derinde olduğu ortaya çıkar. Bu normal bir iş sürecidir. Önemli olan değişikliği kaydetmek ve ilgili taraflarla onaylamaktır, böylece artık geçerli olmayan bir görev çözülmez.

S: Sorunu kim formüle etmelidir: sipariş veren mi yoksa uygulayıcı mı? C: İdeal olan birlikte yapmaktır. Sipariş veren acıyı ve bağlamı tanımlar, uygulayıcı ise bunu spesifik metrikler ve kısıtlamalar diline çevirmeye yardımcı olur. Sadece sipariş veren formüle ederse, sorunun çözümle değiştirilme riski yüksektir. Sadece uygulayıcı formüle ederse, işletme için önemli olan görev yerine başka bir görevin çözülme riski vardır.