Çapraz Fonksiyonlu İş Birliği Nerede Tıkanır?

Çapraz fonksiyonlu iş birliği, tasarım, yazılım, ürün ve pazarlamanın aynı hedefe birlikte çalışması demek. Kulağa yönetsel bir temenni gibi geliyor ama pratikte üç somut yerde kırılıyor: hedefin bulanık kalması, işin sahibinin belirsiz olması ve ekip büyüdükçe iletişimin kendisinin işi yemesi. Aşağıda bu üçünü projenin ilerleyiş sırasına göre tek tek açıyorum.

Önce hedef: "daha iyi deneyim" bir hedef değildir

Bir projeye başlarken ekiplerin üzerinde uzlaştığı cümle, sonradan çıkacak her anlaşmazlığın hakemi olur. Sorun şu ki bu cümle çoğu zaman ölçülemeyecek kadar geniş yazılıyor. "Kullanıcı deneyimini iyileştirmek" bir hedef değil, bir niyet beyanıdır; iki ekip aynı cümleyi imzalayıp aylarca zıt yönlere kürek çekebilir.

Ölçülebilir hale getirmenin yolu, hedefi bir sayıya ve bir tarihe bağlamak. SMART ya da OKR gibi çerçeveler tam olarak bunu yapar. Ama çerçeveyi kullanmak yetmiyor, doğru sayıyı seçmek gerekiyor. "Kayıt formu tamamlama oranını çeyrek sonuna kadar yüzde 40'tan yüzde 55'e çıkarmak" cümlesini ürün de yazılım da aynı şekilde anlar. "Formu sadeleştirmek" cümlesini ise herkes kendi işine göre yorumlar.

İkinci kontrol, hedefin şirketin geri kalanıyla uyumu. UX ekibinin ölçtüğü sayı, üst yönetimin baktığı tabloda hiçbir yere bağlanmıyorsa, o proje ilk bütçe daralmasında düşer.

Sonra rol: RACI matrisinin tek gerçek kuralı

Rollerin yazılı olmaması, yetki boşluğu değil yetki çakışması yaratır. Özellikle UX tarafında sınırlar doğal olarak bulanıktır: akışı kim kurar, metni kim yazar, boş durum ekranına kim karar verir? Bunlar tartışılmadıysa, tartışma her zaman en kötü anda, teslim tarihinde çıkar.

RACI matrisi bu yüzden işe yarar. Ancak matrisi doldururken sık yapılan bir hata onu tamamen etkisiz kılıyor: bir satıra birden fazla "Accountable" yazmak. Sorumlu (Responsible) birden fazla kişi olabilir, işi birlikte yaparlar. Hesap veren tek kişidir. İki isim yazdığınız anda o satırda hesap veren kimse kalmaz ve matris, kimsenin açmadığı bir tabloya dönüşür.

Aynı mantık beklenti yönetimi için de geçerli. Ekiplerin birbirinin kapasitesini bilmesi lafta kalmasın; hangi ekibin sıradaki iki haftası dolu, bu bilgi projenin başında masaya konsun. Sonradan öğrenilen kapasite kısıtı, plan değil kriz üretir.

İletişim yükü ekip büyüdükçe kendi başına bir maliyet

Şeffaflık üzerine yazılan her metin "herkesi sürece dahil edin" ve "düzenli toplantılar yapın" tavsiyelerini yan yana koyar. Bu ikisi belli bir ekip boyundan sonra birbirini yer, çünkü ikili iletişim kanallarının sayısı katılımcı sayısıyla değil, karesiyle büyür: n kişi arasında n(n-1)/2 kanal vardır. Beş kişilik bir ekipte 10 kanal, dokuz kişilikte 36, on iki kişilikte 66.

Pratik karşılığı şu: haftalık bir saatlik ortak toplantıya on iki kişiyi çağırdığınızda haftada 12 kişi-saat harcarsınız ve bunun büyük kısmı, o gün gündemde işi olmayan insanların dinlemesine gider. Çözüm toplantıyı iptal etmek değil, katılımcıyı gündeme göre seçmek ve kalanı yazılı kayıtla beslemek.

İşleyen ayrım genelde şöyle kuruluyor: karar gerektiren ve tartışma açık uçlu olan şeyler senkron (toplantı, demo), durum bildirimi ve karar kaydı asenkron (ortak doküman, tasarım dosyasındaki yorum, ticket). Toplantıda alınan kararın yazıya geçmediği bir ekipte şeffaflık iddiası yalnızca o odada bulunanlar için geçerlidir.

Dilin sadeliği de bu yükün parçası. "Bilişsel yük", "affordance", "race condition", "idempotent" gibi terimler kendi ekibinizde hızlandırıcıyken karma bir toplantıda yavaşlatıcıdır; karşı taraf çoğu zaman sormak yerine anlamış gibi yapar ve yanlış anlaşılma iki hafta sonra kodda ortaya çıkar.

Güven sunumla değil, teslim edilen işle kurulur

UX ekiplerinin en çok şikayet ettiği şey, önerilerinin ciddiye alınmaması. Bunun bir kısmı kurumsal önyargı, ama tamamı değil. Diğer ekiplerin gözünde güven, geçmişte önerilen şeyin uygulanabilir çıkmasıyla birikir.

Burada tasarım tarafının en sık kaçırdığı nokta, kararın uygulamaya maliyeti. Bir arayüz önerisi görsel olarak küçük görünüp veri modelinde büyük olabilir: listeyi "son görüntülenme"ye göre sıralamak, o alan hiç tutulmuyorsa yeni bir tablo, yeni bir yazma yolu ve geriye dönük boş veri sorunu demektir. Bir projede tasarım tarafının haftalarca üzerinde çalıştığı bir akışın, ihtiyaç duyduğu tek alan hiçbir yerde saklanmadığı için son anda çöpe gittiğini gördüm; kimse kötü niyetli değildi, sadece o soru hiç sorulmamıştı.

Bunun önlemi basit: öneriyi sunmadan önce yazılım tarafına "bu veri elimizde var mı" diye sormak. Bu tek soru, ciddiye alınma oranını uzun vadede herhangi bir ikna sunumundan daha çok yükseltir.

Aynı şekilde araştırma bulgusunu paylaşırken sayının nereden geldiği belirtilsin. Kaç kullanıcıyla, hangi görevde, hangi koşulda ölçüldüğü yazılmamış bir bulgu, karşı tarafta "tasarımcının fikri" olarak sınıflanır ve orada kalır.

Değiştiremeyeceğiniz yapılar ve değiştirebileceğiniz alışkanlıklar

Hantal onay zincirleri, sık değişen ekip yapıları, farklı zaman dilimleri: bunların çoğu bir UX ekibinin tek başına düzeltebileceği şeyler değil. Enerjiyi buraya harcamak yerine, kendi tarafınızda kontrol edebildiğiniz üç şey var. Kararları yazılı tutmak, işin tek sahibini belirlemek, önerileri uygulanabilirlik kontrolünden geçirmek.

Çapraz fonksiyonlu iş birliğini kültürel bir mesele olarak anlatmak yaygın, fakat pratikte işi kurtaran şey kültür değil, birkaç sıkıcı alışkanlık. Hedef bir sayıya bağlanmışsa, her satırın tek bir hesap vereni varsa ve toplantıda konuşulan şey yazıya geçiyorsa, ekipler birbirini pek sevmese de proje yürür. Tersi durumda herkes iyi niyetliyken bile yürümez.