Skip to main content

Klasik ürün geliştirme metodolojilerinde, kapsam ve ayrıntılı gereksinim tanımı için iş birimleriyle beraber çalışmak iş analistinin rolüdür. Ancak teoride, iş analistlerinin agile projelerdeki rolleri eksik kalabilmektedir. Genellikle iş birimleri arasından seçilen, ‘ürün sahibi’ olarak adlandırılan, ‘product owner’ adıyla bilinen yeni bir rol; iş analistinin yerini almaktadır. Product owner, gereksinimleri ‘user story’ formatında  tanımlamak ve bunları ‘product backlog’ olarak adlandırılan havuzda önceliklendirmekten sorumludur. Product backlog, çözüm kapsamını da temsil etmektedir.

Product owner’ın, gereksinim tanımını doğru ve tam yapabilmesi için iyi düzeyde süreç bilgisine ve deneyimine sahip olması gerekmektedir. Ancak birçok şirkette; iş birimi yöneticileri, kıdemli kişileri kendi departmanlarındaki daha kritik gördükleri işlerde görevlendirerek; daha az kıdemli kişileri, ‘product owner’ olarak atayabilmektedir. Deneyimin yanı sıra, az kıdemli product ownerlar gereksinimlerin belirlenmesinde ve yönetim süreçlerinde eksik kalabilmektedir. Bu durum agile projelerdeki kapsam tanımı ve yönetimini riskli hale getirerek, sprintlerdeki teknik borçların artmasına sebep olabilmektedir.

Bu riski azaltabilmek adına; kıdemli iş analistleri, product owner olarak atanabilir.  Eğer product owner iş birimlerinden seçilecekse; agile ekibi yalnızca yazılım geliştiricilerden ve test mühendislerinden oluşmamalı, iş analistleri de bu ekibe dahil olmalıdır.

Riski azaltmanın bir başka yolu ise, agile projeler başlamadan önce design thinking atölyeleri düzenlemektir. Atölyeler, proje paydaşlarının çözüm kapsamı ve proje hedefleri doğrultusunda aynı yönde ilerlemesine  yardımcı olmaktadır.

  • Agile ekip üyeleri, atölye çalışmasının ilk aşamasında; sonraki aşamalarda projenin ana hedefi olarak ele alınacak problem ya da fırsatın tanımlanmasına katkı sağlarlar.

Atölyenin bir parçası olarak yer alan agile ekip üyeleri, projenin hedef kitlesinin belirlenmesinde de rol alırlar. Bu durum projenin ilerleyen aşamalarında, memnuniyet yaratılacak kitlenin iş birimleri temsilcilerinden ziyade, hedef kitle (müşteri) olması konusunda farkındalık kazandırılmasına yardımcı olur.

  • Agile ekibi, design thinking atölyelerinin araştırma safhasında; müşteriler ile görüşmeler düzenleyip onları dinleyerek (what they say) ve gözlemleyerek (what they do)  ihtiyaçlarını ve sıkıntı yaşadıkları noktaları belirler. Sonrasında bu araştırma sonuçlarını sistematik bir şekilde aksiyon alınabilecek içgörülere dönüştürürler. Elde edilen içgörüler, tasarlanacak çözümün fayda sağlamasının ötesinde müşteriler tarafından cazip hale gelmesine de temel oluşturur.
  • Design thinking atölyeleri sırasında ortaya çıkan fikirlerden kullanıcı öyküleri oluşturmak (user story) oldukça pratik ve tamamlayıcı bir yaklaşımdır. Her fikir, müşteriye katacağı değer ve fikrin uygulanış zorluğunun değerlendirilmesi ile önceliklendirilir. Fikirler önceliklendirme yapılarak; “wows: çok zorlanmadan uygulanılabilecek yüksek değerli fikirler”, “hows: gelecekte kullanılabilecek fikirler”, ve “nows: çabuk kazanımlar” şeklinde sınıflandırılırlar.

Bu sınıflandırma agile ekiplerinin ürün geliştirme ve sprint planlama sürecinde user story’leri önceliklendirmesi için oldukça değerlidir.

  • Design thinking atölyelerinde fikirler prototipleştirilip kavramsal bir çözüme dönüştürülür. Bu kavramsal çözüm; hem fikirleri somutlaştırmak, hem de müşteri geri bildirimlerini almak için kullanılır. Prototipleştirilen kavramsal çözüm bütün agile ekibini aynı noktada buluşturarak, herkesin proje boyunca ‘neden’ ve ‘ne yapacağına’ dair netlik kazanmasına yardımcı olur.

Agile projelerde büyük resim net olmadığından, design thinking ile elde edilen üst düzey atölye çıktıları ve kavramsal prototipler, projenin başlangıcında bilinmeyenlerin netleştirilmesinde ve bu bilinmeyenler nedeniyle teknik borç riskinin azaltılmasında büyük katkı sağlamaktadır.