Proje ve Ürün Geliştirmede KPI Kullanımı

Ölçmek, ölçmeye çalışmak, her “şey”i sayısallaştırarak sınırlarını çizmek en az 200 senelik bir mesele. Ancak insanı ölçmek hakikaten zor. Kişiyi tek başına ölçmek ayrı, başkalarıyla beraber (takım halinde) ölçmek apayrı bir konu.

Bu yazıda, daha çok “Agile” yazılım geliştirme süreçlerinde; KPI’ları belirlerken neleri dikkate almak gerekir? Parametrelerimiz ne olmalı? Bizim için önemli olan ne? gibi soruların cevabını arayacağım.

Bir şirketin içerisinde hedeflere ulaşmak için tabii ki birilerinin bu hedefleri belirlemesi, belirlenen hedeflerin de uygulanması, izlenmesi, raporlanması gibi süreçler vardır. Üst yönetimler çoğunlukla Proje/Product Yönetimi, Süreç, Kalite, Verimlilik gibi kavramların uygulamasına gelince kendisine “dokunduğu” için doğru olanı yap(a)mazlar. Yapanları ve yapmaya çalışanları tebrik etmek lazım.

Peki KPI (key performance indicators) Nedir?

Reference

PMI’a göre KPI, bir organizasyonun mevcut ve gelecekteki başarısı için en mühim taraflarına odaklanan ve bir dizi tedbiri temsil eden parametrelerdir.

KPI’lar belirli bir hedef olabileceği gibi bir aralık da olabilir.

Organizasyonların KPI’ları sadece bütçe ve süreyi değil; süreç, kalite, müşteri ve sürekli öğrenmeye yönelik parametreleri de barındırmalıdır.

KPI’lar şirket, departman ve çalışan seviyesinden de ölçeklendirilebilir. Bu ölçeklendirme en alt seviyeden en üste kadar tüm süreçlerin bütünsellik içinde değer üretmesine yardımcı olur.

Reference

KPI’ları belirlerken sadece A projesinin bütçesi, planlanan süresi, kalite parametreleri ile ilgilenmek doğru değildir. Eğer A projesi B,C gibi projeleri daha kötü etkiliyorsa ve bu da şirkete faydadan çok zarar getirecekse ona göre tekrar bu KPI işini düşünmek gerekir. Yani A projesi şirketin stratejik hedeflerine de katkı sağlamalıdır. Makasın bir koluna bastığımızda arada parmağımızın olmamasına dikkat etsek güzel olur.

KPI’ları sadece Proje Yöneticisi değil, strateji hedeflerini oluşturan paydaşlar da KPI’ları belirleyen taraflardan biri olmalıdır.

Çoğu şirket, projelerin KPI’larına bütçe ve zaman olarak bakmayı tercih ediyor maalesef. Ürettiğimiz ürün ve o ürünü kullanan müşterilerimizin bu işin sonunda bir “değer” kazanması gerekir. Ürün roadmap’i de, KPI’larımız da bu “Business Value” ya hizmet etmelidir. Her şirketin KPI parametreleri farklı olabilir tabii ki ancak kanaatimce KPI’ları belirlerken “Business Value” kavramı merkezde olmalı.

Peki Agile Geliştirmelerde Bu İşler Nasıl Olmalı?

Agile KPI’lar

1. Sprint burndown

Zamanla ne kadar iş tamamlandığını gösterir. Amaç sprint sonunda taahhüt edilen işlerin tamamlanmasıdır.

İzlenecek Anti Pattern’ler:

• Ekip sprint bitiş tarihinden önce işleri bitirdiyse yeterli taahhüt veremedi.
• İşleri bitiremediyse fazla tahminleme yapıldı.
• İşler burndown guideline’ı gibi azalmazsa demek ki yeterli seviyede iş kırılımı yapılmıyordur.
• Product Owner sprint başladıktan sonra kapsamı değiştirdi mi? Onu da görebiliriz.

2. Epic and release burndown

Daha büyük ölçekteki işlerin nasıl ilerlediğini gösterir. Sprintlerdeki kapsam değişimi çok hoş görülmese de Epic ve Versiyonlar için kapsam değişimi normaldir.

İzlenecek Anti Pattern’ler

• Ekip çalışmaya devam ederken Epic veya Release tahminlemeleri değiştirilmez.
• Bir kaç iterasyondan sonra ilerleme kaydedilmemiştir.
• Kronik kapsam kaymaları Product Owner’ın kapsamda neyi çözmeye çalıştığını tam anlamadığını gösterir.
• Kapsam ekibin bu işleri tamamlayabileceğinden daha hızlı büyür.
• Bir Epic’in geliştirilmesi boyunca takımın incremental release teslimi yapamadığı görülür.

3. Velocity

Bir scrum ekibinin bir sprint esnasında tamamladığı ortalama iş miktarıdır. Product Owner’lar bir takımın backlog’dan ne kadar hızlı iş eritebildiğini bununla izleyebilirler.

İzlenecek Anti Pattern’ler

Velocity uzun süre boyunca düzensiz olursa ekibin estimation durumu sorgulanabilir. Retro toplantılarında aşağıdaki sorular sorulabilir.

• Bu çalışmayı yaparken öngörülemeyen development sorunları var mı?
• Ekibin sınırları dışında dış faktör var mı?
• Sprint’i öngörmede aşırı duyarlı mı davranıyoruz?

4. Control Chart

Bireysel anlamda issue’ların başladıktan sonra tamamlanan’a kadar geçen süre ile ilgilenir. Daha kısa döngü (“In Progress”’ten “Done” olana kadar) süresine sahip takımlar büyük olasılıkla daha başarılı olurlar. İhtiyaçları doğru kırdıklarını gösterir. Bu döngü süresi daha çok Kanban takımları için belirleyici olsa da Scrum ekipleri için de iyileştirmeye yönelik olarak kullanılabilir.

İzlenecek Anti Pattern’ler

Kontrol chart ilk başta kararsız gözükebilir ama önemli olan burada trendin doğru gidiyor olması. 2 kısma odaklanmak lazım:

• Artan Döngü Süresi — Artan döngü süresi Agility’nin esas hedefinden uzaklaşmamıza sebep olabilir. Buartışın sebebini retro toplantılarında bulmak gerekir. Bir istisna, takımın “definiton of done” tanımı büyüdüyse ona göre döngü süresi de artabilir.
• Kararsız Döngü Süresi — Amaç benzer Story point değerine sahip her bir work item için tutarlı bir döngü süresi olmasıdır. Tutarlılığı izlemek için her bir Story point için konrol çizgisine bakılabilir.

5. Cumulative Flow Diagram

Kanban ekiplerinin iş akışının tutarlı olmasını hedefler. Görsel olarak darboğazları görmemizi sağlar ve WIP Limit ile benzer mantıkla çalışır. Bu akışın soldan sağa doğru olabildiğince düz olmasını bekleriz.

İzlenecek Anti Pattern’ler

• Blocker issue’lar bazen büyük backup’lar oluşturur.
• Zamanla denetlenmeyen backlog artışı olabilir. Burada düşük önceliğe sahip işlerin kapanmaması da bu artışa sebep olabilir.

Daha Fazla Metrik

• Development sırasında kaç defect bulundu?
• Müşterilere release çıkıldıktan sonra (canlıdan dönen hata) kaç defect bulundu?
• Ekip dışındaki kişiler kaç defect buldu?
• Bir sonraki release için kaç tane defect ertelendi?
• Kaç tane customer support talebi geldi?
• Otomatik test kapsamının yüzdesi nedir?
• Agile ekipler için release sıklığına ve delivery hızına da bakılabilir.
• Production’dan gelen emergency’ler ne sıklıkta fix’lenebiliyor.

Sonuç olarak;

KPI’lar takım kültürü oluşturmak için gerekli parametrelerden sadece bir tanesidir. Takım içi belirleyici hedefler koymak genellikle doğru olsa da, KPI’larda obsesif olmaya gerek yoktur. Takımı her retrospektif toplantısında dinlemek ve sebeplerini çözmek, takım içi güveni sağlamak, ürün kalitesini önemsemek KPI’lardan daha mühimdir. Ekip “dağılırsa” ne kalite, ne ürün kalır.

İnsanı ölçerken belirlediğimiz KPI’lar yeterli olmayabilir. Bunu da artık yetenekli liderlere bırakmak gerekir diye düşünüyorum.

Proje Yönetiminde Kazanılmış Değer Yönetimi uygulamak isterseniz şu yazıya da göz atabilirsiniz.

Proje Yönetiminde Kazanılmış Değer Yönetimi (EVM)

Başka bir yazıda görüşmek üzere, hoşça kalınız.

Kaynaklar

1. Agile KPI’lar başlığı ve grafiklerin illüstrasyonları için https://www.atlassian.com/agile/project-management/metrics
2. PMBOK → pmi.org