.png){kind=logo}
Kaos teorisinde fraktal yapılardan bahsedilir. Bu yapılar her seviyede kendini tekrar eder ve bütünü oluşturan tüm parçalar adeta bütünün bir özü ve benzeridir.
Karmaşıklıkla baş etmeye çalıştığımız dünyada, ürün geliştirme (özellikle yazılım dünyasında) kaos’a yakın bir noktada cereyan eder. Her seviyede tahminlenmesi güçtür. Ancak hala mümkündür çünkü kaotik değil karmaşıktır. Koas’a yakın bir noktada duran karmaşık ürün geliştirme süreçlerini yönetebilmek için tıpkı bir fraktal yapı gibi her seviyede önceliklendirme esastır.
Portföy ve Ürün yönetiminde, ürünleri, gereksinimleri, özellikleri belirlemek kadar onları önceliklendirmek de önemlidir. Portföy seviyesinde, ürün seviyesinde, iterasyon seviyesinde, günlük seviyede sürekli önceliklendirmeler yapmak, daha tahminlenebilir, daha yönetilebilir ve daha değerlikli ürünler geliştirmemize yardımcı olur.
Önceliklendirmedeki esas gaye "Toplu ve Paralel İş Yığınını" (Batch Size) küçültmek ve iteratif bir hale getirmektir. Toplu ve paralel yürüyen işler verimsizdir, israftır. Baş edilmesi gereken büyük bir envanter oluşturur. Bunları yönetmek ve tahminlemek zordur. Bu büyük envanter ile onu bir kuyruk yapısı gibi önceliklendirerek baş edebilirsiniz. İşlerinizi önceliklendirmeli ve aynı anda yürüyen işleri sınırlamalısınız (Work-In-Progress Limit). Bunu yaptığınız zaman iteratif yürüyebilir ve etkisi büyük kararları, son sorumluluk noktasına (Last Responsible Moment) kadar erteleyerek etkilerini azaltabilirsiniz. Çünkü son karar noktasında baştakinden daha fazla bilgiye sahip olursunuz ve kararlarınızın menfi tesiri ve riski azalır. Daha tahminlenebilir ve tatmin edici kararlar alabilirsiniz. Iteratif ilerlemenin, motivasyon ve inovasyona da müspet tesirleri vardır.
Adına ne derseniz deyin, ister çevik (agile) ister yalın (lean), bugün geldiğimiz noktada kabul edilen en doğru yaklaşımların temelinde işte bu iteratif mantık yatar. Sürekli iyileştirmeyi de ancak böyle sağlayabilirsiniz. İteratif yürümek için ise önceliklendirmek şarttır.
Önceliklendirme önemli, peki ama bunu nasıl yapalım? Nasıl bir yöntem kullanalım? Bu konunun ustalarından Donald Reinertsen’e kulak verelim. “İşinizi ölçün, çalışanlarınızı değil” diyor Reinertsen. Burada işinizi ölçün derken ne demek istediğini, “Eğer sadece tek bir şeyi ölçüyorsanız bu, Gecikme Maliyeti (Cost of Delay) olsun” diyerek yine kendisi açıklıyor.
Gecikme Maliyeti, zamanın etkisini, elde etmeyi umduğumuz sonuçlara aktarmanın bir yoludur. Önceliklendirme ve tercih yapmamıza yardımcı olur.
Gecikme maliyetini iki türlü ölçmek mümkün. Nicel ve nitel olarak. Nicel olarak gecikme maliyetini ölçmek o kadar kolay değil. Her bir ürün, özellik ya da hikayenin gecikmesinin iktisadi olarak elle tutulur bir maliyetini çıkarıp, önceliklendirmeleri bununla yapmak oldukça zor. Parasal bazda haftalık maliyetleri çıkarıp belirlenen iş sırasına göre işlerimizi yaptığımızda ne kadar gecikme maliyeti olacağını hesaplayabiliyorsanız bu harika. Ancak bu iş oldukça zor ve bu noktada zorlananlar için vekil (proxy) parametreler ve göstergeler yardımımıza yetişiyor ve nitel gecikme maliyeti hesabına giriyoruz. Bu makalede bunu nasıl yapacağımıza odaklanacağız.
İlk olarak gecikme maliyetini nasıl ve ne zaman kullandığımızı görelim. Aşağıdaki tabloda 3 farklı durum ile alakalı yöntem tercihleri var.
Ürün geliştirmede en sık rastlanan durum olan "gecikme maliyeti ve süre/büyüklük" parametrelerinin ikisinin de farklı olduğu durumlarda tercih ettiğimiz usül "Ağırlıklı En Kısa İş Önce” (Weighted Shortest Job First - WSJF) usulüdür. Peki WSJF nasıl hesaplanır?
İşlerimizi önceliklendirmek için WSJF değerini hesaplamamız gerek. Görüldüğü gibi WSJF’i hesaplayabilmek için Gecikme Maliyeti’ni ve İş Süresini hesaplamak gerekiyor. Bunları ayrı ayrı ele alalım. Önce Gecikme Maliyetini hesaplayalım.
Dean Leffingwell, SAFe modelinde iş önceliklendirme ile alakalı bölümde “Gecikme Maliyeti - Cost of Delay” hesabını aşağıdaki 3 parametreye bağlar.
Kullanıcı / İş Değeri : Kullanıcılarımız bunu diğerine tercih eder mi? İş süreçlerimizle ilgili geri dönüş değeri nedir? Herhangi bir gecikme cezası var mı? Kısacası kullanıcının gözünde bu işin potansiyel değeri nedir? (bkz. Business Value Game)
Zaman Değeri : Oluşacak olan kullanıcı değerinin zamana yayılma profili nedir? Yapılmadığında sürüm planı sekteye uğruyor mu? Gecikme halinde işin iptal edilme / vazgeçme durumu oluşabilir mi?
Risk İndirgeme / Fırsat Oluşturma Değeri : Oluşan değer bir riski azaltıyor ya da yeni bir fırsat oluşturuyor mu? Oluşacak bilgi bizim için ne kadar değerli? Gecikmesi halinde ne kadar bir fırsattan ya da faydadan mahrum kalacağız?
Burada kullanacağınız puanlama size kalmış. Mesela her bir parametreyi 1-10 arası bir değere bağlayıp bunları toplayabilirsiniz. Ya da planlama pokerindeki gibi değiştirilmiş fibonacci sayılarını kullanabilirsiniz. Ancak en önemlisi mukayeseli gitmek olmalı. İşleri birbirlerine göre puanlamayı unutmayın. En küçük olana 1 deyin. Her sütunda mutlaka 1 değeri olsun. Diğer işleri bununla mukayase edin ve değerini bulun. Tıpkı planlama pokerinde olduğu gibi.
Buradaki 3 parametrenin üçü de aslında Gecikme Maliyeti’nin farklı açılardan değerleri. Yani biri elma, biri armut, biri portakal değil. Sonuçta bunların toplamı bize Gecikme Maliyetinin büyüklüğünü gösterecek.
İş Süresi / İş Büyüklüğü hesaplarken de yine planlama pokeri kullanabiliriz. Scrum’ı bilen herkes, planlama pokerini duymuştur ve bu usüle aşinadır. Daha zor olan, işin süresini tahminlemeye çalışmak yerine, vekil parametre olarak, işin büyüklüğünü tahminleriz süresini değil. Bu bize, aynı zamanda, kişiye göre değişmeyen bir soyutlama sağlar. İkinci olarak bu sayede farklılıkların gücünden yararlanarak karmaşık bir durumla baş etmeye çalışırız.
*WSJF, bazı kaynaklarda CD3 (Cost of Delay Divided by Duration) şeklinde geçer. Biz burada süre (duration) yerine vekil olarak işin büyüklüğünü (size) kullandık.
WSJF değeri en yüksek olan iş önceliklidir. Bu durumda tabloya göre oluşan öncelik sırası B, A, C şeklindedir. Bu sıralamanın doğruluğunu görsel olarak aşağıdaki gibi gösterebiliriz. Grafikte düşey eksen gecikme maliyeti değerlerini, yatay eksen ise işlerin büyüklük değerlerini göstersin. 4 farklı iş sırası kombinasyonunda oluşan siyah alanlar bize Gecikme Maliyetini gösteriyor. En düşük maliyetin B, A, C sıralaması ile mümkün olduğu ve en yüksek gecikme maliyetinin C, A, B sırasında olduğu açıkça görülüyor.
Bu Gayrete Değer mi?
Peki onlarca ürün ve bu ürünlere ait özellikleri ve hikayeleri sıralarken bunları tek tek nasıl hesaplarım? Bu işleri ne zaman yapmalıyım? Bütün bunlar mantıklı mı? Buna değer mi?
Bence mantıklı ve buna değer. Yukarıdaki grafiğe bakalım. Bu grafik aslında bize çok fazla şey söylüyor. Eğer önceliklendirmeseydim, ya da önceliklendirmeyi yanlış yapsaydım neler olacağını açıkça görebiliyoruz. BAC sıralamasında 64 birim maliyet varken, mesela CAB sıralamasında 251 birim maliyet hesaplıyorum. Bu, yaklaşık olarak %75 maliyet azalması (251 birimde 187 birim azalma) demek. İşleri geliş sırasına göre yapsaydım (ABC), 107 birim maliyeti olacaktı. Burada ise yaklaşık %40’a varan bir maliyet azalması söz konusu.
Sonuç olarak işlerimizi her seviyede önceliklendirmek zorundayız. Portföy seviyesinde, Ürün seviyesinde, Sürüm seviyesinde, İterasyon seviyesinde ve günlük olarak işlerimizi hep önceliklendirmeliyiz. Yoksa yönetemeyiz. En yüksek değeri en çabuk bir şekilde üretemeyiz. Değişen dünya koşullarına karşı koyma direncimizi kendi kendimize kırmış oluruz.
Mesela, ürün iş listemiz öncelikli olmak zorunda. Böylece önceliği yüksek olan işlere odaklanırız. Diğer işler için sonuna kadar bekleyebilir, aldığımız geri bildirimlerle daha fazla bilgi sahibi olabilir ve kararlarımızı buna göre verebiliriz. Kullanıcı Hikayeleri Haritası (bkz. User Story Mapping) uygulaması ile ürün ve/veya özelliklerimizin (Feature / Epic) iki boyutlu haritasını çıkarırken yaptığımız en temel işlem önceliklendirmedir. MVP‘lerimizi belirleriz. Yol haritamızı oluşturur, kilometre taşlarını (milestones) belirleriz. Sürüm planını önceliklendirme çalışması ile hazırlarız. Sprint içinde, sprint hedefine göre önceliklere sahip oluruz. Günlük olarak yaptığımız toplantılarda bu öncelikleri konuşuruz ve ona göre pozisyon alırız.
Önceliklendirme işi bir defalık bir iş değildir. Sürekli yapılmalıdır. Çünkü karmaşık sistemler öncelikleri sürekli değişebilen ve bu değişime adapte olabilen sistemlerdir. Planlar sürekli değişir. Önemli olan sürekli planlama yapmak, yani adapte olmak ve planlama aktivitesi esnasında ortaya çıkan bilgi ve değerden faydalanarak işlerimizi sıraya koymak, iş kuyruğumuzu bu sayede yönetmektir. Scrum bağlamında Ürün İş Listesi İyileştirme/Tasfiye (Backlog Refinement) toplantılarıyla her iterasyonun azami %10’u bu işe ayrılır. Bu da bu işin ne kadar önemli olduğunu göstermektedir. Bu toplantıda işler detaylandırılır, netleştirilir ve önceliklendirilir. Kısacası tasfiye edilir. Böylece sürekli olarak gelişen, önceliklendirilmiş, yeterince detaylandırılmış ve güncel bir ürün iş listemiz olur. Her toplantıda ayrıca işlerin büyüklükleri de işi yapan takım tarafından belirlenir.
Ben yine de bu kadar matematikle uğraşmam diyenler, bu yönteme alternatif olarak, önceliklerimiz konusunda karar verirken hesaba girmek yerine aşağıdaki Gecikme Maliyeti profillerini de kullanabilir ya da kendi profillerini oluşturabilirler. Her şekilde kendinize en uygun ve çalışan bir önceliklendirme usulüne ihtiyacınız olacaktır.
Kaynaklar
- Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, 2009
- Kenneth S. Rubin, Essential Scrum, 2012
- Weighted Shortest Job First, https://www.scaledagileframework.com/wsjf
- Cost of Delay Divided by Duration, http://blackswanfarming.com/cost-of-delay-divided-by-duration/