Güçlü bir ürün ekibinin olmazsa olmaz kuralları!
Güçlü bir ürün ekibinin olmazsa olmaz kuralları!
Harika bir ekip kurmak için iyi bir analiz ve uygun bir ortam hazırlamak için bir rehber
Bu hafta kitaplığımdan seçtiğim kitabın muhattabı genel olarak ürün geliştirme alanında çalışanan yazılımcılar, ürün yöneticileri ve genel olarak ürün liderleri. Bu haftaki kitabımızın yazarı “Inspired: How to Create Tech Products Customer Love” yazarı Marty Cagan ve Chris Jones’in 2021 yılında birlikte yayımladıkları “Empowered: Ordinary People, Extraordinary Products” kitabı.
Bilenler olduğuna eminim, Cagan, Inspired kitabında ağırlıklı olarak ürün geliştirme yöntemlerinden ve farklı tekniklerden bahsediyordu. Örneğin müşteri araştırması nasıl yapılır, bunlar nasıl hedeflere dönüştürülür, nasıl bir vizyon ve strateji belirlenir vs. Ancak kendisi kitabın önsözünde, bir çok firmayı gördükten sonra bu firmaların aslında önerdikleri yöntem ve teknikleri uygulamalarına karşın başarılı olamadıklarını söylüyor. Bu durumda da bir çok organizasyonun aslında ürün geliştirme kültürünü düzeltmeleri ve takımlarıyla olan iletişim ve ilişkiyi çözmeleri gerektiğinden bahsediyor. Bu bulgulardan sonra görünüşe göre Cagan ve ekip arkadaşları ile birlikte koçluk yaptıkları firmaların teknoloji ve takım yönetimi pratiklerine derinlemesine eğilmiş olacaklar ki bir çok farklı alanda sistemik sorunlar keşfedip bu kitabı yaratmışlar. Kitapta da bunların her birine detaylı zaman ayırıp güzelce irdelemişler. Gelin hızlıca bunların özetini çıkartalım. Çalıştığınız firmalarda benzer semptomları görüyorsanız yorum kısmına yazın!
Teknoloji ekiplerinin rolü; Yazarlara göre, bir çok firmada teknoloji ekibi denildiğinde firmadaki bir çok kişi “IT departmanı” gibi görüyor. Bu durumda da teknoloji ekipleri değer üreten ya da işin temelini üstlenen bir ekip değil de daha ziyade masraf merkezi olarak düşünülüyor. Bir başka tespite göre de teknoloji ekiplerindekinin tek görevi “iş birimlerine hizmet etmek” olarak tanımlanmış. Bunun bir sonucu olarak da teknoloji ekibinin müşterisi iş birimine dönüşmüş ve firmanın gerçek müşterileri de teknoloji ekiplerinden soyutlanmış hale gelmişler.
Koçluk alışkanlıkları; Firmalarda koçluk alışkanlığının olmadığından, olsa bile çoğu yöneticinin bu konuda tecrübesi olmadığından bahsediliyor. Bu da tabii ki ekiplerin gelişmelerini engelliyor.
Takımlardaki eleman eksiklikleri; Çoğu takımın ihtiyacı olan roller açık ancak bir sebepten dolayı doldurulamıyor. Yani sürekli bir çalışan eksikliği söz konusu. Bu sorunları çözmek için de ya düzgün bir planları yok ya da yeterince sofistike olmayan yanlış yönlendirmeleri takip ederek çözebileceğini düşünüyorlar.
Takım topolojisi; Firmalardaki takım topolojisi öyle bir oluşturulmuş ki, kimse anlamlı olacak bir sorumluluğu üstlenemiyor. Takımlar ilerlemek istediklerinde ise sürekli birbirilerine bağımlılıklar oluşuyor, öyle ki takımlar büyük bir makinenin içinde küçük bir dişli gibi çalışıyor. Yani birinin çalışabilmesi için bir başkasının onu itmesi gerekiyor.
Ürün Vizyonu; Bu firmaların çoğunun ilham verici bir ürün vizyonu yok. Yıllar önce belirlenmiş bir vizyon var ancak yeterince güncellenmemiş ya da çağa ayak uydurulmamış. Teknoloji ekiplerindekiler de “feature factory”’de çalışıyormuş gibi hissediyorlar. Yani sadece yeni özellikler üretiyorlar ve bunlarla birlikte büyük resmi göremiyorlar.
Ürün Stratejisi; Verimsiz çalışan firmaların büyük kısmının ürün stratejileri çok zayıf. Hatta bir stratejileri yok! Sadece mümkün oldukça fazla paydaşı mutlu etmek için geliştirme yapıyorlar.
Takım Hedefleri; Çoğu Google’dan duydukları OKR’ları kullanıyorlar. OKR; Objective and Key Result’un kısaltılması. Genellikle bu OKR’lar katmanlar halinde firmanın en tepesinden aşağıya doğru yayılıyor. Takımları çoğu bu yöntemin faydalı olmadığını düşünüyor.
İş birimleriyle ilişkiler; İş birimlerinin, paydaşların ve üst düzey yöneticilerin teknoloji ekibine güveni çok az ya da hiç yok. Teknoloji takımları da kendilerini ya hiç takdir görmeyen paralı askerler gibi ya da iş birimlerinin uşağı gibi hissediyor.
Takımların yetkilendirilmesi; En kötüsü de, Cagan ve Jones böyle tanımlıyorlar, takımlar hiç bir şekilde problemleri müşterilerinin seveceği şekilde çözebilecek bir yetkiye sahip değiller. Burada yazarlar Empowered kelimesini kullanıyorlar. Ben bunu yetkiye sahip diye düşünerek çeviriyorum. Burası önemli olduğu için ve ben de çevirmen olmadığım için kitaptan direkt olarak alıntılıyorum.
Worst of all, the teams are not empowered to solve problems in ways customers love, yet work for the business. And as such, the teams can’t be held accountable to results.
Sanırım güzel bir özet oldu. Kitap bunu derinliklerinde çok güzel bir şekilde yapıyor ancak kitabın tamamını buraya yazıp sizin de elinizden bunu keşfetme keyfini almak istemiyorum!
Bunun yerine size son 4 yılda başıma gelmiş bir kaç örnekten ve ne şekilde çözüm ürettiğimizden bahsedeceğim. Fakat bundan hemen önce, gelecek bir kaç yazıda da kullanacağımız şu “Ürün liderliği” konusunun hızlı bir tanımını yapalım.
Kimler ürünün lideridir?
Modern ürün geliştirme yöntemlerinde 3 önemli lider var. Teknik lider, Ürün Yöneticisi, Ürün Tasarımcısı. Bu üç kişi bir araya geldiğinde Ürün Liderlerini oluşturuyor. Tabii burada önemli olan şey rollerden ziyade bu üç farklı yetkinlik. Peki bu üç yetkinliğin kattıkları neler?
Teknik Lider; Bu kişi platformun teknik özelliklerine hakim, neler yapıp neler yapamayacağını iyi biliyor ve daha da önemlisi eksikliklerini ve sınırlarını çok iyi tanıyor.
Ürün Yöneticisi; Ürünün bir vizyonu ve stratejisi olmasından sorumlu. Firmanın ulaşmak istediği noktaya ulaşırken kendi ürününün nerelerde etki yaratacağına hakim ve firmanın nasıl para kazandığına hakim.
Ürün Tasarımcısı; Bu rolden beklentiler yıllar içerisinde dramatik bir şekilde değişiklik gösterdi. Öncelikle grafik tasarımcısı olarak başlayan bu beklenti, zaman içerisinde kullanıcı deneyimine evrildi. Ekibin problem çözerken müşterilere ve deneyime yapacağı etkiyi anlamak ve en iyi deneyimi sunarak nasıl çözüm üretileceğini çok iyi biliyor.
Bu üç rolün ortak yetkinliği, ürünü ve müşteriyi çok iyi anlamak. Neyi neden yaptığını sorgulayıp, ekibe ve kendi paydaşlarına detaylı bir şekilde anlatmak. Bu ekibin içerisinde o alan senin bu alan benim gibi bir savaş yok. Onun yerine çok iyi bir partnerlik ilişkisi var. Dikkat ederseniz tanımlama yaparken sorumluluktan bahsetmedim, yetkinliklerinden bahsettim. Bunun özel bir sebebi var.
Her ürün ekibinin kendine özel dinamikleri ve sorunları var. Aynı şekilde kişilerin de güçlü ve zayıf yanları var. Örneğin bir ekipteki teknik lider çok dışa dönük olabiliyorken başka bir ekipte bu böyle olmayabilir. Bu yüzden keskin çizgilerle firma içinde şablonlar çıkartıp kurabiye hamuru gibi kesin şekiller çıkartmak ekipleri ve liderleri ister istemez strese ve sonucunda da verimsiz çalışmaya zorluyor. Bu yüzden ekiplerin oluşturulduktan sonra buna kendilerinin karar vermesi ve güzel bir partnerlik ilişkisi kurması çok önemli.
Bu ekip oluştuktan sonra onların da doğru bir ortamda çalışmaları çok önemli. Zaten bu haftanın kitabının adı da “Empowered”. Yani demek istediğim ekiplerin karar verme yetkisinin olmasının sağlanması, korkmadan hata yapabilecekleri ortamın tasarlanması ve daha da önemlisi hatalarını kapatmak yerine bunu tüm organizasyonla paylaşabilecek kadar sorumluluk alabilmeleri gerekiyor. Bunun için ne gerekiyor?
Psikolojik güvenlik; Bireyler kendi başlarına ya da kolektif olarak ekipler halinde kendilerini kötü eleştirilmeden ifade edebilecek güvenli ortama sahip olmalıdırlar.
Ekibin sorumluluk alanı; Ekipler, üründe nasıl bir etki yaratabileceklerini çok iyi anlamalılar ve bağımlılıklarını kendileri yönetebilmeliler.
Ekip içinde güven; Ekiptekiler takım arkadaşlarına kişisel olarak ve yetkinlikleri adına güvenebilmeli. Yani ekiptekiler kendilerini olduklarından farklı göstermek yerine, alçakgönüllülükle eksiklerini paylaşabilmeli ki ekibindeki diğer kişiler yardım edebilsin.
Kaderlerini tayin edebilme yetkisi; Çoğu firmalarda teslim tarihi ya da proje bitim tarihi ekipler tarafından değil, sahadaki kısıtları bilmeden teslim tarihi veren yöneticiler tarafından belirleniyor olabilir. Bu gibi durumlarda ekiplerin yetkileri ellerinden tamamen alınır ve ekip büyük bir mekanizmanın içindeki bir dişliye dönüşür. Yani kaderlerini tayin edemezler. Benzer bir sorun ekiplere sorun ve fırsat alanıyla gitmek yerine, çözümlerle gidilmesiyle de oluşabilir.
Sürekli öğrenme becerisi; Sanırım artık her ekip bir şekilde retrospektif toplantısı yapıyor. Ancak bu toplantılardan çıkan aksiyonları ne kadar uyguluyor ve takip edebiliyorlar? Süreçlerindeki bir sorunu gördükleri anda çözebilmeleri için yetkileri var mı yoksa bu firmanın bir başka birimine mi bağlı? Eğer bağımlılık varsa ekibin liderleri bu konuda ekibe nasıl yardımcı oluyorlar? Yani ekip her yaptığı hatadan, performans düşüklüğünden ne öğrenebiliyor?
Ekibin ortak bir amacı olması; Ekibin bir takım gibi çalışabilmesi için ortak bir hedefe ihtiyacı var. Ekip, bu ortak amacı biliyor mu? Yani bir probleme çözüm ararken neye göre optimizasyon yaparak çözüm bulabileceklerini ne kadar iyi biliyorlar?
İşte yukarıda anlattıklarım, ve belki de gözden kaçırdığım diğer şeylerle birlikte, ekiplerin “High Performing Team” olabilmelerinin mümkün olduğunu düşünüyorum. Gelin bir örnekle devam edelim.
Bir firmada çalışmaya yeni başlamıştım. Yöneticim ve yöneticileri, beni liderliğini yapacağım takımın bir süredir değer üretemediğine dair uyarmış ve sorunun ne olduğunu anlamadığını söylemişlerdi. Takım, ben başladığımda, 4 aydır bir projeyi bitirmeye çalışıyor, sürekli teslim tarihini ötelemek zorunda kalıyordu. Tarih meraklıları daha iyi bilecektir, ekip adeta bir Passchendaele savaşı yaşıyordu. Ancak her bir “Son bir gayret — one last push” mottosuyla birlikte ekip kendini ya eskiden kalan bir antik servisin çamurlu tarlasına saplanmış şekilde buluyor ya da ön göremediği yan etkiler yüzünden daha fazla zaman kaybediyordu.
Dışarıdan bakınca sorun sanki ekibin başarısızlığı gibi görünebilir. Ancak “gerçek” sorunu anlamak için daha detaylı bakmak lazım. Unutmayın, bu ekip remote çalışıyor.
Ekip içerisindeki güven; Ekipteki mobil yazılımcılar backend geliştirenlere güvenmiyor, backend’in sürekli karar değiştirmesi mobil üzerindeki yapılanları baştan değiştiriyordu. Özellikle her değişikliğin de ciddi bir yan etkisi olarak tüm testlerin baştan yazılması ve tekrar tekrar farklı senaryoların değiştirilmesi gerekiyordu.
Ekibin sorumluluk alanı; Ekibin sorumluluk alanı iyi çizilmemişti, bir çok farklı takım bu takımın yönettiği servislere bağımlı hale gelmiş dolayısıyla bir hareket etmeden önce defalarca düşünmeleri gerekiyordu. Daha da kötüsü bunu çözmek için firma, ekibin yazılımcı sayısını arttırmış, sonra da kısa süreli kontratlarla daha fazla yazılımcı işe almışlardı.
Kaderlerini tayin edebilme yetkisi; Ekibin üzerinde çalıştığı proje “üst yönetim” tarafından ekibe “atanmış”, yönetici kadro bu geliştirmenin yaratacağı etkiye varsayımlara dayalı bir şekilde inanmış ve bunun için diğer paydaşlarına söz vermişti. Dolayısıyla sürücü koltuğunda ekip varmış gibi görünse de ekibe bir direksiyon sağlanmamıştı.
Psikolojik güvenlik; Bütün bunlar yaşanırken, herkes adeta dünyaya düşecek bir meteoru izliyor, çarpıp sonlarını getirmesini bekliyor gibiyken yöneticileri suçluyor, sorumluluk almıyor, benzer şekilde de yöneticiler ekibi suçluyordu.
Bu durumu çözmek için atmamız gereken ilk adım yangını kontrol altına almak ve tarafların beklentilerini yönetmekti. “Üst yönetim” tarafından beklenti sorumluluğu ve yetkiyi aynı anda ekibe vermekti. Yani ekibe çözümle gitmek yerine yaratmak istedikleri etkiyi ve bunun neden iyi bir fırsat olduğunu anlatmalarıydı. Ürün ekibinden beklenti ise aldığı yetkiyle birlikte bir çözüm üretmesi ve bunun neden iyi bir çözüm olduğunu anlatmasıydı. Yani tarafların BİRBİRİNE GÜVENMESİ GEREKİYORDU!
Bunu uygulamaya koymak için ekibin çalışmasını durdurduk, çalışma yöntemlerimizi hep beraber baştan ele aldık. Takımdakilerin birbiri ile sorunlarını açık ve dürüstçe paylaşabilmesi için uygun bir ortam hazırladık, böylece birbirine anlamayan taraflar yaptıklarının sonuçlarını anlamaya başladılar.
Bunu yaparken bir yandan da çözmeye çalıştığımız problemi anlamaya ve nasıl çözebileceğimize bakmaya başladık. Bir kaç tane “ideation oturumu” sonrası ekip çözümleri ve olası artı ve eksi sonuçlarını çıkartmaya başlamıştı.
Tüm bunlar 1 hafta sürdü. 1 hafta sonunda ekibi yeniden rayına sokabilmiştik, ayrıca elimizde 4 tane de fikir vardı. Ben ve benim “suç ortaklarım” olarak bu fikirleri yöneticilerimize sunduk. Sonunda onlar da ekibin yeteneğine ve kendi başına çalışırsa başarabileceğine inanmaya başladılar. Sonuç olarak ekip pivot etme kararı verdi, ve soruna farklı bir şekilde yaklaşıp farklı bir çözüm üretmeye koyulduk. 4 ay önce takımın yaratmak istediği etki, bir metriğin %4 artmasıyken, ekibim bunu 3 haftada %2.9 arttırabildi. Ama en önemlisi ekip kendi kendini tamir etmeyi öğrenmişti.
Umarım bu yazı hoşunuza gitmiştir, eğer eleştiri ya da önerileriniz varsa geribildirim formunu doldurarak, bu e-postaya cevap vererek ya da yorum yazarak sesinizi duyurabilirsiniz!
Bu kitabı ürün ekiplerinde çalışan yazılım yöneticilerine, ekip liderlerine ve ürün yöneticilerine öneriyorum. Ekibe güvenmek için doğru ortamı kurmak, doğru metrik ve sinyalleri takip etmek en önemlisi de ekibinize koçluk yapmanız gerekiyor. Bu kitap da size bunu fazlasıyla öğretiyor.
Eğer bu yazıyı beğendiyseniz iş arkadaşlarınızla paylaşmayı unutmayın!
Eğer hala kayıt olmadıysanız hemen kayıt olmak için tıklamayı unutmayın!