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

UX Projelerinde Bütçe, Değişiklik ve Ekip Yönetimi

UX Proje Yönetiminde Neyi Takip Etmeli, Neyi Bırakmalı

UX projelerinde işler nadiren plana uyar. Asıl sorun planın bozulması değil, bozulduğunu ne kadar geç fark ettiğinizdir. Bütçe kalemlerinin çoğu takip edilmeye değmez, belgelerin çoğu güncellenmeye değmez; hangilerinin değdiğini ayırmak proje yöneticisinin asıl işidir.

Bütçeyi araç lisansları değil, adam-gün aşırır

Bütçe takibi denince akla önce abonelikler, lisanslar, stok görsel paketleri gelir. Bunlar kalemlerin en görünür ama en küçük kısmıdır. Bir UX projesinde paranın gittiği yer insandır: araştırmacı, tasarımcı, test moderatörü, katılımcı teşviki, bir de kimsenin bütçeye yazmadığı geliştirici saatleri.

Hesabı kendiniz yapabilirsiniz. Ekibinizin adam-gün maliyetini alın, iki kişinin bir haftasıyla çarpın, çıkan rakamı yıllık tasarım aracı faturanızla karşılaştırın. Çoğu ekipte tek bir ek araştırma turu o faturanın birkaç katına denk gelir. Küçük harcamaları titizlikle kaydetmek bu yüzden yanlış eksende hassasiyettir; asıl kaydı tutulması gereken şey kimin hangi işte kaç gün geçirdiğidir.

Haftalık finansal rapor da ancak birinin ona bakıp bir kararı değiştirme ihtimali varsa anlamlıdır. Kimsenin okumadığı rapor, bütçe kaleminin kendisidir.

Değişikliği yönetmek, belgeleri güncellemek değildir

Kullanıcı testinden çıkan tek bir bulgu, üzerinde iki hafta çalışılmış bir akışı çöpe atabilir. Bu normaldir. Anormal olan, her değişiklikten sonra bütün dokümantasyonu senkron tutmaya çalışmaktır; o iş hiç bitmez ve bir noktada ekip belgelere bakmayı bırakır, çünkü hangisinin güncel olduğu belirsizleşmiştir.

Hafif alternatif tek bir karar kaydıdır. Tarih, neyi değiştirdik, neden, kim onayladı. Dört sütun. Tasarım dosyası zaten en güncel halini taşır; eksik olan, o hale nasıl gelindiğinin izidir. Üç ay sonra birisi "bunu neden böyle yapmıştık" diye sorduğunda cevabı veren şey akış şeması değil, o kayıt olur.

Sertifika ne söyler, ne söylemez

PMP ve Prince2 süreç dilini standartlaştırır. Farklı şirketlerden gelmiş insanların "risk kaydı" derken aynı şeyi anlaması küçük bir kazanç değildir, kurumunuz eğitim bütçesi ayırıyorsa değerlendirmeye değer.

Ama bir proje yöneticisi işe alırken PMP sertifikasını, teslim edilmiş üç projenin geriye dönük kaydından daha zayıf bir sinyal bulurum. Sertifika neyi bildiğini gösterir; teslim kaydı, plan bozulduğunda ne yaptığını gösterir. UX tarafında ikincisi neredeyse her zaman belirleyici olur.

Kriz anında ses tonu bir yönetim aracıdır

Teslim tarihine üç gün kala ciddi bir sorun çıktığında bağırmak işi öne almaz. Bağıran yöneticiyle çalışan ekip bir dahaki sefere kötü haberi geciktirir, çünkü haberi getiren kişi cezayı yiyen kişidir. Sorunu geç öğrenen yönetici de zaten yönetemez.

Krizde sıra bellidir: önce ne olduğunu tek cümleyle yaz, sonra kimin ne yapacağını dağıt, hatanın nedenini sonraya bırak. O sonrası da gerçekten gelsin. Kimseyi hedef almadan yapılan bir neden konuşması, aynı hatanın tekrarlanmamasının tek pratik yoludur.

Kaynak