DesignOps: Tasarım Sürecinde Neyi Standartlaştırmaya Değer
DesignOps çoğu yazıda süreç iyileştirmenin şemsiye adı olarak geçer ve orada kalır. Somut hali daha dar: tasarım ekibinin tekrar eden işlerinden hangilerinin standartlaştırılacağına, hangilerinin serbest bırakılacağına karar vermek. Bu kararın kendi maliyeti var, çünkü her standart her projede yeniden ödenir.
Neyi çözer, neyi çözmez
DesignOps'un çözdüğü şey tasarımın kalitesi değil, aynı işin her seferinde sıfırdan kurulması. Dosya adlandırması, geri bildirimin kaç tur döneceği, bir işin hangi noktada geliştiriciye geçtiği. Bunlar her projede yeniden tartışılıyorsa haftada birkaç saat oradan gidiyor.
Çözmediği şey de net. Kötü bir ürün kararı süreç düzeldiği için iyileşmez; ekip yanlış şeyi daha hızlı ve daha tutarlı üretir hale gelir.
Nereden başlanır
Yaygın tavsiye süreci baştan sona haritalandırmakla başlar. Büyük ekipler dışında bunun karşılığı yok. Harita çıkarmak haftalar alır, çıktığında bir bölümü çoktan değişmiştir.
Daha kısa yol, son üç projede en çok tekrar eden tek soruyu bulup onu yazılı hale getirmek. Çıkan şey genelde görkemli olmaz. “Bir ekran hangi noktada hazır sayılır” ya da “değişiklik talebi nereye yazılır” düzeyindedir, ve tam bu yüzden işe yarar: haftada beş kez sorulan soruyu bir kez cevaplamış olursun.
Ölçüm: neyi saymak anlamlı
Ölçüm başlığı altında hemen NPS ve memnuniyet anketleri sayılıyor. Bunlar ürünün metriği, ekibin değil. NPS bir fiyat değişikliğiyle, bir kesintiyle, destek ekibinin yanıt süresiyle oynar. Tasarım sürecindeki bir iyileştirmenin payını o sayının içinden ayıklamanın yolu yok.
Bir tasarım kararının fikirden koda geçme süresini NPS'ten daha güvenilir bulurum. Kusursuz değil, oynanmaya açık; ama en azından ekibin kendi kontrolündeki bir şeyi sayıyor: karar ne zaman verildi, ne zaman canlıya çıktı, arada kaç tur geri bildirim döndü.
Standardın maliyeti
Bileşen kütüphanesi DesignOps'un en görünür çıktısı ve maliyeti en çok küçümsenen kısmı. Üç boyutu, dört durumu ve iki teması olan bir bileşen 24 kombinasyon demektir. Buna bir boyut eklendiğinde sayı 32'ye çıkar. Kombinasyonların çoğu tasarımda ayrıca çizilmez, ama kodda bir karşılığı, bir hata ihtimali ve gözden geçirilecek bir hali olur.
Standardın karşılığı bu yüzden ekip ve proje hacmine bağlı. Yılda üç iş çıkaran beş kişilik bir ekipte belgelenmiş devir teslim süreci kazandırdığından fazlasını götürür. Aynı süreç eşzamanlı sekiz akış yürüten bir ekipte kendini ilk ayda amorti eder. DesignOps'a başlarken sorulacak soru yöntemin doğruluğu değil, ekibin hacmi.