UX Projelerinde Proje Yönetimi: Araç Değil Sahiplik Sorunu
Proje yönetim aracı seçmek bir UX projesinin en kolay kararı. Zor olan kısım, üç işe birden dağılmış bir tasarımcının bu hafta hangisine bakacağına kimin karar verdiği. Bu yazı araç karşılaştırması değil, işin tam olarak o tarafına dair.
Araç seçimi en kolay karar
Hangi panoyu kullandığın büyük ölçüde alışkanlık meselesi. Bir görevin kimde olduğunu hepsi gösterir. Hiçbiri o kişinin bu hafta senin işine bakıp bakmayacağını göstermez, çünkü o bilgi panoda değil, başka bir ekibin önceliklerinde duruyor.
Aracı değiştirmek tıkanmayı çözmez, tıkanmanın nerede göründüğünü değiştirir. Bir projede tasarım dosyalarının tek doğrusu Figma'da, görev durumunun tek doğrusu Jira'daydı; iki hafta sonra ikisi de yanlıştı, çünkü ikisini eşitlemek kimsenin işi değildi.
Buradan çıkan kural basit. Bir bilgi iki yerde tutuluyorsa, hangisinin doğru olduğunu söyleyecek bir sahip belirle. Sahip yoksa bir süre sonra ikisi de yanlış olur.
Paylaşılan kişi, gerçek darboğaz
UX projelerinde gecikmenin büyük kısmı tasarımın zor olmasından değil, tasarımcının, araştırmacının ya da frontend geliştiricinin aynı anda başka işlerde olmasından çıkıyor. Pano her şeyi doğru gösterir, kart doğru sütundadır, sadece kimse ona dokunmuyordur.
Bunu yüzdeyle konuşmak işe yaramıyor. "Ayşe zamanının %30'u bizde" cümlesi doğrulanamaz, dolayısıyla ihlal edildiğinde de fark edilmez. Gün yazın: "Ayşe salı ve perşembe bizde." İki hafta üst üste salı günü başka bir işe çekildiyse bunu tartışacak somut bir şey olur.
Paylaşılan kişinin önceliğini belirleyen kişi projenin dışındaysa, projenin gerçek yöneticisi de odur. Bu kişiyle haftada beş dakikalık bir mutabakat, ekip içindeki bütün planlama toplantılarından fazla iş görüyor.
Senkron zamanın faturası
Altı kişilik bir ekipte her gün yapılan yarım saatlik durum toplantısı haftada 15 kişi-saat eder, yani neredeyse iki tam iş günü. Bu, ekibin bir bölümünün o hafta hiç tasarım yapmaması demek. Toplantının kendisi kötü değil; durum güncellemesi için toplanmak kötü.
Durumu yazılı bırakın, toplantıyı karar gerektiren konuya ayırın. Gündemi olmayan tekrar eden bir toplantıyı iptal etmek, çoğu ekipte yeni bir araca geçmekten daha fazla zaman kazandırır ve maliyeti sıfırdır.
Takip etmeye değen tek sayı
Tasarım tarafında ölçüm genelde süreç sayar: kaç prototip, kaç test seansı, kaç bileşen. Bunlar meşgul olunduğunu gösterir, ilerlendiğini değil.
Panoda "bitti" işaretlenen bir tasarımın kullanıcının ekranına düşmesine kadar geçen gün sayısını tutun. Tek başına bu sayı, hangi adımın gerçekten tıkalı olduğunu diğer bütün metriklerden daha hızlı söyler. Sayı büyüyorsa sorun tasarım hızında değil, tasarımdan sonrasında; ki genelde orada oluyor.
Mentorluk ne zaman işe yarıyor
Genel kariyer sohbeti olarak kurulan mentorluk ilişkileri birkaç ay içinde sönüyor, çünkü gündem her seferinde sıfırdan üretilmek zorunda. Somut bir karara bağlandığında ise yaşıyor: şu ekranı iki adıma bölmek mi, tek adımda bırakıp hata mesajını düzeltmek mi. Böyle yirmi dakikalık bir konuşma, aylık "nasıl gidiyor" görüşmelerinden daha fazlasını değiştirir.
Aynısı ters yönde de geçerli. Deneyimi aktarmanın en hızlı yolu ilke anlatmak değil, elindeki gerçek bir kararı birlikte vermek.
Kaynaklar