Ürün Ekiplerinin Yapılanma Biçimleri

Marty Cagan’ın ürün ekiplerinin analizi: Paralı emir kulu musun yoksa katkı sunan misyoner mi?

Photo by Leon on Unsplash

Bu aralar yeniden Marty Cagan’a sardım. Marty Cagan’ı bilmeyenler için Silicon Valley Product Group’un kurucularından olan Marty ürün dünyasında oldukça baba isimlerden birisidir. Ürün dünyasında çokça okunan Inspired and Empowered kitaplarının yazarıdır. Belki de onu tartışmalı ‘ürün yöneticileri ürünün CEO’larıdır’ söyleminden hatırlayabilirsiniz.

Marty teknoloji tabanlı şirketlerdeki ürün ekiplerini ekibin yapılanma ve işleyiş biçimine göre temelde 3'e ayırıyor.

1. Teslimat ekipleri (delivery teams): Yazılımcılar ve backlog yönetiminden sorumlu bir PO’nun (product owner-ürün sahibi) olduğu ekipler. Sonuçlara (outcome) değil çıktıya (output) odaklanırlar.
2. Özellik ekipleri (feature teams): Yazılımcılar, bir ürün yöneticisi ve bir tasarımcıdan oluşan ekipler. Sonuçlara (outcome) değil çıktıya (output) odaklanırlar.
3. Ürün ekipleri (product teams): Yazılımcılar, bir ürün yöneticisi ve bir tasarımcıdan oluşan ekipler. Yetkin, yönetim tarafından kendi başlarına sonuç üretebilmeleri için güçlendirilen, desteklenen ekipler.

Bu arada Türkçe karşılıklarını kendim uydurduğum için terminoloji çok doğru olmayabilir. Eğer daha doğru karşılıkları varsa yorum olarak paylaşırsanız çok sevinirim.

Şimdi konuya derinlemesine gireceğiz ve acaba siz şu anda nasıl bir ekipte çalışıyorsunuz ve nasıl bir ekipte çalışmak istersiniz üzerine düşünebilmek için temel oluşturmaya çalışacağım.

Şimdi söyleyeceklerim, yani daha doğrusu Marty’nin söylediği ve benim de katıldığım düşünceler, özellikle ürün yöneticileri için biraz yaralayıcı olabilir çünkü bir yüzleşme ve üzerine demlenme süreci gerektiriyor. Taşıdığınız o çok havalı ürün yöneticisi unvanı belki de dünyada pek fiyakalı örnekleri verilen ürün yöneticisi unvanından başka bir içerik taşıyordur.

Türkiye’de ve hatta bırakın minicik bu topraklardaki ürün dünyasını dünyada ürün ekiplerinin çoğu teslimat ya da özellik ekipleri olarak çalışıyor.

İster Scrum uygulayan bir startup, ister SAFe (scaled agile framework) benimsemiş bir kurum olun ekipler scrum ekibi, mühendislik ekibi, yazılım ekibi diye anılıyorsa ve ürün yöneticisi unvanını taşıyan kişi temel olarak backlog yönetimi yapıyorsa o zaman dünyada parmakla gösterilen teknoloji şirketlerindeki ürün ekipleri ile aynı işlevde değilsiniz demektir maalesef. Ürün yöneticileri de dünyada o çok paralar kazanan ürün yöneticileri ile aynı kategoride olamıyor bu durumda.

Biraz daha detaya girelim. Gerçek bir ürün ekibindeki rol dağılımı şuna benziyor:

Yazılımcıların görevi çok net. İnşa edilecek şey her ne ise bunu doğru teknoloji ve beceriler ile belli bir zaman çerçevesi içerisinde üretmek. Hatta bu fizibilite riski (feasibility risk) olarak da geçer.

Gelelim tasarımcılara. Bir ürünün kullanılabilir olmasından sorumlular. Kullanıcılar ürünü gerçek anlamıyla nasıl kullanıyor, nasıl etkileşim içine giriyor bunu anlayan, bunun için araştırma yapabilen, kullanıcıların yaşadığı problemlere çözüm geliştirirken kullanımı kolay, keyifli bir deneyim geliştirebilen kişilerdir tasarımcılar. Üründeki kullanılabilirlik riskini (usability risk) üstlenirler.

Türkiye’deki gözlemim teknoloji tabanlı ürün şirketi sayılabilecek bazı şirketlerde tasarımcı rolünün hala olmaması ve işin ajanslara verilmesi. Bilin bakalım o zaman tasarımcının rolünü kısmen de olsa üstlenen kim oluyor ekipte?

Geldik ürün yöneticilerine. Ana görevlerinden birisi insanların satın alacağı ya da kullanmayı tercih edeceği şeyleri bulabilmek yani doğru problemleri, ya da başka bir ifadeyle, fırsatları tespit edebilmek (değer riski, value risk). Ve bunu yaparken de çalıştığı şirket için de değer yaratabilecek fırsatları bulabilmek (işletme riski, business viability risk)

Buradaki temel sıkıntı şu oluyor pek çok şirkette (benim de birebir bu şekilde deneyimim var hatta):

Yukarıda bahsettiğim ana sorumluluğu ürün yöneticilerinin yerine şirketteki bazı yöneticilerin ya da paydaşların üstlenmesi sorunsalı. Ne demek istiyorum? Örneğin satışın başındaki yönetici pazarda çok satacağına inandığı bir özellik istiyor. Bu özellik olduğunda ürünün çok satacağını, şu kadar gelir getireceğini, pazarda şöyle böyle fark yaratacağını yani şirket için faydalı olacağını ve müşterilere de değer getireceğini söylüyor. Ürün yöneticisi de bu isteği alıyor, istenen bu özellik nasıl bir şeymiş, neler gerekli imiş bunları saptayıp tasarımcıdan çözümü istiyor ve yazılım ekibi geliştirmeye başlıyor. Bu senaryo tam bir özellik ekibi (feature team) örneği.

Bu senaryo sanıyorum pek çok ürün yöneticisine tanıdık gelmiştir. Senden istenen özellikler var yani çıktılar (output). Farklı paydaşlar arasında kolaylaştırıcılık yaparak istenen çıktılar arasında önceliklendirme yapma ve proje yöneticiliğine dönüyor iş bu durumda. Yapacağımız dediğimiz özelliği zamanında yapabildik mi mevzu buna dönüyor.

Halbuki ürün yöneticileri (ve benim de örneklerini daha sık görmeyi arzuladığım şey) müşteriyi ve endüstriyi çok iyi bilen, datayı iyi yorumlayabilen, işletmenin diğer iş kollarında (satış, pazarlama, finans, hukuk..) ne olup bittiğinden haberdar olarak onlarla senkronize hareket edebilen ve başarmak istenilen iş sonuçlarına odaklanarak ürün ekibini harekete geçiren kişilerdir.

Şu anda gerçek bir ürün ekibinde ürün yöneticisi olarak mı çalışıyorsunuz yoksa bir teslimat/özellik ekibinde mi çalışıyorsunuz anlayabilmek adına Marty’nin üzerine düşünmek için davet ettiği bazı sorular şöyle:

• Çalıştığın ekip tarihler ve önceliklendirilmiş özelliklerle şekillendirilmiş bir roadmap ile mi çalışıyor yoksa iş sonuçlarına katkı sağlayacak problemleri çözmekle mi mükellef?
• Ürün yöneticisi ve tasarımcı rolleri ekipte birbirine karıştırılıyor mu? İş tanımları iç içe geçmiş durumda mı?
• Gününün büyük çoğunluğunu proje yönetimi ile mi geçiriyorsun? İstenen özellikleri çıkarabilmek mi asıl amacın?

Şöyle basit bir örnek verebiliriz. Diyelim ki yönetim ekibi ürünün aktivasyonunda yani ilk kullanımında sıkıntılar görüyor ve aktivasyon oranı istediği seviyelerde değil. Ürün ekibinin ana uğraşı aktivasyon hedefine katkı sağlamak için yeni kullanıcı onboarding’ini iyileştirmek olabilir. Bu durumda yönetimin beklentisi ürün ekibinin bir problemi çözmesinden ibaret, aktivasyon problemini.

Ürün yöneticisi, tasarımcı ve yazılımcılar kafa kafaya vererek bu problemi çözmek için bir araya geliyorsa, ürün yöneticisi kantitatif ve kalitatif dataları inceleyerek, paydaşlardan görüş toplayarak problemin ne olduğunu derinlenmesine masaya yatırıyor, tasarımcının liderliğinde farklı çözümleri hep beraber tartışıyor, olası çözümleri prototipleyerek test ediyor ve en iyi çalışan çözümü doğru teknoloji ile geliştiriyorlarsa ve bu tüm bunları yaparken özerk bir yapıda iseler yani onlara özgürlük alanı ve ihtiyaç duydukları şeyler için destek sağlanıyorsa Marty’nin bahsettiği gerçek ürün ekipleri (empowered product teams) bu tip bir örneğe tekabül ediyor. Onboarding’i iyileştirmek için denenen çözümlerin sonuca yani aktivasyona katkısını görebildikleri ve sonuç-odaklı çalışan bir ekipten bahsediyoruz.

Bu ideal senaryo tabi. Gerçeklik ise şu seviyelerde olabilir:

• Yönetim, ürün yöneticisine ya da ekibe aktivasyon oranının iyileştirilmesi için yapılacaklar listesi vererek bunları x süre içinde tamamlanmasını isteyebilir. Ekip, tam olarak bir özellik ekibi gibi davranmak zorundadır.
• Yönetim, ürün yöneticisinden aktivasyon oranını iyileştirmesini bekleyebilir yani topu ona atıp gerisine karışmaz. Hesap soracağı tek kişi ürün yöneticisi olur. Ürün yöneticisi ne yapılacağına yani hangi özelliklerin geliştirileceğine kendisi karar vermek zorunda kalır ve roadmap’i buna göre düzenler. Yazılım ve tasarım ekibi aktif olarak problem ve çözüm geliştirme süreçlerine dahil olmak ya da sorumluluk üstlenmek istemez. Bu durum yetkinlik yetersizliğinden kaynaklı da olabilir. Bize sadece ne yapacağımızı söyle biz onu yapalım düşünüş biçiminden bahsediyorum. Başarılı olursa başarı ekibindir, hedeflenen iş sonucu bakımından başarısız olursa ya da zamanında bir şey çıkmazsa (ee biz isteneni yaptık) sorumluluk ürün yöneticisinindir. Ürün yöneticisi hem iş sonucu üretme, hem zamanında bir şeyler teslim etme kaygısını tek başına üstlenir. Bu durum pek bir acımasızdır ve maalesef oldukça da yaygındır. (Burada ürün yöneticisinin ekibi katılımcı olmaya teşvik etmesi, ama en önemlisi yönetim tarafından bunun için desteklenmesi gerekir ki bu biraz ayrı bir konu).
• ??? (bu örnek sizden gelsin)

Pek çok organizasyonel yapılanma içinde dayanışma ruhu taşıyan gerçek ürün ekipleri pek mümkün görünmüyor. İster yazılımcı olun, ister tasarımcı, ister ürün yöneticisi, fark etmez. Ekibiniz şu an hangi seviyede? Nasıl olsun isterdiniz?

Gönlümden geçen şirketlerin ürün ekipleri konusunda mevcut durumlarına biraz daha yakından bakabilmek ve değişimi başlatabilmek için öncelikle fark edebilmek. Yorum olarak nasıl bir ekipte çalıştığınızı paylaşsanız ve tabloya beraber baksak çok hoş olmaz mı? Ardından da değişim mümkün mü ona bakarız. Unutmamak lazım ki değişim güven, yetkinlik ve bireyleri güçlendirme/destekleme ile mümkün.

Bu yazı Marty Cagan’in bu yazısından (product vs feature teams) ilhamla yazılmıştır.