PM ve UX Rol Çakışması: Sorun İş Tanımında Değil, Karar Sahipliğinde

Ürün yöneticisiyle tasarımcı arasındaki çakışma, iş tanımlarının eksik yazılmasından çıkmıyor. İki rolün de aynı karara meşru biçimde talip olmasından çıkıyor: akışa bir adım daha eklensin mi, hangi kullanıcıyla test yapılsın, sprint sonunda kapsamdan ne kırpılsın. Rol dokümanı bu soruların hiçbirini cevaplamaz. Karar başına tek isim yazmak cevaplar.

Çakışma iş tanımından değil, karar masasından çıkar

Ürün yöneticisi ve tasarımcı çoğu ekipte gerçekten farklı işler yapar; günlük görev listelerinde ciddi bir karışıklık yok. Sorun, ikisinin de aynı kararda son sözün kendisinde olduğunu düşündüğü anda başlıyor. Kayıt formunda kaç alan olacağı hem dönüşümü hem takvimi değiştirir, dolayısıyla iki tarafın da gerekçesi haklıdır. Yazılı iş tanımı burada işe yaramaz, çünkü doküman role göre yazılır, çatışma karara göre çıkar.

"Herkes iyi niyetle en iyisini yapmaya çalışıyor" açıklaması doğru ama bir yere götürmez. İyi niyet zaten varsayılan. Aynı işi iki kişi yapıyorsa sorulacak soru neden değil, hangi kararın sahipsiz kaldığıdır.

Sınırın gerçekten bulanık olduğu üç yer

• Araştırma bulgusunun yorumu. Görüşmeyi tasarımcı yapar, bulgudan kapsam çıkarmayı ürün yöneticisi üstlenir. Bulgunun ne anlama geldiğini kimin söyleyeceği çoğu ekipte hiç konuşulmamıştır.
• Akışın uzunluğu. Bir adım eklemek deneyim tarafında savunulur, geliştirme tarafında maliyet olarak görünür. İki taraf da kendi tablosuna bakarak haklı çıkar.
• Kapsamın kırpılması. Sprint sonuna yetişmeyen işi kimin küçülteceği belirsizse iki ayrı kırpma planı doğar ve ikisi de yarım uygulanır.

Rol listesi yerine karar sahibi listesi

Tekrar eden işi durduran şey rol dokümanı değil, tekrar eden kararlara tek isim yazmaktır. Yukarıdaki üç madde tek satırla bağlanabilir: araştırma bulgusunun yorumu tasarımcıda, kapsam kırpma ürün yöneticisinde, akıştaki adım sayısında karar tasarımcıda ama maliyet tahmini geliştiricide. Kim itiraz edebilir sorusuyla kim karar verir sorusu ayrıdır; birincisine herkes girer, ikincisinde tek isim olur.

Kod tarafında bu problem uzun zaman önce çözüldü: depoya bir sahiplik dosyası koyarsın, hangi dizinde kimin onayının gerektiği tartışmaya kapanır. (Tasarım kararları için aynı basitlikte bir şeyin hâlâ yerleşmemiş olmasını tuhaf buluyorum.)

Toplantı çözüm değil, semptom

Rol karmaşasına verilen ilk refleks genellikle haftalık bir senkron toplantısı eklemek oluyor. Sahipsiz karar konuşarak sahiplenilmez, sadece bir hafta ertelenir. Toplantı, karar sahibi belliyken bilgi taşımak için işe yarar; belli değilken kararsızlığı nazikçe uzatan bir tören haline gelir.

Her örtüşme israf değil

Aynı veriye iki kişinin bakması bazen kasıtlı olmalı. Zararlı olan, iki kişinin birbirinden habersiz aynı çıktıyı üretmesi. Faydalı olan, ikisinin aynı görüşme kaydından farklı sorular çıkarması. Ayrımı çıktıya bakarak yaparsın: aynı belge iki kez yazılıyorsa israftır, aynı bulgudan iki farklı çıkarım geliyorsa değildir.

Çakışmayı ölçmenin tek soruluk yolu

Sprint sonunda iki şey sor: bu sprintte hangi işi iki kişi ayrı ayrı yaptı, hangi karar kimse sahiplenmediği için ertelendi. İkincisi daha çok şey söyler. Ertelenen karar sayısı, bir ekipteki sahiplik boşluğunun en dürüst göstergesidir. Aynı karar iki sprint üst üste erteleniyorsa mesele kişilerin çalışma tarzı değildir; o kararın kime ait olduğu hiç yazılmamıştır.