DesignOps Takım Yapıları: Hangi Model Ne Zaman İşe Yarar

DesignOps yapısını seçmeden önce tek bir soruyu cevaplayın: tasarımcının haftası nereye gidiyor? Toplantıya, dosya aramaya, araç lisansına ve her projede baştan kurulan hazırlık işine giden saat, ihtiyacınız olan modeli büyük ölçüde belirler. Ölçmeden seçilen yapı çoğu zaman var olan sorunu çözmez, sadece resmileştirir.

İki haftalık zaman kaydı

Olgunluk modeline, ankete, atölyeye gerek yok. Ekipteki herkes iki hafta boyunca gününü üç kovaya yazsın: tasarım, tasarımı mümkün kılan iş, tasarımla ilgisi olmayan iş. İkinci kova toplamın dörtte birine yaklaşıyorsa ayrı bir DesignOps rolü tartışmayı hak eder. Üçüncü kova büyükse probleminiz DesignOps değil, iş dağıtımı; yeni bir rol açmak orayı düzeltmez.

Beş yapı ve ilk kırıldıkları yer

DesignOps, tasarım ekibinin operasyonel yükünü (süreç, araç, dokümantasyon, işe alım) tasarımcının sırtından alan işin adı. Bu yükü kimin taşıdığına göre beş yaygın kurulum çıkıyor. Kavramın genel çerçevesi için NN/g'nin özeti yeterli.

Yapı	İşe yaradığı yer	İlk kırıldığı yer
Dağınık	Tek ve küçük tasarım ekibi; iş, liderin ek yükü olarak yürür.	Ekip sayısı ikiyi geçtiğinde süreçler birbirinden ayrışır.
Yalnız	Büyümüş tek ekip; atanmış bir kişi yükü toplar.	Talep tek kişinin kapasitesini aşar, işler kuyruğa girer.
Uzmanlaşmış	Araç, süreç ve işe alımın ayrı ayrı ilgi istediği orta ölçek.	Uzmanlar arası devir noktaları; kimsenin sahiplenmediği işler.
Dağıtılmış	Çok ürünlü organizasyon; her ekibe gömülü bir kişi.	Gömülü kişiler kendi ekibine özel çözüm üretir, ortak standart erir.
Yükseltilmiş	Büyük tasarım organizasyonu; bağımsız takım ya da departman.	Merkez sahadan kopar, kimsenin kullanmadığı süreç yazar.

"Küçük başla, sonra büyüt" nerede ters çalışır

Yaygın tavsiye dağınık modelle başlayıp zamanla yukarı çıkmak. Sorun şu: dağınık bir başlangıç aşaması değil, DesignOps'un yokluğu. Zaten herkes oradan başlıyor, seçilen bir şey değil. Üstelik o modelde geçen her ay, ekiplerin kendine göre kurduğu şablon, isimlendirme ve araç seti olarak birikiyor. Geçiş maliyeti beklerken düşmüyor, artıyor.

Sekiz ay boyunca üç ekip üç ayrı bileşen kütüphanesi kurduysa standardizasyon artık süreç işi olmaktan çıkar, göç işine döner ve kimse göçü sevmez. İlk atamayı ikinci tasarım ekibini kurduğunuz ay yapın, ilk şikâyet geldiğinde değil.

Standardizasyon dokümanda değil, kodda görünür

DesignOps'un en çok konuşulan çıktısı tasarım sistemi. Dokümante edilmiş bir sistem tek başına bir şey garanti etmez; asıl soru, tasarım dosyasındaki bileşenle üründe çalışan bileşenin aynı şeyi gösterip göstermediği. İkisi ayrı ayrı güncellendiği sürece iki ayrı gerçek üretirsiniz ve tartışmalar hangisinin doğru olduğuna kayar (dokümanı bileşen kodundan üretmek bu tartışmayı büyük ölçüde bitirir).

Ölçümü de basit: üründe kullanılan bileşenlerin kaçının sistemde karşılığı var? Oran düşükse ekibin yapısını değiştirmeden önce sistemin bakımına bakın.

Hibritler ve geri dönüş

Büyük organizasyonların çoğu merkezi bir çekirdekle gömülü rolleri birlikte kullanır: standardı merkez yazar, gömülü kişi uygular ve sahadan geri bildirim taşır. Bu iki uç arasında düzenli bir hat yoksa merkez kağıt üretmeye başlar. Yapı tek yönlü de değil; talep düşerse büyümüş bir DesignOps departmanını küçültmek, onu hiç kurmamış olmaktan daha kolay bir problemdir.