Ürün Yöneticileri için “Pairing”
Programcıların birlikte daha verimli ve etkin çalışabilmek için sıklıkla kullandıkları, hatta bazı teknoloji şirketlerinde mühendislik kültürü haline gelen “pair programming”, Türkçe’ye ikili programlama ya da eşli programlama şeklinde çevriliyor. Çevik pratiklerden biri olan eşli programlamada yazılım geliştiren iki kişinin bir özelliğin geliştirmek için beraber çalışması, benzer biçimde “analiz yapan, karşılaşılabilecek farklı senaryoları ortaya koymaya çalışan iki ürün yöneticisi için de mümkün olabilir mi?” sorusunu akıllara getiriyor.
Pivotal Labs’de ürün yöneticisi olarak çalışan Anne Thomas’ın konu ile ilgili yazısı “Ürün yöneticileri neden, ne zaman ve nasıl başka bir ürün yöneticisi ile işbirliği yapmalı.” sorularının cevaplarını içeriyor. İşte kendi ağzından Pivotal Labs’daki eşli programlama deneyimi.
Pivotal Labs’da mühendislerimiz eşli programlama yapıyorlar. Eşli programlama iki mühendisin birlikte çalıştığı bir pratik. Tek bir bilgisayarı paylaşır, bir sürücü diğeri ise gözlemci olarak rol alır. Eşli programlamadan daha üretici ekipler yarattığı için faydalanıyoruz. Bu şekilde programlama yapan takımlar daha iyi kod yazmaya ve daha güçlü bir sahiplik duygusuna yatkın oluyor.
Ürün Yöneticileri olarak, sıklıkla “siz de eşli çalışıyor musunuz?” sorusuyla karşılaşıyoruz. Cevap hem evet hem de hayır. Tipik bir Pivotal Labs yapısında, biz ürün yöneticileri olarak mühendislerinki kadar katı bir eşli çalışma yapmıyoruz. Ama, günümüzün önemli bir kısmında başka bir Ürün Yöneticisi ya da Tasarımcı ile ortak bir bilgisayar ya da beyaz tahtada çalışıyoruz.
Yakın zamanda, başka bir Pivotal Ürün Yöneticisi ile çok daha geniş kapsamlı bir eşli çalışma deneyimi yaşadım. Aynı zamanda Pivotal’da çalışan diğer Ürün Yöneticileri ile onların “eşli Ürün Yöneticiliği” deneyimleri hakkında konuşma şansı yakaladım. Bununla birlikte, eşli programlamanın pek çok faydasını eşli Ürün Yöneticiliğinde de kullanılabilir.
Daha iyi Kararlar Verin
Eşli programlamayı uygulamanın sebeplerinden biri de iki mühendisin bir mühendisten daha iyi kararlar verme eğiliminde olma gerçeği. Ürün Yöneticileri olarak karar verdiğimiz en önemli şeylerden biri hangi problemi ele alacağımız. Bu karara varabilmek için, paydaşlarla kullanıcı araştırmaları ve anket çalışmaları yapıyoruz. Bununla, mevcut olan problemler hakkında daha derin bilgi kazanarak; problemlerin göreceli öncelikleri konusunda fikir sahibi oluruz. Mevcut bilgi ve veriler birden fazla kişi tarafından yorumlandığında, problemler hakkında elde edilen sonuçlar daha az ön yargı ve sapma içerir. Bir Ürün Yöneticisi masaya daha kullanıcı merkezli görüş sunarken, bir diğeri son derece iyi bir stratejik bakış açısına sahip olabilir. Aynı şekilde bir Ürün Yöneticisinin görmezden geldiği önemli bir detayı bir başka Ürün Yöneticisi fark edebilir.
Varsayımları Belirleyin
Ürün yöneticilerin bir diğer önemli görevi de test etmemiz gereken riskli varsayımları ortaya koymaktır. İki Ürün Yöneticisi varsayımları belirlemede daha iyi iş çıkarma eğilimindedir. Aynı zamanda bu varsayımları test etmek için daha iyi denemeler yaparlar. Sonuç olarak, her bir tekrarda daha çok değer yaratıp, daha değerli bir ürüne daha hızlı ulaşabiliriz. Bu denemeler, bir ürünü yapmak ya da yapmamak gibi ciddi kararlara varmayı sağlayacağı için, tek bir kişi yerine iki kişinin bu konuda çalışması tercih edilecektir.
Daha Çok Öğrenin
Eşli yazılımın başka bir faydası da mühendislere birbirlerinden bir şeyler öğrenme konusunda yardımcı olmaktır. Deneyimli mühendisler bile, eşli programlama yaptıklarında yeni bir şeyler öğrendiklerini belirtiyorlar. Bu Ürün Yöneticileri için de geçerli. Ürün ve ekip hakkında bilgi sahibi bir Ürün Yöneticisi bir diğerine çalışmaları esnasında çok değerli yorumlar ve geri dönüşler sağlayabilir.
Tüm bunların ötesinde, eşli çalışırken bir Ürün Yöneticisi bir diğeri ile aynı problemlere yaklaşımı konusunda kendisini kıyaslayarak, kendisinin güçlü ve zayıf yönleri konusunda farkındalığını arttırabilir.
Nasıl Eşli Ürün Yöneticiliği Yapılır?
Peki, Ürün yöneticileri olarak nasıl eşli çalışabilirsiniz? Bunun net bir formülü olduğunu düşünmüyorum. Bilgisayarda kullanıcı hikayeleri yazarken, ya da bir ürün güncellemesi hazırlarken, sürücü-gözlemci modeli izlenebilir. Bir Ürün Yöneticisi yazarken, diğeri hataları ortaya belirleyip eksik kısımları tamamlamaya odaklanabilir ya da daha iyi bir şekilde ifade edilebilecek yolları önerebilir. Bir paydaşı sürece dahil ederlen, bir Ürün Yöneticisi konuşmayı yönetirken bir diğeri notları ve aksiyon noktalarını takip edebilir.
“Eş Ürün Yöneticinize sizin gün yüzüne çıkaramadığınız şeyleri masaya koyacağı konusunda inanmalısınız!”
Eşli programlamadan farklı olarak, her bir Ürün Yöneticisinin oynadığı rol birlikte çalışacağı kişi ve çalışmaya bağlı olarak en iyi işleyecek şekilde daha değişken ya da katı olabilir. Siz ve birlikte çalıştığını kişi iş birliği konusunda iyiyseniz, Bu durum son derece doğal bir şekilde oluşacaktır.
Sabırlı Davranmayı Deneyin
Eşli Ürün Yöneticiliğinin faydaları üzerine çokça konuştuk, fakat tıpkı eşli programlama gibi, eşli Ürün Yöneticiliği pratiği de zordur. Ve herkes için işlemeyebilir. Bu süreç empati yapmak, sabır göstermek, ve fikir değiştirmek konusunda hevesli olmak gerekiyor. Aynı zamanda birlikte çalıştığınız kişinin sürece katkı sağlayacağını ve sizin göremediklerinizi karşınıza çıkaracağı konusunda inançlı olmalısınız. Bu bileşenler olmadan eşli Ürün Yöneticiliği yapmak yolunda gitmeyebilir ve hem ürün hem de takım için zarar verici bir hal alabilir.
Ne Zaman Eşli Ürün Yöneticiliği Yapılır?
Eşli Ürün Yöneticiliği maliyetlidir. Bunun bir sonucu olarak, eşli Ürün Yöneticiliğini bazı belli durumlarda uygulanacak şekilde kısıtlama eğiliminde olmak gerekiyor. Örneğin, yeni bir işe alım olduğunda, bir ürünü bir Ürün Yöneticisinden diğerine devrederken, ya da çok geniş kapsamlı ve komplike bir ürünü yönetirken. Tecrübelerime göre, eşli Ürün Yöneticiliği bu senaryolarda faydalı. Örneğin, bir ürün üzerinde çalışıyordum ve belli bir özelliğin kullanıcılara değer yaratmadığı için kesinlikle ihtiyaç duyulmayan bir özellik olduğu konusunda son derece güçlü bir fikrim vardı. Birlikte eşli çalıştığım Ürün Yöneticisi ile yaptığım uzun tartışmalardan sonra bu özelliği eklemeye karar verdik. Kullanıcılar konusunda fikrimde haklı olmama rağmen, bu özellik kurumsal tarafa çok fazla değer katan bir özellik haline geldi. Bu özellik paydaşlarımızı gerçekten çok etkiledi ve destek toplamalarına yardım etti. Eş Ürün Yöneticisi arkadaşım, benim görmediğim şekilde kurumsal kullanıcıların ihtiyaçlarını okumuştu.
Bu her zaman eşli Ürün Yöneticiliği yapmamız gerektiği anlamına mı geliyor? Emin değilim. Bence eşli Ürün Yöneticiliği’nin ne zaman mantıklı ne zamansa olmaması gerektiğini ortaya çıkaran daha fazla araştırma gerekiyor. Ama bundan daha fazlasını yapabileceği konusunda şüpheliyim.
Kaynak: https://builttoadapt.io/pairing-for-product-managers-8adacee03f48
iyzico’da Eşli Ürün Yönetimi
iyzico’da ürün yöneticileri olarak, yazılım ekipleriyle birlikte scrum takımları halinde çalışıyoruz. Aynı zamanda, scrum ekiplerinin diğer iş birimleriyle olan iletişimi de yine ürün yöneticileri üzerinden yürütülüyor. Ürün ile ilgili ihtiyaç ve iyileştirmeleri tüm iş birimlerinden, yapılan kullanıcı araştırmaları sonuçlarından ve ürünlerin stratejik hedeflerinden yola çıkarak bir araya getiriyor, değerlendiriyor ve önceliklendiriyoruz. Önümüze çıkan tabloya göre işleri PM’ler ve ekipler olarak paylaşıp işe koyuluyoruz.
Fakat bazı ürünler, çok büyük kapsamda olabiliyor ve/veya teknik anlamda çok fazla farklı projeye dokunabiliyor. Bu tip durumlarda, ürünü daha küçük parçalara ayırıp, birden fazla scrum ekibine, belli özellikleri geliştirecek şekilde paylaştırıyoruz.
Ama işler her zaman böyle gitmiyor. Tüm teknik yapıya dokunan, büyük kapsamlı ve özellik bazında ayrıldığında büyük resmi görmeyi zorlaştıran, planlanan zamanlamayı aşma ve beklenen kalitede çıkmama gibi riskler taşıyan projeler ve/veya ürünler olabiliyor.
Bu gibi durumlarda, tek bir ekip ile yürütülemeyeceği net olan ama ekiplere bölünmesi projeyi riske atma ihtimali taşıyan bir senaryo ile karşı karşıya kalınıyor. İşte tam da bu noktada, organik olarak iki ekip ve iki PM’den oluşan bir yapı oluşturmanın işe yarayacağını düşündük. Daha doğrusu, ilk aşamada işleri bölüştüğümüzü zannederken, aslında ne kadar uğraşırsak uğraşalım temelinde kocaman bir ürünün parçası olan özelliklerin birbirinden ayrı düşünülemeyeceğini gördük.
Thomas’ın makalesinde belirttiği gibi, büyük kapsamlı projeler söz konusu olduğunda, ekiplerde yer alan yazılım geliştiricilerin arasındaki eşli programlama kadar, PM’ler arasındaki eşli çalışma da altın değerinde oluyor. Kapsamlı ürünleri analiz ederken, ilgili senaryoları ve ihtiyaçları ortaya koyarken, iki kişinin deneyim ve bakış açısının bir araya gelmesi çok daha güzel sonuçlar ortaya çıkarıyor. Özellikle de “ipin ucunu bulmanın zor olduğu” ürünün ilk oluşma dönemlerinde, ne kadar farklı düşünen iki PM bir araya gelirse sonuç o kadar tatmin edici oluyor. Siz bir soruna odaklanmış başka bir şey düşünemezken, eş PM’iniz birden bakmanız gereken daha doğru bir noktayı işaret edebiliyor. Ya da çok güzel bir akış çıkardığınızı düşünürken, akıştaki eksik ya da açık kalmış parçaları tamamlayabiliyor. İşte biz de tam bu noktada eşli PM yapısının ihtiyacımız olan şey olduğunu gördük.
Bir diğer konu ise, her ne kadar PM olarak işimizi yürütebilmek için belli yetkinliklere sahip olmamız gerekse de, her PM’in içinde bulunmaktan daha çok zevk aldığı ve daha yatkın olduğu alanlar var. Özellikle bizim durumumuzdaki gibi geniş kapsamlı projeler söz konusu olduğunda farklı alanlarda yatkınlığı olan iki PM’in birlikte çalışması ürüne çok daha bütünsel bir bakış açısı kazandırıyor.
Birlikte Nasıl Çalışıyoruz?
Eşli PM yapısının bizim için iyi işleyeceğini ve ihtiyaçlarımızı karşılayacağını düşünerek, bu süreci test etmek istedik. Peki sonra nerden başladık?
Öncelikle her gün teknik ekiplerimizle günlük scrum rutinimizi uyguladıktan sonra, bir araya gelip günümüzü planladık. Üzerinde çalışacağımız konuları belirleyip, ortak bir ekran üzerinden analiz edeceğimiz başlıkları belirledik. Birlikte odaklanacağımız kısımlarla ilgili aklımıza gelen soruları listeledik. Çalışma esnasında aklımıza soru geldikçe, bu listeye ekledik. Böylece ürün ile ilgili netleştirmemiz, araştırmamız gereken konuları belirledik. İki kişi bir araya gelince ne kadar çok doğru soru çıktığını tahmin bile edemezsiniz. Bu liste ilerleyen süreçte hangi konuların netleştirilmesi gerektiğini ortaya koyan ve analizin çok önemli bir parçasını oluşturan bir doküman haline geldi.
İş birimleri ile toplantılar ayarlayarak, ürün ile ilgili çıkarmış olduğumuz soruları netleştirirken toplantılarda birimiz toplantıyı yönetirken, diğeri ise çıktıları toplayarak analiz esnasında kullanabileceğimiz hale getirmeye başladı. Bu çok daha verimli toplantılar yapmamızı sağlarken, bir yandan da bize bir araya getirilmesi zor olan farklı iş birimleriyle kapsamlı toplantılar yaparak konuyu farklı boyutlarıyla derinlemesine tartışma olanağı sağladı. Daha yönetilebilir olsun diye her bir iş birimiyle küçük gruplar halinde toplantılar yapma, sonrasında tüm toplantı sonuçlarını bir araya getirme, çıkan sonuçlara yönelik yeniden toplantılar yapma gibi süreçleri minimuma indirdik. İki PM aynı konu üzerinde yoğunlaştığı için, daha büyük ekipler halinde ilerleyerek herkesin ortak tartışabileceği ortamlar yarattık.
Analizlerimizi yaparken tek bir monitör üzerinden çalışarak, aynı konuya yoğunlaşmayı kolaylaştırdık. Dokümanı birimiz yazarken, diğeri de gerekli yönlendirmeleri yaparak ilgili konu için alınan kararları dahil edip etmediğimizi takip etti.
Zamanımızın hepsini eşli çalışarak geçirmiyoruz tabii ki. Birlikte çalışmamızın iyi olduğunu düşündüğümüz konulardan sonra, piyasadaki benzer ürünleri incelemek, güncel ürünlere göz gezdirmek ve analiz ettiğimiz ürünlerin yazılım ekiplerinin üzerinde çalışacağı işlere bölmek için ayrı ayrı çalıştığımız zamanlar da var.
Ne Kadar Süre Eşli Çalışacağız?
Aslında bunu projenin işleyişi belirleyecek. Bir süredir üzerinde çalıştığımız proje kapsamında eşli olarak çalışıyoruz, ve görünen o ki önümüzdeki iki üç ay boyunca böyle devam edecek. Eşli çalışmanın avantajlarından yararlanırken, belli bir noktaya geldiğimizde ayrı ayrı çalışmanın daha verimli olacağına karar verebiliriz. Bunun net bir cevabı olmamakla birlikte, netleşen konular, ürünün belli bir aşamaya gelmesi, ya da ekibin ihtiyacı bu kararı vermemize sebep olabilir.
Bu benim için ilginç bir deneyim, bir yandan eşli çalışmayı deneyimlerken bir yandan da oldukça büyük bir proje içinde dengeleri sağlamaya çalışıyoruz. Ürün yönetim sürecimizi ihtiyaç duyduğumuz kadar bu şekilde yürütmeyi planlıyoruz. Benzer şekilde başka projeler söz konusu olduğunda, ya da Thomas’ın da yazısında bahsettiği eşli Ürün Yöneticiliğinin avantaj yaratacağı durumlardan biriyle karşılaştığımızda yeniden eşli PM pratiğini gündeme getireceğimiz kesin!
