DesignOps Olgunluğu Neden Düşük Kalıyor?
DesignOps'un şirketlerde yerleşmemesi genelde ilgisizliğe ya da bütçeye bağlanıyor. Daha ilginç bir ihtimal var: ölçtüğümüz şey olgunluk değil, hazır bir öneri listesine uyum. Rol, süreç ve ölçüm başlıklarının pratikte nerede dağıldığına bakınca tablo değişiyor.
Olgunluk mu, uyuma verilen not mu?
DesignOps olgunluk çalışmaları hemen hep aynı biçimde kurulur. Önerilen faaliyetlerin listesi çıkarılır, ekiplere kaçını yaptıkları sorulur, çıkan oran olgunluk diye raporlanır. Peki ya listedeki maddelerin yarısı o ekibin ölçeğinde gerçekten gereksizse? Sekiz kişilik bir tasarım ekibinin ayrı bir ResearchOps rolü açmaması olgunsuzluk değil, doğru karar olabilir.
Bu ayrımı yapmadan bakınca düşük oranlar dramatik görünüyor. Ayrımı yapınca soru daha kullanışlı hale geliyor: ekip hangi işi her seferinde elle tekrar ediyor ve bu tekrarın maliyeti bir rol, bir şablon ya da bir otomasyon açmayı haklı çıkarıyor mu?
Ek görev olarak DesignOps neden eriyor
Çoğu şirkette DesignOps ayrı bir pozisyon değil, tasarımcılardan birinin üzerine eklenen sorumluluk. Teslim tarihi olan tasarım işiyle teslim tarihi olmayan süreç işi aynı takvimde yarışınca hangisinin kazanacağı baştan belli.
Peki ya süreç işine de bir tarih ve gözle görülür bir çıktı verilseydi? Çoğu zaman yeterli oluyor. "Süreçleri iyileştir" hiçbir zaman başlamaz, "cuma gününe kadar araştırma katılımcısı davet şablonunu yaz" başlar ve biter. Süreç işini proje işi gibi ele almak, ayrı rol açmadan alınabilecek en büyük mesafe.
Yazılan süreç altı ay sonra neden okunmuyor
Doküman ile işin gerçekte yürüdüğü yol arasındaki fark ilk günden açılmaya başlar. Sorun dokümanın güncellenmemesi de değil aslında; güncellendiğini kimsenin fark etmemesi.
Sürecin yaşamasını istiyorsanız onu insanların zaten baktığı yere koyun. Tasarım dosyasının içindeki kapak sayfası, ticket şablonu, PR açıklamasındaki kontrol listesi, kick-off davetinin gövdesi. Ayrı bir wiki sayfasında duran süreç, ancak birisi onu aramayı akıl ederse vardır.
Tasarım metriği aramanın daha verimli bir yolu
"Tasarım kalitesini ölçemiyoruz" cümlesi büyük ölçüde doğru. Kalite, bağlamı olan bir yargı ve tek sayıya inmiyor. Ama ölçmenin imkânsız olduğu yerden, ölçmeye hiç çalışmamaya atlamak da gerekmiyor.
Tartışmaya kapalı, sayılabilir bir şey var: onaylı bileşenin dışına çıkan ekran sayısı. Tasarım sisteminde tek bir buton tanımlıyken üründe altı farklı buton dolaşıyorsa, bunu kod tarafında saymak birkaç saatlik iş. Sayının kendisi kaliteyi ölçmez; sistemin gerçekten kullanılıp kullanılmadığını ölçer, ki pratikte daha yakıcı soru odur.
Ayrışmanın nerede yoğunlaştığı da ayrıca bilgi veriyor. Aynı ekranda tekrar tekrar sistem dışına çıkılıyorsa ya tasarım o durumu karşılamıyordur ya da uygulaması ekibin bütçesini aşıyordur. İkisi de düzeltilebilir, ama önce hangisi olduğunu bilmek gerekir.
Nereden başlanır
Olgunluk modelinin üst basamağını hedeflemek yerine, ekibin son üç ayda en çok tekrarladığı elle işi bulun. Dosya adlandırma olabilir, katılımcı bulma olabilir, her yeni ekran için baştan yazılan kabul kriterleri olabilir. Onu bir kez kalıcı olarak çözmek, on sayfalık bir süreç dokümanından daha fazlasını değiştirir ve bir sonraki adımın ne olması gerektiğini de kendisi gösterir.