Konuklar: Kübra Cebbar, Mehmet Can Yüney
40. bölümümüzde konuğumuz Seller Growth ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Transkript
Selam ekip. Ben Fofi'nin doldurma salatası ekibinden Fırat.
Ben Product Center ekibinden Erdem.
Teknoloji ekibini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 40.
bölümünde, evet 40. bölümdeyiz.
40. bölümümüzde Seller Growth ekibiyle birlikteyiz.
Ekibi tanıyıp, ekip yapısı kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Arkadaşlar hoş geldiniz. Hoş bulduk.
Hoş geldiniz efendim.
Bir kısaca sizlerden kendinizi tanıtmanızı isteyebilir miyiz sıra sıra?
Selamlar. Kübra ben.
Yaklaşık 2,5 yıldır Trendyol'da çalışıyorum.
Developer'in test rolündeyim.
Trendyol için ilk iş deneyimim diyebilirim.
Merhaba, ben de Mehmet Can Yüney.
2,5 yıldır ben de Trendyol'dayım.
Sailor Growth ekibindeydim. Genel olarak da 4 yıllık bir tecrübem var diyebiliriz.
Süper, süper. Hoş geldiniz efendim.
Hoş geldiniz. İkisiniz de aslında ilk profesyonel şirketler diye anladım.
4 yıllık ve 2,5 yıllık direkt Sailor Growth'un içinden biliyorsunuz.
O zaman efendim, kısaca çalıştığınız domain, Sailor Growth ekibi nedir, nelerle uğraşıyorsunuz?
Neler yapar? Böyle bir kısaca bir özet alabilirsek süper olur.
Ki ona göre yürüyelim. Tabii.
Biz Seller Growth ekibi olarak aslında iki ana domaine sahiplik ediyoruz.
Bunun yanında da geliştirme yaptığımız servisler var.
Ben ufak onlardan bahsedeyim.
Sonra Mehmet Can'a topu atayım iki ana domaine o anlatsın.
Bizim Notification Center dediğimiz bir servisimiz var.
Bunlar adı üstüne seller'lara bildirim yolladığımız bir ekran.
Diğeri Calendar. Satıcıları bir takvim ekranı oluşturduk.
Ve burada ödeme günü... kampanyalarını ve eğitimlerini görebiliyorlar.
Bu şekilde takiplerini kolaylaştırmış bir ekran yapmış olduk.
Son olarak da SEDEBEC ekranımız var.
Burada da satıcının hızlı veya başarılı rozetini kazanmaları için işte neler yapmaları gerektiğini gösterdiğimiz ya da ne kadar ilerlediklerini gösterdiğimiz bir ekranımız var.
Ben de iki ana domeyini bir anlatayım.
İlk domainimiz ekibin isminden de gelen aslında Growth Center'ın kendisi.
Biz burada iki adet projemiz var Challenge ve Level olarak.
Amacımız kullanıcıları aslında sellerları sisteme daha hızlı adapte edebilmek.
Bunu yaparken de aslında bu süreci oyunlaştırarak yapmak.
Challenge dediğimiz sistem kullanıcılara hedefler atadığımız daha sonrası kullanıcı bu hedefleri tamamladığında ona ödüller verdiğimiz bir sistem.
Level'da aslında son bir buçuk senedir olan ve kullanıcılara aslında seviye bilgisi tanımladığımız sistem.
Neredeyse aynı ekran üzerindeler zaten ve amacımız burada da kullanıcı sistemde yaptığı bütün aksiyonlardan level puanı alabilsin ve bu şekilde ödüller kazanabilsin.
Aynı zamanda gerekli rewardları toplayabilsin amacımız bu.
Bunun haricinde ikinci domenimizde strike point dediğimiz uygulama.
Bu da ihlerler ekranı olarak geçiyor.
Kullanıcı herhangi bir tren yolun aykırı gördüğü bir hareket yaptığında bir aksiyon aldığında bunun için bir ceza veriyoruz kullanıcıya.
Ceza puanı veriyoruz. Belirli baremleri açtığında kullanıcı bunun için yaptırımlar uygulanıyor.
Bu da böyle bir sistem diyebilirim.
Özellikle bu gamification tarafı benim bayağı ilgimi çekti, güzelmiş.
Benim merak ettiğim kısım aslında birazcık şey yani birlikte çalıştığınız ekipler ve domeniler neler?
Diğer ekiplerle nasıl çalışıyorsunuz?
O kısmı birazcık merak ettim bir de onun dışında.
Biz aslında Seder Center altındaki satıcının aksiyon aldığı tüm domenilerle yakın çalışıyoruz.
İşte örnek olarak kampanya ekibini söyleyebilirim, promosyon ekibi.
kupon, reklam.
Yani çoğu ekiple aslında dediğim gibi çalışıyoruz.
Peki diğer ekiplerden data'yı nasıl alıyorsunuz?
Aranızdaki iletişim nasıl oluyor?
Tabii onu da ben anlatayım. Şöyle aslında biz mümkün olduğunca iletişimlerimizi event-based yani Kafka üzerinden yapmaya çalışıyoruz.
Biz bir iş geldiğinde hangi ekiple çalışacaksak önce gidiyoruz onlarla bir tanışıyoruz hiç daha önce de iş yapmadıysak ve diyoruz ki hani böyle bir data'ya ihtiyacımız var.
Sizde bunu sağlayan bir Kafka mesajı var mı aslında?
Mesela düşüyor mu diye. Ama hepimizin de bileceği gibi bu bazen mümkün olmuyor.
Bazen datalar böyle anlık aksiyonlar üzerinden olmuyor.
Bu noktalarda da aslında iki yöntemimiz var.
Birincisi bize daha sağlıklı gelen kullanıcı açısındaki experiences daha iyi sağlamak için aslında lokalize etmek datayı.
O almamız gereken datayı kendi tarafımızda lokalize ediyoruz aslında.
Bir diğeri de bu lokalizasyonu da yapamadığımız noktalar.
Bunlarda da aslında cablar kuruyoruz.
O an o hedefi kim içeriyorsa onlar için bir cab kuruyoruz ve diyoruz ki belirli periyotlarda bir bak bakalım bu data tamamlandı mı?
Şu an ne durumda kullanıcı?
Ki olabildiğince küçük tutmaya çalışıyoruz bu periyotları ki kullanıcı hani ekranında anlık datayı görebilsin.
Süper. Peki abi orada küçük bir sorun var.
Şimdi satıcı diyoruz ya Seller Growth.
Burada yani tedarikçileri de sayıyor muyuz?
Yani örneğin fulfillment tarafında da mesela bizim depolarımıza ürünler geliyor.
satıcılardan. Oradaki hani tüm seller'lara yani seller dediğimiz bayağı Trendyol'da satış yapan tüm seller'lar diyebiliyor muyuz?
Yani seller growth için. Aslında marketplace satıcısı olan tüm satıcılar yani Trendyol içerisinde marketplace işlemi yapan, satışı yapan bütün satıcılar bizim için satıcı diyebiliriz bizim domenide.
Süper. Peki tamam. O zaman siz aslında şu anda bir de anladığım kadarıyla çok fazla ekiple de hani iletişim kuruyorsunuz.
Çünkü o bilgilerin toplanması, işlenmesi vs.
oluyor. Bizim taraftan mesela işte Fulfillment tarafında olduğumuz ekip de çok fazla işte İntegrasyondur, iletişimdir vesaire oluyor.
Bir de bu işlerin işte support kısımları oluyor.
Mesela sizlere bu support kısımlarda örneğin işte production'da vesaire bir sorun yaşadığınızda böyle aldığınız bir aksiyon falan var mı?
Ya da işte bizim entegrasyonumuz çok fazla olduğu için.
Diğer ekiplere göre şunu daha fazla yapıyoruz dediğiniz vesaire bir şeyler var mı?
Test olabilir, gelişim olabilir, support olabilir emin değilim.
Tabii yani şöyle anlatayım.
Genel anlamında alert sistemleri bizim için dediğin gibi çok önemli.
Çünkü satıcının anlık olarak kaçırdığımız tek bir eventi bile o kullanıcıya sanki o işlemi yapamamış.
Hatta belki ödülünü alamamaya iten bir sistem.
Bu da kullanıcıda çok kötü bir imaj yaratıyor açıkçası bizim sistemde.
Bunu sağlamak için yani olmaması durumları için şöyle bir şey yapıyoruz.
Nivrelik alertlerimiz var. Bütün kullandığımız sistemlere neredeyse entegre etmeye çalışıyoruz.
Grafana'da pod alertlerimiz var.
Herhangi bir şekilde pod düştüğü, memory restart yediği, CPU'nun çok overheadlere çıktığı noktaları hep görmeye çalışıyoruz.
Bunun haricinde dediğim gibi daha demin cablar vardı.
Bu cablar gerçekten çalışıyor mu diye.
hani çalışan sistemde bile belki hata olabilir diye Kibana'da alertlerimiz var.
Eğer ki belirli bir log gelmediyse hata alıyoruz ve bunların hepsi Slack'te bize gösteriliyor.
Aynı zamanda frontend üzerinde de bunlar hep backend'de tabii.
Frontend üzerinde de Sentry kurulu.
Kullanıcılar orada da anlık olarak tekil kullanıcı ne sorun yaşarsa Sentry'den bize alert düşmeye çalışıyor ve biz de onları takip ediyoruz.
Tabii dediğim gibi asıl problemimiz her zaman dediğim gibi çok fazla ekiple çalışıyoruz ve ekiplerin bir tane mesajındaki fark bir tane datadaki bir yanlışlık aslında bütün sistemin etkilenmesine
sebep oluyor o kullanıcı için.
Bunu da aslında şöyle çözdük.
Belki diğer ekiplerin yapmadığı bir şey olabilir.
O yüzden söyleyelim. Biz error topiği dediğimiz, yani aslında Kafka'dan gelen mesajların herhangi bir tanesi hata aldığında başka bir topiğe yönlendiriyoruz.
Ve o error topiğini her bir sistem, harici bir sistem, biz buna Kafka error tracker dedik ama...
Bunu sürekli takip ediyor.
Herhangi bir error topiğine bir mesaj düşerse diyor ki bu kullanıcı için şu topik şu konuda hata aldı.
Bak bu neyi sağladı bize?
Mesela support oranını çok yarı yarıya düşürdü diyebiliriz.
Hani kullanıcı mesela ekranına giriyor.
Ben bu aksiyonu yaptım ama neden gözükmüyor gibi sorular geliyordu.
Biz bu sistemi yaptıktan sonra fark ettik ki hani datada ufak bir oynaklık bizim fark etmediğimiz bir şey veya yeni bir feature gelmiş veya işte arada kalmış o.
Biz onları artık çok rahat görebilmeye başladık.
Kullanıcı support ekranına girip o kötü tecrübeyi yaşamadan aslında biz onu çözmüş oluyoruz.
Tabii bunun haricinde incident her zaman olabilecek bir şey.
Elimizden geldiğince RCA kayıtlarını tutuyoruz her incident için.
Bu RCA kayıtlarında neleri daha iyi yapabilirdik, neyi fark ettik, ne öğrendik hepsini tutmaya çalışıyoruz.
Ki daha sonradan bunlara dönüp bakalım mesela neleri daha iyi yapmışız, neleri daha kötüye götürmüşüz diye.
Tabii en iyisi de aslında dediğin gibi testler.
Biz bu incidentlar oluşmaması için...
Elimizden gelen her türlü test senaryosunu düşünüp çıkartmaya çalışıyoruz aslında.
Süper. Peki burada şey mi oluyor?
Direkt dedin ya bir erroru attığımızda direkt alertler kuruyoruz.
Yani aslında senin orada error dediğin yani bazı işte retry edebileceğiniz şeyler var.
Ama retry etmeniz belirli bir zaman alacak.
O retry etmek yerine sen aslında onu direkt fail edip bunun içinde kendi alertlerinizi kuruyorsunuz.
Yani bir sorun olduğunda aslında direkt kendiniz müşteri görmeden önden görüp aksiyon alıyorsunuz.
Aslında aynen öyle. Yaptığımız şey şu bir retry mekanizması var dediğin gibi fakat retry mekanizmasının da çözemediği bir hataysa en sonunda artık eröre düşüyor ve biz erörde görüyoruz aslında.
Diyoruz ki burada bir yanlışlık var bu kullanıcı bunu aslında yapmalıydı ama yapamadı gibi.
Ben bir de şey kısmını merak ediyorum ya test.
bahsettik ama bizim ekipte de testlere çok ağırlık veriyoruz ve çoğu yerde aslında bizi böyle amiyane tabirle ipten aldığı noktalar oldu diyebilirim.
Gerçekten manuel testler sırasında çıkmamış.
Şimdi testler belki yakalayamamış bazen.
Bu tarz konularda böyle yaptığınız ekstra bir şeyler var mı?
Burada nasıl pratikler uyguluyorsunuz?
O kısmı merak ettim ben de.
Aslında bizim de en önemli amacımız bu bahsettiğimiz incidentları en baştan engellemek ve tabii servisleri, performans güvenliğini de arttırmaya çalışıyoruz.
Bu yüzden biz de çeşitli testler yapıyoruz.
aslında. Bunlar içindeki en önemlisi acceptance testler.
Biz acceptance testleri developerlarla beraber yazmaya başladık Haziran'ın ayından itibaren.
Burada önce acceptance kriteriyeleri belirleyip daha sonrasında aslında önce acceptance kriterleri belirledikten sonra testlerin yazılımı daha sonra geliştirme yapılmak üzere böyle bir sürecimiz var burada.
Bunun dışında kullanıcı arayüzünü test etmek için eklediğimiz UI testlerimiz var.
Çok fazla ekiple çalıştığımızı söylemiştik.
Bunun için en gerekli olan kontrak testlerimiz var.
Bunları yazıyoruz. Diğer ekiplerin herhangi bir değişikliklerinden haberimiz olsun diye.
Prod'da çalışan smoke testlerimiz var.
Bu da servisin temel işlevlerini konsolettiğimiz testler oluyor genelde.
Bunun dışında en başta da dediğim gibi aslında performans testlerimiz de var.
Bunun servisin performansını ölçmek için.
Düzenli olarak koşuyoruz yük testlerini de aylık olarak.
Bunun dışında bir de şu an için yapmıyoruz ama ilerisi için planımız olan stage'e yük testleri ekleyip her end...
point çıkışında bir ufak böyle yük testi koşup sonrasında proda almak gibi bir planımız var.
Test süreçlerimiz böyle ilerliyor.
Bu test süreçleriyle ilgili küçük bir sorum olacak Kübra.
Kontrak testleriyle ilgili bir ara biz de bir konuşmuştuk da.
Bunu mesela yapılan iş maliyetine karşı direkt o değil mi?
Karşılığını mesela ya gördüm gerçekten şurada bizi kurtardığı gibi kontrak testi böyle şey oluyor mu?
Yoksa nice to have mi?
Yoksa gerçekten olmadığında şurada yararını gördük gibi bir şey oldu mu?
Şöyle aslında her ekip için zorunlu diyemem ya da olması gerek.
diyemem. Ama bizim gibi orta bir ekipseniz eğer bence olmalı.
Çünkü biz en başında challenge'ı yazarken, challenge projesini çok fazla şeyle karşılaştık.
İşte bir end point'ten bir field artık dönmüyor.
Neden? Öyle değiştirdik.
Ya da işte bu servisi şu an kapattık.
Neden? Kapattık.
Hani hiç haberimiz yok ve bunu ekiplerle iletişime geçip öğrenebiliyoruz ancak.
Bu yüzden kontrak test bizim ekibimiz için önemli bir yerde.
Evet ya çok haklısın. Özellikle yani bizde de çok fazla entegrasyon var.
Biz daha çok hani provider kısmı olduğumuz için daha az sorun yaşayan kısmı olabiliyoruz bazen.
Çünkü genelde insanlar bizden geliyor ama biz özellikle konsümer tarafı olursak hani sizlere sanırım tam tersi gibi anlıyorum.
Hani çok fazla... Yerden bilgi topluyorsun vesaire.
Bir yerde bir properti iptal oluyor.
Olan sana da oluyor. Senle gidiyorsun gibi bir şeyler oluyor yani.
Aynen biraz öyle oluyor gerçekten.
Peki bu testler tarafında developerlarla beraber test yapıyoruz.
Eski testleri falan. Dedin ya o kısım oradaki süreç nasıl ilerliyor?
Yani Payroll'u mu ilerletiyorsunuz yoksa ayrı ayrı o testlerin sorumluluğunu mu alıyorsunuz?
Ya biz aslında bu düşünceye biraz şey olarak başladık.
İşte lead time süresini kısaltmak için neler yapabiliriz?
Bir de işte bu bizim trend yolu içerisinde de çok kullanılan bir geleneksel akış var ya hani yapılır, developer, yazar servisi teste atar, test edilir sonra proda çıkar bir sorun yoksa.
Bizim buradaki amacımız da şey oldu tamamen işte koddaki bir değişiklik ile aslında birinin acceptance test'te bir sorun olduğunu bilmesi arasındaki süreyi iyileştirmek istedik.
Bu yüzden böyle bir başlayalım dedik.
Burada da önce developerlarla beraber bir back-end'lerle beraber bir kick-off yapıyoruz.
Ben ve onlar. Sonrasında aslında Pio bize acceptance kriteriyeleri getiriyor groomingde.
Ama biz developerlarla beraber şeyi konuşuyoruz.
Bunun bir uç case'i olabilir mi?
İşte seller buradan bu şekilde gelebilir mi?
Bu şekilde faydalanabilir mi?
Gibi. Bunlar için ek uç case'ler yazıyoruz.
Ve daha sonrasında acceptance test'ler yazılıyor.
Sonra geliştirmeler yapılıyor.
Bu şekilde proda çıkmış oluyoruz.
Bu da bize aslında şey kazandırdı.
Daha hatasız kodlar elde ettik.
Çünkü test akışın...
Sonunda olunca, test akışının sonunda olunca şey oluyor.
Hani hatayı en son görüyorsun ve o zaman hadi en baştan hadi bu hatayı çözelim diye bir süreç uzuyor.
Hatayı gördük ve hızlı ulaştık.
Böylece çözüm de hızlı oldu.
Bununla beraber produktiviteyi de arttırdık ve hızlı değişimlere adapte olduk.
O yüzden bizi sevdik yani böyle ilerlemeyi.
Burada ben de birazcık backend açısından cevap vereyim bu soruya.
Nasıl yapıyoruz gibisinden.
Biz en başta başlarken emin olamadığımız için ilk defa denediğimiz bir şey.
Kübra ile birlikte mesela yazmıştık.
Birlikte gerçekten oturduk.
Acceptance testleri konuştuk.
İlk acceptance testi birlikte yazdık.
Ve daha sonrasından o işin geliştirmesini yapıp proda çıktık.
Şunu fark ettik ki zamanla aslında biz acceptance testleri öncesinden konuşup yaptığımızda ve tam olarak belirlediğimizde aslında gelişme de yani backend açısından gelişim de birazcık kolaylaşmaya
başlıyor. Çünkü ben kodu yazıyorum.
deniyorum testi.
Gerçekten çalışıyor mu diye.
Gerçekten bakıyoruz. Çalışıyor ve ben diyorum ki evet gerçekten yazdığım kod okey oldu artık.
İlerletebilirim. Aynı zamanda bunu ilerlettikten sonra ya acaba başka bir yeri mi kırdım noktasında.
Her zaman mesela Kübra'ya diyorduk işte acaba başka bir yer kırıldı mı kırıldı mı şeklinde.
Şimdi bunları zaten geçiyorsa ve tüm acceptance testler de geçiyorsa artık bu bağlantıya da çok fazla gerek kalmıyor.
Yani birbirimizi de bölmüyoruz. Ben yolluyorum kodu.
Burada kadar ilerleyebiliyor.
Böyle şekil hani arada UI testlerde olduğu için.
%100 güvenilir bir şekilde. %100 demeyelim tabii de.
Olabildiğince güvenilir bir şekilde kodu yollamış oluyoruz.
Hatta bunun için bir RFC'de yazdık.
Gerekli yorumları da toplayabilmek adına.
Şu anlık bizim için bu metot yaradı diyebiliriz.
Süper abi. RFC'de vardı.
Teyit etmişsiniz resmen direkt.
Aynen. Çok iyi. Peki burada mesela az önce Kübra mesela bir lead time'dan vs.
bahsetmişti. Biliyorsunuz şu an şirkette her yerde vardır.
Sizde de vardır diye tahmin ediyorum. 4K metrik, Dorometrikler vs.
lead time'ı kısalım. gibi muhabbetler oluyor.
Burada işte 4K metrikleri şu an siz mesela bu metrikleri nasıl takip ediyorsunuz veya geliştiriyor musunuz ya da sizin ekibe uymayan kısımları var mı, uyuyan kısımları var mı?
Ekipten ekibe çünkü küçük değişiklikler de olabiliyor.
Özellikle mesela sizde entegrasyon çok fazla ya belki etkiliyor da olabilir.
Sizin tarafta nasıl ilerliyor işler?
Tabii genel böyle bir bu senenin başlangıcından itibaren böyle bir cevap vermeye çalışayım.
Biz bu senenin başından itibaren bunlara böyle çok...
Periyodik olarak bakmaya başladık ayda bir.
Toplantılar düzenleyerek baktık neyi daha iyi yapabiliriz veya neyi yaptık ne bize nasıl bir etki oluşturdu gibisinden.
Bunlardan böyle birkaç tane örnek verebilirim aslında.
Biz senenin başında işleri böyle büyük büyük açıp altlarına mesela küçük küçük ilerlemeye çalışıyorduk.
Fakat YT adımında falan takıldığımız noktalar oluyordu, ilerletemiyorduk çünkü tam iş bitmemiş oluyordu.
Mümkün olabildiğince toplanıp küçük işlere bölüyoruz en ufak parçalara ve mümkün olduğunca en...
hızlı bir şekilde proda yollamaya çalışıyoruz.
Kullanıcıyı en etkilemeyecek bir şekilde.
Bunun haricinde Jira'daki bu subtask muhabbetini kullanmaya başladık.
O bizi çok rahatlattı.
Dediğim gibi bir sürü ekiple çalıştığımızdan mesela bazen o ekibin bir şeyi bitirmesini bekliyoruz.
Şimdi ana iş bekliyor fakat benim aslında onları tam olarak beklememe gerek yok.
Ben kodu yazıp gönderebilirim.
Sıkıntısız bir şekilde kalabilir.
Nasılsa hani bir şekilde interaksiyona girmeyeceği için o kod parçası ve testleri de tam olduğu için.
Aslında bu şekilde ilerliyoruz.
Jirada bir saftas kaçıp o işi halledip daha sonrasında tamamen herkes okey dediğinde yolladığımız oluyor.
Bunun haricinde daha demin dediğimiz zaten testleri backend ile yazmak buradan çıkardığımız bir aksiyon bu.
Buradan denemek istediğimiz bir şeydi.
Acaba daha hızlı proda gidebilir miyiz?
Bu aradaki testten backend'e backend'den teste geçiş kısmını böyle tek ile indirebilir miyiz diye.
Bunun haricinde çok fazla code review'umuz vardı sene başında.
Tabi dediğim gibi işte domenler çok fazlalaşınca bazen bir kurgu diğer kurguyla çakışabiliyor ve böyle bazen ortalık karışabiliyor yani.
Bunu da engellemek adına biz sürekli MR açıyorduk ama fark ettik ki ya bunları çok da yapmamıza gerek yok.
Asink bir şekilde ilerletebiliriz bunları.
Hani bir MR açıp o 2 saat beklemesine hiç gerek yok.
Biz o an mesela o an kim müsaitse, payer'ım kimse çağırıp bakıp bu tamam dediğimiz noktada zaten testleri de geçiyorsa bu olaya hiç gerek kalmadığını fark ettik.
Bunun haricinde UAT'de bekleme gibi bir muhabbetimiz vardı.
Neden? İşte dediğin gibi çok fazla ekip olduğu için o ekibin mesela bir kurgunluğusunu ekranda gösterirken bir kelime yanlış çıkmıştır.
Bir yer farklı gözüküyordur business'ın istediğinden.
Bunu biz piyok atmanın da aslında egale etmeye çalışıyoruz.
Ondan bir UAT çeki bekliyoruz.
Tabi her işte değil bu. Hani bunu da Aslında Piyo'nun belirlemesini bekliyoruz.
Hani o ben bu işe bakmalıyım kısmında veya biz söylüyoruz.
Burada da şunu yaptık.
Fark ettiğimiz Jira'da bir iş UAT'ye geçtiğinde ta ki biri Jira'ya bakana kadar o işin UAT'ye geçtiğini kimse anlamıyor.
Ya biz şunu fark ettik.
Bunu hani nasıl otomatize edebiliriz?
Hani sürekli mesela gidip Piyo'ya da işte bu geçti UAT'ye hadi yazar mısın?
Hadi bakar mısın? Veya aynı şekilde Piyo mesela UAT'ye okey verdi.
Red Pro'da hadi çıkar mısınız gibi muhabbetler.
Bunu atıyorsunuz değil mi böyle Piyo'yu dakikada bir?
YT vardı ama falan değil.
Onun da bir toplantı akışı var.
Sonuçta biz de mesela o dediğinde bakamayacak durumda olabiliriz.
Bunu minimale etmek için şöyle bir yöntem izledik.
Jira'da iş ne zamanki teste...
UAT'ye Ready to Pro'da gelirse bir alert fırlatıyor Slack.
Bu şekil biz aslında bunu görüyoruz ve diyoruz ki tamam bu iş artık çıkabilir.
Veya bu iş artık UAT'den Piyo da orayı takip ediyor.
Ve görüyor diyor ki tamam bu iş artık bende.
Aslında bunu sağladık.
Şunu da yaptık. Daha sonradan da şeyi fark etti.
Geçtiği anda mesela o an bir toplantıda oluyorsun.
Slack mesajların kapanıyor veya arada kayboluyor.
Bunu da engellemek adına bu deployment frequency'yi de düşürdüğüm bir şey sonuçta.
Hani o an kalıyor çünkü o veya cycle time'ı.
Bunu engellemek adına da 2 saatte bir buradaki 2 saati çok böyle optimize ettik git gel gele gele.
Bir saat aralığı bulduk.
İki saatte bir bize diyor ki bu iş çıkmadı bunu çıkabilirsin şeklinde.
Süper ya süreçleri bayağı aslında oturtmuşsunuz.
Ekibi de böyle yani konuştukça kafamda bayağı oturdu benim.
Gerçekten dinamik ve böyle kritik işler yapan bir ekip olduğunuzu anladım.
Merak ettim konulardan birisi de aslında takım olarak en büyük challenge'ınız nedir?
Yani çok böyle ekibi detaylı dediğim gibi aslında konuştuk.
Ama şeyi de merak ettim yani aslında yaşadığınız en büyük challenge neydi bugüne kadar?
Var mıdır söyleyebileceğiniz anlatabileceğiniz bir şey?
Onu sorayım dedim. Bizim en büyük challenge'mız orta bir ekip olmak.
Bu en başından beri söylediğimiz şey aslında.
Çünkü iletişimi sürekli devam ettirmemiz gerekiyor diğer ekiplerle.
Ve bunu sağlıklı bir şekilde ilerletmemiz gerekiyor.
Burada da aslında cross team collaboration'ın önemini de anlamış oluyoruz.
Çünkü ortak bir hedefe ulaşmak için çalıştığımız bir süreç ilerletmemiz gerekiyor bütün ekiplerle.
Bu yüzden aslında biz bu iletişimi bence şu ana kadar iyi götürdük.
Bunu sağlayabiliyoruz Slack'ten.
Bu da trend yolunun aslında...
kültürlerinden biri olduğu için.
Yani hani biz bir ekibiz.
Gerçekten bunu hissediyoruz yani kullanırken.
Süper, süper. Peki efendim burada şimdi sen diyorsun ki mesela bizim çok fazla işte ekiple işte entegrasyon var vesaire.
Mesela bizim tarafta da böyle maddeler oluyor.
İşte analiz ediyoruz. Farklı ekiplerle olan iletişimlerden dolayı o madden işte analizi için insanlarla ihtiyaçlarını işte karşılaman gerekiyor, konuşman gerekiyor vesaire vesaire.
Sizlere böyle bir board olduğunda önemli.
Bir madde için bir madde mesela gruma nasıl gelmeli?
Ya da bir madde geldiğinde işte maddede şunlar olmalı veya biz maddeyi şöyle dolduruyoruz gibi.
Özellikle entegrasyon çoksa ki ekipte size çok diye anladım.
Mesela Jira'da bir task için bir yaklaşım mesela nasıl oluyor?
Şimdi şöyle aslında biz öncelikle Pio ile zaten belli bir business akışı olduğu için hangi işlerin ne zaman gireceği onun katmanında belli.
Burada bazen birimize yazıyor.
Diyor ki böyle böyle bir ekip var.
Bunlarda böyle bir data var mıdır diye.
Biz de aslında Pio katmanıyla beraber onların da işte karşı ekibin de piyosunu bir araya getirerek bir aslında toplantı yapmaya çalışıyoruz.
Hem işte arkadaşların domeyini anlayalım.
Oradaki bir sistemin bize nasıl entegre edeceğini bir konuşalım şeklinde.
İlk aslında adımımız bu.
İşte Kafka mı yapacağız? İşte onlardan bir apimi alacağız şeklinde.
Aynı senin dediğin gibi entegreasyonla da sonuçta oralarla konuşurken aslında biz burada size gelen ekip gibi oluyoruz.
Şimdi bunları yaptıktan sonra aslında birazcık acceptance kriteriyalar belli olmuş oluyor.
Yani biz birazcık bunları modifiye etmiş gibi oluyor.
Sonuçta neyi nasıl alacağımızı işte mesajın içerisinde ne olacağını nasıl işleneceğini ortaya çıkarmış oluyor.
Şimdi grooming'e gelmeden aslında bunlar belli.
Şimdi grooming'de biz artık şeyi detaylarını öğreniyoruz.
Bir tasktır bu. İlerlemesi gereken bir hedefin altındaki bir görevdir.
Görevin mesela ilerlemesi veya durması gerekiyordur zaman zaman.
Bu yüzden aslında bu bilgileri ondan alıyoruz.
Modifiye ediyoruz. Sonra teknik analize başlıyoruz.
Teknik analizde de bazen öyle bir şey oluyor ki yeni bir teknoloji kullanmamız gerekiyor.
Hangi teknolojiyi seçeceğiz noktasında?
Trendyol'da çok kullanılan bir metot.
Bu scorecard'ı çok kullanıyoruz.
Hangi teknoloji bize ne kadar fayda sağlar?
Hangisini ne kadar kullanabiliriz?
Bunları oluşturduktan sonra diyelim ki bir tanesine karar verdik ve büyük bir teknolojik bir gelişim yani aslında teknik bir değişiklik gerekiyor.
Bunun da hemen ADR'ını tutmaya çalışıyoruz mümkün olduğunca.
Çünkü burada artık biz bir karar vermişizdir fakat acaba yeni gelen bir arkadaş bunu direkt anlayabilecek mi?
olayı ortadan kaldırmak için ADR'ı tutmuş oluyoruz.
Daha sonrasında şu an hep mesela back-end ve front-end tek ayrı ayrı yaptığı gibi.
Fakat bazı işlerde hem back-end hem front-end gibi bir bağlantı var.
Burada da aslında bir kick-off gerçekleştiriyoruz.
Yine async bir şekilde. O an hangi arkadaş o back-end'i işte back-end'de hangi arkadaş yapacaksa ve front-end'de hangi arkadaş yapacaksa bir araya geliyorlar.
Burada da amaç şu. Hangi data front-end'e lazım?
Hangi query atılırsa Mesela front end'e daha rahat bir sorgu gider.
Hangisi optimizasyon olarak daha iyidir?
Bunları çıkartmaya çalışıyoruz ve en sonunda estimate'e giriyoruz bunlarla.
Her şey belli olduktan sonra puanlandırıp Daha sonradan geliştirmeye başlıyoruz aslında.
Gayet güzel. Şimdi benim en sevdiğim konulardan biri aslında.
Katılan ekiplere de hep soruyoruz.
Retro toplantılarınız nasıl geçiyor?
Retro'da çok sık geliyor.
Bu konu çok önümüze düşüyor dediğiniz bir konu var mı?
Ya da yakın zamanda tartıştığınız bir örnek olursa çok güzel olur bizler için.
Böyle bunu sormuş olayım. Tabii aslında şöyle.
Retro toplantımız her spin sonunda kesinlikle yapmak istiyoruz zaten.
O an bir maddemiz olmasa bile en azından devam ede bir şey yazalım ki en azından ne yaptığımızı, neyi iyi yaptığımızı görelim.
Ama amacımız her zaman Retro'da şu.
Biz o sprint neye takılı kaldık veya neyi optimize edebilirdik?
Daha demin dediğin gibi mesela işte...
A ekibinden bir şey bekliyorduk fakat o gelir diye tamir edip işe başladık.
Bunu belki yapmamalıydık.
Bu mesela bizim retroda ilk retrolarda challenge sistemini ilk yaparken en çok konuştuğumuz konulardan bir tanesiydi mesela.
Bazen estimate'de hatalar yaptığımızı fark ediyorduk çünkü böylelikle.
Onun haricinde bunları konuştuktan sonra zaten aksiyonlarımızı iyice not etmeye çalışıyoruz ve eski aksiyonları da konuşuyoruz o retroda.
Hani hangisini yaptık, nasıl bir fayda sağladı veya hangisini yapmadık, neden vazgeçtik.
gibisinden. Bunları da aslında sorgulamaya çalışıyoruz.
Bir de son yıl içerisinde özellikle bu 4K metrikleri de takip ederken retro toplantılarının sonunda bir 10-15 dakika şunu bakmaya başladık biz.
Sprint raporu var Jira üzerinde.
Gerek yine Jira üzerinde olur veya Sprint'teki işleri döktüğümüzde de ortaya çıkıyor.
Acaba hangi işe hangi puanı verdik ve gerçekten mesela bazen oluyor 3 puanlık iş 5 puan çıkıyor veya 5 puanlık iş 3 puanla düşüyor 1 puanla düşüyor.
Ya bu acaba niye oldu?
Mesela olmaması için ne? sağlayabilirdik?
Daha iyi estimate'i ne yapabilirdik?
Şeklinde. Genelde konuşmaya çalışıyoruz.
Bir de haricinde son yaklaşık bir aydır iki aydır diyeyim.
Bir yeni bir tablo daha gördük aslında Jira'da.
Cycle Time Control Chart diye bir tablo aslında.
Burada da şunu fark ettik.
Bir iş mesela ne kadar UAT'de kalıyor?
Bir iş ne kadar Inder'de kalıyor?
Bir iş ne kadar mesela Red Prod'da kalıyor?
Aslında şeyleri de buradan çıkartmaya başladık biz.
Ya bir bağlantımız vardı.
Mesela bu bağlantıyı ne kadar bekledik?
Beklemeden çıkardık. bilir miydik acaba?
Ya sonuçta şey de değil sonuçta.
Her zaman mesela karşı ekibin bitirmesini beklememiz de gerekmiyor.
Biz çıkarız mesela. Her şeyi okeyleriz.
Toggle'a bağlayabiliriz. Ki en büyük aksiyonlardan bir tanemiz de buydu zaten.
Bu tablolara bakmaya başladığımızda bu sprint raporlarına falan Toggle'lı sisteme çok geçmeye başladık.
Böylelikle hani geliştirme çıkıyordu.
Biz daha sonrasından hatta Pio bile kontrol edebiliyor bu şekilde açıp kapamaları.
En büyük aslında retro konularımız bunlar diyebilirim.
Abi ben Toggle'ımı Toggle'ımı oraya takalım.
Ben de Togo diyebiliyorum ama.
Ben de Togo diyebiliyordum ama emin değilim.
Şu an bir sorguladım kendi kendime.
İkimiz de anlıyoruz ama.
Aynen. Tamamen aynı noktadayız.
Benim peki bununla ilgili farklı bir sorum var.
Yine bizim geçmiş bölümlerde de böyle genelde sorduğumuz sorulardan biri.
Sprint dışında kendinize ayırabildiğiniz zamanlar oluyor mu ya da RG için vesaire araştırma, girişme yaptığınız şeyler var mı?
Bazı ekipler mesela şey diye cevap veriyor.
İşte birileri mesela bir kitaptan bir çepter okuyor.
O çepterinin işte sunumunu yapıyor.
Mesela biz böyle bir şey yaptık gibisinden.
Hani anlatım yapıyor. RG saati oluyor.
Bizde mesela işte örneğin Cuma 10 ile 11 arası RG saati oluyor.
Önceden bir konu belirlemiş oluyoruz.
Böyle bir topik listemiz var bekliyorumuz.
İşte bir aktarım oluyor veya biri bir şey...
İşte en son DATNET'in 8'i çıkmıştı, 8 ile ilgili bir anlatım yapıldı vs.
Bu tarz şeyler olabiliyor. Sizde böyle kendinize ayırabildiğiniz sprint dışında bir saatler vs.
bir şeyler var mı? Aynen var bizimde.
Bizde mutlaka haftada bir gün.
Öğleden sonralarını buna ayırmaya çalışıyoruz.
Biz de dediğim gibi lunch and learn'lar yapıyoruz.
Bu elellerde ya bir kitap okuyoruz belirleyip.
Biz bu kitabı chapter'lara bölüyoruz.
İşte kişilere atıyoruz. Onlar gelmeden önce bize böyle hap bilgileri çıkarıyor açıkçası.
Yani ya da işte ekipte ne yapmıyoruz?
İşte bakın şöyle yapabiliriz gibi karşılaştırmalı bir şekilde de anlattıkları oluyor.
Ya da yeni bir teknoloji buldu, anlatmak istedi.
Bizim ekip için yararlı olduğunu düşündü.
Hani burada bunu kullanabiliriz gibi.
Lanterlerimizi yapıyoruz.
Bunun dışında İngilizce toplantılarımız var.
Her hafta yapmaya çalıştığımız.
Bu İngilizce toplantılarını da değiştirmeye çalışıyoruz sürekli.
Hani aynı bizi sıkmasın diye açıkçası.
İşte bazen oyunlar oynuyoruz İngilizce.
Bazen bir konu belirliyoruz.
İşte o konu hakkında tartışıyoruz.
Ya da hiçbir şey yapmadıysak bile ozuma girip işte günlük hayatımızdan ne yaptın, ne ettin gibi.
Böyle en az bir saat olsa bile İngilizce konuşabildik.
İngilizce masu çok iyiymiş ya.
Toplantılar bir de eğlenceli de geçiyor.
Mesela kelime oyunları falan oynuyoruz ve akılda kalıcı oluyor yani böyle.
Bir yerde writing'e de başlayacağız ama bakalım ne zaman.
Şey mi? Yani silikte vesaire konuşurken mi?
Yok hayır şey diye düşünmüştük hani böyle hikaye yazabilir miyiz?
İşte karakterleri belirleyebileceğimiz bir şekilde hani hep beraber böyle sıfırdan bir şey yazmaya başlayalım ama bir tık zor o.
Yani onun da biraz daha böyle adım ilerlememiz lazım yani ona geçmemiz için.
Şimdilik konuşma yani.
Onun dışında da bazen teknik okumalarımız oluyor bireysel olarak.
Böyle ilerliyor. Gayet güzelmiş.
Benim merak ettiğim bir diğer konu da aslında bu ekipçe...
Anladığım kadarıyla eğlenceli şeyler yapıyorsunuz ama kaynaşmak için yaptığınız böyle ekstra şeyler var mı?
Bizim ekipte örneğin. Biz işte oyun saatlerimiz var aslında haftada bir saat.
Hani bir şekilde o yoğunluklarımızı da ayarlayıp beraber oyun oynamaya çalışıyoruz.
Herkes keyif alacağı basit küçük oyunlar oynamaya çalışıyoruz.
Sizin yaptığınız şeyler var mı bu tarz?
Biz aslında ekip olarak yemek yemeyi seven bir ekibiz.
Bu yüzden böyle senede birkaç kez böyle ekip yemekleri falan düzenliyoruz.
İşte ofis buluşmaları yapıyoruz.
Ama bunları... Genelinde yiyoruz yani yemek yiyoruz.
Hatta bunun için bir ara Antep'e gitmiştik hafta sonu.
Sırf iki gün boyunca yemek yedik mesela.
Kip gibi ekip yani gerçekten. Yani dediğiniz gibi işte oyunlar biz de oynuyoruz arada.
Ama bizimki daha çok böyle zoomlarda boş attığımız zamanlar oluyor.
Hani böyle çok bunaldığımızda işte bir şeyleri çözmeye çalıştığımızda falan.
Böyle ilerliyoruz etkinlik olarak.
Bir ekip mesela mangal demişti.
Mesela kalite mangal çok iyi.
Birisi BMW şeylerinden bahsetmişti hatırlamıyorum.
O çok iyiydi. BMW arabalardan bahsediyorlardı.
Her ekibin çok fazla kültürünün olması güzel.
Ama Antep'e gitmek de bence şey ya.
Bunu diğer ekiplerde şey diyeceğim.
Abi bak millet Antep'e gidiyor yani.
Neler var. Çok iyi.
Süper. Peki burada yeni gelen biri olduğunda mesela ekibi dair ederken onboarding sürecinde mesela yaptığınız bir şeyler var mı?
Örneğin Antep'e götürüyor musunuz hafta sonu?
Nasıl oluyor işler? Aslında şöyle abi Antep döneminde mesela yeni başlayanlardan direkt Antep'e gitmişlerdi.
Karar alındı ve Antep'e gidildi yani o şekil.
Ama şöyle diyeyim aslında yeni bir kişi geldiğinde aslında bir düzenimiz var.
Şöyle bir buddy atanıyor.
O buddy arkadaşı gelmeden önce bir arıyor.
Hani nasılsın? İşte bizim ekibe geleceksin.
Var mı bir sorun? Sana yardımcı olabileceğim bir şey var mı şeklinde.
Bunların haricinde de aslında iki haftalık bir onboarding planı hazırlanıyor.
İşte teknik aktarımlar bunlar işte bizim sistemin tamamı.
Bütün domenlerimiz, kullandığımız teknolojiler nasıl kullanıyoruz?
Nelere bakmamız gerekiyor? Hepsini ufak tefek böyle basitleştirmiş bir halde anlatmaya çalışıyoruz.
Daha sonrasında bir HR'la görüşmesi oluyor.
İşte ekip liderleriyle oluyor.
Büyük genel o dediğimiz engagement'ı aslında tanıtıyoruz.
Seller engagement'ı. Daha sonrasında zaten seller growth'la zaten sürekli iş dışı oluyor.
Bunun haricinde ilk günden itibaren aslında sorumluluk vermeye çalışıyoruz biz.
Hani herhangi bir şekilde böyle iki hafta beklesin.
İki hafta bizle pair yapsın.
Sadece gözlemlesin. Muhabbeti açıkçası hani şu ana kadar gelenlerde hiç yapmadık.
Direkt böyle ilk işi direkt verdik ve dedik ki işte bu işi direkt bitirip hani proda gönderebiliriz.
Birlikte orada çalıştık.
İşte gerek pair yaptık, gerek koduna baktık.
İşte bunu daha iyi nasıl yapabiliriz konuştuk.
Ve şunu diyeyim ikinci haftasında proda kod yollamışlıkları var yani öyle diyebiliriz hatta.
Bir efsane olmuş. Uzun süredir birlikte çalışan bir ortama girdiklerinde veya bizim artık göremediğimiz şeyleri de fark ediyor olabilirler.
Biz bu yüzden aslında şunu da yapmaya çalışıyoruz.
Sürekli böyle birlikte çalışırken ara ara ya bu konuda senin bir görüşün var mı?
Acaba bize verebileceğin süreci geliştirebileceğimiz bir şey var mı?
Şeklinde sürekli feedback almaya çalışıyoruz ki biz de sistemimizi de geliştirelim.
O arkadaş da bu şekilde kendi katkılı bir şekilde aslında takıma dahil olmuş oluyor.
Aslında bu şekilde ilerletiyoruz o süreci de.
Süper ya. Çok iyi.
Çok teşekkür ettik her şey için.
Güzel bir sohbet arkadaşlar. Biz teşekkür ederiz.
Selim Ekip Podcast serisinin 40.
bölümünde, evet yeniden belirtiyorum 40.
bölümünde Selim ve Grot ekibini ağırladık.
Arkadaşlar çok teşekkür ederiz.
Bu ekibi bu bölümde hem ekibi tanıdık, işte ekip yapısı, kullanılan teknolojiler, pratikler gibi konulardan bahsettik.
Bir sonraki bölümde görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.