Agile / Scrum geliştirme metodolojisinin tercih edildiği ortamlarda iş analizi aktiviteleri ve iş analistlerinin görevlerini incelediğimiz yazı dizimize Product Owner rolünü inceleyeceğimiz 3. ve son bölüm ile devam ediyoruz. İş analistinin Development Team üyesi rolünü incelediğimiz Bölüm 1’e şuradan, Scrum Master rolünü incelediğimiz Bölüm 2’ye ise şuradan ulaşabilirsiniz.
İş Analisti: Product Owner Rolünde
Adından da anlaşılacağı üzere, Product Owner (PO), ürünü sahiplenen kişidir. PO, Development Team’in işini ve ürünün değerini en üst seviyeye çıkarmakla sorumludur. PO, ürünün müşterilere ve kullanıcılara olduğu kadar, şirket için de değer yarattığından emin olmalıdır. PO, ürünü başarıya götüren, ürün kararlarını alan kısacası ürünle ilgili son sözü söyleyen kişi olarak düşünülebilir.
İş Analisti’nin Product Owner rolündeki görevi nedir?
İş analisti ve Product Owner’ın projedeki görevleri göz önüne alındığında aslında aynı amaca hizmet ediyorlar gibi görünebilir. Fakat geleneksel proje ekiplerindeki iş analistlerine, Scrum’daki PO kadar yetki verilmediğinin bilinmesi gerekiyor. Yani, bir iş analisti Scrum ekibinde Product Owner görevindeyse, artık daha fazla sorumluluk ve daha fazla yetki aldığını bilmesi gerekir.
PO sadece müşteri ihtiyaç analizine odaklanmaz veya Kullanıcı Hikâyeleri (User Stories) yazma uzmanı değildir. İlgili ürüne değer katabilmesi için market, pazarlama, rekabet, yasal ve finans konularında da yetkin ve söz sahibi olmalıdır.
Projenin boyutu ve kapsamına göre bu kadar yetkin bir PO’ya gerek olmayabilir. Bir iş analistinin, PO olarak görevlendirildiğinde, gün 1 için tüm bu yetkinliğe sahip olması beklenmemelidir. Hem ürün için, hem de iş analistinin PO rolü için aşamalı olgunlaşmak daha gerçekçi bir yöntem olacaktır.
İş Analisti – Proxy Product Owner Rolünde
Agile yöntemler, geliştirici ekip ile birlikte çalışan bir Product Owner olmasını önerir. Scrum Guide’da Product Owner rolü “Geliştirme Takımının işini ve ürünün değerini en üst seviyeye çıkarmakla sorumludur.” olarak tanımlanmıştır. Bu görev tanımına göre PO, ürün değerini arttırmak için müşteri ve gereksinimlerini iyi bilmeli ve belirlemeli, aynı zamanda da Development Team’in ortaya koyduğu işin değerini takip edebilmek için ekip ile birlikte çalışmalıdır.
Scrum Guide, PO görevinin tek bir kişiye ait olması gerektiğinden bahseder. Bir grup veya komite, PO görevini üstlenemez. Hem müşteri tarafındaki isterleri belirleyebilmek, hem de bu isterleri geliştirici ekibin anlayabileceği şekilde iletebilmek, PO rolündeki kişiyi iki yönlü düşünmeye zorluyor. Bu sebeple de tüm bu sorumluluğun tek bir kişiye yüklenmesi ayrı bir tartışma konusu haline gelmiş durumda.
Genellikle Scrum uygulayan şirketlerde/organizasyonlarda PO rolü iş biriminden yetkili bir kişiye veriliyor. İş birimi, geliştirilecek ürün ve yapılacak iş bilgisine en çok hakim olan birimdir. PO görevini ürünün sahibi olarak değerlendirdiğimizde, bu görevin iş biriminden birinde olması en doğru kararmış gibi görünebilir. Fakat ürünü geliştirecek olan ekip ile birlikte çalışabilmek için az da olsa teknik bilgiye sahip olmak gerekiyor. İş birimi ile teknik ekip çalışmaları da çok sağlıklı olmayabiliyor. Tam da bu noktada teknik ekip ile iletişimi daha güçlü aynı zamanda PO’ya destek olabilecek vekil bir role ihtiyaç duyuluyor. Proxy Product Owner rolü de bu ihtiyaç doğrultusunda ortaya çıkmıştır.
Product Owner ve Proxy Product Owner görev paylaşımı nasıl olmalıdır?
Scrum ekibinde, iş biriminden yetkili birinin Product Owner ve iş analistinin Proxy Product Owner olarak görev alması, her iki roldeki kişilerin görevlerini en verimli şekilde yerine getirmesinde ve Scrum’ın doğru uyarlanmasında etkili olacaktır.
Product Owner şu konulara odaklanmalıdır:
– Ürün özellikleri/fonksiyonları ve bunların Product Backlog’da önceliklerinin belirlenmesi,
– Müşteriler ve şirket/organizsyon içindeki paydaşlar ile iletişim,
– Ürün kapsamı ile iligli çalışmalar/görüşmeler,
– Son kullanıcı için değerli olacak olan en yalın ürünü (MVP – Minimum Viable Product) belirleyerek iterative çalışmayı sağlama.
Proxy Product Owner’ın odaklanması gereken konular ise:
– Geliştirici ekip ile iletişim,
– PO’ların ürün özellikleri ve önceliklerini belirttiği Product Backlog için, hikaye (story) düzeyinde User Story’ler oluşturma,
– Geliştirici ekip ile birlikte Product Backlog Refinement aktivitelerinde yer alma,
– Oluşturduğu User Story ve Product Backlog Refinement çıktılarını PO ile paylaşma ve doğrulama.
Tüm bu odak noktalarına ek olarak, Proxy PO için, kilit paydaş ve karar verici kişi PO iken, diğer paydaşlarla etkileşime girmesi gereken kişinin PO olduğu unutulmamalıdır.
İlkim Dilara KADAKALOĞLU
Kıdemli İş Analisti, BA-Works