📣 🎉 Üretim Bandı & Brick Institute Ürün Yönetimi Raporu 2023 için veri topluyoruz. RAPORLAR menüsünden katkıda bulunabilirsiniz! 📣 🎉
📣 🎉 Üretim Bandı & Brick Institute Ürün Yönetimi Raporu 2023 için veri topluyoruz. RAPORLAR menüsünden katkıda bulunabilirsiniz! 📣 🎉
Bültene hoş geldin 👋
Bu sayının konusu biraz kişisel: Yönetici ya da üretici olmak ne demek, nasıl farkları ve gereklilikleri var, özellikle de ben hangi yolu tercih etmek istiyorum gibi sorulara bir süredir ara ara cevap arıyorum. Belki aynı sorulara cevap arayan başka kişilere de yardımcı olur diye de bu süreci “düzenli kaos” formatında yazıya dökmeye karar verdim: Alıştığımız formattan ziyade düşünce ağırlıklı, başı sonu belli olmayan bir blog yazısı gibi oldu. Umarım yeni şeyler düşünmeye teşvik eder ya da düşündüklerinize katkısı olur!
İyi internetler,
Burcu
📢 Duyuru: Üretim Bandı toplululuğu, 2 Eylül Perşembe akşamı saat 19:00'da bir araya geliyor! 🎉Webinar’lar, online buluşmalar bir yere kadar: Havalar güzelken keyfini çıkaralım, birbirimizi görelim, muhabbet edelim dedik. Ajanda yok, amaç sosyalleşmek. Nerede mi buluşuyoruz? Bir sürü şehirde buluşmalar organize edildi bile! Bu formdan kayıt yapabilirsin.
Bu konuya nereden geldim?
Neden karar vermek gerekli gibi geliyor?
Nasıl karar verilebilir?
Neredeyse on senedir dijital süreçlerin çeşitli yönlerine dokunan rollerde bulunuyorum, bu sürenin katıksız dört, biraz daha kapsamlı düşünürsem altı senesi bilfiil ürün geliştirmekle geçti. Hatrı sayılır sayıda yerde hem fonksiyonlar arası ekipleri hem de ürün yönetimi ekiplerini koordine ettim, bolca sektör ve iş modeli gördüm; aynı rolde kalarak çok farklı problemlere çözüm ürettim ve sorumlulukları üstlendim özetle. Böyle düşününce sonsuza kadar ürün yöneticisi olabilirmişim gibi geliyor, hala sürekli yeni şeyler öğreniyorum ve bilmediğimi bildiğim bir dünya şey var (bilmediğimi bilmediklerimi daha saymıyorum bile). Ben kendimden ne bekliyorum, gidişat nereye gibi konuları düşünürken de şu sorulara kadar geliyorum:
Ürün geliştiren ekiplere, özellikle ürün yönetimine ilgi duyan ve bu alana geçerek kariyer değişikliği yapan kişi sayısı sürekli artarken, ürün yönetiminden farklı bir alana geçen pek fazla kişi görmüyorum. Mevcutta ürün yönetiminde olan kişiler hangi alanlara doğru evrilebilir?
Herkesin CXO ya da VP olacak hali yok, şartlar olsun, şans olsun, kişisel tercihler olsun bir sürü etken var ve bu rollerde çalışan kişi sayısı diğer rollere göre doğal olarak düşük. O zaman nasıl bir hedef koymak lazım?
Bir noktada kendi ürünümü geliştirmek istiyorum gibi duruyor, o nokta ne zamana tekabül ediyor? Aslında kendi ürünümü geliştirmek ya da o organizasyonu yönetmek istemiyor olabilir miyim? Danışmanlık da bir seçenek mi?
Ürün yönetimi derya deniz bir alanlar bütünü, herhangi birinde uzmanlaşmak mı hepsinden azar azar bilmek mi daha iyi? Ben ne zaman, hangi alanda uzmanlaşmaya çalışsam? Bir noktada bambaşka bir alana geçmek istersem yapabilecek miyim?
Her şey sürekli değişiyor, bir sürü konuda da kontrol pek bende değil gibi. 2-3 seneden sonrasını düşünmemek daha mı doğru?
Ünvanları ve promosyonları önemsemiyorum da, başka türlü aynı organizasyonda kalmanın, o sırada kazancı artırmanın ve öğrenme motivasyonunu zinde tutmanın yolu var mı? Bunu yönetici olarak mı yapmak istiyorum, üretici olarak mı?
Bu soruların her biri ayrı bir sayının konusu olmayı hak ediyor (belki de olur, bu sayının geri bildirimlerine göre hareket ederiz), o yüzden benim gündemimi en çok meşgul edeni, yani sonuncuyu seçtim: Öğrenmeyi sevdiğim ya da iyi olduğumu düşündüğüm bir alanda çalışan bir ekibin yöneticisi olmayı mı istiyorum, yoksa bu alanda ya da bambaşka bir alanda özelleşerek daha derinlemesine ve karmaşık işler üzerine uygulamalı (hands-on) çalışmayı yani üretici (individual contributor, IC) olmayı mı?
Ekip yöneticisi olunan kariyer yolu, hepimizin alışık olduğu ve özellikle Türkiye’de çoğu teknoloji şirketinin sağlayabildiği tek seçenek: Senior PM, Lead/Head PM, Group PM, Director PM, VP/CXO diye gidiyor. Çoğu insan iş değiştirirken bu pozisyonları kovalıyor ki etki alanını genişletebilsin, yeni sorumluluklar edinebilsin veya gelir artışı elde edebilsin. Bu çıkmaz da aslında ekip yönetmek istemeyen kişilerin ekip yönetmesine, dolayısıyla o ekiplerin mutsuz olmasına ya da işten ayrılmasına kadar gidebiliyor bu arada.
IC olarak devam edilen kariyer yoluysa hem organizasyon için hem de kişiler için daha zorlu: Aynı organizasyonda kalıp tecrübe edindikçe ekip yönetmemeyi tercih etmek biraz zor, çünkü hem genelde bu organizasyonun yönetim ekibi istiyor ki bu kişi ekibi büyütsün ve tecrübesini yönetici olarak ekibine aktarsın, hem de çoğu zaman bu kişi kazancını artırmak ve “kariyerinde yükseliyor” beklentisini karşılamak için “ekip yönetmek” şapkasını takmak durumunda (“Hala müdür olamadın mı” gibi sorular bayramlarda bize değilse de birilerine soruldu). IC olunan kariyer yolları daha çok mühendislik alanında mümkün ve orada da tüm organizasyonlarca benimsenmiş bir yol değil: Google, Dropbox, Square gibi büyük toplar bu süreçleri güzel oturtmuş yerler. Temel sebebi de bu bahsettiğim “aynı organizasyonda kalmak, o sırada kazancı artırmak ve öğrenme motivasyonunu zinde tutmak” ihtiyacını karşılamak. Öbür türlü insanlar birkaç sene çalışıp fırsat bulunca başka yere geçerlerdi çünkü.
Ürün yönetimi alanında IC kariyer yolunu sağlayabilen organizasyonlar var, ama sayıları hayli sınırlı ve ekip yöneticisi tarafındaki gibi genele yayılmış bir seviyelendirme anlayışı hiç yok.
Şimdi gelelim hangisini istediğimize karar vermeye.
Önce kısaca bu soruyu kendimce cevaplayayım:
Kararsızken insan yerinde sayıyor gibi hissediyor, “Yıllardır aynı şeyleri yapıyorum” hissiyatı geliyor.
Karar verince hangi konularda daha iyi olmak ve yeni şeyler öğrenmek gerektiğini belirlemek daha kolay.
Yeni şeyler öğrenmeye dair kısa dönemli bir hedef olmazsa o öğrenme heyecanı zaman içinde sönümlenebiliyor.
Bu kararı yöneticiyle paylaşmak ve karşılıklı beklentileri konuşmak herkes için daha faydalı. Özellikle yöneticinin mentorluk yapabilmesi için güzel bir zemin hazırlanmış oluyor.
Alan seçmek, pazar seçmek gibi görece akışkan geçişlere nazaran daha keskin bir seçim gibi duruyor ve bir yerden başlamak gerekiyor gibi.
Ne istediğini bilerek. Özünde iki aşamalı bir süreç: Bu iki kariyer yolunun ne olduğunu ve birbirlerinden farklarını anlamak, bunun üzerine kendi isteğinin hangi yol olduğuna karar vermek. Bazı önemli notlar:
Çok iyi bir yönetici olabilecek yeteneklere ve öğrenimlere sahipken aslında ekip yönetmek istemediğimizi fark edebiliriz ve yatkın olmamıza rağmen o yolu seçmeyebiliriz, bu gayet doğal.
Aynı şekilde pek yatkın değilsek ya da çok bilgimiz yoksa ama ekip yönetmeyi istiyorsak bu kasları geliştirmek de gayet mümkün.
Türkiye’de pek fazla örneği olmasa da başka ülkelerde insanlar IC olarak kariyerlerini geliştirip daha fazla kazanç ve öğrenme sağlayabiliyor. IC’ler ve yöneticilerin kazançları arasında uçurumlar yok, iş biraz kişinin kendini ne kadar geliştirdiğine bağlı.
Bu iki yoldan birini seçmek, bir daha diğer yola geçilemeyeceği anlamına gelmiyor. Küçük bir arama yaparak bu geçişlere dair aktarılan deneyimlere rahatça ulaşabilirsiniz. Yani insan bir noktada farklı hissetmeye başlarsa ya da öncelikleri değişirse odağını değiştirmek kolay olmasa da mümkün.
Hem yöneticilik, hem de üreticilik ürün yönetiminin doğası gereği liderlik ederek etki yaratmayı gerektiriyor, yani liderlik etmek ve ekip yönetmek aslında aynı şey değil. Ken Norton’ın konuyla alakalı fikirlerini bu yazıyı tamamladıktan sonra okudum ve IC’den kopup gelen üçüncü bir seçenek olarak “liderlik” üzerine bir kariyer yolu kurgulanabileceğine kesinlikle katılıyorum.
Birçok kaynağı tüketip bu iki kariyer yolunu ve birbirlerinden farklarını anlamaya çalıştıktan sonra, anladıklarımı özetler bir tablo hazırladım:
Bonus: Karar verme sürecinde bilen birinden mentorluk almak makul bir kısayol olarak görülüyor, çünkü aslında aynı yollardan geçmeyi isteyebileceğimiz birine, cevabını kolayca şekillendirebileceği spesifik bir soru sormak ve çok vaktini almadan ne düşündüğünü öğrenmek çok basit ve verimli bir deneyim aktarım yöntemi.
Bu kararı halihazırda çalışılan organizasyonda uygulama imkanı var mı, onu anlamak yapılacak ilk şey olabilir. Bunun için tabii ki yöneticiyle şeffaf bir konuşma yapmak ve sonucuna hazır olmak gerekiyor, çünkü belki de bir yöneticiye ihtiyaç yok ve bir süre de olmayacak ya da bir yöneticiye ihtiyaç var ve üretici olarak kalmanın öğrenmeye ya da kazanç edinmeye dair beklentileri karşılamadığı bir organizasyon kültürü hakim.
Bu konuşmadan güzel sonuç alınırsa ne ala, alınamadıysa devam edelim.
Yönetici olmak isteniyorsa:
Bu seçenekle ilerlemek görece daha kolay: Belirli bir uygulanış şekli uzun süredir var. Mevcut organizasyonda bu ihtiyaç yoksa farklı yerlere geçiş denenebilir. Bazı yetkinliklerin eksikliği hissediliyorsa da bu konuda yönetim ekibinden mentorluk, eğitim, geri bildirim mekanizmaları ile destek istenebilir.
Üretici olmak isteniyorsa:
Bu seçenekte yol almanın gördüğüm kadarıyla iki olası yolu var:
Mevcut organizasyonda ve üründe bir süre vakit geçirdikten sonra alan/pazar/iş modeli değiştirmek. Bu durum bir süre kazancı sabitlemeye sebep olacak olabilir, ancak uzun vadede farklı disiplinleri deneyimlemek ve sürekli öğrenmeyi körüklemek motivasyonu yüksek tutabilir ve bir noktada yönetici olmadan tecrübeli bir üretici olma haline ulaşmayı sağlayabilir.
Mevcut organizasyondaki etki alanını genişletmek. Bunu yapmak pek kolay olmayabilir, çünkü hem yeni fırsatların doğması hem de diğer ekiplerin doğal çalışma halini bozmadan, kimseyi rahatsız etmeden hareket etmek gerekiyor. Şu yazıyı bu sıralar okudum ve konuyla bir hayli alakalı olduğunu düşünüyorum.
Bu sayılık bu kadar. Karşılıklı yorumlaşmak isterseniz Slack grubumuza bekleriz.
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayıda bir süredir üzerine kafa yorduğumuz ve okumalar yaptığımız bir konu üzerinde durmak istedik: Araştırma havuzları. Dağlar denizler gibi uçsuz bucaksız bir kavram ve üzerine türlü türlü yazılmış çizilmiş, farklı farklı bir sürü ihtiyacı çözerken çeşitli zorlukları da beraberinde getiriyor ve hala gelişen bir konsept olduğundan ortak bir “en iyi” yok. Hem yazı içinde hem de kaynaklar kısmında bu çeşitliliği aktarıp, zihinlerde bir şeyler canlandırmak istedik. Umarız bir yerlerde bir ışık yakar!
İyi internetler,
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel buluşmalara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Nedir?
Faydaları ve zorlukları
Nereden başlanır ve nelere dikkat edilmeli?
Yararlı kaynaklar
Research repository, Türkçe’de henüz kabul görmüş bir karşılığı olmayan, çok da emin olamayarak “araştırma havuzu” olarak çevirip kullanmayı tercih ettiğim bir kavram. Anlamı şu: Organizasyondaki herkesçe yararlanılan ve beslenen, kullanıcı ile alakalı her türlü verinin (nicel, nitel, davranış odaklı, ihtiyaç odaklı) bir araya getirildiği, analiz edildiği ve anlamlandırıldığı alan ya da alanlar bütünü.
Bu ihtiyaç aslında tüm ürün odaklı organizasyonlarda var ve farklı farklı yöntemlerle yönetiliyor: Görece az sayıda kişinin bulunduğu yerlerde sözlü iletişimle aktarım çok daha ön plandayken, ürün geliştiren ekiplerin formunu bulmasıyla ürün yöneticileri ve ürün tasarımcıları bayrağı devralarak bu ihtiyaca çözüm olabilecek yazılı kaynaklar üretmeye ve süreçler oturtmaya başlıyor, ürün geliştiren ekip sayısının arttığı ve süreçlerin ölçeklenemediği noktada da DesignOps ya da ProductOps fonksiyonları bu görevi üstlenip ilgili süreçleri yönetiyor.
Fonksiyonlar arası sorumlulukların kırmızı çizgilerden arındığını ve daha iç içe yapılara dönüştüğünü, bu sırada da bilginin ve karar alma mekanizmalarının demokratize edildiğini hepimiz gözlemliyoruzdur. Özellikle bir ürün yöneticisinin bir tasarımcı ya da veri analistiyle paylaştığı alanlar ve kararlar gün geçtikçe çoğalıyor. Birçok öncü ürün şirketinin organizasyonel yapısını ya da üretip paylaştığı içerikleri incelediğimizde de görüyoruz ki bu araştırma havuzunun işler ve fonksiyonlar arası ortak çalışmaya dayalı olması, süreçlerinde önemli bir yer tutuyor. Araştırma havuzu ihtiyacına yönelik ve farklı alt çözümlere odaklanan bir sürü ürünün yakın zamanda parlaması ve kullanıcı odaklı ürün geliştirmenin daha da benimsenmesiyle pazar da hızla büyüyor: Önümüzdeki günlerde daha da sık konuşulacak bir konu olduğunu öngörebiliriz bu yüzden.
Bir araştırma havuzu oluşturmanın ve sürdürmenin çok belirgin faydaları olduğu gibi zorlukları da var. Bunları şöyle derledik:
Bilginin kaybolmaması ve ulaşılabilirliği: Bir organizasyondaki kullanıcılarla etkileşimde olan ekipleri düşünün: Satış, CS, Destek, kimi zamanlar Pazarlama, Ürün ekibi (ürün yöneticisi, tasarımcısı ve geliştiricisi).. Herkesin bu kullanıcılardan öğrendiği bir şey mutlaka oluyor ve bu öğrenilenler farklı farklı yerlerde kalıyor: Sunumlar, raporlar, toplantı notları, hatta zihinlerin içi. Ekip büyüdükçe ya da ekip üyeleri değiştikçe, hatta organizasyon ölçeklenirken kimsenin bu bilgileri paylaşmaya vakti olmadıkça bu bilgiler paylaşılamıyor ve bir anlamda kayboluyor. Ortak bir havuz yaratmak bu bilgiye herkesin eşit ölçüde erişebilmesini sağlıyor.
Zorluğu: Bu havuzu beslemeye vakit ayırmak hala bazı fonksiyonlar için zorlayıcı olabilir. Organizasyon genelinde ihtiyacı ve faydalarını aktarmak, yönetim ekibinin konuyu önemsemesi ve önceliklendirmesi, hatta teşvik etmek adına ilk kullanıcılardan biri olması bu anlamda önemli.
Tekrarlardan kaçınmak ve zamandan kazanmak: Ekipin hangi konuda, hangi kullanıcılarla görüştüğü ve ne gibi bilgiler edindiği görünür olunca aynı konulara odaklanmak yerine mevcut bilgiyi işlemek ve üzerine ne konulabilir’i düşünmek, planlamayı kolaylaştırırken operasyonel tekrardan da uzaklaştırıyor ve toplamda zaman kazandırıyor.
Zorluğu: Havuzu güncel tutmak ve devamlı bilgi akışını sağlamak gerekiyor ki tekrardan kaçınmak mümkün olsun.
Bilgiye dayalı karar alabilmek: Bilişsel ve duygusal önyargılar, ürün geliştiren ekiplerin farkında olması ve kontrol edebilmesi gereken önemli insani eğilimler (eski bir yazımızda bilişsel önyargıları konuşmuştuk). Kullanıcıları çok iyi tanıdığımızı ya da belirli bir probleme olabilecek en iyi çözümün kendi fikrimiz olduğunu düşünmek oldukça kolay. Bu ve benzeri türlü zorluğu konsensus yaratarak aşmanın tek yolu da somut veriyi analiz ederek karar almayı yaygınlaştırmak oluyor.
Desenleri keşfedebilmek: Kullanıcılar, geçmişleri, beklentileri ve ihtiyaçları arasındaki desenleri ve bağlantıları keşfetmek çok kolaylaşıyor çünkü organizasyon düzeyinde kategorize edilmiş bilgiyi katmanlar halinde tüketmek mümkün oluyor.
Zorluğu: Bu kategorizasyonu ve taksonomik yapıyı oluşturmak da, sürdürmek de başlı başına bir iş ve pek kolay değil. Kaynak ayırmak, devamlı gözlemlemek ve değişiklikler yapmak gerekiyor ki sistem ölçeklendikçe bilgiye erişilebilir olma hali devam etsin.
Devamlı keşfetmeye (Continuous Discovery) ve kullanıcı deneyimi odaklı hareket etmeye teşvik: Günlük tempoda operasyonel işlerden ya da birincil sorumluluklardan sıyrılıp, düzenli olarak kullanıcılarla görüşmek mümkün olmayabiliyor, özellikle de belirli bir soruya cevap aramayan kullanıcı görüşmeleri oldukça seyrek oluyor. Araştırma havuzu oluşturmanın ve devam ettirmenin motivasyonu kullanıcı odaklı ürün geliştirmek olabilir, ancak bu havuzun geliştiğini ve ekiplerce karar alma mekanizmalarında refere edildiğini gördükçe organizasyon içinde devamlı keşfetmeyi teşvik edeceği de kesin.
Hemfikir olmak: Organizasyondaki diğer departmanlarla, özellikle ürün geliştirmede payı olanlarla bu araştırma havuzuna ihtiyaç olduğuna dair teyitleşmek, karşı argümanları değerlendirmek ve sonuç olarak ihtiyaca hemfikir olmak gerekiyor.
Mevcut akışı dökümante etmek: Mevcutta organizasyon içinde kullanıcılara dair bilgiler nerelerden, hangi araçlar ve süreçler vasıtasıyla geliyor konusunu düşünmek ve dökümante etmek, öncelikli ihtiyaçları belirlemek ve genel bir egzersiz olması açısından faydalı oluyor.
Gereklilikleri netleştirmek: Mevcut akış üzerine bu araştırma havuzundan faydalanacak diğer ekiplerle konuşmak, geri bildirimlerini almak ve herkese yarayacak bir gereklilikler listesi çıkarmak ilerlemeyi kolaylaştırıyor.
Kullanılacak aracı belirlemek: Pazardaki türlü türlü araçları bu gereklilikler listesine göre test edip, en iyi sonuç alınan araca karar vermek ve diğer ekiplerden de kabul almak gerekiyor.
Pilot bir proje/özellik ya da segment belirlemek: Mevcutta üzerine çalışılacak bir proje ya da özellik varsa bunlardan birini seçmek, daha jenerik bir araştırma düzeni düşünülüyorsa da belirli bir segmentten bir kullanıcı grubuyla başlamak küçük adımlar atmak anlamında yardımcı olabilir. Bu süreç seçilen aracı test etmek için de faydalı oluyor.
Altyapıyı oluşturmak: Kimlerle ya da hangi konuda, hangi sıklıkta ve hangi periyotta araştırma yapılacağı netleştikten sonra bu araştırmanın yöntemini belirlemek ve yardımcı enstrümanları oluşturmak gerekiyor. Örneğin kullanıcı görüşmeleri yapılacaksa, not alma şablonları, görüşme rehberleri ve soru setleri hazırlamak hem sürece adaptasyonu hem de sonrası için verinin organizasyonunu kolaylaştırıyor.
Veri havuzunu besleyerek pilot sürecini tamamlamak: Araştırma boyunca ortaya çıkan türlü tipteki verileri havuzda bir araya getirmek, ortak desenleri yakalamak ve ölçülebilir bir rapor haline getirmek, pilot sürecini tamamlamak adına yeterli oluyor.
Başlangıç toplantısı: Organizasyon geneline bu araştırma havuzunu tanıtmak ve raporun üzerinden geçmek genel bir başlangıç yapmak adına önemli. Aynı toplantılarda sunulacak bilgiye nasıl ulaşılabileceğine ya da katkıda bulunabileceğine dair eğitim dökümanları hazırlamak, herkesin aynı noktada olmasını sağlıyor.
Farklı araştırmaları başlatmak: Pilot sürecinde öğrenilenler ve tüm ekiplerden gelen geri bildirimler sonrasında altyapı elden geçiriliyor ve farklı araştırma süreçlerini başlatmaya hazır olunuyor.
Düzenli ve geniş katılımlı raporlama toplantıları yapmak: Farklı araştırmalarla veri havuzu beslendikçe ilgili ekiplerle yapılacak periyodik raporlama toplantıları, araştırma sonuçlarını paylaşmak, üzerine fikir yürütmek ve gerekli değişiklikleri netleştirmek adına faydalı oluyor.
Süreci ölçeklendirmek: Havuza giren veriler çoğaldıkça veri analizine ve depolamaya dair izlenen yöntemleri ölçeklendirmek (global temalar, kodlar ya da taksonomiler oluşturmak gibi) ve tüm sürece yaymak adına standart akışları oluşturmak gerekli oluyor.
The Ultimate User Research Repository Checklist 2.0 – Link – Bir UX research tool’u olan EnjoyHQ’dan adım adım araştırma havuzu oluşturma rehberi.
User Research Repositories for Cross-Functional Teams (Video) – Link – Cambridge University Press’in CX Direktörü Eden Lazaness, araştırma havuzlarının nasıl farklı ekiplerin katkılarıyla beslenebileceğini ve konuyla alakalı deneyimlerini anlatıyor.
Documenting research findings at GitLab – Link – GitLab UX ekibinin araştırma süreçlerini nasıl yürüttüğü ve bulgularını nerede ve nasıl depoladığını anlatan döküman.
I built a user research repository — you should do the same – Link – Yapılabileceklerin adım adım anlatıldığı bir blog.
Atomic Research resources – Link – Atomik araştırma konseptine dair çeşitli kaynakların listelendiği bir döküman.
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayıda bir süredir üzerinde durduğumuz “Yeni bir özellik geliştirmek” yazı dizisinin üçüncü kısmı olan “Koordinasyon” konusuna geçtik (ilk iki kısım olan “Keşif” ve “Planlama”yla alakalı sayıların linklerini yazının sonunda bulabilirsin): Farklı farklı ekiplerle hangi durumlarda, hangi yöntemlerle koordine olunuyor anlamak, uzaktan çalışmanın koordinasyona etkilerini konuşmak istedik ve serinin diğer sayılarında olduğu gibi sözü topluluk üyelerimize bıraktık.
İyi internetler,
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel buluşmalara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Koordinasyon: Nedir?
Koordinasyon halkaları: Farklı ekiplerle koordine olmak
Uzaktan çalışma ve koordinasyon
Koordinasyon, Latince’deki “ordo, ordin” —yani “order” kökünden geliyor ve bu kökün anlamı da “düzenlemek, sıralamak” şeklinde. Günümüzdeki anlamı da bu köke yakın ve şöyle özetleyebiliriz: “Ortak bir amaca hizmet eden farklı fonksiyonların, kişilerin ya da ekiplerin birlikte çalışmalarını kolaylaştıran eylemler bütünü”.
Ürün yönetimi rolünün organizasyon içindeki en kritik görevlerinden biri farklı ekiplerin aynı hedef doğrultusunda çalışmasını, yani koordinasyonun devamlılığını sağlamak. Roadmap üzerine çalışırken, kullanıcı araştırması yaparken ya da ekip içi bir süreci iyileştirmeye çalışırken koordine olmak gerekliliği hep var, ama koordinasyonu sık ve aktif tutmak en çok yeni bir özellik geliştirirken gerekli oluyor: En değişken olan ve diğer tüm ekipleri de bu değişkenlik içinde güncel tutmanın gerektiği durumlar genelde bir özellik geliştirirken karşımıza çıkıyor. Biz de bu seride yeni bir özellik geliştirme sürecindeki koordinasyon üzerinde durduğumuzdan, keşif ve planlama adımları tamamlandıktan ve geliştirilecek özelliğin kapsamı netleştikten sonraki kısma özel olarak koordine olmayı ele alalım istedik.
☝️Yan okumalık: Bu sayıyı destekler bir konuyu, “Ürün/Özellik Durum Takibi” başlıklı önceki bir sayımızda da işlemiştik. Bir özellik üzerine çalışan kişilerin birbirleriyle, farklı ekiplerle ya da tüm organizasyon genelinde haberleşmesine yarayan fikirler ve yöntemleri konuşup, globalden de örnekler verdiğimiz bu sayıyı da tavsiye ederiz.
Yeni bir özellik geliştirirken ekip içinde ve ekipler arasında nasıl koordine olduklarını, herhangi bir değişiklik halinde nasıl hareket ettiklerini topluluk üyelerimize danıştık ve şöyle cevaplar aldık:
Özelliği geliştiren ekip üyeleri birbirlerinin yaptığı işlerden nasıl haberdar oluyor?
Uzaktan çalışmaya başladıktan sonra takım içi iletişim yolları da koşullara hemen ayak uydurdu. Öncelikle her sabah günlük toplantılarda takım üyelerinin üzerinde çalıştığı işleri ve ihtiyaçlarını konuşuyoruz. Günlük sabah toplantıları zaten uzaktan çalışmaya başlamadan da hayatımızın bir parçasıydı, sadece bunu video görüşmeye geçirmiş olduk.
Haftalık toplantılar ise haftanın planlaması, öncelikli işlerin kapsamının konuşulması ile geçiyor. Bu toplantıda genel tanımların üzerine konuşmakla beraber, teknik detaylar için kısa takip toplantılarını ilgili kişiler için ayarlayabiliyoruz. Planlama ve teknik detaylar hazırlanırken yazılı iletişim yerine görüntülü konuşmaların tercih edilmesi ve bu sırada iş dokümanlarında konuşulan önemli noktaların not düşülerek ilerlenmesi çoğunlukla iletişim sorunlarından bizi koruyor.
İlerlemeye engel bir blok olduğunda tercihimiz bunun günlük toplantılarda konuşulması ancak hiçbir sistem bu kadar mükemmel olamayacağı için anlık mesajlaşma ya da görüntülü iletişim konuyu hızlı çözmemize imkan sağlıyor. Bloklayan işler için ne kadar zamanda çözdüğümüzü takip etmeye çalışarak, takım veya konu özelinde en iyi iletişim sistemini kurgulamaya çalışıyoruz.
Gün içindeki anlık iletişimler için Slack kullanmanın yanında özellikle uzun toplantılar yerine 15 dakikalık konuşmalar ve peer-coding için Discord’u kullanmaya çalışıyoruz.
Her sabah yaptığımız stand-up/daily ile ekip üyeleri işlerden haberdar oluyor.
İletişimi daily ile sağlarken işin kapsamından çıkmamayı ise Confluence üzerinde işi dokumana çevirerek sağlıyoruz. Bu aynı zamanda daha sonraki çalışanlara yol gösterici oluyor.
Ekip içi iletişimi Slack ile sağlıyoruz, toplantı yapmamız gerekirse Google Meet veya Slack kullanıyoruz. İş takibi için de Atlassian ürünlerini kullanıyoruz (Jira ve Confluence). Retro için ise Figma, Miro gibi araçları kullanıyoruz.
Product Manager ve Product Owner’lar olarak haftalık toplantılar ile gelen işleri ve öncelikleri konuşuyor, fikir alışverişinde bulunuyoruz. Benzer bir toplantıyı squad içerisinde iş veya özellik netleştiğinde de yapıyoruz.
Satış, pazarlama gibi diğer ekipler ya da yönetim ekibiyle hangi konularda, ne sıklıkla, hangi yollarla iletişim kuruyorsunuz?
Pazarlama ve içerik ekipleri ile aylık düzenli toplantılarımız oluyor. Onların ihtiyaçlarını, yeni taleplerini dinleyip, olgunlaştırıp, roadmap üzerinde iki tarafı da mutlu edecek bir takvimde ilerlemeye çalışıyoruz. Google Meet ve Slack üzerinden iletişim kuruyoruz.
Yeni bir geliştirme aşamasının öncesinde olduğu gibi, geliştirme esnasında da düzenli olarak süreç hakkında ilgili paydaşları güncel tutmak gerekli. Çünkü başarılı bir ürün teslimatı, ancak hedef kullanıcıyı yeni özellikle en doğru şekilde buluşturarak mümkün olabilir. Bu ekiplerin en önemli ihtiyacı, yeni özelliğin en başta belirtilen zamanda hazır olmasıdır. Dolayısıyla proje süresince bu ekiplerle haftalık veya kapsamın boyutuna göre iki haftada bir toplantılar düzenliyoruz. Böylece herhangi bir gecikme durumu ortaya çıktığında hattın en sonunda yer alan paydaşlar hızlı bir şekilde haberdar ediliyor. İkinci olarak yeni sürümün canlıya alınması öncesinde bir email kampanyası, detaylı sürüm notları, ürün demoları, wiki sayfaları gibi pratiklere ihtiyaç duyuyoruz. Bunları organize edebilmek için yeni özellikle/projeyle ilgili ekiplerle yine haftalık/iki haftada bir toplantılar düzenleyerek görev dağılımının yapılmasını, gerekliyse email görselleri, yardım dokümanları gibi içeriklerin zamanında ve uygun hazırlanmasını sağlıyoruz. Bunları Jira, Asana gibi proje yönetim araçları veya Excel gibi basit araçlar üzerinden takip ediyoruz. Geliştirmenin canlıya alınması öncesinde, yine pazarlama ve satış ekipleriyle beraber demo seansları ayarlayıp canlıya alma tarihlerini netleştirip, her şeyin zamanında ve doğru şekilde, herkesin bilgisi dahilinde gerçekleştiğinden emin oluyoruz.
Stratejik toplantılar dışında, kendi deneyimimi göz önünde bulundurursam, ekip liderleri ile haftalık toplantıların olması ve birbirini etkileyen ekipler ile ortak iki haftada bir kontrol toplantıları olması süreçlerin sağlıklı bir şekilde ilerlemesi için yeterli oluyor. Ancak toplantı sıklığı kesinlikle her ürün takımı ve diğer paydaşlar arasında konuşularak deneyimlere göre düzenlenmesi gereken bir konu. Maalesef ürün yönetiminde konuşabileceğimiz mutlak tek bir doğru yok, takımlar ve ürünün dinamiğine göre çeşitli sıklıklar denenebilir.
Toplantıların uzamaması, sıklığının artmaması için anlık iletişime önem verilmesi gerektiğini düşünüyorum. Özellikler ekiplerin ortak Slack kanallarının olması, ürünle ilgili anlık soruların orada sorulması, konuların kısa sürede çözülmesine katkı sağlıyor.
Ürün istekleri veya takibi için ise Slack gibi yazılı kanallar yerine ürünü yönetirken kullanılan organizasyonel araçların üzerinden istek ve takip yapılması daha sağlıklı bir yaklaşım diyebiliriz.
Zaman planının ya da özelliğin kapsamının süreç boyunca değiştiği oluyor mu? Bu konuda iç ve dış ekiplerle nasıl koordine oluyorsunuz?
Tüm planlarınızı yeni geliştirmenin başta belirlenen zamanda kullanıcıyla buluşturulması için yapsanız da, bazen gecikmeler ve değişiklikler kaçınılmaz oluyor. Bunun çeşitli sebepleri olarak öngörülemeyen entegrasyon sorunları, kapsam değişiklikleri, diğer takımlara olan bağımlılıklar ve bunlardan kaynaklanan aksamaları sayabiliriz. Eğer özelliğin kapsamında bir değişiklik söz konusuysa, ilk olarak müşteri ve geliştirme ekibiyle koordine olunması gerekiyor. Geliştirme ekibiyle yapılan günlük scrum’larda paylaşılabileceği gibi, boyuta göre daha kapsamlı bir toplantı da oluşturulabilir. Eğer müşteriniz bir iç paydaşsa direkt ilgili ekiplerle, dış paydaşsa da satış, pazarlama ve müşteriyle direkt olarak kapsam değişikliği paylaşılıyor. Bu değişikliğin ürün roadmap’ine ve sıradaki projelere/geliştirmelere olan etkisinin ortak olarak tüm paydaşlara doğru şekilde iletilmesi gerekiyor. Tüm bunlar için bir önceki soruda bahsetmiş olduğum periyodik toplantılar kullanılabileceği gibi durumun aciliyetine göre pop-up toplantılar da gerekebilir.
Tüm geliştirme ekiplerini ilgilendiren bir konu ise öncelikli olarak Slack ya da email yolu ile bildirim veriyoruz, detaylı iletişim veya destek gerektiren bir değişiklik ise kısa bir toplantı ayarlayarak ilgili ekiplere durumu detaylıca aktarıyoruz.
Pandemi süresince çoğumuzun önceden bu ölçüde deneyimlemediği bir koordinasyon ihtiyacı oluştu. Topluluk üyelerimize bu süreçte koordine olurken yaşadıkları zorlukları ve aldıkları önlemleri sorduk:
☝️Yan okumalık: “Pandemide uzaktan çalışmak” sayımızda da bu konuyu irdelemiş, olası problemleri ve çözüm önerilerini konuşmuştuk.
Uzaktan çalıştığınız dönemde koordine olurken en çok nerelerde zorlandınız? Bu zorlukların üstesinden nasıl geldiniz?
Şimdiye kadar deneyimlediklerimden yola çıkarak söyleyebilirim ki, otonominin yüksek olduğu takımlarda uzaktan çalışırken koordinasyonda çok büyük sorunlar oluşmuyor. Özellikle mikro yönetim ile ilerleyen takımların bu konularda zorluk yaşadığını söyleyebilirim, o yüzden öncelikle öğrenmemiz gerek şey takım içinde şeffaflık ve güveni yükseltmek, böylece sorumluluk bilinci oluşturmak.
Uzaktan çalışırken toplantı yoğunluğundan pek çok kişi işlerine odaklanamıyor, bu yüzden toplantı saatlerini mümkün olduğunca kısıtlı tutmayı amaçlayarak, iyi planlamanın yanında anlık iletişim yollarını kullanmayı tercih ediyoruz. Benim görüşüme göre toplantı konularının iyi ayarlanması ve her konuya belli bir zaman ayrılması çok önemli. Ayrıca 60 dakikalık toplantılar yerine maksimum 50 dakikalık toplantılar ayarlanması ve eğer takip toplantısı yapılması gerekiyorsa, toplantı aralarına 10-15 dakikalık molalar koyulması insanların hareket etme, hava alma ve kendini bir sonraki toplantıya hazırlaması için önemli oluyor.
Biz takım içinde uzaktan çalışma koşullarının sadece işi nasıl etkilediğini değil, insanlar üzerinde nasıl zorluklar yaratabileceğini konuşarak ve bunlara çözüm bulmaya çalışarak ilerliyoruz. Çünkü pek çok açıdan çalışan için daha rahat imkanları olsa da, uzaktan çalışma koşulları çalışanlar üzerinde sürekli müsait olma, belli bir saati doldurana kadar çalışma gibi baskılar hissettirebiliyor. Benim görüşüme göre takım çalışması için önemli olan doğru iletişim ve planlı çalışma olmalı ve çalışanın kendi gününü planlaması için mümkün olduğunca alan bırakılmalıdır, ancak bu durumda gerçek verimlilik görülebilir.
Uzaktan çalışma döneminde en çok zorlandığımız konu çok detaylı ve kapsamlı bir özellik geliştirirken ekibin aynı noktada olmadığını fark ettiğimiz zamanlar oldu. Bunun için hali hazırda yaptığımız iş netleştirme/olgunlaştırma toplantılarına ek daha detaylı dokümantasyon yazmaya başladık. Bu işin bitiminde çıkabilecek farklılıkların önüne geçmemize olanak sağladı.
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayıda bir süredir ne olduğunu araştırdığımız “Product-Ops” rolüne biraz daha yakından bakmak ve sizlere de anlatmak istedik: Nedir ve ne değildir, ne zaman ihtiyaç duyulur ve ne gibi sorumlulukları olur, organizasyona faydaları nelerdir gibi konulardan bahsedip, yararlı kaynakları da her zamanki gibi sayının sonuna ekledik.
Not: “Yeni Özellik Geliştirmek” serimize önümüzdeki sayı “Koordine Olmak” adımıyla devam edeceğiz, beklemede kalın! 🥁
İyi internetler,
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Nedir, ne değildir?
Sorumlulukları ve faydaları
Yararlı kaynaklar
Product Ops, ProdOps ya da yaygın olmasa da Türkçesiyle Ürün Operasyonları, ürün yönetimi dünyasında görece yeni bir alan. Aşina olduğumuz ve benzer işlevleri olan DevOps, SalesOps, DesignOps gibi alanlardan daha yeni gibi duruyor, çünkü konunun internette ilk dile getirildiği zamanlar ancak birkaç sene öncesine kadar gidiyor.
ProdOps’un (bu bir kişi ya da bir ekip olabilir) en temeldeki işlevi bir organizasyon içindeki ürün yönetimi süreçlerini standartlaştırmak ve ölçeklemek. Bunu da aslında o organizasyondaki ürün ekiplerinin kullanacağı bir iç-ürün geliştirmek gibi düşünebiliriz: Bu ekiplerin nelere ihtiyacı var, nerelerde zorlanıyorlar öğrenmek, bu ihtiyaçları önceliklendirmek, çözümler üreterek/bularak kullanıma sunmak ve onboarding yapmak, sonrasında da geri bildirimler alarak iyileştirmeler yapmak gibi ürün yöneticilerinin ürüne dair sorumluluğu olan adımları, ProdOps’çular bu ürün yöneticileri için yapıyor. Her organizasyonun ürün yönetişi farklı ve doğalı da bu olarak görülüyor; ancak ortak görüş bir organizasyon içindeki ürün yönetiminin, orada çalışan ürün yöneticilerinin kişiliklerine ya da bireysel tercihlerine bağlı olmaması ve kişilerden bağımsız, sürdürülebilir ve istikrarlı olması gerektiği yönünde.
Görece küçük organizasyonlarda ProdOps işlevini ürün ekiplerini yöneten tecrübeli kişiler, ekibe sağladıkları koçluk ve yönlendirme ile süreçleri tanımlayarak görüyorlar. Ancak tüm ekip büyüdükçe, ki bu büyüme çeşitli kaynaklarda 5-6 ürün geliştirme ekibine ulaşmak olarak konuşuluyor, her ekibin girdilerini edinme ya da çıktılarını sunma şekli farklılaşmaya başlıyor ve bu ekiplerin birbirlerini güncel tutmaları ya da yönetim ekibinin olan biteni takip etmesi zorlaşmaya başlıyor. Yani aslında her ekip aynı kaynakları kullanarak benzer çıktılar üretiyor, ama ekipler arası ya da yönetim ekibiyle koordine olmak ve iletişim kurmak gibi kısımlar, bu çıktıları üretmekten daha çok vakit almaya başlıyor. Bu noktada ürün geliştirmeyle alakalı aşağıdaki gibi sorulara dair standartları tanımlamak gerekli hale geliyor:
Hangi durumlarda, hangi araçlar/şablonlar, hangi pratiklerle/metodlarla kullanılıyor, bu kullanımlardan neler öğrenildi ve tüm ekibin işini en çok kolaylaştıranlar hangileri oldu?
Hangi nicel/nitel veriler nerelerde ne amaçlarla tutuluyor, yeni bir özellik geliştirirken bu verilere nasıl ulaşılabilir ve canlıya alınan özelliğe dair metrikler nerelerden takip edilebilir?
Ekibe yeni biri katıldığında bu süreçlere en hızlı nasıl adapte olur, bu adaptasyon sürecine nasıl iyileştirmeler yapılabilir?
ProdOps’un en çok karıştırıldığı rol olarak Program Management konuşuluyor. Yüzeysel benzerlikleri olan bu iki rol şu noktada farklılaşıyor: Program Manager’lar organizasyon içindeki farklı farklı ekiplerin aktif rol aldığı çok büyük ölçekli projelerin/özelliklerin yönetimini yapıyorlar, yani aslında Proje Yönetimi’nin ölçeklenmiş versiyonu diyebiliriz. ProdOps’çular ise tüm proje ve özellikler için ortak bir kaynak olarak konumlanıyor ve işlevleri bu süreci yönetmek değil, süreç içindeki karar alma mekanizmalarında ihtiyaç duyulan girdiyi ve yardımı sağlamak ve bu girdileri standart hale getirerek ölçeklemek.
Aslında rolün ne olduğunu konuşurken “süreçleri standardize ederek iyileştirmek ve ölçeklendirmek” gibi bir tanımla sorumluluklarından ve faydalarından da bahsetmiş olduk, ancak biraz daha farklı açılardan yaklaşırsak aslında ProdOps’un şu gibi faydaları da var:
PM ekibine vakit kazandırmak: Süreçleri standartlaştırmanın en büyük artısı PM ekibine vakit kazandırmak olabilir. Buradan ProdOps rolü PM rolünün alanına giriyor gibi anlaşılacak olabilir, ama aslında ProdOps bir destek fonksiyonu ve bunu da PM ekibine gerekli zamanlarda (hem istek halinde, hem de proaktif olarak) veri, içgörü ve yol göstericilik yaparak sağlıyor. Herhangi bir özellik geliştirirken bu özellikle hangi kullanıcıların ilgileneceğini, bu kullanıcıların nasıl iletişmeyi tercih ettiklerini ve ürününüzle ya da ekibinizle olan geçmişini hızlı bir şekilde görebildiğinizi düşünün. Ya da belirli konularda diğer ekipleri bilgilendirmek için neredeyse otomatize edilmiş bir bilgi akışı sisteminizin olduğunu. Ekibin ihtiyaçlarına göre hangi araçlar hangi şekillerde kullanılabilir, diğer ekipler yeni özellikler konusunda nasıl onboard edilebilir ve benzeri destek noktaları da ProdOps’un ilgilendiği bazı örnek konular oluyor.
Birilerinin süreçler üzerine dedike çalışıyor olması: ProdOps ekibinin ilgilendiği bir başka konu da süreçleri tanımlamak, iyileşme noktalarını bulmak ve iterasyonlarla iyileştirmeler yaparak yaşayan bir yapı olmasını sağlamak. Bunları yeni gelen ekip üyelerine anlatmak ve işleyişe dahil olmalarını hızlandırmak da yine sorumluluklarından biri. Bu sayede tüm ekip aynı dili konuşabiliyor, aynı yöntemlerle benchmark yapıyor ya da aynı şablonlarla çıktılarını sunuyor. Organizasyon büyüdükçe, ekip kalabalıklaştıkça ve süreçler eskisi kadar verimli olmamaya başladıkça da bu sistemi devamlı gözleyen ve gerekli adımları atan birilerinin olması büyük kolaylık oluyor.
The rise of Product Ops – Link – Pendo’dan ProdOps rolünün sorumlulukları, etki alanı ve organizasyona ne gibi katkıları olduğuna dair bir e-kitap.
Product Operations 101 – Link – Shopify ProdOps ekibinin bir üyesi, Shopify’da bu rolün ne yaptığını ve bu alana nasıl giriş yapılabileceğini anlatıyor.
Do you need Product Operations?! – Link – Pendo, InVision, Simplifeye gibi organizasyonlarda ProdOps’çuların yaptıklarını özetleyen bir blog.
Team Ops and Product Ops: The Perfect DesignOps Pair – Link – Salesforce Design ekibinden, DesignOps rolünü nasıl Team Ops ve Product Ops olarak ikiye böldüklerini ve birlikte nasıl çalıştıklarını anlatan bir blog.
Batuhan Apaydın ile Startuplar için Pazarlama, İçerik ve Distribution – Buradan dinleyin
Akar Şümşet ve Aslı Sevinç Daver ile ATÖLYE nasıl üretiyor? – Buradan dinleyin
Burak Boğaçhan Doğan ile Shopside’in Serüveni – Buradan dinleyin
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Birkaç hafta önce Eran’la konuşurken tesadüfen bültenin 26. sayısında olduğumuzu ve 52 haftadır, yani tam bir yıldır aksatmadan iki haftada bir yeni bir sayı çıktığımızı fark ettik. Böyle bir cümlede yazınca çok bir şey ifade etmiyor ama son bir senede pandemidir, türlü türlü gündelik dertlerdir aklıma gelen her şeyi bir film şeridi gibi gözümün önünden geçirince bültene verdiğim emeği ve bu emeği ne kadar çok sevdiğimi bir kez daha fark etmiş oldum.
Bu sayıda da biraz bültenin kendisine dair konuşalım istedim bu yüzden: Ben nasıl Üretim Bandı ekibine dahil oldum, düzenli yazmak bana nasıl katkı sağladı, kaç yazıyla nelerden bahsettik, kimler bize nasıl destek oldu, nerelere gitmek istiyoruz, okurlarımız neler hissediyor hepsini bir araya getirelim ve geriye güzel bir birinci yıl anısı bırakalım diye. Umarız bu bir senede küçük de olsa iş yapış şekillerinize, düşünme biçimlerinize, farklı bakış açıları geliştirmenize yardımcı olabilmişizdir.
İyi internetler,
Burcu
Eran’ın notu:
Bundan yaklaşık bir sene önce, Üretim Bandı’nı bir podcast’ten daha fazlasına, bir öğrenme platformuna çevirmeye karar verdiğimde aklımda birkaç konu vardı: Üretim Bandı dinleyecileri ile iletişimi nasıl arttırabiliriz, podcast dışında farklı içerik türleriyle kapsamımızı genişletebilir miyiz? Bunların ikisine de çok güzel bir giriş yaptık. Slack topluluğumuz 1300 kişiye yaklaştı, bültenimiz ise özgün içerikleriyle 800’e yakın aboneye istikrarlı bir şekilde dolu dolu bilgiler sunuyor.
Bültenin birinci senesini tamamladığımız bu günlerde geriye bakıp misyonumuzu başarıyla devam ettirdiğimizi görmek beni çok mutlu ediyor. Üretim Bandı ekip üyeleri olarak amacımız hep aynı —ürün geliştirme ve şirket yönetimi konularını farklı bilgi kaynaklarından öğrenmek. Aslında biz içeriği üretenler olsak da bunlar bizim öğrenme yolculuğumuzun bir parçası. Burcu sayesinde bu yolculuğa çok önemli bir parça daha eklenmiş, ana misyonumuz genişlemiş oldu. Bültenin ileride daha da gelişeceğine, katkısının hem bize hem siz okuyanlara giderek artacağına inancım tam. Bu yolculuğa katıldığınız için teşekkürler.
Üretim Bandı’nı seneler seneler önce, Eran’ın Kolektif House Sanayi’de düzenlediği bir PM Istanbul meetup’ında keşfetmiştim. Çalıştığım organizasyondaki tek ürün yöneticisiydim ve birilerinden bir şeyler öğrenmek için kıvranıyordum, Eran da sağolsun her zamanki gibi topluluğa faydalı olma gayretiyle tam da bu konuya parmak basıyordu. Etkinlikte sunumlarıyla deneyimlerini paylaşan insanlar bir karşılık beklemeden oradaydılar, bütün akşamlarını bize ve sorularımıza ayırdılar. O gün “insanlar neler neler biliyor, nasıl güzel konuşuyor ya” diye hevesle oturumları izledim ve düşündüm ki “öğrenmenin önemli bir parçası bildiklerini paylaşmak”.
Bu düşünce aklımda iyice yer etmeye başlayınca ben de aslında yazı yazmayı, araştırıp öğrendiklerimi yazı yoluyla paylaşmayı ve herkes için kalıcı hale getirmeyi istediğimi fark ettim. Eran’la bunun üzerine konuştuk, “Gel bizim ekibe katıl” demesiyle de kolları sıvayıp 23 Haziran 2020’de ilk sayımızı paylaştık.
O günden bu yana her iki haftada bir “bu ara neler konuşuluyor”, “ben ne öğrenmek istiyorum” diye düşündüm, Eran’la bu konu üzerine sohbet edip bildiklerini öğrendim, internet taramalarıyla konuyu iyice anladım, anladıklarımı yazdım, farklı farklı ürün yöneticileriyle tanışıp onların bilgilerini toparladım ve bu sayıları tamamladım. Bülten olmasaydı “internet taramalarıyla konuyu iyice anladım”dan fazlasını yapmazdım. Yazmak temelde bir iletişim şekli ve insan yazdıkça gelişiyor ve öğreniyor; üzerine sorgulama, araştırma, benzer akıllarla bir araya gelme, süreklilik, odaklanma gibi beceriler ve imkanlar da eklenince düzenli yazı yazma isteğim aslında bana hiç aklımda olmayan bir sürü şey kattı.
26 sayıdır bültende türlü türlü konudan bahsettik: Önceliklendirme, strateji, 1:1 görüşmeler ve geri bildirim vermek, işe alım kültürü, personalar, segmentasyon ve kullanıcı araştırmaları, içgörüler ve bilişsel önyargılar, farklı rollerle kesişen ve ayrışan noktalar, son olarak da yeni bir özellik geliştirmek serisi… Önceleri belirlediğimiz konuya dair sohbet havasında bildiklerimizi paylaştık, sonradan o konular üzerine çalışan topluluk üyeleriyle mini röportajlar yapmaya başladık, şimdi de röportajlı yazı dizileri var.
Formatı hala zaman zaman değiştiriyoruz ama niyetimiz hep aynı, “bilen birinden öğrenmek”. Bu motivasyonla da bültene devam edeceğiz. Bu yıl için Üretim Bandı ekibi olarak yeni hayallerimiz var, bilginin evrenselliği üzerine. Umarım bu hayallerimizi de gerçekleştirebiliriz.
Okuyucularımız bize hep destek oldular sağolsunlar: Hem bültenin okunduğunu gördükçe motive olduk ve devam etme gücü bulduk, hem de aynı okuyucular kolektif bilgiyi arama vizyonumuza kendi fikirleriyle dahil oldular ve sayelerinde bülten çok sesli, farklı bakış açılarını bir araya getirebilen bir platform oldu.
Fikirleriyle bize destek olan, mini röportajlarla sorularımızı cevaplayan okuyucularımıza ayrı ayrı teşekkürler (ilk sayıdan itibaren, sayıların yayınlanma zamanına göre): Mert Aktaş, Aykut Bal, Mustafa Büyükkara, İrem Yetener, Görkem Çetin, Burak Alparslan, Alican Bektaş, Elif Bektüzün Küçüksöz, Can Ülker, Çağlar Bozkurt, Murat Gölcü, Melih Özbekoğlu, Serkan Baydın, Bertuğ Oymak, Sertaç Pıçakçı, Berna Aksoy, Muharrem Derinkök, Rıza Selçuk Saydam, Seda Elibol, Gizem Belen Akgüney, Onur Yılmaz, Çağatay Tanyıldız, Zafer Sever, Nazlı Danış, Berkan Ünal, İrem Çilingir, Ecem Keskin, Emrah Şamdan, Aybüke Kayacı, Merve Artukarslan, Eslem Aykutluğ, Nihan Demirkazıksoy, Ahmet Ertaş, Selen Kozanoğlu ve Özge Yağlı.
Bültenle alakalı duygu ve düşüncelerini sorduğumuz bazı okurlarımızdan aldığımız, anısı kalacak mesajlar da şöyle:
Can Ülker:
Ürün yönetimi ile ilgili kaliteli Türkçe içeriği bülten ile Üretim Bandı ayağımıza getiriyor. Her zaman dayanışma odaklı, topluluğu dahil ederek üretilen bu içeriğin ekosistemimize ve mesleğimize faydasının uzun vadede daha da fazla anlaşılacağına eminim, ellerinize sağlık Üretim Bandı ekibi 🙂
Şeyda Öztürk:
En tatlı sabahlar Üretim Bandı Bülten ile başlar 🚀🌞 Son zamanlarda bültenlerle şöyle bir bağ kurmuştum, paylaşmak istedim:
Tam ürün ekibimiz ile bir konu üzerine şu nasıl olur, nasıl daha iyi yapabiliriz gibi bir başlık üzerine konuşmalar yaparken hemen ardından bülten yayınlandığında hep benzer konular denk geldi ve bültenden aldığım fikirlerle konuyu destekleyebildim/farklı fikirleri gördüm/diğer farklı uygulamaları keşfedebildim. 🙏 O yüzden başta Burcu’ya ve diğer katkı sağlayan tüm kişilere teşekkürler 🎉
Giray Batıtürk:
Selam Üretim Bandı! Çok güzel ve faydalı içerikler yapıyorsunuz, bu yolda lütfen devam edin. Okuyucuların da yapabileceği şeyler var ise mutlaka bizlerden isteyin. İstemenin gücü önemli 🙂
Nasuh Akın:
Hemen hemen tüm bölümlerini dinlediğim, uzun süredir takipçisi olduğum Üretim Bandı’nın bültenleri de podcast’ler kadar iddialı. Okumaktan çok keyif alıyorum. Sürekli yeni şeyler öğreniyorum, öğrendiklerimi pekiştiriyorum. Konu ile alakalı topluluk üyelerinin yorumları ve yararlanılan kaynaklar ise paha biçilemez.
Daha nice güzel yaşların olsun Sevgili Bülten.
Uzun bir seneyi olabildiğince özetleyerek, neler yaptık neler yapacağız’ı size anlatmış olduk. Umarım 2. yaş sayımızı da seneye aynı zamanlarda yazar, sizlerle yine aynı mutlulukla paylaşırız. Desteğiniz için çok çok teşekkürler!
Not: Bilgiyi yaymayı unutmayın ve geri bildirimlerinizi lütfen eksik etmeyin! Slack’ten ya da bu maile cevap vererek bize ulaşabilirsiniz. 📬
Bültene hoş geldin 👋
Bu sayıda geçen sayı başladığımız “Yeni bir özellik geliştirmek” yazı dizisinin ikinci kısmı olan “Planlama” konusuna devam ediyoruz. Konuyu “Akış” ve “Gereksinimler” temaları altında iki ayrı sayıda inceleyeceğiz demiştik, ve bu sayının konusu bu yüzden “Planlamada gereksinimler”: Gereksinim nedir ve neden önemli, içeriği ne ve nasıl oluşturuluyor, diğer fonksiyonlarla beraber planlama yaparken bu gereksinimler üzerine nasıl hemfikir olunuyor gibi konular üzerine kafa yorduk ve topluluk üyelerimizden fikirlerini aldık. Umarız sizde yeni fikirler oluşmasına vesile oluruz!
İyi internetler,
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel buluşmalara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Gereksinimler: Nedir?
Planlama süreci: Gereksinimleri Aktarma ve Hemfikir Olma
Gereksinimler özetle ürün geliştirme süreçlerinin standart bir parçası haline gelmiş, özünde geliştirilecek ürünün/özelliğin detaylarını belirlemeye ve ekipler arasında tektipleşmiş bir biçimde aktarmaya yarayan bilgiler bütünü olarak tanımlanabilir. Bu araçlar planlama öncesinde ya da sırasında ortaya çıkan detayları yazılı ve görsel olarak dökümante etmeyi sağlıyor ve organizasyonlar arasında farklılaşsa da genel olarak bazı temel noktaları barındırıyor.
Önceki sayılarımızdan “Ürün Gereksinimleri Dökümanı (Product Requirements Document, PRD)”nda gereksinimlerin öneminden, faydalarından ve zorluklarından bahsetmiştik ve hem globalden, hem topluluk üyelerimizin deneyimlerinden hareketle örnekler paylaşmıştık. Bu sayıda tekrara düşmemek için daha çok bu gereksinimlerin aktarım şekillerini ve ürün yönetimi ekiplerinin organizasyondaki diğer fonksiyonlarla ortak çalışma yollarını anlamak istedik ve sözü topluluk üyelerimize bıraktık.
Topluluk üyelerimize gereksinimleri aktarırken izledikleri yöntemleri, kullandıkları araçları, bu gereksinimlerin içeriğini ve diğer fonksiyonların içeriğe olan katkılarını sorduk ve şöyle cevaplar aldık:
1. Gereksinimleri aktarma yönteminiz ne oluyor?
Gereksinimleri aktarma yöntemi olarak genellikle yapılandırılmış bir prosedürü takıp ediyorum. Öncelikle kullanım senaryolarını (use cases) belirgin bir şekilde ayrıntılı olarak yazıyorum. Bunun için daha önceden yaptığım kullanıcı görüşmelerinden faydalanıyorum. Daha sonra bütün menfaat sahipleri ile görüşerek kullanım senaryolarını anlatıyor ve onların sorularını cevaplıyorum. Kullanım senaryoları ve amaç anlaşıldıktan sonra menfaat sahipleri ile sorumluluklar ve zaman çizelgelerini belirliyoruz. Riskli durumlar varsa risk analizi yapıyoruz. Çalışmaya başlamadan önce dökümanlar bütün menfaat sahipleri ile paylaşılıyor ve ürün üzerinde çalışmak için onay alınıyor.
Gereksinimlerin belirlenmesi ve geliştirme sürecine dahil edilmesi pek çok adım içeriyor. Gereksinimler paydaşlardan gelebileceği gibi, bizim tarafımızdan veri analizleri ve geri dönüşlerin değerlendirilmesi ile de geliştirme sürecine alınabiliyor. Gereksinimler her çeyreğin yol haritası üzerinden iletilebilir veya mevcut sprint içerisinde ek gereksinimler ortaya çıkabilir. Bu gereksinimler bir önceki sprint başında product owner ekibi tarafından öncelik durumuna göre değerlendirilmek ve bir sonraki sprint planına alınabilmek üzere paylaştırılır. Her product owner gereksinimin detaylarını araştırır. Bu araştırma süreci; benchmarking, paydaşlarla gereksinimin detaylarını inceleme ve bağımlılıkları yönetme, tasarımların netleştirilmesi ve geliştirme kısıtlarına uygunluğunun kontrol edilmesi, geliştiricilerle ilgili servis ve iş akışlarının değerlendirilmesi, gereksinimin aciliyetinin ve teslim edilme sürecinin incelenmesi gibi durumların tamamını kapsar. İlgili gereksinimler bütünü, tüm detaylar netleştirildikten sonra bir sprint içerisinde teslim edilebilir boyutlarda olacak şekilde user story’lere paylaştırılır. User story’lere bölüştürülmüş gereksinimin detayları her sprint öncesinde geliştirme ve QA ekipleriyle konuşulur ve işlerin tahmini eforları sayısal puanlama üzerinden belirlenir. Oy çokluğu ile efor belirlendikten sonra gereksinim öncelik durumuna göre sprint’e dahil edilir. Ekip içerisinde işin detayları product owner’ın işi anlattığı ve tüm soruların cevaplandığı kick-off toplantısıyla tekrar netleştirilir. Kontrat (Backend ve client ekibi arasındaki servis detaylarının netleştirilmesi) yapıldıktan sonra iş geliştirici tarafından çalışılmaya hazır olur.
2. Bu sırada hangi araçları kullanıyorsunuz?
Kullandığımız toollar ihtiyaçlara göre dönemsel olarak değişiklik gösterebiliyor, son dönemde aktif olarak kullandığımız toollar:
Miro: Taleplerin etkilediği ekranlar ve bu ekranlar arasındaki akışların gösterilmesi, benchmarking çalışmalarının paylaşılması, bütün paydaşların yorumlarıyla katılım sağlaması gibi talebin genel detaylarını oluşturan öğeleri bir arada görmek ve değerlendirmek için Miro’yu kullanıyoruz.
Asana: Paydaşlardan gelen taleplerin yönetimi, Product Owner’lar arasındaki iş birliğini ve genel talep takibini sağlamak için Asana’yı kullanıyoruz. Bu süreç için tool kullanımı ekipten ekibe göre değişebiliyor, Mobil ekip olarak biz Asana’yı tercih ediyoruz.
Zeplin: UX ekibinin hazırladığı ekran tasarımları için Zeplin’i kullanıyoruz.
ProtoPie: UX ekibinin hazırladığı tasarımlar üzerindeki etkileşim demolarının gösterilmesi için ProtoPie kullanıyoruz.
Jira: Gereksinim detayları finalize edildikten sonra talebi user story formatında ekibe aktarmak için Jira’yı kullanıyoruz.
Slack & Google Meet: Gereksinimleri ekibe aktarmak için toplantıları Slack ya da Google Meet üzerinden organize ediyoruz.
Genellikle Google Sheets, Google Docs, Figma ve Jira kullanıyoruz.
3. Gereksinimlerin içeriği ne oluyor?
İşi detaylandırdığımız user story’ler için belli bir taslak kullanıyoruz ve bu taslak içerisinde şu 3 ana başlık yer alıyor:
Context: Taslak yapısının ilk elementi olarak Context bölümü bulunuyor. İşi yapacak ekibe ve tüm paydaşlara anlamlı bir anımsatıcı olması için user story’nin çıkış hikayesini ve kapsamını bu başlık altında iletiyoruz.
Assumptions: Bu bölüm ile user story’nin tamamlanması için gerekli maddeleri listeliyoruz.
Geliştirilecek özelliğin beklenmedik durumlarda açılıp/kapanabilme yeteneğinin kazandırılması isteniyorsa Toggle bilgilerini maddeler arasına ekliyoruz.
VoiceOver ve TalkBack (Accessibility) özellikleri için gerekli bilgileri detaylandırıyoruz.
Tasarım gerektiren bir iş ise mutlaka Zeplin linkini ekliyoruz.
İlgili user story için yük testi ihtiyacını takımla görüşüp netleştiriyoruz ve bunun sonucuna göre Assumptions maddeleri arasına yük testi gerekliliğini ekliyoruz.
Servis yenileme ya da data tanımlama işi ise servis kontratlarını ekliyoruz
İş kapsamının ve diğer detayların çalışıldığı bir Miro board’u mevcut ise o board’u linkliyoruz.
Başka bir iş ile alakalı herhangi bir bağımlılık varsa o bağımlılığı belirtiyoruz. Bağımlı işleri birbirine linkleyerek ilişkilendiriyoruz ve işlerin takibini sağlıyoruz.
Acceptance Criteria: Son adım olarak belirlenen kapsamı doğrulayacak kabul kriterlerini ekliyoruz.
Özetle şu ana başlıkları takip ediyorum:
Kullanım senaryoları,
Amaç,
Başarı kriterleri,
Tasarım spesifikasyonları,
Kullanıcı görüşmeleri özeti
Teknik detaylar,
Eğer tamamiyle yeni bir konsept veya birçok özelliği bulunduran bir ürün ise, press release de yazabiliyorum.
4. Her bir fonksiyonun bu içeriğe nasıl katkısı oluyor?
Aslında her birimin görev tanımı ve tecrübeleri doğrultusunda içeriğe optimum seviyede katkıları oluyor. Product ekibi olarak, bu katılımın istenen seviyede olmasını sağlayacak yönlendirmelerin yapılması ve koordinasyonun sağlanması için aktif bir rol alıyoruz. Bu süreci özetlemek gerekirse;
Talep sahibi, ihtiyacı ve talebi iletiyor. Bu paydaş, bazı durumlarda teknoloji dışından bir birim, bazı durumlarda ise teknoloji bünyesindeki diğer ekipler olabiliyor. Bu aşamada doğru sorular ve yönlendirmeler ile gereksinimler şekillenmeye başlıyor. İhtiyacın sağlıklı bir şekilde adreslenebilmesi açısından en kritik süreç bu adımda gerçekleşiyor. İhtiyaçları nitel formdan nicel forma doğru evirmeye çalışıyoruz ve bunu sağlamak için gerekli aksiyonları belirliyoruz.
İhtiyaçlar netleştikten sonra Miro’da bir board oluşturup; elimizdeki doneleri ve ihtiyaç duyulan akışlar, metrikler, yorumlar, kurallar gibi bilgileri bu boardda topluyoruz. Sürecin devamı da bu board üzerinden ilerliyor.
UX ekibi ile ihtiyacı tartışıp, kullanıcı deneyimine karar veriyoruz ve çıktı olarak; arayüz tasarımları ve etkileşimler için gereksinimleri gösteren/anlatan çalışmaları alıyoruz. Deneyime ve etkileşimlere karar verme süreci bazen sadece bir toplantı ile mümkün olabilirken, bazen de araştırma, benchmarking, data toplama vb. çalışmalardan oluşabiliyor.
Bu noktaya kadar elimizde olan doneler çerçevesinde, geliştirme ekibiyle bir grooming session düzenliyoruz. Bu session’da işin teknik boyutunu değerlendiriyor ve izleyeceğimiz yönteme karar veriyoruz. Tabi her şey, her zaman bu kadar pürüzsüz ilerlemiyor ve çıkmaza girdiğimiz noktalar da oluyor. Bu gibi durumlarda ise, ilgili paydaşların yer aldığı (pazarlama, geliştirme ekibi, UX vb.) bir oturum daha düzenliyoruz ve geldiğimiz noktayı değerlendiriyoruz. Çıktı olarak ise ortak paydada buluşabilmeyi hedefliyoruz.
Yukarıdaki adımlar istenen olgunluğa geldiğinde ise artık Product ekibi olarak User Story’lerin oluşturulması sürecine geçiyoruz. Eğer tek bir User Story yeterli olacaksa elimizdeki tüm doneleri barındıracak şekilde oluşturuyoruz. Eğer birden fazla User Story’den oluşan bir süreç ise, user story list belirlenerek, ilgili user storylerin içerisine ilişkili doneleri ekliyoruz. Son olarak, oluşturulan User Story’lere belirlenen kapsamı doğrulayacak kabul kriterleri ekleniyor ve iş, eforlama sürecine hazır hale geliyor.
5. Yapılacak işlerin teknik gerekliliklerinin planlanma sürecine ne kadar dahil oluyorsunuz?
Çok fazla değil. Sadece planlama yapıldıktan sonra zaman çizelgeleri ve yöntem konusunda bilgilendiriyorum. Sorularım veya sorunlarım varsa bunları dile getiriyorum, geliştirme ekibi ile birlikte daha iyi bir zamanlama veya yöntem bulabilir miyiz tartışıyoruz.
Hepsiburada’da Product Owner’lar geliştirme ekiplerinin bir parçası olarak iş süreçlerinin takibini sağlıyor. Uçtan uca iş takibi yapma sorumluluğunu üstlendiğimiz için işlerin teknik gerekliliklerinin belirlenmesi ve planlanması noktasında doğrudan müdahil oluyoruz. Gereksinim henüz bizim tarafta olgunlaşmadan önce teknik paydaşlarla beraber servislerin, tasarım ve iş akışlarını karşıladığına emin oluyoruz. Servislerde eksik varsa paydaşlara bunu bildiriyoruz, aynı zamanda tasarım süreçlerinde teknik gerekliliklere uygun tasarımların çalışıldığından emin oluyoruz. Uygulamadan atılan analitik event datalarının kontrol edilebilmesi noktasında hazırladığımız kontratlar ile teknik ekiplerin ortak bir dil üzerinden event datalarını takip etmesini sağlıyoruz. Belli işlerde, kickoff toplantıları üzerinden backend ve client ekipleri arasındaki kontrat planlama süreçlerine destek verebiliyoruz.
6. Geliştirme ve tasarım fonksiyonları beraber ve aynı anda mı hareket ediyor, yoksa tasarım tamamen finalize olduğunda mı geliştirme başlıyor? Tasarım kararlarında ne kadar bulunuyorsunuz?
Beraber çalışılıyor, hatta çalışmanın başında geliştirme ve tasarım ekipleri sürece dahil olarak kullanım senaryolarına göre ürünler tasarlamamız için en baştan fikir ve yorumlarıyla bize yardımcı oluyorlar.
Tasarımlara dair alınan kararlarda hep varım, benim onayım olmadan geçmiyor
Tasarımın netleşmediği durumlarda işe başladıktan sonra çok fazla git-gel yaşanıyor, kapsam değişiklikleri olabiliyor ve işin tamamlanma süreci riske giriyor. Bu sebepler dolayısıyla tasarım finalize edilmediyse ilgili işe başlamayı tercih etmiyoruz. Fakat bazı durumlarda, işin önceliğine göre inisiyatif alıp tasarımı tamamlanmamış işi sprinte ekleyebiliyoruz.
Bir iş ihtiyacı doğduğu noktada biz ve ilgili paydaşlar tasarım ekipleri ile ortaklaşa çalışıyoruz. Kullanıcı deneyimi odaklı çalışan ekipler, kullanıcı araştırmaları ve benchmarking çalışmaları yürütüyor. A/B test ihtiyacı konuşuluyor ve bu çalışmaların neticesinde Miro üzerinden tasarım planları bizimle paylaşılıyor. Bu noktada; teknik kısıtları, mobil dünyaya uygunluğu ve gelen feedbackleri değerlendirerek tasarımlar üzerinden yorumlarımızı iletiyoruz. Bir işin eforu ve bu işin etki hacmi üzerine anlaşma yapıyoruz, örneğin kullanıcılar tarafından limitli oranda kullanılan bir gereksinim için yüksek eforlu tasarım çalışılmaması gerektiği konusunda yönlendirmeler yapabiliyoruz veya kullanıcının sevdiği ve desteklediği deneyimleri artırmaya çalışıyoruz. Zeplin’e yüklenen tasarımların; hata, başarı, bilgilendirme, yüklenme caselerini içerdiğinden, ikonların uygun tipte olduğundan, pop-up/tool-tip gibi yardımcıların eklendiğinden emin oluyoruz. A/B test neticesine göre kullanıcı deneyimi ve etkileşimi açısından revize ihtiyacı varsa belirleniyor ve gerekli düzenlemelerden sonra geliştirme bütün kullanıcı gruplarında canlıya alınıyor. Bunun yanında, geliştirme aşamasında ortaya çıkan ekstra durumlarda tasarım ekibiyle bire bir etkileşim kurarak hızlı çözümler üretiyoruz.
8. Kapsam konusunda farklı fonksiyonlarla hemfikir olma sürecini nasıl yönetiyorsunuz?
Genelde kapsam konusunda hemfikir olma süreci, gereksinimler olgunlaştırılırken organik bir şekilde oluşuyor. Bir noktada tüm fonksiyonların ortak bir amacı bulunuyor ve bu çerçevede en verimli olacağına inandığımız ya da kanıtlayabildiğimiz kapsam üzerinden ilerliyoruz. Genelde birinci önceliğimiz pazara sürüm süresi (time to market) oluyor. Pazara sürüm süresi üzerinden kapsamı belirlemeye çalışıyoruz ancak bu kaliteden ödün verdiğimiz anlamına gelmiyor tabii ki. Duruma göre esnediği senaryolar da olabiliyor. Bu tarz durumlarda da ilgili talebi fazlandırarak ilerliyoruz. Bir MVP kapsamı belirliyoruz ve sonraki iterasyonların kapsamlarını netleştirip tüm paydaşlarla neden fazlandırılması gerektiğini, bize neler kazandıracağını, riski ne kadar minimize ettiğini şeffaf bir şekilde anlatıp, hemfikir olup süreci ilerletiyoruz.
Devamlı bütün menfaat sahipleri ile ortaya çıkmakta olan ürünün defalarca üstünden geçerek. Haftalık olarak buluşuyor süreci ve ortaya çıkmakta olan ürünü değerlendiriyoruz. Tasarım veya geliştirmeyi yaparken karşımıza çıkan engelleri tartışıyor ve ürünü daha iyi nasıl yapabiliriz üzerine birlikte çalışıyoruz. Kapsam biraz bu görüşmelerde değişebiliyor ama asıl kapsam en başında kullanıcı senaryolarının üzerinden geçerken belirleniyor. Tutumumuz genellikle en az özellikle en fazla değeri nasıl aktarabiliriz baz alınarak kararlaştırılıyor.
🤔 Siz gereksinimleri nasıl aktarıyorsunuz, diğer ekiplerle nasıl hemfikir oluyorsunuz? Slack’te yeni sayılar üzerine sohbet etmeyi seviyoruz, sizi de bekleriz!
Akın Ömeroğlu ile Açık Kaynak Üzerine – Buradan dinleyin
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayıda geçen sayı başladığımız “Yeni bir özellik geliştirmek” yazı dizisinin ikinci kısmı olan “Planlama” konusuna giriş yaptık. Konuyu “Akış” ve “Gereksinimler” temaları altında iki ayrı sayıda inceleyeceğiz ve bu sayının konusu bu yüzden “Planlamada akış”: Geliştirecek olan özelliğin hangi probleme çözüm olacağını netleştirip kapsamı da belirledikten sonra planlama süreci nasıl başlıyor, hangi metodolojiler nasıl uygulanıyor bunlar üzerine global örnekler paylaşıp, topluluk üyelerimizin de deneyimlerini aktarmaya gayret ettik.
İyi internetler,
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel buluşmalara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Planlama: Nedir? Neden önemli?
Planlama süreci: Akış
Faydalı Kaynaklar
Yeni bir özellik geliştirirken temelde yaptığımız üç şey var: Problemi/ihtiyacı/beklentiyi anlamak (Serinin “Keşif” isimli ilk sayısında bu konu üzerine kafa yormuştuk), uygun çözümü geliştirmek ve bu çözümü kullanıcılara sunmak. Aslında keşif sürecinde edindiğimiz bilgiyi uygun çözümü geliştirebilmek adına kullanmaya hazır hale getirmek için yaptığımız her şeyi planlama kapsamında değerlendirebiliriz. Planlama adımı yeni bir özellik geliştirirken izlenen süreçte en az keşif kadar önemli ve değerli; çünkü nasıl doğru probleme odaklanılmadığında çözümün bir önemi kalmıyorsa, doğru planlama yapılmadığında da keşfin bir yanı eksik kalıyor.
Çözümü geliştirmeye başlamadan önce planlama yapmak neden önemli?
Planlama sonucunda bu yeni özelliği geliştirecek her bir ekip üyesinin payına ne düştüğünü görmesi ve takip etmesi kolaylaşıyor.
Herkesin problemi ve çözümü doğru anladığına ve aynı şeyi anladığına emin olmak mümkün oluyor.
Özelliği geliştirmeye başlamadan önce tüm organizasyon bu özellikten ne bekleyeceğini, özelliği geliştirecek ekibi ve detayları anlayabileceği bir çıktıya sahip olabiliyor ve geri bildirim verebiliyor.
Organizasyondaki tüm ekiplerin aşina olduğu ve sürdürdüğü bir planlama sistemi, organizasyon ölçeklenirken olan biteni izlemeyi ve ürün kalitesini yüksek tutmayı kolaylaştırıyor.
Planlama konusunda biraz geriye gidelim: 2000’li yıllar öncesinde teknoloji şirketlerinde yapılan planlamalarda ilk günden kesinleştirilen ve sabit tutulan bir gereksinimler dosyası takip ediliyor, bu gereksinimlerin zaman ekseninde planladığı Gantt chart’lar oluşturuluyor ve tüm bunlar Waterfall metodolojisi çatısı altında yönetiliyordu. Değişiklik yapılması gerektiği fark edilse dahi plan dışına çıkmak mümkün görülmediğinden, geliştirme yapılırken geçen onca zamanda gelişen yeni ihtiyaçlara cevap vermeyen, ölü doğan ürünler, özellikler ortaya çıkıyordu. Tutmayan kaynak planları da cabası.
2000’ler sonrasında teknoloji ekiplerinin daha pratik planlama yöntemleri üzerine kafa yormasıyla gelen çevik yazılım geliştirme metodolojileri bu uzun dönemli, değişmez ve bölünmez planları daha kısa döngülerle, güncellenebilen ve yakın geleceğe odaklanan planlara evriltti. Şimdilerde bir özellik üzerine planlamaya başlamanın ya da planlar yaparken izlenebilecek yöntemlerin türlü türlü çeşitleri, örnek uygulamaları var. Ekipler organizasyon büyüklüğüne, iş modeline, hatta ekip üyelerinin çalışma tercihlerine göre bu yöntemlerden birini ya da birkaçını sentezleyerek seçiyor, uyguluyor, değiştiriyor ya da terk edip başka bir model denemeye geçiyor. Kanaat önderleri de bu yüzden planlama süreçleri için bu dinamik ve çevik kalma halini öneriyor: 30 kişiden 100 kişiye çıkan ya da ekip yapılarının değiştirildiği bir organizasyonda mutlaka planlamada da değişmesi gereken şeyler olacaktır.
Son dönemde gözlemlediğimiz bir yaklaşımsa organizasyonun ürün kültürüne göre takip edilebilecek planlama yöntemlerine karar vermesi, yapılacak özellik granülünde uygulanacak yöntemin ve akışın seçilmesi şeklinde. Ölçeklenmiş ve ürün odaklı teknoloji şirketleri, ürün kültürünü tüm ekiplerin benimsemesine gayret ederken onlara yol gösterici “Playbook”lar hazırlıyor ve ihtiyaca göre süreci adapte edebilmelerine izin veriyorlar.
“Playbook” konseptini uygulayan ve nasıl uyguladığını aktaran iki ürün şirketine dair blog yazılarını buraya bırakıyorum: Typeform ve Zalando.
Topluluk üyelerimize bir özelliği planlamaya başlamadan önce neler yaptıklarını sorduk ve şöyle cevaplar aldık:
Planlamanın ilk adımı CTO, Engineering Manager, ben ve benim ile birlikte çalıştığım PM arkadaşım oluyor. Aslında burada teknik feasibility işlerini temsilen CTO, resource management ı temsilen eng. manager ve ürün gerekliliklerini temsilen PM ekibi oluyor. Biz bundan öncesinde, ürünün prototip tasarımlarının hazır olduğundan ve job story’lerinin belirlenen scope kapsamında yazılmış olduğundan emin oluyoruz. Aslında daha geniş bir ekip ile bu konuları önceden konuşmuş oluyoruz. (Tasarımcı, engineer arkadaşlar). Yani aslen story’ler o zaman periyodu için ekipçe shape edilmiş oluyor ve scope’lar belirlenmiş oluyor.
Planlamaya başlamadan önce ihtiyaç veya problemi belirliyoruz. Geliştireceğimiz özelliklere bazen elimizdeki verileri anlamlandırarak, kullanıcıların potansiyel ihtiyaçlarını belirleyerek karar veriyoruz, kimi zaman da doğrudan kullanıcı geri bildirimlerinden yola çıkıyoruz. Elimizdeki KPI’ları da düzenli takip ederek bunların iyileştirilmesi üzerine yaptığımız fikir alışverişlerinden yola çıkıp, özelliğin kullanıcılara nasıl bir iyileştirme sağlayacağını netleştiriyoruz.
Öncelikle product ekibi (product owner, product lead, product manager) olarak fikir alışverişi yaparak kapsamı genel hatlarıyla belirliyoruz.
Sonrasında özelliğin nasıl geliştirileceğini ve teknik detayları tartışmak için teknik ekip (developer/data scientist) ve tech leadler ile bir araya geliyoruz. Böylece ürünü geliştiren ekip neyin neden yapıldığı konusunda fikir sahibi oluyor ve işin etkileşimi net bir şekilde anlaşılıyor. Yapılabilecekler ile ilgili karara varıp, işin yaklaşık büyüklüğünü tahminliyoruz.
Bu aşamadan sonra büyük resmi, detayları, kısıtları, akışı, metrikleri toparladığımız bir product canvas hazırlıyoruz. Özellik canlıya alındıktan sonra yaratacağı etkiyi ölçebilmek için KPI’lara karar veriyoruz ve tespit ettiğimiz data eksiklikleri varsa bunlar için ön hazırlıklar yapıyoruz. Yapılmak istenen ölçümlere göre A/B test koşulup koşulmayacağının kararını veriyoruz. A/B test yapılacak ise testin gereksinimlerini de ayrıca belirleyip feature canlıya çıkmadan önce hazırlık yapılmak üzere planlıyoruz.
Yapılacak iş farklı takımlara dokunuyorsa bunları da göz önünde bulundurarak diğer ekipler ile bir araya geliyoruz.
İhtiyaçlar belirlendikten sonra UX ekibine geliştirilecek özelliği aktarıyoruz. İşin ölçeğine göre belirlenen bir MVP varsa hem bu kapsam hem de fazlandırmayı düşündüğümüz aşamaları aktarıyoruz. Bu doğrultuda tasarım ihtiyaçları üzerine konuşarak özellik ile ilgili gerekli tasarımları alıyoruz.
Topluluk üyelerimizin planlama akışlarına ve uyguladıkları yöntem ve metodolojilere dair görüşleri şöyle:
Biz Shape Up kullanıyoruz. Ama onu da zaman içinde kendi sistemize göre uyarladık. Aslında Shape Up’a sprint’te bir şey deliver edememe problemi yüzünden geçmiştik. 2 haftalık sprint planlaması, ölçmesi, groom etmesi derken sürekli bir koşturma nedeniyle neredeyse verimli iş yapamadığımıza karar verdik. Shape Up sayesinde 6 haftalık bir sürede gerçekten müşteriler ve takım için anlamlı bir şeyler çıkaracak planlamayı yapabilir hale geldik. Ancak son dönemde bir pivot halindeyiz ve Shape Up’ı da yine kendimize göre değiştirerek, biraz sprint’e yakınsar hale geldik. Çünkü daha hızlı bir şekilde bir şeyleri test etmek istiyorduk. O nedenle 3’er haftalık daha ufak deliverable’lara odaklandık. Ancak akış genel olarak aynı. O da şöyle:
PM herhangi farklı bir metodolojide olacağı gibi yapılacak işi getirir. Bunun için biz JTBD metodolojisine dayanıyoruz. Ama Shape up ile harmanlarken çok son seviyede detay vermemeye dikkat ediyoruz.
Daha sonrasında bu getirilen iş üzerinden developerlardan bir bölüm (daha senior’lar diyeyim), designer, CTO bir scope belirleme çalışması yapıyor. Bunu yaparken aslında bir işi 6 haftada yapmak için hangi kısımlardan feragat edebiliriz, bilmediğimiz bir teknik engel var mı, bu konu müşterilere nasıl fayda sağlayacak bakıyoruz.
Daha sonrasında belirli bir iş setinden hangilerini alacağımıza CTO, PM Ekibi ve Eng. Manager olarak karar veriyoruz.
Arkadaşlar işi yapıyor. Ölçümleme metriklerimizi koyuyoruz.
Scrum metodolojisini göz önünde bulundurarak planlama sürecini yürütüyoruz. Ürün geliştiren takımlar agile çalıştığı ve scrum uyguladıkları için biz de ürünler için bir execution planı yaparken buna göre hareket ediyoruz. Roadmap’i her bir çeyrek için önceden planlanıyoruz ve önceliklendiriyoruz. Takımların çeyrek içerisindeki işleri bitirme hedefleri oluyor. Burada işin kapsamını baştan belirleyip kullanıcılarımıza geliştirdiğimiz özellikleri en hızlı şekilde sunmayı hedefleyen bir MVP planı hazırlayarak bu işi parçalara bölüyoruz. Küçük ölçekli işleri ise ekip ile birlikte doğrudan sprintlere dağıtıyoruz.
Bu metodoloji ile ilerleme sebebimiz işleri küçük parçalara bölerek daha hızlı bir şekilde canlıya almak. Bu sayede işlerin planlama ve geliştirme tarafında karmaşıklığını ve birbirine bağımlılığını azaltmış oluyoruz. Küçük parçalara bölünmüş işleri canlıya alarak hatalı olan işlerden daha erken dönebilme fırsatı da yakalıyoruz. Başarısız olabilecek bir işe büyük eforlar harcamış olmak yerine, en başta az bir efor harcayarak canlıya alıp, gözlemleyip, takımın eforunu verimli kullanabilmiş oluyoruz.
Bazen plananan özellikler çok büyük eforlar gerektiriyorsa bu işleri çok sayıda parçaya bölmüş olabiliyoruz. Bu durumda her zaman önceliğimiz MVP için planlanan işler olsa da geliştirme takımının kapsamdan uzaklaşmaması adına planlanan feature üzerine detaylı aktarım yapıp takımın büyük resmi de takip edebilmesini ve işin devamını görebilmesini sağlamaya çalışıyoruz.
Her çeyrek için development takımı ile birlikte roadmapin üzerinden geçiyoruz. Çeyrek içerisinde, ekibin roadmap ile align olabilmesi ve oluşabilecek belirsizlikleri gidermek için düzenli aralıklarla ekibe roadmap içerisinde hangi noktada olduğumuzu ve ileriki sprintlerde yapılması planlanan işleri anlattığımız toplantılar yapıyoruz.
Akış ise şöyle oluyor:
İhtiyaç belirlendikten sonra development ekibi ile bir araya geliyoruz, işin kapsamını ve büyüklüğünü çıkarıyoruz.
İş için MVP belirleyip büyüklüğüne göre mevcut çeyrek içerisine eklenebilecek bir iş olup olmadığını kararlaştırıyoruz. Düşük eforlu bir iş ise bu işler takımın roadmap yoğunluğuna göre çeyreğe eklenebiliyor. Büyük eforlu ancak öncelikli bir işse de çeyrekte farklı bir iş ile değiştirilebilir mi kontrolü yapıp ona göre ilerliyoruz.
Product Canvas’ı hazırlayıp öncelikle MVP olarak yapılacak işleri küçük parçalara bölüyoruz. İleriki fazlar için de genel planı çıkarıyoruz.
Diğer takımlara dokunan işlerde onların çeyrek planlamalarını da göz önünde bulundurarak iletişime geçip ortak bir planlama yürütüyoruz.
UX ekipleriyle ve varsa işin dokunacağı ekipler ile birlikte tasarım ihtiyaçlarını konuşup netleştiriyoruz. Tasarım ihtiyacı olan bir iş ise işi kararlaştırılan tasarıma uygun akışa döküyoruz tekrar product Canvas’ta.
İşin MVP kapsamındaki adımlarını sprintlere dağıtıyoruz ve her sprint öncesi tüm takım ile birlikte konuşarak puanlanabilir işlere kırıyoruz.
Puanlanan işleri önceden planlanmış olan sprintler içerisine yerleştiriyoruz ve sprint başladığında takım sprint içi önceliğine göre üzerinde çalışmaya başlıyor.
Sizin uyguladığınız, örnek uygulamalardan farklı ya da hibrit planlama akışları var mı? Slack’te yeni sayılar üzerine sohbet etmeyi seviyoruz, sizi de bekleriz!
Üretim Bandı Podcast: Thundra nasıl ürün geliştiriyor? – Link – Emrah Şamdan’ın yazıda bahsettiği Shape Up yöntemiyle alakalı daha fazla bilgi alabileceğiniz bir podcast bölümü.
Great Products Don’t Happen By Accident – Link – Jon Lax’tan, ürün tasarımı ve geliştirme süreçlerini iyileştirmek için Playbook’ları önerdiği bir blog.
Can Algül ile Pubinno – Biranın İnterneti – Buradan dinleyin
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayıda uzun soluklu bir yazı dizisine başladık: Yeni bir özellik geliştirmek. Bu konuyu farklı sektörlerden, farklı iş modellerinden ürün ekipleri yeni bir özellik geliştirirken hangi süreçlerden geçiyor, mevcut süreçlerini nasıl iyileştirebilirler, örnek uygulamalar neler gibi konulara değinebilmek için seçtik.
Her bir organizasyonun hatta ekibin yeni bir özellik geliştirmede izlediği adımlar farklı olabiliyor, biz de o yüzden genelde kabul görmüş ortak adımlar üzerinden gidip, bu adımlarda uygulanan pratiklerin ya da işleyişlerin farklarını görmeyi amaçlıyoruz. Bu genelleme üzerinden her bir sayıda bahsedeceğimiz adımları şöyle belirledik: keşif, planlama, koordinasyon, canlıya alma, canlı sonrası. Her bir adımda topluluk üyelerimize de danışıp, mini röportajlarla değişik bakış açılarına yer vereceğiz 🥁
Bu sayının konusu olan “Keşif”te üzerinde duracağımız konular araştırma ve fikirleştirme olacak; yani bir problem üzerine çalışmaya karar verilen noktadan, çözüm olarak geliştirilecek özelliğin kapsamına karar verilen noktaya kadar yapılanların üzerinde duracağız. Oldukça geniş ve çok yönlü bir adım olduğundan, konunun özünde kalmaya çalışarak bu sayıyı tamamlamaya gayret ettik. Umarız bu seri kenarından köşesinden fikirler verir ve ilham olur!
İyi internetler,
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel webinarlara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Keşif: Nedir? Neden önemli?
Keşif süreci: İhtiyacı anlamak ve kapsamı belirlemek
Faydalı Kaynaklar
Ürün geliştirme terminolojisinde keşif (discovery) kavramı, kullanıcı ihtiyaçlarını anlamak ve geliştirilecek ürünü ya da özelliği bu ihtiyaçlara cevap verecek şekilde kurgulamak anlamında kullanılıyor.
Daha geniş bir tanımda, keşif adımı aslında son durumda ne yapılacağına karar verirken şu parametreleri göz önünde bulundurmaya yarıyor:
ürün stratejisine göre hareket ederek, ekip üyelerinin beklentilerini karşılıyor muyuz? (vizyon)
kullanıcılar üreteceğimiz çözümü anlayıp, kullanabiliyor mu? kullanıcıların gerçekten umursadığı bir problemi mi çözüyoruz? (validasyon)
bu çözümü üretecek kaynağımız, yetkinliğimiz var mı? (uygulanabilirlik)
Bu sorulara cevap aramak da aslında çıktı (output) yerine sonuca (outcome) odaklanmaya yarıyor. Birçok organizasyonda bir özelliği geliştirmek ve kullanıcıya ulaştırmak, o özelliğin çözdüğü problemi derinlemesine anlamaktan daha anlamlı görülebiliyor; bu da aslında bir anlamda keşif süreçlerini hafife almak demek oluyor. Ekip üyelerinin gözlemleri ve deneyimleriyle edindiği içgörülerin keşif sürecinin bir parçası olması beklenen ve önerilen, ancak problemi anlamak ya da doğru çözüme yönlenmek için her zaman yeterli olmayabiliyor. Özellikle de geliştirilen özelliğin kapsamı kararlaştırılırken, kullanıcıların ortak ihtiyaçlarına hitap eden bir kabiliyetler listesine karar verebilmek için kullanıcıların da bir parçası olduğu keşif pratikleri yapmak elzem görülüyor. Bu konuyla alakalı fikir yürüttüğümüz geçmiş bir sayımıza da şuradan ulaşabilirsiniz: “Input > Output > Outcome”.
Keşif süreçleri iki ana kısımdan oluşuyor: araştırma ve fikirleştirme. Araştırmalar keşif sürecinin ilk kısmı ve genel olarak kullanıcı geri bildirimleri edinmek ve bu bilgilerle ihtiyacı anlamak ve doğrulamak üzerine oluyor. İhtiyaçları anladıktan sonra gelen ikinci kısım ise kapsamı belirlemek yani fikirleştirme. Bu kısımda da genel olarak ihtiyacı doğruladıktan sonra gelen olası çözüm önerilerini test etme ve farklı parametrelerle yoğurduktan sonra kapsamı netleştirme üzerine çalışılıyor.
Kullanıcıların belirli bir probleme dair beklentilerini ve ihtiyaçlarını anlamak için uygulanabilecek birçok araştırma tekniği var: Anketler, A/B testler, yüz yüze ve bire bir görüşmeler, focus grupları, veri anlamlandırma ve analitiği, market analizi, gibi gibi. Bu tekniklere, ne zaman hangi tekniğin uygulanabileceğine ve nelere dikkat edilebileceğine önceki sayılarımızda yer vermiştik, daha detaylı bilgi için inceleyebilirsiniz: “Nitel (qualitative) kullanıcı araştırmaları” ve “Nicel (quantitative) kullanıcı araştırmaları”.
Bu araştırma tekniklerinin kullanımı üzerine topluluk üyelerimizin fikirlerini aldık:
Ürün geliştirmeyi bitmek tükenmek bilmeyen bir araştırma ve çıktı yaratma süreci olarak görüyorum ve bu doğrultuda ürün geliştirme sürecindeki ihtiyaca göre yukarıda örneklediğin bütün teknikleri yeri geldiğinde kullanıyorum. Burada altı çizilmesi gereken nokta ürün geliştirme sürecinde bulunduğun nokta aslına bakarsan. Örnek olarak tamamen yeni bir iş alanına ve değer önerisine giriyorsan market ve rekabet analizi çok alakalı iken mevcut bir ürünün iterasyonunda zaman kaybı olabilir. Dolayısıyla araştırma teknikleri kadar, hatta belki daha da fazla, araştırmadan çıktı beklentisine (research outcome) odaklanılması gerektiğini düşünüyorum.
B2B SaaS platformu olarak Segmentify’da müşterilerimiz ile birebir görüşmelere çok değer veriyoruz. Bu noktada en çok kullandığımız ve öncelik verdiğimiz araştırma tekniği diyebilirim. Bu görüşmeler özellikle hizmet verdiğimiz müşterilerin problemlerini ve ihtiyaçlarını yakından dinlememizde, en değerli küçük problemi bulmamızda ve bu problemi çözecek en değerli küçük ürünü oluşturmamızda yol gösterici oluyor. Bunun yanı sıra hizmet verdiğimiz e-ticaret sektörünün dinamik ve değişken bir yapıya sahip olması nedeniyle değerli kuruluşların paylaştığı pazar analiz raporlarını ekip olarak düzenli bir şekilde takip ediyoruz. Çok yakın zamanda Mixpanel’i özellikle ürünlerimizin kullanımı noktasında quantitative verilere dayandırarak varsayımlarımızın sonuçlarını değerlendirmede değerli bir kaynak olarak kullanmaya başladık. İç ekiplerimizi (Account Management, Customer Success, Satış) yakından ilgilendiren araştırmalar için de sıkça anketler paylaşıp geri bildirimleri toplamaya çalışıyoruz.
Şu anda aslında bu saydığın tekniklerin hepsini kullanıyoruz. Özellikle büyük geliştirmeler gerektiren stratejik işlerde araştırma ekibi ve birlikte çalıştığı iş ortaklarının koordinasyonuyla anket, focus group, 1-1 görüşmeler sonucu detaylı bir rapor oluşturuluyor. Bunu bir de strateji ekibinden ya da farklı kaynaklardan aldığımız market dokümanları ile birleştiriyoruz. Aynı zamanda kendi verilerimiz üzerinden bir analiz çalışması ile de destekliyoruz bunları.
Bunun dışında ürün ekibi olarak development öncesi hipotezlerimizi doğrulamak için prototip testleri ya da smoke test gibi yöntemlerden faydalanıyoruz.
En nihayetinde de mutlaka A/B testi uyguluyoruz. A/B testleri bizim ürün geliştirme kültürümüzün çok önemli bir parçası. Sadece yeni özellikler için değil, neredeyse her değişiklikte A/B testi uyguluyoruz. letgo’da A/B testi yapılmadan bir özellik çıkmaz diyebilirim.
JotForm’da ürün geliştirme süreci kabaca ikiye ayrılıyor ve aslında izlediğimiz araştırma süreci de ona göre şekilleniyor.
1. Varolan kullanıcı etkileşimini/aktifliğini ve bağlılığını arttırmak: Kullanıcılarımızın ürüne olan bağlılığını arttırmak, onların iş akışlarına doğrudan kolaylık sağlamak için izlediğimiz süreç.Bu süreçte kullanıcı yorumlarını günlük olarak takip ediyoruz. Bu sayede bir sonraki adımımızı genellikle önceden tespit etmemizi sağlıyor.
Kullanıcılarımızın farklı ürünlerimizden bizlere ulaştırdığı yorumlarını analiz etmekle başlıyoruz ve bu yorumları bir kaç gruba bölüyoruz: Improvement Suggesstions, Feature Requests, Bugs, Nice to do’s, gibi. Bu kategoriler içinde oluşan grupları yorumluyor ve daha derin bir analiz yapmak için doğru soruları sormaya çalışıyoruz. Sorularımızı belirledikten sonra yorum/istek yapmış olan kullanıcı gruplarımızdan bir segment belirliyoruz (ürünümüzdeki aktiflikleri, kullandıkları özellikler ışığında) ve bir kaç farklı grup oluşturmuş oluyoruz. Sonraısnda bu grupları User Research takımımıza iletip görüşme sürecini başlatıyoruz.
Görüşmeler küçük bir kullanıcı grubu ile yapıldığı için A/B testler bizim vazgeçilmezimiz. Çözümlerimizi A/B testleriyle değerlendiriyoruz ve kullanıcılarımızdan gelen isteklerle bizim sunduğumuz çözümlerin belirlediğimiz başarı metrikleri üzerindeki etkilerini gözlemliyoruz.
Bu noktada Data ekibimiz toplanan verinin anlamlandırılması konusunda takımları destekliyor ve testin kapatılması gereken vakti, doğruluk payı gibi daha bir çok farklı bilgi ve önerilerini takımlarla paylaşıyor.
2. Yeni kullanıcı kazanmak ve farklı pazarlarda büyümek, bunu yaparken varolan kullanıcımızın akışlarını da kolaylaştırmak.
Market analizi yine bizim için hiç durmayan bir süreç, ama potansiyel bir hedef belirlediğimiz zaman market/rakip analizlerine de özellikle odaklanıyoruz.
Kullanıcılarımızın aktif olarak JotForm dışında kullandığı ürünler gibi noktalarda yine varsa veri ve kullanıcı görüşmeleri gibi yardımcı gereçlere de başvurarak belirliyoruz.
Özetlemek gerekirse her ürünün ya da stratejinin kendine göre farklı süreçleri oluyor, bu sebeple duruma göre ilerleyeceğimiz yöntemler üzerinde kendi kombinasyonumuzu ve sıralamamızı yapıyoruz. Bana göre test yöntemlerinin da her zaman test edilmesi gerekiyor.
Araştırma tekniklerinden biri olan kullanıcı görüşmelerini diğerlerinden biraz daha ayrı tutmak istedik, çünkü problemi derinlemesine anlamak için kişisel görüşüm bu görüşmelerin en etkili yöntem olduğu yönünde. Kullanıcılarla hangi durumlarda ve hangi adımlarda etkileşime geçtiklerini, ve kimlerle görüşeceklerine nasıl karar verdiklerini topluluk üyelerimize sorduk:
Görüşme süreçlerinde oluşturmuş olduğumuz sorular ışığında kullanıcılarımızdan onların pain pointlerini ve düzeltme önerilerini alıyoruz. Varsa iş süreçleri için kullandıkları 3rd party ürünleri öğreniyor ve JotForm’u complete bir çözüm yapmak için değerlendirmeler yapıyoruz. Bütün bu bilgiler ışığında artık kullanıcıların önündeki engelleri kaldırma ve çözümler üretme vakti gelmiş oluyor ve farklı çözüm önerileri ve iterasyonlar yapıyoruz.
A/B test süreci Booking için biraz ayrı olduğundan onu ayırmam gerekli, ama diğer kalitatif ve kantitatif yöntemleri ortalama en az çeyrekte bir kere kullanarak kullanıcılarla etkileşime geçiyorum. Bu konuda özellikle ROI (return on investment) çoğunlukla gözden kaçan çok önemli bir etmen. Özellikle ciddi zaman ve kaynak yatırımı yapma potansiyeli olduğunu öngördüğüm durumlarda problem tespiti ve problemi iyi anlama, konsept geliştirme ve erken dönem validasyona ciddi zaman ayırıyorum. Ürünü canlıya çıktıktan sonra erken dönem araştırma sürecinde kurduğumuz ana hipotezlerin ne kadar doğru çıktığını veriye bakarak ve AB testlerle bir kez daha valide ediyoruz. Çoğunlukla bu süreçte bu sefer çalışan ürün üzerinden ya da çalışan ürünün ufak iterasyonlu prototipi üzerinden kullanıcı testleri gerçekleştiriyoruz ve roadmap sürekli olarak bu verilerden besleniyor.
Araştırma senaryosu geliştirme sürecinde user researcherlar ana sorumluluğu alıyor, buna uygun kullanıcı seçme (screening) süreçleri dahil. Burada daha ziyade onlardan gelen soruları cevaplıyorum ve doğru kullanıcılarla görüştüğümüzden emin olmaya çalışıyorum.
Müşterilerimizden geribildirimleri toplama, ihtiyaçlarını anlama noktasında Account Management ve Satış ekibimiz çok büyük bir rol oynuyor. Tüm istekleri Jira üzerinde “Requests” adlı projemizde toplayıp önceliklendiriyor veya ihtiyacı, problemi daha net anlamak adına detaylandırıyoruz. Fakat bizler sadece bu feedbackler üzerinden değil müşteriler ile birebir görüşerek de ihtiyaçları veya problemleri müşterilerimizin bakış açısıyla dinlemeye çalışıyoruz. Product ekibimizdeki Product Manager ve Product Ownerlarımızın haftada en az iki müşteri toplantısına girme hedefi mevcut. Müşterilerimiz ile ürün geliştirme sürecinin her aşamasında görüşüyoruz. Özellikle roadmap planlama noktasında müşterilerimizin problemlerini daha iyi anlamak adına analiz öncesinde, bulduğumuz çözümün müşterinin problemini doğru bir şekilde çözüp çözmediğini ve anlaşılır, kullanılabilir olduğunu netleştirmek adına analiz esnasında ve çözümün iterasyonu noktasında çözüm geliştirildikten sonra sık sık müşterilerimizle görüşmeye, geri bildirimlerini almaya çalışıyoruz. Müşterimize sunduğumuz hizmet nedeniyle sadece e-ticaret siteleri değil, müşterilerimiz ile ilerlettiğimiz süreçlerin aynısını iç ekiplerimizle de ilerletmeye çalışıyoruz. Görüşeceğimiz müşterileri iki farklı şekilde ve temel amaca hizmet edecek şekilde belirliyoruz diyebilirim. Görüşmeler yeni kabiliyetler içinse Account Management veya Satış ekibimiz aracılığıyla ihtiyacını daha önceden görüşmelerde belirtmiş kullanıcıları seçmeye çalışıyoruz. Amacımız ürün kullanımını artırmak ve deneyimi iyileştirmeksa somut veriye dayalı şekilde ürünümüzü pasif bir şekilde kullanan veya çok aktif kullanan müşterilerimizi tercih ediyoruz.
Kullanıcılarımızla farklı ülkelerde olduğumuz için birebir temas etme imkanımız pek fazla olmuyor. Ancak elbette farklı farklı geri bildirim alma yöntemleri kullanıyoruz. Öncelikle şunu söyleyebilirim: letgo daha çok nicel veri odaklı bir şirket (ve bunun da çok faydasını gördük) ve kullanıcı geri bildirimlerini kesin sonuçlara varmak yerine daha çok soru sormak için kullanıyoruz. Bir geri bildirim üzerine veriye detaylıca girip o zamana kadar farkına varılmamış bir problemi ortaya çıkarabiliyoruz.
Sorunları tespit etme, problemi anlama aşamasında 1-1 görüşmeler, kullanılabilirlik testleri sıklıkla başvurduğumuz yöntemler. Bunun dışında varsayımları test etmek adına prototip testleri, smoke test ve A/B testlerine başvuruyoruz genelde.
Görüşeceğimiz kullanıcıları belirlemek adına çok detaylı kriterlerimiz yok. Milyonlarca kullanıcının kullandığı bir ürün olduğu için çok farklı profillerden önemli geri bildirimler alabiliyoruz. Üzerinde çalıştığımız özelliğe ya da projeye göre bazen belirli profiller gerekebiliyor.
İhtiyacı anlamak üzerine araştırmalar ve analizler yaparken, diğer fonksiyonlarla koordine hareket etmek büyük yarar sağlıyor. Bazı organizasyonlarda kullanıcı araştırmaları üzerine kurulmuş spesifik ekipler bulunuyor ve ürün yöneticileri bu ekiplerle çalışıyor; bazılarında da bu sorumluluğu ürün yöneticileri üstleniyor ve kullanıcılarla doğrudan iletişimi olan Müşteri Deneyimi ya da benzeri ekiplerle ortaklaşarak süreci yönetiyor. Her iki durumda da ürün yöneticileri sürecin önemli bir parçası oluyor.
Topluluk üyelerimize bu süreçlerde diğer ekiplerle nasıl koordine olduklarını ve araştırma sonuçlarını nasıl paylaştıklarını sorduk:
Diğer ekiplerin sürece etkisi oluyor mutlaka. Sadece satış, pazarlama gibi ekipler değil aynı zamanda CRM, mühendislik, data ekipleri de burada önemli stakeholder’lar oluyor. Genellikle problem tanımı yapıldığında çözümler için brainstorming’den başlıyoruz birlikte çalışmaya. Herkesin tasarımında yer aldığı bir ürün/özellik herkes tarafından daha çabuk sahipleniliyor ve benimseniyor.
Çoğunlukla araştırma sonuçları tüm şirketle paylaşıyoruz. Şeffaflık çok önemli bizim için. Bütün şirkete açık olan read out oturumları yapıyoruz ya da bir rapor varsa onu paylaşıyoruz. Ayrıca A/B testi sonuçları bütün şirket ile bir email üzerinden paylaşılır ve herkesin bilgilenmesi sağlanır.
Segmentify’da hizmet verdiğimiz müşterilere yarattığımız en büyük değerlerden biri Customer Success ekibimiz ile müşterilerimize verdiğimiz destek. POC sürecinden itibaren müşterimiz ile Account Managerımız çok yakın bir iletişim sürdürüyor. Bu noktada düzenlediğimiz birebir görüşmeleri çoğunlukla Account Managerımızın eşliğinde gerçekleştiriyoruz. Account Management ekibimiz genellikle toplantı ayarlama ve müşteri ile bizi bir araya getirme noktasında bir köprü işlevi görüyor.
Cross-functional takımlar olarak çalışıyoruz ve takımlarımızın içinde o takımın üzerinde çalıştığı geliştirmelere özel araştırmalar yapan bir User Researcher oluyor. Aynı zamanda büyük resme odaklı User Research ekibimizde var.
Takımdaki User Research ve Designer dirsek temasında çalıyor. Takım içinde kullanıcıların savunuculuğunu yapan birinin olması her toplantıda hem designer hem developer olmak üzere herkesi tek bir paydada buluşturuyor. Günlük bazda ürün üzerindeki experience problemleri kullanıcıların takıldıkları yerleri tartışıyor ve hızlı iterasyonlarla hem araştırmaları hem tasarımları yeniliyorlar.
Yerine göre ekipteki her bir kişi bir şekilde dahil oluyor ama genellikle mutlaka kullanıcı deneyimi ekipleri (UX Design, UX Copywriter, UX Researcher) masada bulunuyor. Burada araştırma sürecine özel ekipler var, örneğin UX ve Market Research ekipleri merkezi ekipler ve ürün ve pazarlama ekiplerine yakın çalışıyorlar. Ben Ürün Yöneticisi olarak genellikle bu ekiplerden talep eden konumundayım ama execution sürecinde hands on dahil oluyorum ve araştırma süreçlerinde onlarla birlikte çalışıyorum. Yani araştırma ekipleri sürece liderlik ederken ürün geliştiren ekibin ürün yöneticisi de tasarımcısı da yazılımcısı da hands on dahil oluyor.
Araştırma sonuçları genelde sunum formatında şirketin FB vari iletişim portalında paylaşılıyor. Özellikle birincil düzeyde etkilenebilecek diğer ekiplerin ürün yöneticileri ile ben direkt olarak da paylaşıyorum.
Araştırma süreçleri bittikten sonra aslında kapsam az çok ortaya çıkmış oluyor. Bu sonuç üzerine karar alma süreçlerini nasıl yönettiklerini topluluk üyelerimize sorduk:
Analiz sonrası müşterinin ihtiyaçlarını ve şirketin genel stratejisini en önde tutarak, yazılım geliştiricilerimiz ile görüşerek müşterinin problemlerini çözebileceğimiz en yalın ve en değerli kapsama karar kılıyoruz. Bu sürece hem teknik ekibimiz hem de iç ekiplerimiz çok yakından dahil olarak katkıda bulunmaya çalışıyorlar. Olabildiğince feedback alabilmek için ekipler ile toplantılar düzenleyerek görüşlerini öğreniyoruz.
Özellik kapsamını belirleme sürecinde araştırma diğer pek çok başka şey gibi bir girdi, araştırmadan kesinlikle ürün ekibinin işi olan karar alımını yapmasını beklemiyorum. Araştırma çıktılarından ürün kapsamına giden süreçte aslında kendi ekibim başta olmak üzere alakalı partilerle yürüttüğüm fikir alışverişine dayalı, karar almayı hedefleyen iteratif bir yaklaşım var. Buna araştırma ana çıktıları üzerinden yaptığımız brainstorming çalışmalarından ekiple gerçekleştirdiğimiz grooming çalışmalarına, üst yönetimden gelen geri bildirimden diğer ekiplerden gelen girdilere kadar pek çok farklı şey dahil. En sonunda bu yine bir ROI oyununa dönüyor; kısaca ne kadar zaman ve emek harcayarak ne çıktı yaratmak istiyorsun? Ve de tabii ki scope mevzusu; bu çıktıyı yaratmak için doğru konumlanmış mısın, ihtiyacın olan şeylere sahip misin? Ana karar alımı kriterlerim sanırım bu şekilde.
Lean product development felsefesini uygulamaya çalışıyoruz böyle durumlara. Büyük projeler yerine MVP mantalitesinde hızlı şekilde ürün geliştirip kullanıcılardan veriyi toplayıp sonra bu verilerle optimize ederek, değişiklikler yaparak ilerleme alışkanlığımız var şirket olarak. Burada MVP içeriğini belirlemek önemli bir problem tabi. Bunun için de kullanıcı araştırmaları ve veri analizi ortaya çıkan ana pain point’e odaklanmaya çalışıyoruz. Farklı birimleri etkileyen bir üründen söz edersek de o ekiplerle bu verileri tartışıp MVP tanımında el sıkışarak ilerliyoruz.
The Evolution of Modern Product Discovery – Link – Ürün keşif koçu Teresa Torres’ten, keşif süreçlerinin tarihi gelişimine dair bir konuşma ve konuşma metni.
Product Discovery – Link – Marty Cagan’ın konunun özüne dair fikirlerini aktardığı bir blog.
Product Discovery: A Practical Guide for Agile Teams – Link – Tim Herbig’den keşif süreçleri üzerine kapsamlı bir yol haritası ve model.
A step-by-step guide for conducting better product discovery – Link – productboard’dan problem ve çözüm alanları üzerine çalışırken uyguladıkları “Double Diamond Approach” üzerine bir blog.
Continuous user research in 11.6 seconds – Link – Kullanıcı araştırmalarının özellik bazında olmadan, devamlı yapılmasının gerekliliği ve faydaları üzerine bir blog.
Dilara Neutze ile Tasarım, Organizasyon ve Ürün – Buradan dinleyin
Burak Akgün ile Büyük Veri Mühendisliği – Buradan dinleyin
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:
Bültene hoş geldin 👋
Bu sayıda içgörüleri anlamak istedik: Kelime anlamı, ürün yönetimindeki rolü, eksikliğinde olabilecekleri ve önsezilerden farkları üzerine araştırmalar yapıp bulgularımızı paylaşırken, daha detaylı okumalar yapmak isteyebilecek okurlarımız için yararlı kaynakları da yazının sonuna iliştirdik.
İyi internetler,
Burcu
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel webinarlara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Tanım
İçgörü, pratik anlamıyla bir problem ya da durum hakkında edindiğimiz bilgi parçacıklarını ve deneyimleri ilişkilendirmemiz sonucu oluşan ani bir aydınlanmaya, bir konuya daha farklı bir yerden bakabilmemize yarayan bir idrak edişe ya da bir konuyu ya da kişiyi derinlemesine ve isabetli biçimde anlamaya deniyor. Tasarım, pazarlama ve hatta psikoloji gibi farklı farklı ekollerde içgörünün yeri var ve kapsamı az çok değişse de özünde aynılar. Ürün yönetimi dünyasındaysa içgörünün rolü büyük, çünkü ürün ekiplerinin en temel sorumluluklarından biri kullanıcılarının problemlerini, beklentilerini ve ihtiyaçlarını anlamak ve ürünü en uygun sonuca ulaştıracak kararları alabilmek.
Ürün yönetimi süreçlerinden bir örnek
Bir problemi çözmek ya da bir ihtiyacı karşılamak adına geliştirilecek bir özellik üzerine çalışmaya başlayacağımızı varsayalım:
İlk yapacağımız şey, problem alanını keşfetmek olsun. Kullanıcılardan gelen geri bildirimleri, takip ettiğimiz metrikleri, benzer ürünlerin bu problemi nasıl çözdüğünü inceleyelim ve ekibin kullanıcıları iyi tanıyan üyeleriyle konu üzerine fikir alışverişi yapalım.
Sonraki adım, bu bulgulardan hareketle ortaya çıkardığımız varsayımlar olsun.
Bu varsayımları valide etmeye dair yaptığımız kullanıcı araştırmaları ile karar alma mekanizmalarımızı besleyelim.
İşte bu ikinci ve üçüncü adımlar arasında, yani varsayımlardan karar almaya giden süreçte devamlı “Neden?” sorusunu tekrarlamak, içgörüler edinmemize ve asıl problemi çözmeye yarıyor.
Ürün içi arama yapmayı sağlayacak bir özellik geliştiriyoruz diyelim ve varsayımlarımızdan biri “Kullanıcılar aradıkları şeyin ismini biliyorlar, ancak nerede olduğunu bilmiyorlar” olsun. Bu varsayımı test ederken gözlemlediğimiz bir davranış şu oldu: Kullanıcı aynı isme sahip birçok farklı arama sonucuna sahip ve hangisinin aradığı asıl sonuç olduğunu anlayamıyor. Bu noktada “Neden hangi sonuç olduğunu anlamakta zorlanıyorsunuz?” diye soruyoruz ve karşılığında “Bu isimde birçok dosyam var, hangi klasörde oldukları bilgisini de görebiliyor olsaydım çok daha kolay olurdu.” gibi bir cevap alıyoruz. Bu cevap sayesinde edindiğimiz içgörü, “Kullanıcılar birden fazla dosya için aynı ismi kullanıyor olabilir, ve bu dosyaları birbirinden ayrıştırmak için bulundukları klasör isimlerinden faydalanıyorlar” olacak, varsayımımızı yeniden gözden geçireceğiz ve sonuçta ihtiyacı daha iyi karşılayan bir özellik geliştirebileceğiz.
İçgörü eksikliği nelere sebep olabilir?
Yukarıdaki akıştan hareketle, ortaya koyulan varsayımları doğrulamadan çözüm alanına geçtiğimizde özünde yaptığımız şey kullanıcı adına karar vermek, ve bu da problemi çözsek de kullanıcıların beklentilerini karşılamayan ya da ihtiyaçlarını “tam olarak” çözmeyen bir sonuca sebep olabiliyor. Sadece sayısal veriye dayalı karar alma mekanizmaları da analiz felcine, problemin altında yatan asıl probleme yani kök probleme kadar inememeye, yüzeysel çözümlere ya da farklı bir problemi çözmeye kadar gidebiliyor. İçgörülerin önemi bu anlamda ürün stratejisine kadar varıyor: Ürünün yol haritası kök problemlere odaklanmadığında, karar alma mekanizmaları safi veriler ya da varsayımlar üzerine kurgulandığında, ortaya koyduğumuz strateji de yanlış olabilir.
Önsezi?
Peki şöyle durumlarda ne yapacağız: Bir problemin çözümü üzerine ürettiğimiz çıktıları kullanıcılarla paylaştığımızı ve iki çok farklı yönde geri bildirimin eşit ölçüde ortaya çıktığını düşünün (varsayımlarımızı doğrulamış ve içgörülerle desteklemiş olmamıza rağmen). Ya da tüm kullanıcılar aynı yönde geri bildirim verdi ve o da ürettiğimiz çözümü desteklemiyor. Yani farklı farklı tipte veriyi topladık, anlamlandırdık ve sonuçta bir şekilde yine de karar veremiyoruz. Bu noktada anlamaya çalıştığım şey içgörünün önseziden (gut feeling) farkı oldu.
Önsezi aslında bu gibi kompleks karar alma mekanizmalarında yeri olan ve kimi durumlarda başvurmanın gerekli olduğu bir bilişsel düşünce süreci. İçgörü ve önsezilerin temel farkı şu: Önseziler bilişsel olarak halihazırda mevcut desenlerden (pattern) hareketle ortaya çıkarken, içgörüler yeni desenler üretebilmeye yarıyor. Mevcut desenler ise aslında kişinin bilinçli ya da bilinçsiz olarak edindiği yaşamsal tecrübelerinden oluşuyor.
Özetle durum şu: İçgörülerimizle önsezilerimizi besliyoruz. Önsezilerini bu içgörülerle besleyen ve bilişsel önyargılarının farkında olup, karar alma mekanizmalarında bu önyargılardan uzak durabilen kişiler (bilişsel önyargılar üzerinde durduğumuz sayımız bu konuya güzel bir başlangıç olabilir), daha isabetli kararlar alabiliyor ve kompleks problemler karşısında daha sağlıklı sonuçlar elde edebiliyorlar. Kişinin bir pazarda ya da organizasyonda uzun süre çalışıp edindiği içgörüler sayesinde önsezilerine daha çok güvenmesi bu anlamda makul bir davranış oluyor, ancak kritik nokta önyargıları kontrol altında tutabilmek ve önsezileri besleme mekanizmalarını devamlı geliştirmek. Bunu hakkıyla yapabilen kişiler de aslında organizasyonun yönetim kadrolarında yer almaya daha uygun kişiler oluyorlar.
İçgörüler ve önseziler nasıl daha iyi beslenir?
İçgörüler ve önsezilerin bir organizasyondaki karar alma mekanizmalarında dengeli ve yerinde kullanımı için hem olabildiğince tipte veriye sahip olmak hem de bu verilerin erişilebilir olması gerekli. Yeni bir özellik geliştirirken yapılan keşiflerin çıktıları eğer sadece o özelliği geliştiren ekibin erişebildiği bir dökümanda olursa aslında organizasyona pek bir yararı olmuyor. Aynı şekilde pazara dair verilerin ya da kurucu ekibin belirli konulardaki önsezilerinin ve içgörülerinin tüm organizasyonla yeterince paylaşılmıyor olması da diğer ekip üyelerinin isabetli olmayan içgörüler geliştirmesine ve dolayısıyla önsezilerini doğru yönde besleyememesine sebep olabiliyor.
Özellikle ürün ekiplerinin bu kolektif bilişsel düşünce süreçlerine katkıda bulunması elzem: Bunu yapmanın en iyi yolu da aslında diğer rollerle ortak çalışmak ve edinilen tüm bilgileri ve verileri merkezileştirerek, karar alma mekanizmalarını görünür kılmak. Bu akışı iyi yöneten organizasyonlar çok hızlı büyüseler dahi şirket vizyonunun ve ürün stratejisinin tüm ekiplerce anlaşıldığı, tek bir organizma olarak hareket edebilen yapılar oluyorlar, çünkü hem ekipten ayrılan kişilerin öğrenimleri kaybedilmiyor, hem de yeni gelen kişiler kolayca bu bilgilere ve mekanizmalara adapte olabiliyorlar.
E-kitap: How to gather and leverage deep user insights – Link – Productboard’dan kullanıcı geri bildirimleri üzerine içgörüler edinmeye ve yol haritasını beslemeye yönelik bir şablon.
Key Differences between Instinct, Intuition, and Insight? – Link – Konuya psikoloji ekseninden yaklaşan, tanımları ve farkları üzerine bir blog.
The Aha! Moment: The Science Behind Creative Insights – Link – İçgörüler ve yaratıcı süreçlerin ilişkisi üzerine bilimsel bir makale.
The Decision-Making Dilemma: When to Trust Your Gut vs. the Data – Link – Lucidchart CEO’sundan konuya dair öneriler.
Emre Ertan ile Getir Nasıl Ürün Geliştiriyor? – Buradan dinleyin
Evreka nasıl ürün geliştiriyor? – Buradan dinleyin
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz: