Karar İçin Ölçmek, Yargı İçin Değil
Ölçüm konuşmalarının çoğu, fark edilmeden performans konuşmasına dönüşür. Bir metriğin işe yaramamaya başladığı an tam da budur — insanlar, sayının tarif etmesi gereken işi değil, sayının kendisini optimize etmeye başlar.
Bir sayıya bakmanın iki farklı sebebi
Karar için ölç
- • Sorun nerede ve ne kadar büyük?
- • Değişiklik beklenen etkiyi yarattı mı?
- • Hangi iş yaşlanıyor veya tıkanıyor?
- • Bir sonraki en güvenli deney nedir?
Yargı için ölçme (bundan kaçının)
- • Kişileri sıralamak
- • Takımları tek sayıyla karşılaştırmak
- • Hedefi metrikle eşitlemek
- • Yerel verimle bütün sistemi optimize etmek
Bir metrik ödül veya ceza hedefi haline geldiği an, insanlar sistemi değil sayıyı optimize etmeye başlar. Eklemek üzere olduğunuz her metrik için şu testi uygulayın: bu metriğin değiştirmesi gereken kararı tam olarak adlandırın.
Kararın yargıya kayması pratikte genelde böyle olur. Bir destek yöneticisi, her temsilcinin ortalama ilk yanıt süresini haftalık bir tabloda paylaşmaya başlar — niyeti iyidir, müşterilerin daha hızlı yanıt almasını ister. İki ay içinde ortalama ilk yanıt süresi gerçekten düşer. Ama müşteri memnuniyeti puanları da düşer. Olan şu: temsilciler, karmaşık talepleri “inceleniyor, en kısa sürede döneceğiz” gibi hızlı ama boş bir ilk yanıtla kapatıp asıl çözümü sonraya bırakmayı öğrenir. Yöneticinin izlediği sayı harika görünür. O sayının temsil etmesi gereken şey — müşterinin gerçekten hızlı yardım alması — kötüleşir. Metrik yanlış değildi; yargı için kullanılması onu bir hedefe, hedef de oyunlanan bir şeye dönüştürdü.
Tek sayı değil, dört mercek
Bunlardan yalnızca birini optimize etmek, genellikle fark edilmeden bir diğerini bozar. Kaliteyi göz ardı eden hız, yeniden çalışmaya dönüşür. Akış görünürlüğü olmayan memnuniyet, büyüyen bir kuyruğu gizler. Dengeli bir bakış dördünü birlikte izler ve aralarındaki ödünleşimleri kazara değil, görünür kılar.
Değer
Kullanıcı sonucu, iş veya risk etkisi, benimseme.
Akış
Döngü süresi, throughput, devam eden iş.
Kalite
Kaçan hata, yeniden çalışma, teknik sağlık.
Takım sağlığı
Odak, güven, sürdürülebilir tempo.
Bunun somut bir hâli şöyle: sprint sonuna doğru bir ekip, daha çok işi kapatmak için code review standardını gevşetir — akış hızlanır, throughput yükselir, burndown harika görünür. Üç hafta sonra üretimde art arda üç olay (incident) yaşanır ve bunları söndürmeye harcanan zaman yeni özellik geliştirmeyi neredeyse durdurur. Akışı kaliteyi izlemeden optimize etmişlerdir; kalite bozulunca akış da onunla birlikte bozulur. İki merceği birlikte izleselerdi, aynı haftaki throughput artışının yanında kaçan hata oranındaki artış da anında görünür olurdu — üç hafta sonra öğrenmek yerine, WIP limitini sıkılaştırmak ya da review standardını koruyup hız beklentisini baştan ayarlamak için yeterince erken bir sinyal.
Bu, çıktı–sonuç–etki zincirinin üzerine kurulur
Daha önce okumadıysanız önce Çıktı, Sonuç ve Etki Farkı yazısını okumak faydalı olur — yukarıdaki "değer" merceği, tam olarak o zincirin bir metriğe uygulanmış hâlidir. Bir çıktı sayısı (yayınlandı, kapatıldı, dağıtıldı) gereklidir ama tek başına asla yeterli değildir; değer hakkında bir şey söylemesi için bir sonuç veya etki sinyaliyle birlikte okunmalıdır.
Sık sorulan sorular
Velocity de bir metrik değil mi — neden karar metriği değil?
Velocity, bir takımın kendi kapasite planlamasında bir karar metriği olabilir. Takımları sıralamak veya hedef koymak için kullanıldığı an bu özelliğini kaybeder — o noktada insanlar işi değil sayıyı optimize etmeye başlar.
Dört merceği aynı anda izlemek karmaşık gelmiyor mu?
Dört ayrı panoya bakmak anlamına gelmiyor. Herhangi bir sayıyı okumadan önce, bunun neyi feda edebileceğini sormak anlamına geliyor. Pratikte genelde mercek başına bir-iki sinyal, tek tek değil birlikte gözden geçiriliyor.
Metrik seçimine nereden başlamalıyım?
Elindeki veriden değil, karardan başla. Önce 'aslında hangi kararı daha iyi vermeye çalışıyorum?' diye sor, sonra o kararı değiştirecek en küçük sinyali seç.