DesignOps: Hangi Sorunu Çözer, Nerede Yanlış Kurulur

Tasarım ekibi büyüdükçe tasarımcının zamanı tasarıma değil koordinasyona gider: hangi dosya güncel, kimin onayı bekleniyor, bu bileşen zaten bir yerde var mı. DesignOps bu kaymayı tersine çevirme girişimidir; tasarımın kendisiyle değil, tasarımın etrafındaki işle uğraşır. Çoğu kurulum da tam bu ayrımı kaçırdığı için bir süre sonra kendisi fazladan iş haline gelir.

Tasarımın etrafındaki iş

DesignOps bir ekibin çıktısını değil, o çıktıya giden yolu konu alır. Üç soruya indirgenebilir:

• Birlikte nasıl çalışıyoruz: ekip yapısı, işe alım, yeni gelenin ilk haftası.
• İşi nasıl bitiriyoruz: akışlar, önceliklendirme, dosya ve bileşen düzeni.
• Çıktı nasıl değere dönüşüyor: kalitenin takibi ve sonucun kurum içinde görünür olması.

Bu soruların hiçbiri iki kişilik bir ekipte sorun değildir. Dördüncü tasarımcı geldiğinde, ikinci ürün hattı açıldığında ya da aynı buton üç dosyada üç farklı halde bulunduğunda sorun olmaya başlar. Kavramın son yıllarda bu kadar konuşulmasının sebebi de bu: ekipler büyüdü ve koordinasyon maliyeti tasarım maliyetini geçti.

Ölçümü en sona koymanın bedeli

Standart anlatım dört adım verir: durum analizi, hedef belirleme, uygulama, ölçümleme. Sıra mantıklı duruyor. Ama ölçüm en sonda olduğunda karşılaştıracak bir şey kalmaz. Standartlaştırmadan önce sayı almadıysan, sonrasında çıkan sayının iyi mi kötü mü olduğunu söyleyemezsin; elinde bir fark değil, tek bir ölçüm olur. Durum analizi bu yüzden anket değil sayım olmalı.

Neyi sayacağına gelince, ekip memnuniyeti anketlerini teslim sonrası geri dönüş sayısından daha az güvenilir bulurum. Anket ekibin o haftaki moralini ölçer. Bir tasarımın geliştirmeye gittikten sonra kaç kez geri döndüğü ve ilk teslimle canlıya çıkış arasında kaç gün geçtiği ise sürecin kendisini ölçer, kimsenin yorumuna ihtiyaç duymaz. Bu iki sayı çoğu ekipte halihazırda bir yerde kayıtlıdır; çıkarmak için yeni araç gerekmez, geçmiş işleri geriye doğru okumak yeter.

Kim sahiplenir?

Büyük organizasyonlarda DesignOps bir rol olarak açılır, küçük ekiplerde "kolektif sorumluluk" diye anlatılır. Kolektif sorumluluk pratikte sahipsizliktir: bileşen kütüphanesini kimse temizlemez, çünkü herkesin işidir.

Peki ekip üç kişiyken gerçekten ayrı bir unvan mı açılacak? Hayır. Ama sahiplik isimsiz kalmaz. Haftada yarım gün ayıran bir kişi yeter; mesele o yarım günün takvimde gerçekten yer tutması ve kimin ayırdığının bilinmesi.

Kurma kararı da aynı yerden verilebilir. Koordinasyona giden zamanı bir ay boyunca yazarsan, ayrı bir operasyon katmanının gerekip gerekmediği kendiliğinden ortaya çıkar. Yazmadan kurulan DesignOps, çözdüğünü iddia ettiği karmaşanın yeni bir katmanıdır.