30 saniyelik özet

Product Goal, ürünün ulaşması amaçlanan gelecek durumunu ifade eder. Ekibin yaptığı işleri ortak bir yöne bağlar ve ilerlemeyi değerlendirmek için referans oluşturur. “Müşteri portalını yenilemek” yapılacak işi anlatır; “yeni müşterilerin ilk projelerini danışman desteği olmadan başlatabilmesi” ise ulaşılmak istenen durumu açıklar. Bu ayrım, çözümün kullanıcıya fayda sağlamadığı anlaşıldığında başka bir seçeneğe geçmeyi kolaylaştırır. İyi bir ürün hedefi, kim için neyin değişeceğini anlaşılır kılar. Hedefin gerçekleştiğini gösterecek kanıt, çözüm adaylarından ayrı düşünülmelidir. Özellik sayısının artması, ürün hedefinde ilerleme olduğu anlamına gelmez.

Neden önemli?

Bir ekip aynı dönemde raporlama, müşteri kurulumu ve yeni ödeme seçenekleri üzerinde çalışıyor olabilir. Her işin gerekçesi vardır; ancak birlikte hangi ürün sonucunu oluşturdukları belirsiz kalabilir. Toplantılarda işlerin durumu konuşulurken ürünün kullanıcıya sağladığı fayda arka planda kalır.

Ürün hedefi bu belirsizliği azaltır. Öncelik görüşmesinde “Kim istedi?” sorusunun yanında “Bu iş, ulaşmak istediğimiz duruma nasıl katkı sağlıyor?” sorusunu sormayı mümkün kılar. Böylece farklı talepler, aynı değerlendirme zemini üzerinde ele alınabilir.

Yönetim açısından mesele yatırımın yönüdür. Bir dönemin sonunda çok sayıda özellik teslim edilmiş olabilir; fakat müşteri hâlâ temel görevini tamamlayamıyorsa yapılan yatırımın beklenen sonucu oluşmamıştır. Hedef açık olduğunda bu fark daha erken görülebilir. Ekip, geliştirmeye devam etmek yerine problemi yeniden inceleyebilir.

Hedef ayrıca bir vazgeçme ölçütü sağlar. Belirli bir müşteri grubunun ihtiyaç duyacağı düşünülen bir yetenek için çalışırken yeni kanıtlar bu ihtiyacın zayıf olduğunu gösterebilir. Harcanan emeği gerekçe yapıp devam etmek kaynak kaybını büyütür. Hangi durumda hedefin yeniden değerlendirileceğini önceden konuşmak, bu kararı kişisel bir başarısızlık tartışmasından çıkarır.

Terim nedir?

Scrum, karmaşık problemleri kısa çalışma dönemlerinde ele alıp sonuçlardan öğrenmeye dayanan bir çalışma çerçevesidir. Scrum Guide’da Product Goal, ürünün gelecekteki durumunu tanımlar ve Scrum Team’in planlama yapabileceği bir hedef oluşturur. Product Backlog’un, yani ürünün geliştirilmesi için gereken işlerin sıralı listesinin içinde yer alır. Listedeki diğer işler, bu hedefe ulaşmak için gerekenleri zamanla ortaya koyar.

Kılavuz, Product Goal’ü takımın uzun vadeli amacı olarak tanımlar. Takım, bir hedefi gerçekleştirmeden veya terk etmeden sonraki hedefi üstlenmez. Hedefi geliştirmek ve açıkça iletmek Product Owner’ın, yani ürün sahibinin hesap verebilirlik alanındadır.

Scrum Guide her ürün hedefi için sabit bir ay sayısı veya zorunlu bir sayısal yazım biçimi belirlemez. Sprint Goal ise tek bir Sprint’in, yani kısa çalışma döneminin amacıdır. Bu iki hedefin zaman ve kapsam düzeyi farklıdır.

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

Uygulamada ürün vizyonu, hedef ve çözüm arasında ilişki kurmak yararlıdır. Vizyon ürünün yaratmak istediği daha geniş değişimi anlatabilir. Ürün hedefi bu yönde ulaşılacak belirli bir durumu ifade eder. Çözüm ise o durumu oluşturmak için denenebilecek araçtır. Bu ayrım bir planlama yaklaşımıdır; bütün şirketlerin aynı belge yapısını kullanması gerekmez.

Gerçek vaka: Hogan Assessments’ta Scrum ve tasarım odaklı düşünme

Scrum.org’un yayımladığı vaka özetinde, kişilik değerlendirmeleri alanında çalışan Hogan Assessments’ın liderlik gelişimi deneyimi oluşturmak için Professional Scrum yaklaşımını Design Thinking ile birleştirdiği belirtiliyor. Design Thinking, kullanıcı ihtiyacını anlamaya, çözüm seçenekleri geliştirmeye ve bunları denemeye dayanan tasarım odaklı düşünme yaklaşımıdır.

Yayımlanan özet; pazara çıkışta hızlanma, Sprint hedeflerinin karşılanmasında ve ekip moralinde iyileşme bildiriyor. Bunlar vaka yayınında raporlanan sonuçlardır. Tek başına ürün hedefi kullanımının bu değişimleri oluşturduğunu göstermez.

Kaynağın erişilebilen özeti, takımın Product Goal cümlesini veya bu hedefin gerçekleşmesini nasıl ölçtüğünü açıklamıyor. Dolayısıyla şirkete belirli bir ürün hedefi atfetmek doğru olmaz. Bu vaka, Scrum ile kullanıcı ihtiyacını araştıran çalışmaların birlikte yürütülmesine doğrulanabilir bir örnektir.

Ürün hedefi açısından çıkarılabilecek ders bir yorumdur: Keşif ve geliştirme çalışmaları birlikte yürütülürken, hangi kullanıcı durumunun değiştirilmeye çalışıldığı ayrıca açıklanmalıdır. Pazara hızlı çıkmakla kullanıcının beklediği faydayı oluşturmak farklı değerlendirmeler gerektirir.

Kaynak
Scrum.org, Resource Search, Hogan Assessments vaka özeti.
https
//www.scrum.org/resources?type=69
Vaka başlığı
Hogan Assessments Takes a Groundbreaking Product to Market in Record Time Using Professional Scrum and Design Thinking.

Varsayımsal örnek: Danışmanlık ürününde ilk proje kurulumu

Kurumsal müşterilere proje takibi sunan bir yazılım düşünelim. Yeni müşteriler ilk projelerini oluştururken danışmanla görüşmek zorunda kalıyor. Yönetim “kurulum ekranını yenileyelim” diyor. Product Owner, çözümü kesinleştirmeden müşterilerin nerede ve neden yardım istediğini araştırıyor.

Görüşmelerde proje türünün seçimi, kullanıcı yetkileri ve başlangıç verilerinin hazırlanması farklı sorunlar olarak ortaya çıkıyor. Ekip hedefi şu şekilde ifade ediyor: Yeni kurumsal müşterilerin yetkili kullanıcıları, ilk projelerini danışman yönlendirmesi olmadan doğru biçimde başlatabilsin.

“Doğru biçimde” ifadesi ayrıca açıklanıyor: Proje türü uygun seçilecek, gerekli kullanıcılar erişebilecek ve başlangıç verileri eksiksiz olacak. Böylece sadece oluşturma düğmesine basılması başarı sayılmıyor.

Ekip, başlangıç durumunu incelemek için destek kayıtlarını ve kurulum oturumlarını kullanıyor. Yardım almadan tamamlanan kurulumları izlemek istiyor; ancak kayıtların kapsamını doğrulamadan bir başarı oranı veya artış hedefi yazmıyor. Sayısal hedef, başlangıç verisi ve kapasite değerlendirildikten sonra kararlaştırılacak.

Kurulum adımlarını açıklayan yönlendirmeler, örnek proje şablonları ve daha anlaşılır yetki seçenekleri çözüm adayları oluyor. İlk denemede açıklama metinlerinin sorunu çözmediği görülürse hedef korunabilir; başka bir çözüm denenebilir. Araştırma, müşterilerin esasen danışmanlık hizmetini tercih ettiğini gösterirse hedefin iş gerekçesi yeniden değerlendirilir.

Yaygın üç hata

  1. Çözüm adını hedef olarak yazmak

“Yeni panel geliştirmek” ifadesi kullanıcıda hangi değişimin beklendiğini açıklamaz. Panelin hangi görevi kolaylaştıracağını ve bunun nasıl anlaşılacağını yazın. Bir çözümü baştan hedefe dönüştürmek, daha uygun bir seçenek bulunduğunda yön değiştirmeyi zorlaştırır.

  1. Ölçümü sonradan düşünmek

Hedefe ulaşılıp ulaşılmadığını değerlendirmek için gerekli veri teslimattan sonra kurulmaya çalışılırsa başlangıç durumu kaybolabilir. Kullanıcı grubunu, başarı sayılacak davranışı ve veri kaynağını önceden tanımlayın. Gösterge iyileşirken hata, destek yükü veya müşteri şikâyeti artıyor mu, birlikte inceleyin.

  1. Yeni talep geldiğinde hedefi sessizce değiştirmek

Her önemli talebi mevcut hedefin içine eklemek odağı belirsizleştirir. Talebin hedefle ilişkisini ve beklemesinin etkisini değerlendirin. Yeni kanıt mevcut hedefi geçersiz kılıyorsa değişikliği açık bir karar olarak kaydedin. Hedef cümlesini genişleterek çatışmayı gizlemeyin.

Mini uygulama / şablon

Ürün listenizdeki önemli bir girişimi seçin. Aşağıdaki alanları ekip ve ilgili paydaşlarla doldurun.

Hedeflenen gelecek durum
—
Etkilenen müşteri veya kullanıcı grubu
—
Mevcut problem ve gözlenen kanıt
—
Şirketin yönüyle ilişkisi
—
Başlangıç durumu ve veri kaynağı
—
Başarı sayılacak kullanıcı davranışı
—
Başarı ölçütü ve gerekçesi
—
Korunması gereken kalite koşulları
—
Aday çözümler
—
Hedefe katkısı belirsiz işler
—
İlerlemenin değerlendirileceği zaman
—
Hedefi terk etmeyi gerektirecek kanıt
—

Ardından listenizdeki işleri bu hedefe göre gözden geçirin. İlişkisi açıklanamayan işleri otomatik olarak silmeyin; neden gerekli olduklarını araştırın. Bakım, güvenlik ve mevcut hizmetin sürdürülmesi gibi ihtiyaçları görünür tutun. Değerlendirme sırasında tamamlanan işlerin yanında kullanıcıdaki değişimi konuşun. Veri yetersizse başarı ilan etmek yerine hangi kanıtın eksik olduğunu kaydedin.

İlgili terimler

Product Owner, Product Vision, Product Strategy, Product Backlog, Sprint Goal, Outcome ve Output, Business Objective, Product Discovery, KPI ve Metrics, Acceptance Criteria, Product Roadmap, Hypothesis