Kariyerime iş analisti olarak başladım. Aradan geçen yıllarda unvanım değişti, işin bir kısmı değişti, ama analiz masası hiç boşalmadı. Bugün hem sistemi çözümleyen hem de neyin önce yapılacağına karar veren tarafta duruyorum.
Sektörde bunun adı genelde konulmuyor. İlanda “Product Owner” yazar, işin yarısı iş analizidir. Ya da tersi olur, unvan “iş analisti” kalır ama backlog’un sıralamasını da siz yaparsınız. Bu yapı istisna değil, oldukça yaygın.
Yıllarca ikisini birlikte taşıdıktan sonra öğrendiğim şey şu: asıl mesele iş yükü değil, hangi kararın kime ait olduğu.
Scrum Guide’ın değiştirdiği şey
Scrum Guide, Product Owner’ı ürünün yarattığı değeri en üst düzeye çıkarmaktan sorumlu tek kişi olarak tanımlıyor. Product Backlog’un içeriği, sıralaması ve şeffaflığı da bu sorumluluğun kapsamında. Kritik nokta devir konusunda. Bu işlerin yapılmasını başkasına devredebilirsiniz, sorumluluk yerinde kalır.
PSPO II’ye çalışırken bu tanımın ne kadar keskin olduğunu gördüm. Sınav, Product Owner’ı gereksinim yazan kişi olarak gören her cevabı eliyor. Sorular ısrarla değeri kimin ölçtüğünü, kararı kimin verdiğini, hayır deme yetkisinin nerede durduğunu soruyor.
İki rolü aynı kişide yürütmenin asıl meselesi de burada netleşiyor. Aynı anda iki farklı sorumluluk taşıyorsunuz ve hangi anda hangisini taşıdığınızı karıştırmamanız gerekiyor.
Neden bu kadar yaygın
Suçlu aramaya gerek yok. Yapı çoğunlukla mecburiyetten doğuyor.
Ürün küçüktür, iki ayrı role bütçe ayrılmaz. Domain derindir, işi öğrenmek uzun sürer, yeni birinin devralması aylar alır. Ya da kurum Agile’a geçerken mevcut iş analistlerine Product Owner unvanı verir ve iş tanımını sonradan yazmayı planlar. Sonradan pek yazılmaz.
Bir de şu var: iş analizi geçmişi olan biri bu role gerçekten uygun. Sistemi bilir, paydaşı tanır, hangi isteğin altından ne çıkacağını sezer. Kararı hızlı verir çünkü zemini zaten kendi hazırlamıştır.
Nerede işe yarıyor
En büyük kazanç, aradaki çeviri kaybının ortadan kalkması.
İki ayrı kişi olduğunda analiz bir dokümana yazılır, Product Owner o dokümanı okur, okuduğunu yorumlar, sonra karar verir. Her devirde bir şey buharlaşır. Aynı kişide toplandığında bu zincir kısalıyor. Ekipten gelen bir soruya aynı oturumda cevap verebiliyorsunuz, çünkü hem sorunun teknik karşılığını hem de iş tarafındaki önceliğini biliyorsunuz.
İkinci kazanç, kararın gerekçesiyle birlikte durması. Neyi neden sıraladığınızı ayrıca anlatmanız gerekmiyor, analizi yapan zaten sizsiniz.
Nerede tıkanıyor
Kendi analizinizi denetleyemiyorsunuz. İki kişi olduğunda karar veren, analizi sorgulayabilir. Bu iki sorumluluk tek kişide toplandığında o frenleme çoğu zaman yapılamıyor. Kendi çıkardığınız analize kendi kararınızla onay veriyorsunuz ve arada bağımsız bir göz kalmıyor.
Analiz ile önceliklendirme aynı takvimde yarışıyor. Analiz derinleşmek ister, önceliklendirme hızlı olmak ister. Bu yarışta genelde analiz taviz veriyor, çünkü backlog’un aciliyeti çoğu zaman daha yüksek.
Paydaş hangi şapkayla konuştuğunuzu bilmiyor. Aynı toplantıda bir isteği “bunu şöyle çözebiliriz” diye karşılayıp beş dakika sonra “bunu bu çeyrekte yapmıyoruz” demek zorunda kalabiliyorsunuz. Bu, karşı taraf için tutarsızlık gibi görünüyor.
Pratikte nasıl yürüyor
Analizle karar arasına zaman koyuyorum. Aynı oturumda hem çözümleyip hem karar vermeye çalışmak kötü sonuç veriyor, o yüzden mümkün olduğunda kararı ertesi güne bırakıyorum.
Verdiğim kararı gerekçesiyle yazıyorum. Bir isterde herhangi bir değişiklik yapıyorsam bunu mutlaka Jira’da ilgili işin altına yorum olarak bırakıyorum. Bu hem ekibi anlık olarak bilgilendiriyor, hem de aylar sonra dönüp bakıldığında kararın neden verildiğini ve nasıl uygulandığını gösteriyor. Regülasyonlu tarafta çalışıyorsanız izlenebilirlik gereksinimi bunu zaten bir tercih olmaktan çıkarıyor.
Spesifikasyonu olabildiğince net tutuyorum. Muğlak yazılmış bir gereksinimin bedelini her koşulda birileri ödüyor. Kısa, tek anlama gelen, kabul kriteri olan maddeler; ekibin bana en az soru sorduğu ve en doğru işi çıkardığı format bu.
Toplantıda hangi sıfatla konuştuğumu söylüyorum. “Şu an analiz tarafından bakıyorum” ya da “bu bir öncelik kararı” demek basit görünüyor ama paydaşın kafasındaki tutarsızlık hissini büyük ölçüde ortadan kaldırıyor.
İki rolün sorumluluk tanımlarını ayrıntılı karşılaştırdığım yazı burada: Product Owner ve İş Analisti Farkı: 2026’da Rol Nereye Gidiyor?
Aynı durumdaysanız
Unvanınıza değil, iki soruya bakın. Backlog sıralamasına son kararı gerçekten siz mi veriyorsunuz? En son verdiğiniz “bunu yapmıyoruz” kararı ayakta kaldı mı?
İkisine de evet diyorsanız iki rolü birlikte taşıyorsunuz ve bu, doğru koşullarda güçlü bir pozisyon. Cevaplardan biri hayırsa, size verilen şey sorumluluk değil, sadece iş. O zaman da tartışılması gereken konu iş yükü değil, yetkinin nerede durduğu oluyor.
Kaynak: Scrum Guide (2020)