PM ve UX: Görev Paylaşımı Değil Karar Paylaşımı
PM ve UX uzmanı aynı ürün üzerinde çalışırken genelde bir görev listesi hazırlayıp sorunu çözdüklerini düşünür. Çakışma o listeyle bitmiyor, çünkü tartışmanın asıl konusu işi kimin yapacağı değil, işin sonunda kimin karar verdiği. Kullanıcı araştırmasını UX'in yürütmesi, araştırma bittiğinde özelliğin kapsamını da UX'in belirlediği anlamına gelmez. Ayrımı buradan kurmak, görev tablosundan çok daha uzun ömürlü oluyor.
Çakışma dört noktada toplanıyor
PM ve UX'in sınırı neredeyse hep aynı sorularda bulanıklaşır:
- Kullanıcı araştırmasını kim yürütür?
- Erken keşif ve ilk eskizlerde söz kimin?
- Bilgi mimarisini kim kurar?
- Yeni özellik ihtiyacını kim tespit eder?
Dördü aynı ağırlıkta değil. Bilgi mimarisi tartışması çoğu ekipte birkaç konuşmada kapanır, çünkü sonucu ekranda görünür hale gelir ve yanlışsa ilk kullanıcı testi bunu söyler. Araştırma ile özellik tespiti kapanmaz; ikisi de ürünün yönünü belirlediği için sahiplenme kavgası oraya yerleşiyor.
Yürütme yetkisi ile karar yetkisi ayrı şeyler
Görev listesi yapmak bu yüzden yetmiyor. Liste "kim yapar" sorusunu cevaplar, kavga ise "kim karar verir" sorusunda. UX araştırmayı yürütür, ama bulgunun yol haritasına hangi sırada gireceğine PM karar verir. Bu iki satırı ayrı yazmadığınız sürece rapor teslim edildikten sonra kimsenin ne yapacağını bilmediği bir boşluk oluşur.
| Konu | Yürüten | Son kararı veren |
|---|---|---|
| Kullanıcı araştırması | UX | Soruyu ikisi birlikte yazar, yöntemi UX seçer |
| Bulgunun yol haritasına girmesi | UX (bulguyu sunar) | PM |
| Yeni özellik sinyali | UX ve destek ekibi | Önceliği PM verir |
| Arayüz akışı ve bilgi mimarisi | UX | UX; PM yalnızca iş kuralıyla çeliştiğinde itiraz eder |
| Kapsamı kesmek | PM | Geliştirme tahmini masada olmadan verilmez |
Son satır en sık atlanan yer. Bir akışın kapsamını kesme kararı, o akışın geliştirmeye kaç gün tuttuğu bilinmeden verilirse ortaya çıkan şey karar değil dilek olur; süreyi veren kişi o masada olsun.
Yazılı sorumluluk matrisi neden eskiyor
Yaygın tavsiye şöyle işler: sorumlulukları projenin başında yazıya dök, sonra ihtiyaç değiştikçe esnek davran. İki tavsiye birbirini yiyor. Her esneme belgeyi biraz daha yanlışlar, üçüncü değişiklikten sonra kimse belgeyi açmaz ve ekip alışkanlığa döner. Alışkanlık da pratikte sesi yüksek olanın karar vermesi anlamına geliyor.
Çözüm belgeyi büyütmek değil, kapsamını değiştirmek. Görev başlıkları yerine karar türlerini yazın, her satıra tek isim koyun, yeni bir akışa başlarken o satırları on dakikada gözden geçirin (bunu ayrı bir süreç haline getirmeyi gereksiz buluyorum).
Küçük ekipte "uzmana devret" diye bir şey yok
Üç kişilik bir ekipte araştırmayı devredeceğiniz bir araştırmacı yoktur. Burada rolleri birleştirmek yerine işin kapsamını küçültmek daha iyi sonuç veriyor. Yirmi kişilik bir çalışma yerine beş kişilik bir tur yapın; Nielsen Norman Group yıllardır beş kullanıcının ciddi kullanılabilirlik sorunlarının büyük bölümünü ortaya çıkardığını söylüyor ve küçük ekipler için bu eşik iş görüyor. Moderasyonlu seansı bırakıp kayıtlı, moderasyonsuz bir teste geçin. Her turda tek soruyu cevaplayın.
Kapsamı daraltmak kaliteyi düşürmez, araştırmayı yapılabilir kılar. Hiç yapılmayan geniş araştırmanın ürüne katkısı sıfırdır.
İlk adım
Bir sonraki başlangıç toplantısında görev listesi değil karar listesi çıkarın: araştırma sorusunu kim yazar, yöntemi kim seçer, bulguyu yol haritasına kim koyar, kapsamı kim keser. Tek satırda iki isim görürseniz proje büyük olasılıkla orada tıkanacak; o satırı kapatmadan işe başlamayın.