DesignOps Rolleri: Kim Neyi Devralır, Ne Zaman Gerekir

Tasarım ekibinde yapılan işin bir kısmı tasarım değildir: dosya adlandırma, araç lisansları, araştırma katılımcısı bulma, teslim formatını geliştiriciyle konuşma, aynı toplantıyı üçüncü kez özetleme. Bu yük kimsenin görev tanımında yazmadığı için genelde en kıdemli tasarımcının takvimine yapışır. DesignOps, bu işi görünür kılıp bir yere adresleme girişimidir; roller de bu adresleme biçimine göre ayrışır.

Operasyonel yük yok olmaz, bir yere toplanır

DesignOps'un tanıtım cümlesi hep aynı kurulur: tasarımcıyı operasyonel işten kurtarır, yaratıcı işe döndürür. İlk yarısı doğru, ikincisi eksik. Dokümantasyon yazılmaya, araçlar güncellenmeye, metrikler toplanmaya devam eder. Değişen tek şey, bu işin on kişiye dağılmış görünmez halden çıkıp bir kişinin tanımlı işi olmasıdır.

Kazanç da tam buradan gelir. Aynı süreci her projede yeniden icat eden on kişi yerine, bir kez kurup tekrar eden biri çalışır. Yani rol tartışmasına "bu işi kim daha iyi yapar" diye değil, "bu iş şu anda kimin takviminden sessizce çalınıyor" diye başlamak gerekir.

Üç çekirdek rol ve aralarındaki gerçek fark

Unvanlar şirketten şirkete kayar. Ayrım, sorumlu olunan zaman ufkuna bakıldığında netleşir.

DesignOps Lead

Sistem düzeyinde çalışır: süreç, araç seti, dokümantasyon standardı, işe alım ve oryantasyon akışı. Ufku bir çeyrek ya da bir yıl. Tek bir teslimin yetişip yetişmemesi onun işi değildir; aynı tipte teslimlerin neden her seferinde son güne kaldığı onun işidir.

Producer

Proje düzeyinde ve günlüktür. Takvim, bağımlılıklar, kimin kimi beklediği, tasarımdan geliştirmeye devir. Ufku hafta. Birden fazla ürün ekibinin aynı iki tasarımcıya iş yığdığı yapılarda en hızlı karşılığını veren rol budur.

Program Yöneticisi

Organizasyon düzeyindedir: çok ekipli ortak standart, ölçüm altyapısı, ekipler arası bilgi aktarımı. Ufku yıl. Tek tasarım ekibi olan bir şirkette bu rolü açmak, yönetecek programı olmayan bir yönetici üretir.

Üçünün aynı anda bulunması gerekmez, sıraları da sabit değildir. Büyüyen ekiplerde ilk ihtiyaç çoğunlukla Producer tarafında doğar, çünkü acı ilk olarak teslim takviminde hissedilir.

Tam zamanlı pozisyonun eşiği bir hesaba dayanır

"Ekip büyüyünce DesignOps gerekir" cümlesi karar vermeye yetmez. Tasarımcı sayısını, kişi başı operasyonel işe giden zaman payıyla çarpın. Sekiz tasarımcı ve kişi başı %20 ise ortada 1,6 kişilik iş vardır; tam zamanlı pozisyon kendini rahatça öder. Beş tasarımcı ve %15 ise toplam 0,75 çıkar, yani pozisyon açmak değil, işi tek kişide toplayıp takviminde yer ayırmak doğru karardır.

Buradaki yüzdeyi tahminle doldurmanın anlamı yok. İki hafta boyunca gün sonunda tek soru sormak yeterli: bugün kaç saatini tasarım dışı işe verdin. Çıkan sayı neredeyse her zaman beklenenden yüksek olur ve hangi kalemin en çok yediğini de söyler.

Ben bu işe araç satın alarak başlamam. Aldığınız araç, bakım ve eğitim isteyen yeni bir kalem olarak aynı listenin sonuna eklenir; ölçmeden yapılan araç seçimi de genelde en gürültülü şikayeti çözer, en pahalı olanı değil. Önce saatler, sonra araç.

Ekip şekline göre ne yapmalı

Küçük ve merkezi ekipte ayrı pozisyon açmak gerekmez, ama sorumluluğu adlandırmak gerekir. Operasyonel işi üstlenecek kişinin adı ve haftalık saati yazılı olsun, hedeflerine de girsin. Yazılı değilse teslim baskısı geldiğinde ilk düşen kalem o olur, her seferinde.

Ekip büyüyüp dağıldığında Lead devreye girer. İlk işi araç entegrasyonu değil, dokümantasyon ve oryantasyondur: yeni gelen tasarımcının ilk haftada kimseye soru sormadan çalışmaya başlayabilmesi, sürecin sağlık göstergesidir.

Büyük ve dağıtık yapıda iş birden fazla Producer, Program Yöneticisi ve ResearchOps sorumlusuna bölünür. Risk burada tersine döner: operasyon kendi bürokrasisini üretmeye başlar. Buna karşı işe yarayan tek pratik, her sürecin bir sahibi ve bir gözden geçirme tarihi olmasıdır. Sahibi olmayan süreç kimsenin kaldırmaya cesaret edemediği bir alışkanlığa dönüşür.

Komşu roller

DesignOps tek başına durmaz; operasyonel sorumluluğun bir kısmı zaten mevcut rollerde dağılmış haldedir.

• Design Manager: kişi yönetimi ve kapasite planlaması; küçük ekiplerde fiilen DesignOps işini de taşır.
• Design Lead: kalite kontrolü ve karar dokümantasyonu; süreci değil çıktıyı sahiplenir.
• ResearchOps: katılımcı havuzu, onam ve veri saklama, araştırma arşivi. Araştırma yapan ekiplerde en çabuk karşılığını veren uzmanlaşma budur.

DevOps ve PeopleOps ile temas noktası da gerçektir: araç erişimi, yetkiler, yeni başlayan kurulumu. Bu üçünü her ekibin kendi başına çözmesi, DesignOps'un var olma gerekçesinin tipik örneğidir.