Yararlı bir problem tanımı, insanların başarması gerekenler ile bugün gerçekleşenler arasındaki gözlemlenmiş farkı açıklar. Etkilenen grubu, görevi veya süreci, farkın görüldüğü koşulları ve sonucunu ekleyin. Tercih edilen çözümü ve doğrulanmamış nedeni tanımın dışında tutun; böylece bunlar araştırmaya açık kalır.
Her kuruluş için zorunlu tek bir problem tanımı formatı yoktur. Aşağıdaki format pratik bir yazma aracıdır. Ürün keşfinde, proje teklifinde veya ekip retrospektifinde bulunan yinelenen bir sorunda kullanılabilir.
Çözüme bağlanmadan önce problemi anlama ilkesi GOV.UK keşif rehberinde de yer alır. Bu makaledeki örnekler ve atölye, bildirilen müşteri sonuçları değil, özgün varsayımsal anlatımlardır.
Kopyalanabilir problem tanımı formatı
Başlangıç cümlesi olarak şunu kullanın:
[Bağlam] olduğunda [etkilenen grup], [görev veya istenen sonuç] için [gözlemlenen fark] ile karşılaşıyor. [Kaynak ve dönem] kanıtları [biliniyorsa kapsam veya sıklığı] gösteriyor ve bu da [kanıtlarla desteklenen sonucu] doğuruyor.
Ardından kısa bir kanıt notu ekleyin:
- Bilinen: Tanımı destekleyen gözlemler.
- Bilinmeyen: Yorumu değiştirebilecek sorular.
- Kapsam dışı: Bu çalışmanın ele almayacağı bağlantılı problemler.
- Başarı sinyali: Hangi gözlemlenebilir değişiklik önem taşır.
Her boşluğa sayı yazmaya zorlamayın. “Sıklık henüz ölçülmedi” demek, uydurulmuş bir başlangıç değerinden daha güvenilirdir. Kaynak küçük veya alışılmadık bir örneklemi kapsıyorsa bu sınırı belirtin. Kanıtlar geliştikçe tanım da kesinleşmelidir.
Tanımda neler yer almalı?
| Öğe | Yararlı ifade | Sorgulanması gereken ifade |
|---|---|---|
| Etkilenen kişiler | Yeni hesap yöneticileri | Herkes |
| Görev | İş arkadaşlarını davet etmek ve erişimi doğrulamak | Ürünümüzü daha iyi kullanmak |
| Gözlemlenen fark | Bekleyen davetlerle kabul edilenleri ayırt edemiyorlar | Bir panoya ihtiyacımız var |
| Bağlam | Birden fazla davet gönderdikten sonra | Her zaman |
| Sonuç | Durumu doğrulamak için desteğe başvuruyorlar | Milyonlarca verimlilik kaybı |
| Kanıt | Belirli bir döneme ait incelenmiş vakalar | Bu çok açık |
Sonuç nitel olabilir. Örneğin, kullanıcının kendi başına yapması beklenen bir görev için yardım alması, finansal maliyeti bilinmeden önce de anlamlıdır. Savunulabilir bir yöntem olmadan her zahmeti gelir kaybına dönüştürmeyin.
Uygulamalı örnek: talepten probleme
Varsayımsal örnek: Bir proje “Davet panosu oluşturun” talebiyle başlıyor. Bu bir çözüm önerisidir. Ekip doğru şekilde inşa etse bile yanlış problemi çözebilir.
Keşif sırasında ekip, belirli bir aydaki on iki destek görüşmesini inceliyor ve davet görevini yapan dört yöneticiyi gözlemliyor. Bazıları bir davetin gönderilip gönderilmediğini veya kabul edilip edilmediğini soruyor. Bu gözlemler araştırmaya değer bir probleme işaret ediyor, ancak tüm müşteriler arasındaki yaygınlığını kanıtlamıyor.
Daha iyi bir tanım şöyle olabilir:
Birkaç iş arkadaşını davet ettikten sonra hesap yöneticilerinin çalışma alanına kimlerin erişebildiğini doğrulaması gerekiyor, ancak davet ekranı bekleyen ve kabul edilen davetleri ayırt etmiyor. Destek görüşmeleri ve gözlemlenen dört oturum, yöneticilerin başka yerden doğrulama aradığını ve işe alıştırma sürecine elle yapılan bir kontrol eklendiğini gösteriyor.
Ekip iki bilinmeyen ekliyor: belirsizliğin gözlemlenen hesap türlerinin dışında da yaşanıp yaşanmadığı ve teslimat hatalarının da katkı sağlayıp sağlamadığı. Olası yanıtlar artık daha açık durum etiketlerini, bir onay mesajını, etkinlik görünümünü veya davet sürecinde değişiklikleri içeriyor. Tanım bunlardan birini erkenden seçmiyor.
Üç yaygın format ve ne zaman kullanılacakları
Kısa karar tanımı: Okuyucuların problemi hızlıca anlaması gereken bir proje özetinde iki veya üç cümle kullanın. Araştırma kaydının tamamını eklemek yerine kanıta bağlantı verin.
Mevcut durum, istenen durum, fark: Bir süreçte tanımlı bir beklenti olduğunda kullanın. Bugünkü durumu anlatın, gerekli koşulu açıklayın ve aradaki farkı belirtin. İstenen durumun yalnızca bir yöneticinin tercihi değil, gerçekten gerekli olduğunu doğrulayın.
Kullanıcı, görev, engel, sonuç: Bir ürün veya hizmet problemi birinin deneyiminden doğduğunda kullanın. Tanımın yalnızca ekran değişikliğinin daha geniş bir süreci çözebileceğini ima etmemesi için operasyonel kısıtları ekleyin.
Bunlar yazma yapılarıdır, birbiriyle yarışan yöntemler değildir. Kararı netleştiren en kısa yapıyı seçin. Tek cümle okunması zor hâle gelirse paragraf ve destekleyici tablo kullanın.
35 dakikalık problem çerçeveleme atölyesi yürütün
Problemi yaşayan ve kanıtları yorumlayabilecek kişileri çağırın. Varsayılan çözümü sorgulayabilecek birini ekleyin. Kaynak materyali önceden gönderin ve hangi iddiaların hâlâ belirsiz olduğunu açıklayın.
- Beş dakika: sessizce okuyun. Her katılımcı gözlemleri, yorumları ve önerilen çözümleri farklı biçimde işaretler.
- Sekiz dakika: ayrı tanımlar yazın. Herkesten ürün, araç veya uygulama adını anmadan farkı anlatmasını isteyin.
- On dakika: sınırları karşılaştırın. Kimlerin etkilendiğini, hangi bağlamın önemli olduğunu ve çalışmanın dışında ne kaldığını konuşun.
- Yedi dakika: ortak bir sürüm yazın. Tartışmalı iddiaları belirsizlik notunda tutun.
- Beş dakika: bir sonraki kanıt adımını seçin. Sorumluyu ve kanıtın yön vereceği kararı belirleyin.
Amaç herkesin aynı düzeyde emin olması değildir. Amaç, emin olunan noktanın nerede bittiğini gösteren, incelenebilir bir tanım oluşturmaktır. Grup etkilenen nüfus üzerinde anlaşamıyorsa sonraki iş çözüm atölyesi değil, araştırma olabilir.
Gizli çözümleri ve desteklenmeyen nedenleri kontrol edin
“Müşterilerin bir yapay zekâ asistanına ihtiyacı var” bir teknolojiyi önceden belirler. Hangi görevin zor olduğunu ve insanların hangi sonuca ulaşmaya çalıştığını sorun. Teknoloji, ihtiyacın tanımı hâline gelmeden seçenekler listesinde kalabilir.
“Ekip önemsemediği için talepler gecikiyor” kanıtsız biçimde motivasyon iddia eder. Bunu, devir teslimden sonra sahipsiz kalan talepler gibi gözlemlenebilir bir koşulla değiştirin ve bu koşulun neden oluştuğunu araştırın.
“İletişim kötü” eyleme yön vermek için fazla geniştir. Hangi bilginin, kimler arasında, hangi karar noktasında ve hangi sonuçla ilgili olduğunu belirleyin. Yanıt birkaç ayrı problemi ortaya çıkarabilir. Kimsenin sahiplenemeyeceği tek bir tanım oluşturmak yerine bunları ayırın.
Ekip işindeki yinelenen farkları bulmanın bir yolu retrospektiftir. Gözlemleri toplamak için basit bir pano formatı kullanın, ardından seçilen konuyu bu problem çerçeveleme sürecine taşıyın.
Tanımın hazır olup olmadığına karar verin
Projeyi tanımayan bir iş arkadaşınızdan metni okumasını isteyin. Etkilenen kişiyi belirleyebiliyor, neyin yanlış gittiğini anlatabiliyor ve iki farklı yanıt önerebiliyor mu? Sadece tercih ettiğiniz çözümü tekrarlayabiliyorsa tanımı gözden geçirin.
Ardından izlenebilirliği kontrol edin: olgusal her iddia kanıta bağlanmalı, her varsayım da etiketlenmelidir. Tanımın ne zaman yeniden ele alınacağını kararlaştırın. Yeni kanıtlar problemi daraltabilir, başka bir nedeni ortaya çıkarabilir veya daha fazla çalışmanın gerekli olmadığını gösterebilir.
Değişiklik test edildikten sonra retrospektif iyileştirme süreciyle inceleyin. Uygulamanın tamamlanması, gözlemlenen farkın giderilmesiyle aynı şey değildir.
Sık sorulan sorular
Problem tanımı ne kadar uzun olmalı?
Genellikle tanımın kendisi için kısa bir paragraf yeterlidir. Hassasiyet ana metni okunamaz hâle getirmesin diye kanıtları, varsayımları ve sınırları destekleyici notta tutun.
Problem tanımı çözümü içermeli mi?
Bağlam açıkça kısıtlı bir uygulama gerektirmediği sürece çözümü ayrı tutun. Böyle bir durumda bile okuyucuların seçilen yanıtın problemi giderip gidermediğini değerlendirebilmesi için problemi bağımsız olarak açıklayın.
Henüz nicel kanıtımız yoksa ne yapmalıyız?
Somut nitel gözlemler kullanın ve sınırlarını açıklayın. Sıklık, maliyet veya beklenen fayda uydurmak yerine eksik ölçümü bir sonraki adım olarak kaydedin.