30 saniyelik özet
Stakeholder, Türkçe karşılığıyla paydaş, bir ihtiyaç, değişim veya çözümle ilişkisi bulunan kişi ya da gruptur. Ürün geliştirmede bu ilişki; ürünü kullanmak, satın almak, işletmek, desteklemek veya ürün kararlarından etkilenmek şeklinde ortaya çıkabilir. Paydaşları tanımak, talepleri doğru kişiden duymayı ve bir kararın başka yerde oluşturacağı etkiyi görmeyi sağlar. Product Owner, yani ürün sahibi, bu bilgileri ürün kararlarında değerlendirir. Her paydaşın isteğini yerine getirmek mümkün olmayabilir; ancak ihtiyacının nasıl değerlendirildiği açıklanabilir. İyi bir paydaş çalışması isim listesiyle sınırlı kalmaz. Beklentiyi, katkıyı, karar yetkisini ve geri bildirimin ne zaman alınacağını görünür kılar.
Neden önemli?
Bir özellik kullanıcı için yararlı görünebilir, satış ekibi tarafından desteklenebilir ve geliştirme açısından yapılabilir bulunabilir. Buna rağmen kullanıma açıldığında operasyon ekibi yeni süreci işletemeyebilir. Destek ekibi hangi hataya nasıl müdahale edeceğini bilmiyorsa müşterinin deneyimi tasarlanan akıştan farklı olur.
Bu tür sorunlar bazen ihtiyaç yanlış anlaşıldığı için, bazen de doğru ihtiyaç eksik kişilerle konuşulduğu için ortaya çıkar. Bir yöneticinin süreci anlatması, o süreci her gün uygulayan kişinin yaşadığı güçlükleri tam olarak göstermeyebilir. Satın alma kararını veren kişiyle ürünü kullanan kişinin beklentileri de farklı olabilir.
Paydaşları erken tanımak, bu farkları geliştirme başlamadan incelemeyi kolaylaştırır. Hangi ekip uygulama sonrasında ek iş üstlenecek? Kim gerekli verinin sahibi? Hangi uzman, çözümün uygulanabilirliği konusunda kritik bilgiye sahip? Bu soruların cevabı, yalnızca toplantı davetlilerini değil, ürün kararının dayandığı kanıtı da değiştirir.
Yönetici açısından paydaş çalışması bir koordinasyon yatırımıdır. Herkesi bütün görüşmelere çağırmak zaman tüketir; ilgili kişiyi karar kesinleştikten sonra çağırmak ise yeniden çalışma doğurabilir. Katılımın değeri, kişinin doğru aşamada doğru soruya katkı verebilmesidir. Bunun için ürün sahibinin hangi kararın açık olduğunu ve hangi bilginin eksik kaldığını anlatması gerekir.
Terim nedir?
International Institute of Business Analysis, kısaca IIBA, BABOK sözlüğünde paydaşı değişim, ihtiyaç veya çözümle ilişkisi bulunan kişi ya da grup olarak tanımlar. Bu tanım, paydaş olmayı belirli bir unvana veya toplantıya katılma şartına bağlamaz.
Tanım kaynağı: IIBA, BABOK Guide Appendix A: Glossary, stakeholder maddesi.
Ürün bağlamında müşteriler, kullanıcılar, satış, destek, finans, operasyon ve teknik hizmet sağlayıcılar paydaş olabilir. Liste ürünün sınırına göre değişir. Şirket dışındaki bir iş ortağı ürünün çalışması için veri sağlıyorsa ilişkisinin ayrıca değerlendirilmesi gerekir.
Paydaşın ihtiyacı, dile getirdiği çözüm talebinden farklı olabilir. “Bana özel rapor yapın” isteğinin arkasında müşteriyle görüşmeye hazırlanmak, iş yükünü izlemek veya bir tutarsızlığı araştırmak bulunabilir. İhtiyaç anlaşılmadan talebi geliştirme maddesine dönüştürmek, gereğinden pahalı veya dar bir çözüm seçilmesine yol açabilir.
Paydaş olmak karar yetkisine sahip olmakla da aynı şey değildir. Bir kullanıcı güçlü saha bilgisi sağlayabilir, fakat yatırım bütçesini belirlemeyebilir. Bir yönetici bütçeyi kontrol edebilir, fakat kullanım sorunlarını doğrudan gözlemlemeyebilir. Bu farkları kaydetmek, görüşlerden hangisinin hangi karar için gerekli olduğunu açıklığa kavuşturur.
Pratik bir incelemede kişinin ürünle ilişkisini, beklediği faydayı, etkilenme biçimini ve katkısını ayrı alanlarda değerlendirmek yararlıdır. Sadece organizasyon şemasına bakmak bu bilgileri vermez. Aynı bölümde çalışan kişiler bile farklı kullanım koşullarını temsil edebilir.
Gerçek vaka: Shell’de ortak anlayış kurmak
Scrum.org’un 14 Aralık 2023 tarihli podcast bölümünde Olga Rownanyk ve John Coleman, Shell’deki ürün sahipliği deneyimini anlatıyor. Rownanyk, farklı iş kolları ve sistemlere dağılmış müşteri bilgilerinin bütüncül biçimde ele alınmasının güçlüğünü açıklıyor. İhtiyaç, kurumsal müşterilerle çalışan ekiplerin daha kapsamlı müşteri bilgisine erişebilmesiyle ilişkili.
Rownanyk, ürün sahibi olarak ekip üyeleriyle bireysel ve grup görüşmelerine zaman ayırdığını, sorular sorduğunu ve aynı konulardan aynı anlamı çıkardıklarından emin olmaya çalıştığını söylüyor. Coleman ise büyük kurumlarda beklentilerin yanında bilgi güvenliği, veri koruma ve finans gibi konuların da geliştirme boyunca ele alınması gerektiğini vurguluyor.
Bölümün son kısmında Rownanyk, bilgiyi neden istediğini açıklamanın, insanların ne bekleyebileceğini belirtmenin ve alınan kararların gerekçesini paylaşmanın önemini anlatıyor. Yeni bilgi ortaya çıktığında kararları gözden geçirmek de bu yaklaşımın parçası.
Bu anlatım, katılımcıların deneyim aktarımıdır; paydaş katılımının etkisini tek başına ölçen bir araştırma değildir. Vakadan çıkarılabilecek ders, ortak anlayışın kendiliğinden oluşmadığıdır. Paydaşlarla ilişki, ilk talep toplantısından sonra da açıklama ve geri bildirim gerektirir.
Varsayımsal örnek: İade yönetiminde görünmeyen iş yükü
Bir e-ticaret ürününde müşterinin iade talebini kendi hesabından başlatması planlanıyor. İlk görüşmeye satış yöneticisi ve müşteri hizmetleri temsilcisi katılıyor. Beklenti, müşterilerin telefonla başvurmak zorunda kalmaması.
Product Owner, talebin başlatılmasından sonuçlanmasına kadar süreci izlediğinde depo, finans ve kargo iş ortağının da değişimden etkileneceğini görüyor. Depo ürünü teslim aldığını bildirecek, finans geri ödeme için gerekli bilgiyi kullanacak, müşteri hizmetleri ise talebin hangi aşamada olduğunu açıklayacak.
Bu kişilere aynı soruları sormak yerine ürünle ilişkilerine göre ilerliyor. Depodan teslim alınan ürünün hangi koşullarda eşleştirilemediğini öğreniyor. Finanstan geri ödeme işlemini başlatmak için gereken bilgileri istiyor. Müşteri görüşmelerinde ise talep açma kolaylığının yanında sürecin durumunu bilmenin de önemli olduğu anlaşılıyor.
Başlangıçtaki “iade formu” talebi böylece daha geniş bir ihtiyaç içinde değerlendiriliyor. Ekip, formun ardından ilgili kişilerin kullanabileceği durum bilgisini nasıl sağlayacağını araştırıyor. Depo ekibine yeni veri giriş sorumluluğu verilmeden önce mevcut çalışma koşulları inceleniyor.
Çözüm taslağı ilgili kişilerle gözden geçiriliyor; uygulama sonrasında belirsiz durumların ve destek ihtiyacının nasıl izleneceği kararlaştırılıyor. Paydaşların görüşleri karar gerekçesine dönüşüyor. Öncelik, herkesin istediği ekranı yapmak yerine müşterinin ve süreci işleten ekiplerin ihtiyaçlarını birlikte karşılayabilecek seçenekleri değerlendirmek oluyor.
Yaygın üç hata
- En görünür kişiyi bütün kullanıcıların temsilcisi saymak
Yönetici görüşünü saha gözlemiyle destekleyin. Farklı görevleri, deneyim düzeylerini ve kullanım koşullarını inceleyin. Tek bir kişinin anlatısını bütün grubun ihtiyacı olarak kabul etmeden hangi durumları temsil ettiğini açıklayın.
- Paydaşları yalnızca onay için çağırmak
Karar kesinleştikten sonra yapılan görüşmede alternatiflere yer kalmayabilir. Hangi konunun değiştirilebilir olduğunu ve hangi soruya cevap arandığını önceden belirtin. Geri bildirimi topladıktan sonra nasıl değerlendirildiğini paylaşın.
- İtirazı kişisel direnç olarak yorumlamak
Bir itiraz ek iş yükünü, hizmet kesintisini veya eksik bilgiyi gösteriyor olabilir. Önce itirazın dayandığı koşulu araştırın. Çatışan ihtiyaçları ve seçeneklerin etkilerini yazın. Uzlaşma sağlanamıyorsa karar yetkisini kullanacak kişiye somut seçenekler sunun.
Mini uygulama / şablon
Yaklaşan bir ürün değişikliğini seçin. Her önemli paydaş için aşağıdaki alanları doldurun.
- Kişi veya grup
- —
- Ürünle ve değişimle ilişkisi
- —
- Beklediği fayda
- —
- Etkilenen görevi veya süreci
- —
- Dile getirdiği talep
- —
- Talebin arkasındaki ihtiyaç ve kanıt
- —
- Sağlayabileceği bilgi veya katkı
- —
- Karar yetkisi
- —
- Görüşünün alınacağı aşama
- —
- Açık anlaşmazlık veya bağımlılık
- —
- Kararın paylaşılma biçimi
- —
- Sonraki geri bildirim zamanı
- —
Listeyi oluşturduktan sonra eksik ilişkileri arayın. Değişimin yükünü kim taşıyor? Üründen etkilendiği hâlde görüşü alınmayan biri var mı? Kararı uygulayacak kişi sonuçtan haberdar mı? Bu sorular, paydaş listesini ürün geliştirme sırasında kullanılabilecek bir çalışma aracına dönüştürür.
İlgili terimler
Product Owner, Stakeholder Analysis, Stakeholder Management ve Alignment, Customer ve User Ayrımı, Requirements Elicitation, Voice of Customer, Product Goal, Product Backlog, Customer Interview, Change Request ve Impact Analysis