Sorun Tespit Edilince Hangi Ekip Sahiplenmeli?

Bir ürün ekibinde çalışıyorsanız şu sahneye yabancı değilsinizdir: Bir sorun fark edilir, herkes masada toplanır, ekrana bakılır ve havada şu soru asılı kalır — "Tamam da bunu kim çözecek?" Sorun ortadadır, ama sahibi belirsizdir. UI'de mi başlıyor, UX akışında mı kırılıyor, yoksa kullanıcının hiç göremediği bir yerde, back-end tarafında bir veri mi takılıyor? İşte bu belirsizlik anı, aslında ürün kültürünüzün en çok test edildiği yerlerden biri.

Kısa cevabı şu: Sorunu önce ürün ekibi tanımlar ve sahiplenir, ardından problemin gerçekten hangi katmanda olduğunu tespit edip ilgili ekibi sürece dahil eder. Yani sahiplenme tek seferlik bir devir-teslim değil; önce "problem" sahiplenilir, sonra "çözüm" doğru ekibe yönlendirilir.

Sorunun Sahibi ile Çözümün Sahibi Aynı Kişi Değildir

Ürün ekibinin ilk işi, gelen sinyalin gerçekten bir problem olup olmadığına karar vermektir. Kullanıcı geri bildirimleri, KPI'larla örtüşüyor mu? Mesela formu kullananların büyük kısmı süreci yarıda bırakıyorsa ve bu, tanımlı başarı metriklerinizle çelişiyorsa, ortada tartışılmaz bir problem var demektir.

Bu noktada ürün sahibi (Product Owner) ya da paydaşlar (stakeholders) devreye girer. "Evet, bu bir problem ve düzeltilmeye değer" kararı verildikten sonra iş, teknik olarak nerede çözüleceğine bakmaya geçer. Yani sahiplenme zinciri şöyledir: Önce problem tanınır, sonra önceliklendirilir, sonra ilgili ekibe yönlendirilir.

Problem Hangi Katmanda Yaşıyor?

Bazen sorun göründüğü yerde değildir. Ön yüzde (front-end) her şey kusursuz çalışıyor olabilir; buton tıklanıyor, form gönderiliyor, animasyonlar akıyor. Ama perde arkasında, veriler back-end'e aktarılırken bir yerde tıkanma varsa, kullanıcı yine aynı kötü deneyimi yaşar.

Bu yüzden sahiplenme kararından önce küçük bir teşhis aşaması gerekir:

• UI katmanı: Görsel hiyerarşi, buton yerleşimi, okunabilirlik gibi yüzeydeki problemler.
• UX katmanı: Akışın mantığı, adımların sırası, kullanıcının zihinsel yükü.
• Teknik katman: Veri iletimi, yanıt süreleri, hata yönetimi gibi kullanıcının doğrudan göremediği ama hissettiği problemler.

Her katmanın sahibi farklıdır. Bir UX problemini geliştirme ekibine atmak ya da bir back-end gecikmesini tasarımcıdan çözmesini beklemek, çoğu zaman değerli zamanın yanlış kapıda harcanmasına yol açar.

Başarı Metriğini Çözüm Yönlendirir

Ürün ekibi sadece "şu form uzun" demez; ne kadar uzun olduğunu, bunun hangi metriği nasıl etkilediğini ve müdahale sonrası neyin değişmesini beklediğini de tanımlar. Mesela formdaki terk edilme oranının (drop-off rate) yüzde 10 azaltılması gibi net bir hedef koymak, çözümün hangi ekibe gideceğini de doğrudan şekillendirir.

Çünkü hedef "sadeleştirme" ise iş daha çok tasarım tarafındadır. Hedef "yükleme süresini düşürmek" ise mesele teknik ekibe geçer. Başarı metriği, sahiplenmenin pusulasıdır.

Backlog Gerçeği: Yeni İş, Boş Takvime Düşmez

Burada çoğu zaman gözden kaçan bir gerçek var: Hiçbir ekip sizin probleminizi beklemiyor. Geliştirme ekibinin de, tasarım ekibinin de zaten planlanmış sprint'leri, sıraya konmuş işleri, açık backlog'ları var. Yeni bir problem geldiğinde bu, mevcut iş listesine eklenen bir madde haline gelir; ama nereye ekleneceği başlı başına bir karardır.

Bu yüzden sahiplenme sorusu aslında iki katmanlıdır:

1. Kim çözecek? — Hangi ekibin uzmanlık alanı.
2. Ne zaman çözecek? — Şirketin genel gidişatına etkisi, aciliyeti, diğer işlerle karşılaştırıldığında önceliği.

Bir problem teknik olarak küçük olabilir ama iş etkisi büyükse, backlog'un üstüne yerleşir. Tersi de geçerlidir: Görünürde devasa bir iyileştirme, eğer kimsenin metriğini doğrudan etkilemiyorsa, sıranın daha aşağılarına düşebilir.

Peki Bu Durumda Nasıl İlerlemeli?

Elinizde bir problem olduğunda, doğrudan "bunu kim yapacak?" sorusuna atlamadan önce küçük bir sıralama izlemek işleri çok kolaylaştırır:

• Önce problemi ürün ekibi olarak tanımlayın. Geri bildirim mi, veri mi, ikisi birden mi söylüyor bunu?
• Problemin hangi KPI ile çeliştiğini netleştirin. Başarı metriği yoksa, çözümün başarısını ölçemezsiniz.
• Paydaşlarla bu gerçekten bir problem mi mutabakatına varın. Onay aşaması atlanırsa, sonradan herkes farklı tellerden çalar.
• Problemin kökünün yaşadığı katmanı belirleyin: tasarım mı, akış mı, teknik mi?
• İlgili ekibin backlog'una doğru öncelikle yerleştirin. "Acil" damgası bedavaymış gibi davranmak, sistemi körleştirir.

Bu adımlar küçük gibi görünür, ama her biri atlandığında ekibin enerjisi yanlış sorunlara harcanmaya başlar.

Sahnede Bir Form Örneği

Diyelim ki kullanıcı geri bildirimlerinde ve analiz verilerinizde aynı şey çıkıyor: Kayıt formunuz uzun ve insanlar yarıda bırakıyor. Ürün ekibi durumu inceliyor ve şu kararı veriyor: "Bu bir problem. Formu sadeleştirerek terk edilme oranını yüzde 10 düşürmek istiyoruz."

Bu kararla birlikte iş, doğal olarak tasarım ekibine geçer; çünkü adımların yeniden kurgulanması, alan sayısının azaltılması, akışın bölünmesi gibi kararlar onların alanıdır. Ama uygulama aşamasında geliştirme ekibi de masaya oturur, çünkü bazı alanların back-end tarafındaki bağımlılıkları olabilir. Yani sahiplenme tek bir ekibe yapılmış olsa bile, çözümün hayata geçmesi neredeyse her zaman bir orkestrasyon işidir.

Öte yandan, eğer aynı problemde tasarım kusursuz görünüyor ama formun gönderilmesi sırasında saniyelerce yanıt gelmiyorsa, sahiplenme baştan teknik ekibe geçer. Problem aynı (terk edilme), ama sahibi tamamen farklıdır.

Merak Edilenler

Problemi her zaman ürün ekibi mi tespit etmeli?

İlk sinyal her yerden gelebilir: müşteri destek, satış, hatta geliştiricinin kendi gözlemi. Ama "bu gerçekten bir problem mi ve önceliğimiz mi?" kararını ürün ekibi vermelidir. Aksi halde herkes kendi gördüğü problemi öncelik haline getirir.

Sahiplenme tek bir ekibe mi olmalı?

Net bir sahip olmalı, evet. Ama çözüm sürecinde diğer ekiplerin dahil olması neredeyse kaçınılmaz. "Sahip" demek, "tek başına yapan" demek değil; sürecin sonunu getirmekten sorumlu olan ekip demektir.

Paydaş onayı şart mı?

Özellikle iş etkisi olan, kaynak gerektiren değişikliklerde şart. Paydaşlar (stakeholders) sürece dahil edilmediğinde, sonradan gelen "biz bunu istememiştik" cümlesi en pahalı geri dönüşlerden biridir.

Backlog'a girmeyen sorunlar ne olur?

Görünmez hale gelirler. Tanımlanmamış, sıralanmamış bir problem aslında çözülmesi planlanmamış bir problemdir. Kayıt altına almak, çözmenin ilk adımıdır.

Sahiplenme Bir Karakter Meselesidir

Hangi ekibin neyi sahipleneceği, aslında sadece organizasyon şemasıyla ilgili bir konu değil. Bir ekibin problemi gördüğünde "bu benim değil" demek yerine "bu bizim, ama doğru yere taşıyalım" diyebilmesiyle ilgili. İyi ürün kültürleri, sahibi belirsiz problemlerin oradan oraya savrulduğu değil, hızlıca doğru masaya konulduğu yerlerdir. Ve bu masayı kurmak, çoğu zaman ürün ekibinin ilk ve en kıymetli işidir.