Problem Statement

30 saniyelik özet

Problem tanımı bir çözüm fikri değil, kanıtla desteklenmiş bir durum tespitidir. Kim, hangi durumda, neden zorlanıyor ve bunun işletmeye maliyeti ne? Bu dört soruyu yanıtlamadan yazılan her gereksinim, tahmine dayalı bir yatırımdır.

Neden önemli?

Bir toplantıda "bize raporlama ekranı lazım" cümlesini duyduğunda iki seçeneğin var: ekranı backlog'a yazmak ya da o ekranın hangi karara hizmet ettiğini sormak. Birincisi hızlı görünür ama pahalıdır. Yanlış problem üzerine kurulan çözüm, kusursuz teslim edilse bile değer üretmez.

Endüstri mühendisliği eğitimindeki bir refleks burada işe yarıyor: bir sistemi iyileştirmeden önce mevcut durumu ölçeriz. Problem tanımı, ürün ve iş dünyasının bu refleksi kurumsal bir belgeye dönüştürmüş hâli.

Problem tanımı nedir?

Çözülmesi gereken iş problemini sınırlayan, çözümü seçmeyen bir ifadedir. İyi bir tanım genelde şu unsurları taşır:

• Kim: Etkilenen rol veya segment
• Durum: Hangi iş akışında ya da bağlamda
• Engel: Ne yüzünden zorlanıyor
• Etki: İşletme için sonuç (zaman, maliyet, kayıp gelir, risk)
• Kanıt: Bunu nereden biliyoruz (görüşme, veri, ölçüm)

Karşılaştır:

• "Yeni bir CRM sistemi kurmalıyız." → Bu bir çözüm.
• "Kurumsal satış temsilcileri müşteri geçmişini üç ayrı sistemden topladığı için teklif hazırlama süresi uzuyor ve bazı fırsatlar takipsiz kalıyor." → Bu, araştırılabilir bir problem.

İkincisi seni CRM'e de götürebilir, mevcut sistemlerin entegrasyonuna da, hatta süreçteki gereksiz bir onay adımının kaldırılmasına da. Problem doğru tanımlanınca çözüm alanı açık kalır.

Gerçek vaka: Amazon'un "Working Backwards" yaklaşımı

Amazon'da ürün ekipleri geliştirmeye başlamadan önce, ürün yayınlanmış gibi bir basın bülteni ve müşterilerin soracağı sorulara yanıt veren bir SSS belgesi (PR/FAQ) yazar. Bu belgeler ekibi baştan şu sorulara zorlar: Hangi problemi çözüyoruz? Müşteri bunu neden önemsesin? Mevcut alternatifler neden yetersiz?

Bu vakadan çıkan ders şu: özellik listesiyle başlamak yerine müşteri açısından ürünün neden var olması gerektiğini yazılı olarak savunmak, problem tanımını bir formalite olmaktan çıkarır. Fikir güçlü değilse, belge yazılırken bu ortaya çıkar. Bu da geliştirme maliyeti doğmadan olur.

Varsayımsal örnek

Bir e-ticaret altyapısı sunan B2B SaaS şirketinde satış ekibi "müşteriler gelişmiş raporlama istiyor" diyor. İş analisti bunu backlog'a yazmıyor. Bunun yerine 50-250 çalışanlı mağazaların operasyon yöneticileriyle görüşüyor ve şunu buluyor: Haftalık stok raporu üç sistemden Excel'e elle birleştiriliyor, bu işlem yaklaşık iki saat sürüyor ve satın alma kararı geç veriliyor.

Problem tanımı şöyle oluyor:

"Operasyon yöneticileri, stok riski taşıyan SKU'ları sipariş vermeden önce tek ekranda göremediği için her hafta elle Excel birleştirmesi yapıyor ve satın alma kararları gecikiyor."

Yanına eklenenler: görüşme notları, mevcut süre ölçümü, hata örnekleri ve etkilenen müşteri segmenti. Çözüm henüz seçilmedi. Belki bir rapor ekranı olacak, belki otomatik bir uyarı. Sırada bu var, ama önce problem.

Sık yapılan 3 hata

1. Çözümü problem diye yazmak. "Mobil uygulama lazım" bir çözüm önerisidir. Sorun kendini "lazım" kelimesiyle belli eder.
2. Etkiyi yazmamak. Zorluk var ama maliyeti yok. Öncelik sıralaması yapılamaz, çünkü her şey eşit derecede önemli görünür.
3. Kanıtsız yazmak. En yüksek sesle konuşan paydaşın isteği "iş gereksinimi" sanılır. Kanıt eklemek, tartışmayı fikir düzeyinden veri düzeyine taşır.

Mini uygulama: Problem tanımı kontrol listesi

Yazdığın her problem tanımını şu sorulardan geçir:

İlgili terimler

Business Objective, Stakeholder Analysis, Root Cause Analysis, Jobs-to-be-Done