Konu Başlıkları
Yükleniyor...

Ürün Yönetimi ve UX: Çatışma Rolde Değil, Kararda

PM ve Tasarımcı Arasındaki Tıkanma Nerede Çözülür?

Ürün yöneticisiyle tasarımcı arasındaki sürtüşme çoğu yazıda “rol tanımları çakışıyor” diye açıklanır. Oysa ekiplerin büyük kısmında roller yeterince belli, tıkanan şey karar. Aynı ekranı iki kişi farklı gerekçeyle savunuyorsa ve hangi gerekçenin öncelikli olduğu hiçbir yerde yazmıyorsa, toplantı sayısını artırmak bunu çözmüyor.

Çakışan şey rol değil, karar

Rol çatışmasını RACI tablosuyla çözmem. Tablo doldurulurken herkes hemfikir olur, ilk ciddi anlaşmazlıkta kimse o tabloyu açmaz. Çünkü soru “kim sorumlu” değil, “iki makul gerekçe çarpıştığında hangisi önce gelir”.

İşe yarayan şey daha küçük: tartışmalı her karar için kararı verenin adı, gerekçesi ve bu karardan dönmeyi gerektirecek kanıt tek yerde yazılı dursun. Üç satır yeter. Altı ay sonra “bunu neden böyle yapmıştık” sorusunun cevabı da orada bekler.

Tartışmayı maliyetle bağlayın

Tasarım tarafı bilişsel yükten, ürün tarafı takvimden konuşurken ikisi de haklı görünür. Konuşmayı ortak bir birime çevirmek gerekiyor: bu değişiklik kaç geliştirme günü tutuyor ve hangi metriği ne kadar oynatması bekleniyor.

Asıl faydası, arayüz iddiasının kodda karşılığı olup olmadığının erken çıkması. “Alan bazında anlık doğrulama ekleyelim” cümlesi, doğrulama kuralları sunucuda tek kaynakta duruyorsa birkaç günlük iş. Kurallar her formda elle tekrarlanıyorsa aynı mantığı iki yerde tutmayı kabul etmiş oluyorsunuz ve o iki yer bir sonraki sprintte ayrışıyor. Tasarımcının bunu önceden bilmesi gerekmiyor, sözü geliştiriciye sorulmadan verilmemesi gerekiyor.

Araştırmayı ikinci elden almayın

Kullanıcı testinin özet raporu, bulguyu tartışılabilir bir iddiaya çeviriyor. Oturumu kendi gözüyle izlemiş bir ürün yöneticisi “kullanıcılar filtreyi bulamıyor” cümlesine itiraz etmez; raporu okuyan eder, çünkü elinde bulgu değil sizin yorumunuz var.

Pratikte işleyen düzen şu: oturumlar canlı izlenir, hemen ardından on beş dakikada ortak not çıkarılır. Rapor sonra yazılır ve kararı rapor değil, izleme belirler.

İki yol haritası tutmayın

Ayrı bir tasarım yol haritası, tasarım işlerinin geliştirme listesine hiç girmemesinin en kibar yolu. Tek liste olsun; araştırma ve tasarım borcu kalemleri de aynı listede, aynı ölçütle önceliklensin. Görünmeyen iş yapılmıyor.

Tasarım borcu kalemine somut bir tetikleyici yazın: hangi ekran, hangi ölçüm, hangi eşiğe düştüğünde ele alınacak. “Sonra düzeltiriz” diye yazılan kalemler listede yaşlanıyor.

Haftalık toplantı yerine karar günlüğü

Altı kişilik bir ekipte haftada bir saatlik senkron toplantı, ayda yirmi dört kişi-saat eder. Bu sürenin çoğu durum aktarımına gidiyor, durum aktarımı ise yazıyla çok daha ucuz.

Toplantıyı kaldırmak gerekmiyor, gündemini daraltmak yetiyor: karar bekleyen maddeler toplantıya, geri kalanı yazıya. İki disiplinin birlikte çalışması aslında bundan ibaret. Aynı listeye bakmak, kararı kimin verdiğini bilmek, gerekçeyi bir yerde tutmak.