Ürün ve UX Ekiplerinde RACI Matrisi Nerede Tıkanır

RACI, kim ne yapıyor sorusunu değil, kim karar veriyor sorusunu çözmek için var. Ürün ekiplerinde çoğu matris bu yüzden çalışmıyor: R sütunu zaten belliyken doldurulup A sütunu geçiştiriliyor. Aşağıda matrisin gerçekten tıkandığı üç yer ve nereye yazılması gerektiği var.

Asıl iş A sütununda

R sütununu doldurmak kolaydır, çünkü çoğu görevde kimin yaptığı zaten bellidir. Kullanıcı görüşmesini araştırmacı yapar, prototipi tasarımcı çizer. Matrisi kurmaya değer kılan şey A: bir görev tamamlandı mı, yeterli mi, ilerleyebilir miyiz sorusuna cevap verecek tek kişi.

Tek kişi olması kuralı laf olsun diye konmamış. İki isim yazıldığı anda kural işlevini kaybeder, çünkü anlaşmazlıkta kime gidileceği yine belirsizdir. Peki gerçekten tek isim yazılamayan görevler ne olacak? Araştırma bulgusunun tasarıma girmesi gibi iki disiplinin ortasında duran işler var. Orada yapılacak şey iki A yazmak değil, görevi ikiye bölmek: bulgunun geçerliliğine araştırmacı, o bulgunun bu sürümde uygulanıp uygulanmayacağına ürün yöneticisi karar verir.

Consulted sütunu sessizce takvim yer

C zararsız görünür. Fikri alınacak kişi, katkı sunan uzman, kulağa iyi geliyor. Uygulamada her C bir bekleme noktasıdır: o kişiye ulaşılana kadar görev ilerlemez.

Bir karara beş kişi C olarak işaretlendiyse, karar beş takvimin kesişimini bekliyor demektir. Ekipler bunu genelde matris şişince değil, sprint sonunda "neden bu kart hâlâ inceleme aşamasında" diye bakınca fark ediyor. Ya bu isimlerin çoğunu I'ya çevirsek? Kaybedilen şey erken itiraz imkânı, kazanılan şey hız. Kararın geri alınması pahalıysa (veri modeli, fiyatlandırma, erişilebilirlik uyumu) C kalsın; kararın geri alınması ucuzsa (metin, ikon, yerleşim varyantı) I yeterli, itiraz sonradan da gelebilir.

Matrisin kendisi bir bakım yükü

Görev sayısı ile rol sayısının çarpımı kadar hücre doldurursunuz. Yirmi görev ve sekiz rol, yüz altmış hücre demek. Bunların hepsini bir atölyede doldurmak bir günü alır, sonra ilk sprintte görev listesi değişir ve matris eskimeye başlar. Kimse güncellemediği için de üç ay sonra kimse bakmaz.

Bu yüzden tam matris kurmak yerine dar başlamak daha isabetli. Son retrospektifte gerçekten karışıklık çıkan görevleri listeleyin, genelde beşi geçmez, sadece onlara A ve C atayın. Karışıklık çıkmayan görev için satır açmak boşa iş.

Scrum ile uyumu iddia edildiği kadar kolay mı?

Kaynakların çoğu RACI'nin çevik ekiplere kolayca uyarlanabildiğini söylüyor. Burada bir gerilim var: scrum, sprint içindeki iş dağılımını takımın kendisinin yapmasını bekler, RACI ise görev bazında rolü önceden sabitler. İkisi aynı anda uygulandığında ya matris her sprint yeniden yazılır ya da takımın kendi kendini örgütlemesi kâğıt üzerinde kalır.

Pratikte işleyen ayrım şu: sprint içindeki günlük işler için matris kurmayın, takım kendi dağıtsın. Matrisi sprint sınırını aşan kararlar için saklayın, mesela araştırma bulgularının yol haritasına girmesi, erişilebilirlik uyumunun kimin onayıyla kapandığı, canlıya çıkış kararı. Bunlar zaten takım içinde çözülmeyen, dışarıdan bir A isteyen işler.

Nereye yazılacağı, ne yazılacağı kadar belirleyici

Ayrı bir dosyada duran matris ölü doğar. Kimse görev başlarken başka bir dokümana bakmaz. Bunun yerine matrisi görevin kendisine gömün: kart şablonuna iki alan ekleyin, onaylayan kim ve görüşü alınacak kim, üçüncü bir araca gerek yok. Alan boşken kart açılamıyorsa matris kendiliğinden güncel kalır.

Yazılım tarafında bunun çalışan bir örneği zaten var. Depodaki CODEOWNERS dosyası tam olarak bir RACI parçasıdır: dosya yoluna göre kimin onayı zorunlu, bunu ayrı bir tabloda değil işin geçtiği yerde tutar ve onay alınmadan birleştirme yapılamaz. Tasarım ve araştırma çıktıları için de aynı mantık kurulabilir, önemli olan onayın işin akışını fiilen durdurabilmesi. Durduramıyorsa yazdığınız şey matris değil, temenni.