#ef7e12

Çevik Çalışma Modelimiz HEY!’de İşleri Nasıl Önceliklendiriyoruz?

Tankut Hasbaş - Allianz Türkiye // Çevik Koç

Önceliklendirme, hayatın her anında yanı başımızda duran, kendini bize sürekli hatırlatan, çok da bayılmadığımız bir karar süreci.

İster devlet bütçesini dağıtın, ister proje portföyünü oluşturun ya da hafta sonu yapılacaklar listesini hazırlayın, önceliklendirmenin tek bir doğrusu yok. Bu yüzden yaptığınız listeyle herkesi memnun etmek pek mümkün değil. Unutmayın, siz pizza değilsiniz.

Bu noktada yapılması gereken altın formülü bulmak değil, bir metod geliştirmek, sonuçları gözlemlemek ve bir standart yakalayabilmek. Sonuç olarak yapabileceklerimizin de bir sınırı olduğu için önceliklendirmeye ihtiyaç duyuyoruz.

Çeviğim bilirsin

Proje yönetiminde önceliklendirmeden bahsetmeden, takım türlerine de şöyle bir göz atalım:

Çevik takımları, çıktı üretme hızı ve sürekliliğine göre iki farklı şekilde ele alabiliriz.

Birinci tip takımlar sıfırdan bir sistem tasarlar/devreye alır, çıktıları da daha uzun soluklu bir koşu olarak görülebilir. Kapsamlarını ya da amaçlarını yerine getirdiklerinde işi tamamlamış olurlar.

İkinci gruptakiler ise var olan bir uygulamayı ya da işi sürekli daha iyiye götürmeye çalışır ya da kısa süreli eforlarla sık sık üretimde bulunur.

Birinci tip takımları anlamak için “büyüyünce ne olacaksın” sorusunu düşünün. Henüz okula başlamamış bir çocuğun kariyer seyri hakkında kesin hükümler vermek ne kadar hatalıysa, çevik proje yönetim süreci içerisinde de ilk andan itibaren hedef ürüne yönelik nihai tasarımlar da bir o kadar hatalıdır.

İkinci tipteki çevik takımları da şu soruyla örnekleyelim: Hafta sonu ne yapacağım? Hafta sonları genelde iki tip aktiviteye zaman ayırırız. “Yapılması önemli” olan konular yani yapıldığında eşinizin, çocuğunuzun ya da kendinizin mutlu olacağı konular. Diğeri ise sizi orta vadede belli bir amacın gerçekleştirilmesinde destekleyecek konular (dil öğrenmek, dershaneye gitmek, spor yapmak gibi).

İşte size günlük hayattan örneklerle hey! Sprintlerimizdeki öncelikleri belirlerken de tıpkı bu örneklerdeki gibi kimi değişkenlere bakıyoruz: aciliyeti ya da kritikliği bir eksende yer alırken, diğer eksende ise talebin o takımın amacına ne kadar hizmet ettiğini ölçüp biçiyoruz.

onceliklendirmematrisi

Projelerde ne yapacağız?

Buradan sonrası biraz da konunun derinine inmek isteyenler, hey!’de işler nasıl yürüyor diyenler için.

Projeleri gerçekleştirirken, çevik takımları oluştururken iki farklı tip backlog yaratıyoruz: Product ve Sprint. Product Backlog, bir akarsuyun kaynağı gibidir projeye ait tüm geliştirmeler orada yer alır. Sprint Backlog ise hangi işleri hangi aşamada ele alacağımızı planladığımız alandır. Ve ta taam, beklenen an: Önceliklendirme yapacağız.

Product backlog içerisinde önce kullanıcı hikâyelerini gruplandırdığımız, epiklerin proje amacı ya da ana stratejiyle uyumuna bakıyoruz. Kullanacağımız metod MoSCoW analizi olabilir. Yani: Must*, Should, Could ve Won’t Have.  Öncelikli konular elbette “Must”. Bunu belirlerken fokusumuzda bazen müşteri bazen de projenin bir paydaşı oluyor.

Ardından hangi işleri öncelikli olarak önümüzdeki sprintte koşacağız sorusu geliyor. Burada da MVP** yaklaşımıyla değerlendirip, sonuca en çok katkı sağlayacak özelliklere sahip kullanıcı hikâyelerini ilk koşulacaklar arasına alıyoruz.

2x2 bir matris çizelim, bir ekseni aciliyet, diğeri katkı olsun, bu matrisin sürekli yaşatılması ve gelişmelerin buradan takip edilmesiyle beraber dinamik bir önceliklendirme metodumuz hazır oldu bile.

 

Kıssadan hisse: Tek bir doğru yok!

Hayatın hızlandığı, işlerin daha etkili, ekipteki herkesin adan zye yetkili olduğu çalışma modelimiz HEY!in bize kazandırdıklarından biri de önceliklendirme kasımızı sürekli güçlendirmeye çalışmak. Kararların sonuçlarına dair geri dönüşleri dinlemek, tamamlanan taleplerin performanslarını izlemek ya da önceliklendirilmeyen talepler yüzünden kaçan fırsat ya da oluşan risklerden ders almak bize hep tek bir doğrunun olmadığını, öğrenmenin bitmeyen bir yolculuk olduğunu zaten gösteriyor.

 

* Must: Zorunlu, olmazsa olmaz özellikler, Should: Kritik olmayan ama önemli ihtiyaçlar, Could: Arzu edilen özellikler, Won’t Have: Yapılmayacak özellikler.

** Minimum viable product: Asgari çalışır ürün

 

Ufak bir not: Çevik çalışma metodu hakkında deneyimlerini paylaşmak ve merak ettiklerini sormak için buraya tıklayarak bize ulaşabilirsin.

Comments

Resimli CAPTCHA
Resimde görünen karakterleri girin.