30 saniyelik özet

Product Owner, kısaca PO, Scrum çerçevesinde ürünün yarattığı değeri artırmaktan hesap veren kişidir. Scrum, karmaşık problemleri kısa çalışma dönemlerinde ele alıp sonuçlardan öğrenmeye dayanan bir çalışma çerçevesidir. PO’nun günlük işinde müşteri ihtiyaçları, şirket hedefleri ve geliştirme kapasitesi karşı karşıya gelir. Asıl beceri, bu talepleri anlaşılır kararlara dönüştürmektir. Hangi problemi önce ele alıyoruz, neden şimdi ve başarılı olduğumuzu nasıl anlayacağız? Bu sorular cevaplanmadığında düzenli bir iş listesi bile ekibi yanlış sonuca götürebilir. Rolün etkisini değerlendirirken tamamlanan maddeler kadar karar gerekçelerine ve ortaya çıkan kullanıcı davranışına da bakılmalıdır.

Neden önemli?

Bir satış temsilcisi büyük müşterinin istediği özelliği öne almak istiyor. Destek ekibi mevcut kullanıcıların zorlandığı işlemi düzeltmek istiyor. Yönetim ise yeni pazara açılmayı bekliyor. Her talebin kendi bağlamında makul olması, hepsinin aynı anda yapılabileceği anlamına gelmez.

Bu durumda PO’nun önünde bir kaynak tahsisi sorunu vardır. Bir işe ayrılan kapasite, başka bir ihtiyacın beklemesine yol açar. Dolayısıyla öncelik kararı, ertelenen işin bedeliyle birlikte değerlendirilmelidir. Örneğin yeni satış getirecek özellik, mevcut müşterilerin temel işlemlerini yapamamasından doğan kaybı telafi ediyor mu? Kararı etkileyen bilgi eksikse önce hangi belirsizliğin azaltılması gerekiyor?

Yönetici açısından bu rolün değeri, yatırımın hangi sonuç için yapıldığını görünür kılmasıdır. “Ekip çok yoğun” açıklaması kapasite sorununu gösterir; ürünün doğru probleme çalıştığını göstermez. İyi bir değerlendirme, yapılan işi müşteri ihtiyacıyla ve beklenen iş etkisiyle ilişkilendirir.

Burada yetki de belirleyicidir. Bir kişi önceliklerden sorumlu tutuluyor, fakat her sıralama kararı başka bir yönetici tarafından gerekçesiz değiştiriliyorsa sorumluluk ile karar gücü ayrışır. Böyle bir ortamda rol tanımını değiştirmek tek başına yeterli olmaz. Hangi kararın kim tarafından alınacağı ve anlaşmazlığın nasıl çözüleceği açıklığa kavuşturulmalıdır.

Terim nedir?

Scrum Guide’a göre Product Owner, Scrum Team’in çalışmasından doğan ürün değerini en üst düzeye çıkarmaktan hesap verir. Product Backlog’un etkili yönetimi de bu sorumluluğa dahildir. Product Backlog, ürünü geliştirmek için ihtiyaç duyulan işlerin sıralı ve gelişen listesidir.

Bu yönetim; Product Goal’ün, yani ürün hedefinin geliştirilmesini ve açıkça paylaşılmasını, iş maddelerinin anlaşılır biçimde ifade edilmesini, sıralanmasını ve listenin görünür olmasını kapsar. PO bu işleri başkalarına yaptırabilir; hesap verebilirlik kendisinde kalır. Rol tek kişiye aittir. Çok sayıda paydaşın ihtiyacını temsil etmek, öncelikleri bir komitenin belirsiz ortak sorumluluğuna bırakmak anlamına gelmez.

PO’nun ürün kararlarındaki sorumluluğu, geliştiricilerin çalışma planını tek başına belirlemesi anlamına da gelmez. Scrum’da geliştiriciler, ilgili dönemde hangi işleri yapabileceklerini görüşerek seçer ve bunları nasıl gerçekleştireceklerini planlar.

Rol tanımı kaynağı: Ken Schwaber ve Jeff Sutherland, The Scrum Guide, Kasım 2020; Product Owner ve Sprint Planning bölümleri.

Pratikte şirketler aynı unvana farklı görevler yükleyebilir. Bu yüzden bir pozisyonu değerlendirirken unvanın yanında müşteriyle temas imkânına, öncelik kararlarının sınırına ve başarı ölçütlerine bakmak gerekir. İş analizi deneyimi ihtiyaçları açıklamayı kolaylaştırır; ürün sahipliği ayrıca alternatifler arasında seçim yapmayı ve bu seçimin sonuçlarını izlemeyi gerektirir.

Gerçek vaka: ING Netherlands’ta özerklik ve ortak yön

McKinsey’nin 10 Ocak 2017 tarihinde yayımladığı röportajda ING Netherlands yöneticileri Peter Jacobs ve Bart Schlatmann, bankanın 2015’te başlattığı çevik dönüşümü anlatıyor. Pazarlama, ürün, ticari uzmanlık, kullanıcı deneyimi, veri analizi ve teknoloji yetkinlikleri müşteri ihtiyaçlarına odaklanan küçük, farklı uzmanlıklardan oluşan ekiplerde bir araya getirilmiş.

Jacobs, Product Owner’lara son kullanıcılardan geri bildirim toplamak ve her yeni sürümle ürünü geliştirmek konusunda geniş özerklik verildiğini belirtiyor. Bununla birlikte ekipler arasında düzenli uyum sağlanmazsa farklı yönlere gidilebileceğini de söylüyor. Schlatmann ise ekiplerin amaçlarını ve müşteriye etkilerini nasıl ölçeceklerini belirlediğini; çeyreklik iş değerlendirmelerinde sonuçları, öğrenilenleri ve gelecek hedeflerini paylaştığını anlatıyor.

Yöneticiler pazara çıkış, müşteri memnuniyeti ve çalışan bağlılığında ilerleme bildirmiş. Bu anlatım, şirket yöneticilerinin dönemsel değerlendirmesidir; yalnızca PO rolünün etkisini diğer dönüşüm unsurlarından ayıran bir kanıt değildir.

Bu vakadan çıkarılabilecek yönetim dersi şudur: Karar özerkliği, ortak hedefler ve sonuç değerlendirmesiyle desteklenmelidir. Ekiplerin geri bildirimle yön değiştirebilmesi değerlidir; ancak bu değişimlerin şirketin genel öncelikleriyle ilişkisi de konuşulmalıdır. ING örneği, başka şirketler için hazır bir organizasyon şeması olarak alınmamalıdır.

Kaynak: McKinsey, ING’s agile transformation, 10 Ocak 2017; Peter Jacobs ve Bart Schlatmann röportajı.

Varsayımsal örnek: Sipariş yönetimi ürününde öncelik kararı

Kurumsal müşterilere sipariş yönetimi yazılımı sunan bir ekip düşünelim. Satış ekibi yeni bir muhasebe sistemi bağlantısı istiyor. Destek ekibi ise yeni müşterilerin ilk siparişlerini oluştururken veri aktarımında zorlandığını bildiriyor. PO, iki talebi de hemen teslimat sözüne dönüştürmeden dayandıkları ihtiyaçları inceliyor.

Önce bağlantı eksikliği nedeniyle hangi satışların ilerlemediğini araştırıyor. Ardından destek kayıtlarını, kurulum görüşmelerini ve kullanıcıların işlemi nerede bıraktığını değerlendiriyor. Aynı belirti farklı nedenlerden kaynaklanabilir: Veri dosyası anlaşılmıyor olabilir, alan eşlemesi zor olabilir veya kullanıcı gerekli yetkiye sahip olmayabilir.

Geliştiriciler ve tasarımcılarla yapılan incelemede, veri aktarımı sırasında hataların anlaşılır gösterilmesinin mevcut müşterilerin başlamasını kolaylaştırabileceği düşünülüyor. PO, önce bu sorunu ele alma kararını veriyor. Gerekçeyi satış ekibiyle paylaşıyor; bağlantı talebinin yeniden değerlendirilmesi için hangi müşteri kanıtının gerektiğini kaydediyor.

Başarı, yalnızca yeni hata ekranının yayımlanmasıyla değerlendirilmez. İlk siparişe ulaşma süresi, işlemi tamamlayamayan kullanıcıların davranışları ve destek ihtiyacı izlenir. Başlangıç verisi görülmeden sayısal hedef uydurulmaz. Beklenen değişim oluşmazsa ekip sorunun nedenini yeniden araştırır.

Yaygın üç hata

  1. Talep yoğunluğunu değer kanıtı saymak

Bir isteğin sık tekrarlanması araştırmaya değer olduğunu gösterir; önceliğini tek başına belirlemez. Talebin hangi kullanıcı grubunu etkilediğini, hangi görevi engellediğini ve beklemesinin bedelini inceleyin. Aynı müşterinin farklı kanallardan yaptığı tekrarları bağımsız ihtiyaçlar gibi değerlendirmeyin.

  1. Karar vermeyi tek başına çalışmak sanmak

PO’nun karar sorumluluğu, teknik değerlendirmeyi veya müşteri bilgisini tek başına üretmesini gerektirmez. Seçenekleri ilgili uzmanlarla geliştirin. Katılımı artırırken son kararın gerekçesini görünür tutun. Herkesin görüş bildirmesiyle herkesin aynı şeyi istemesi arasında fark vardır.

  1. Teslim edilen özelliği başarı kabul etmek

Bir özelliğin tamamlanması, hedeflenen faydanın oluştuğunu kanıtlamaz. Kullanıcının hangi davranışının değişmesini beklediğinizi önceden yazın. Sonucu inceleyecek kişiyi ve değerlendirme zamanını belirleyin. Kullanım düşükse bunu yalnızca tanıtım eksikliğine bağlamadan ihtiyacı ve çözümü yeniden değerlendirin.

Mini uygulama / şablon

Sıradaki önemli ürün kararını seçin. Toplantıya özellik listesiyle başlamadan aşağıdaki alanları doldurun.

Karar verilecek konu
—
Etkilenen müşteri veya kullanıcı grubu
—
Gözlenen problem ve kanıtı
—
Desteklediği ürün hedefi
—
Değerlendirilen seçenekler
—
Seçilen seçenek ve gerekçesi
—
Ertelenen seçenek ve beklemesinin bedeli
—
Teknik bağımlılıklar ve kapasite değerlendirmesi
—
Beklenen kullanıcı davranışı
—
Başlangıç verisi ve başarı ölçütü
—
Karar yetkisi ve görüşüne başvurulan kişiler
—
Sonucun değerlendirileceği zaman
—
Kararı yeniden açacak kanıt
—

Bu şablonu bir karar kaydı olarak kullanın; her küçük iş için uzun belge üretmeyin. Amaç, ekip ve paydaşların aynı gerekçeyi anlayabilmesidir. Değerlendirme zamanı geldiğinde önce ne öğrenildiğini konuşun. Sonuç beklentiyi karşılamadıysa devam etme, çözümü değiştirme veya işi durdurma seçeneklerini yeniden ele alın.

İlgili terimler

Product Goal, Product Backlog, Stakeholder, Outcome ve Output, Product Management, Product Discovery, Acceptance Criteria, Sprint Goal, Backlog Refinement, Product Roadmap, Prioritization ve RICE