30 saniyelik özet
Stakeholder Management, yani paydaş yönetimi, ürün kararlarını etkileyen veya bu kararlardan etkilenen kişilerin ihtiyaçlarını, katkılarını ve beklentilerini yönetme çalışmasıdır. Alignment, yani ortak yön ve anlayış oluşturma, hedefin, önceliklerin ve karar gerekçelerinin anlaşılmasını ifade eder. Herkesin aynı özelliği istemesi gerekmez. Product Owner, yani ürün sahibi, taleplerin arkasındaki problemleri anlamalı, çatışan ihtiyaçları görünür kılmalı ve kararları açıklamalıdır. Paydaşları dinlemek, her talebi kabul etmek anlamına gelmez. Yararlı bir süreç, kimin hangi karara katkı verdiğini, kararın neden alındığını ve hangi yeni bilgiyle yeniden değerlendirileceğini açık tutar.
Neden önemli?
Satış ekibi büyük bir müşterinin istediği özel raporu öne almak istiyor. Destek ekibi kullanıcıların tekrar eden erişim sorununu çözmeye çalışıyor. Mühendislik ekibi ise aynı alandaki teknik bağımlılığı gündeme getiriyor. Her taraf kendi gördüğü etkiyi önemli buluyor; fakat diğer tarafın gerekçesini bilmiyor olabilir.
Ürün sahibi bu talepleri yalnızca sıraya koyarsa çatışma çözülmüş görünür. Oysa özel rapor ertelendiğinde satışın hangi sözle müşteriye döneceği, erişim sorunu sürdüğünde desteğin ne yapacağı ve teknik çalışmanın hangi ihtiyacı mümkün kıldığı belirsiz kalabilir. Öncelik kararı, sonuçlarıyla birlikte paylaşılmalıdır.
Ortak anlayış, bu sonuçları konuşmaya yardımcı olur. Hangi kullanıcı etkileniyor? Talebin kaynağı nedir? Gecikme neye yol açacak? Alternatif bir çözüm var mı? Sorular, kişilerin konumundan bağımsız olarak gerekçeleri karşılaştırmayı sağlar.
Yönetici açısından bu çalışma, kaynak kararlarının tutarlılığını değerlendirme fırsatıdır. Aynı tür kanıt farklı taleplerde farklı muamele görüyorsa nedenini açıklamak gerekir. Bir talebin üst yönetimden gelmesi, kapsamının ve etkisinin anlaşılması ihtiyacını ortadan kaldırmaz. Aynı şekilde kullanıcı geri bildirimi de tek başına stratejik öncelik oluşturmayabilir.
Güven, her görüşmeden olumlu karar çıkmasıyla kurulmaz. İnsanlar katkılarının nasıl kullanıldığını görebildiğinde, ertelenen talebin gerekçesini anlayabildiğinde ve kararın değişme koşullarını bildiğinde süreç daha öngörülebilir hale gelir. Gerekçeyi paylaşmadan yalnızca “Şimdilik yapmıyoruz” demek, aynı talebin farklı kanallardan tekrar gelmesine yol açabilir.
Terim nedir?
Stakeholder, yani paydaş, ürün kararından etkilenen veya kararı etkileyebilen taraftır. Kullanıcılar ve müşteriler kadar satış, destek, operasyon, tasarım, mühendislik ve yöneticiler de ilgili olabilir. Kimlerin dahil edileceği, konuşulan karara göre belirlenmelidir; her kararda aynı kişilerin bulunması gerekmez.
Paydaş yönetiminde ihtiyaç ile önerilen çözümü ayırmak önemlidir. “Özel rapor istiyoruz” çözüm talebidir. “Müşteri mevcut rapordan sözleşmedeki hizmet düzeyini değerlendiremiyor” ise araştırılabilecek problem bağlamıdır. İkinci ifade, farklı kapsam seçeneklerini tartışmaya alan açar.
Alignment, kararın amacı, dayanağı ve sonucu konusunda ortak anlayış oluşturmayı gerektirir. Bir paydaş seçilen çözümü tercih etmese de gerekçesini anlayabilir. İtirazın kayda alınması da değerlidir; özellikle yeni kanıt içeriyorsa karar yeniden ele alınabilir.
Scrum çerçevesinde 2020 Scrum Guide, ürün sahibinin Product Backlog yönetiminden hesap verdiğini belirtir. Product Backlog, ürün için gereken işlerin sıralı listesidir. Ürün sahibi bir komiteden oluşmaz. Değişiklik isteyen taraflar gerekçeleriyle onu etkileyebilir; bu, ürün işlerinin herkesin oyuyla sıralanmasını gerektirmez. Geliştiricilerin uygulama planına ilişkin sorumlulukları da korunur.
Çerçeve kaynağı: Ken Schwaber ve Jeff Sutherland, The Scrum Guide, Kasım 2020, Product Owner ve Sprint Planning bölümleri.
Karar yetkisinin açıklığı, katkıyı sınırlamak için kullanılmamalıdır. Ürün sahibi önemli bilgiyi ilgili uzmanlardan edinmelidir. Kurumdaki sözleşme, bütçe veya güvenlik kararları başka sorumluluklar içerebilir. Hangi kararın kimde olduğunu ayırmak, ürün sahibinin her konuya tek başına karar vereceği varsayımını önler.
Gerçek vaka: Mettle’da ortak görünürlükle öncelikleri konuşmak
Atlassian’ın Mettle müşteri vakası, NatWest bünyesindeki şirketin büyürken iletişim ve iş yönetimi güçlükleri yaşadığını anlatıyor. Mettle, fikirleri toplamak ve önceliklendirmek için Jira Product Discovery’yi Jira ile birlikte kullanmaya başlamış.
Vaka, ürün, mühendislik ve tasarım ekiplerinin ortak bir referans noktası oluşturduğunu belirtiyor. Kıdemli ürün yöneticisi Charlie Duke, kurumun başka alanlarında yapılan işleri gösterebilmenin daha yapıcı tartışmaları desteklediğini ve önceliklendirmeye yardımcı olduğunu söylüyor. Çalışmaların iş hedefleriyle ilişkisini değerlendirmek de bu görünürlükle kolaylaşmış.
Bu, çözüm sağlayıcısının yayımladığı müşteri deneyimi aktarımıdır. Kaynak, ortak görünürlüğün tek başına belirli bir gelir veya teslimat iyileşmesini yarattığını kanıtlayan karşılaştırmalı araştırma sunmuyor. Araç benimsenmesiyle ürün sonucunu aynı şey saymamak gerekir.
Vakadan çıkarılabilecek ders, paydaşlara yalnızca kendi taleplerinin durumunu göstermekten daha geniştir. Diğer çalışmalar ve öncelik bağlamı da görülebildiğinde seçenekler birlikte tartışılabilir. Ancak ortak araç, karar yetkisi ve gerekçeler açık değilse bu anlayışı kendiliğinden oluşturmaz.
Varsayımsal örnek: Özel rapor, erişim sorunu ve teknik bağımlılık
Bir danışmanlık yazılımı, müşterilerin proje ilerlemesini değerlendirmesini kolaylaştırmak istiyor. Satış ekibi belirli bir müşteriye özel rapor öneriyor. Destek ekibi ise mevcut rapora erişemeyen kullanıcıların kayıtlarını getiriyor. Mühendislik ekibi, yetki kurallarının dağınık yapısının yeni rapor çalışmasını zorlaştıracağını açıklıyor.
Ürün sahibi talepleri ayrı başlıklar olarak toplamakla yetinmiyor. Her biri için etkilenen kullanıcıyı, problemi, kanıtı ve gecikmenin sonucunu kaydediyor. Satışın önerisi müşteri görüşmesiyle, destek talebi sorun kayıtlarıyla, teknik bağımlılık ise mevcut uygulamanın incelenmesiyle açıklanıyor.
İlk değerlendirmede erişim sorununun müşterilerin mevcut raporu kullanmasını engellediği görülüyor. Özel rapor için istenen bilginin bir kısmının mevcut verilerle farklı biçimde sunulabileceği anlaşılıyor. Ekip, özel raporun bütün kapsamını başlatmadan önce erişim davranışını düzeltmeyi ve sınırlı rapor seçeneğini değerlendirmeyi öneriyor.
Karar görüşmesinde hangi seçeneğin neden öne alındığı anlatılıyor. Satış ekibi müşteriye aktarabileceği kapsam ve belirsizlik bilgisini alıyor. Destek ekibi geçici yönlendirme yöntemini netleştiriyor. Geliştiriciler gerekli teknik düzenlemenin sınırını ve doğrulamalarını belirliyor.
Özel rapor talebi kaybolmuyor. Talebin hangi koşulda yeniden değerlendirileceği ve eksik müşteri bilgisini kimin sağlayacağı kaydediliyor. Müşteri görüşmesinde farklı bir zorunluluk ortaya çıkarsa öncelik yeniden ele alınabilir. Karar değişikliği olduğunda önceki gerekçe ve yeni bilgi birlikte paylaşılır.
Yaygın üç hata
- Ortak yönü herkesin onayıyla eşitlemek
Her paydaşın aynı tercihi yapması mümkün olmayabilir. Karar yetkisini ve kullanılan ölçütleri açıklayın. İtirazları dinleyin; toplantıyı herkesin memnuniyetini garanti eden bir mekanizma gibi kurmayın.
- Paydaş iletişimini yalnızca durum raporuna indirmek
“Devam ediyor” bilgisi neden bu işin yapıldığını açıklamaz. Hedefi, kanıtı, alternatifleri ve kabul edilen sonuçları paylaşın. Ayrıntı düzeyini kişinin karar veya katkı ihtiyacına göre seçin.
- Ertelenen talepleri gerekçesiz bırakmak
Sessizlik, talebin unutulduğu düşüncesini doğurabilir. Erteleme nedenini ve yeniden değerlendirme koşulunu kaydedin. Güncel olmayan beklentilerle müşteri sözü verilmesini önlemek için değişiklikleri zamanında paylaşın.
Mini uygulama / şablon
Yaklaşan bir öncelik kararı için aşağıdaki alanları doldurun.
- Ürün hedefi ve karar konusu
- —
- Etkilenen paydaşlar
- —
- Her tarafın ihtiyacı ve önerisi
- —
- İhtiyacı destekleyen kanıt
- —
- Çatışan beklentiler
- —
- Alternatif kapsamlar
- —
- Gecikmenin veya seçimin etkisi
- —
- Katkı verecek uzmanlıklar
- —
- Karar yetkisi
- —
- Seçilen seçenek ve gerekçesi
- —
- İtirazlar ve açık sorular
- —
- İletişim sorumlusu
- —
- Yeniden değerlendirme koşulu
- —
Ardından kararı ilgili taraflardan birine kendi cümleleriyle anlattırın. Hedefi ve gerekçeyi aynı biçimde anlıyor mu? Yanlış beklenti varsa kaydı ve iletişimi düzeltin. Aynı talep sürekli yeniden açılıyorsa yalnızca kararın duyurulup duyurulmadığını değil, hangi bilgi veya çıkar çatışmasının hâlâ çözülmediğini de inceleyin.
İlgili terimler
Stakeholder, Product Owner, Product Goal, Product Backlog, Prioritization, Stakeholder Analysis, Decision Log, Product Roadmap, Dependency Management, Outcome ve Output, Customer Interview, Risk Management, Opportunity Cost, Product Manager