Adım 2: Önceliklendirilmiş İnceleme
Envanter teyit edildikten sonra her iş akışını iki eksende sıralarız: beklenen getiri ve uygulama zorluğu. Bu adımın amacı kesin bir ROI sayısı üretmek değildir — tek bir sayfada hangi iki veya üç iş akışının önce ele alınmaya değer olduğunu net görmenizi sağlayacak bir sıralama ortaya çıkarmaktır.
Neye bakarız
Beklenen getiri genellikle frekans × örnek başına maliyet fonksiyonudur. Frekansı (haftada veya ayda) gerçekçi örnek başına süre ile çarpar, dolaylı maliyet tahminini ekleriz — bağlam değiştirme, daha sonra geri alınması gereken hatalar, müşteri deneyimi etkileri. Ayda 200 kez çalışan ve her seferinde 10 dakika süren bir iş akışı, ayda üç kez çalışan ve iki saat süren bir iş akışından farklı bir konuşmadır.
Uygulama zorluğu, dürüstçe tahmin etmesi daha zor olan eksendir. Zorluk tahminini, henüz işe almadığınız bir geliştirici uygulamayı yapacakmış gibi yazarız — biz yapacakmışız gibi değil. Bu, tahmini bizim iyimserliğimizden ziyade piyasa oranına sabit tutar. Zorluk hem inşa maliyetini (ilk çalışan sürümü almak ne kadar sürer) hem de bakım maliyetini (bu şey ne sıklıkla bozulur, kurtarma ne kadar karmaşık) içerir.
Sonra bariz kazançları ararız: yüksek getirili, düşük zorluklu, düşük riskli iş akışları. Bunlar genellikle öneri listesinin tepesine gider. Ve bariz atlamaları ararız: zorluk ne olursa olsun düşük getirili veya marjinal kazançla yüksek zorluklu iş akışları.
Bu aşamada yaygın hatalar
Darboğaz yerine acılı adımı optimize etmek. Bazen en kötü hisseden iş akışı adımı — ekibinizin en çok şikayet ettiği — aslında gerçek kısıtlamanın akış aşağısındadır. Acılı adımı otomatikleştirmek iş akışını hızlandırmaz; sadece beklemeyi kaydırır. Gördüğümüzde bunu açıkça işaretleriz.
'Daha fazla otomasyon'u otomatik olarak daha iyi olarak ele almak. Bir insan tarafından %99 güvenilirlikle 4 dakikada yapılan bir iş akışı bazen doğru cevaptır. Onu otomatikleştirmek üç ay mühendislik zamanına mal olabilir ve yeni bir başarısızlık modu getirebilir. Bu adımın doğru çıktısı bazen 'bunu otomatikleştirmeyin'dir.
Bakımı hafife almak. Otomasyonlar çürür. API'ler değişir, satıcılar özellikleri kullanımdan kaldırır, iş kuralları kayar. İnşa için bir mühendis-haftası ve çeyrek başına bir mühendis-gün bakım gerektiren bir iş akışı, aynı haftada inşa edilen ve hiç bozulmayan birinden çok farklı bir ömür maliyetine sahiptir. Zorluk tahminine bakım maliyetini dahil ederiz.
Bu adım pratikte nasıl görünür
Bir sayfalık bir sıralama alırsınız. Envanterdeki her iş akışı şunları gösteren bir satır alır: tahmini yıllık geri kazanılan süre (saat ve kabaca dolar cinsinden), düşük/orta/yüksek ölçekte uygulama zorluğu, sıralama için tek cümlelik bir gerekçe ve bir durum: 'önerilen,' 'belki' veya 'henüz değil.' Sayfa bilinçli olarak kısadır. Ona bakıp hangi iki veya üç iş akışının daha fazla konuşmaya değer olduğunu hemen bilmeniz gerekir.
Çoğu zaman bu sayfadaki en şaşırtıcı satır 'henüz değil' girdisidir — otomatikleştirmek için geldiğiniz, düşük sıralanan bir iş akışı. Her zaman nedenini açıklarız. 'Neden,' gerçekte yararlı çıktıdır, sıralamanın kendisinden daha fazla.