Selam Ekip - E49 - Product Reward and Compliance

Selam ekip. Ben Storefront TRPDP ekibinden Cengiz.

Ben Fulfillment Order Master Data ekibinden Fırat.

Ben Productivity ekibinden Erdem.

Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 49.

bölümünde Product Reward and Compliance ekibiyle birlikteyiz.

Product Reward and Compliance ekibini tanıyıp ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.

Arkadaşlar hepinize hoş geldiniz.

Efendim hoş geldiniz. Hoş bulduk.

Hoş bulduk. Merhaba. Hoş bulduk.

Bugün yine dinamik bir ekiple güzel arkadaşlarla beraberiz.

Öncelikle arkadaşlar başlarken kendinizi kısaca tanıtabilir misiniz?

Tabii ki ben başlayayım. Merhabalar, ben Gülümser.

Yaklaşık 4,5 yıldır Trendyol'da.

2 yıldır da Product Reward and Compliance ekibinde backend yazılım geliştiriciyim.

Merhabalar, ben devam edeyim. Özge ben de.

Yaklaşık 2 yıldır Product Reward and Compliance ekibinde backend developer olarak çalışıyorum.

Merhabalar, ben devam edeyim.

Ben de Mustafa. Yaklaşık 2,5 yıldır Trendyol'da PRC ekibinde frontend geliştirici olarak çalışıyorum.

Merhaba, Sevgi ben. Yaklaşık 2,5 yıldır Trendyol'da PRC ekibinde developerin test rolündeyim.

Hepinizin iki buçuk yıl olması bir planlı bir şey miydi?

Yani iki yıldan aşağılara almıyoruz oldu.

Çok iyi denk gelmiş. Bu ekip yeni bölündü de o yüzden.

Yani iki yıl önce bölündü aslında aynen iki buçuk yıl önce.

O yüzden boy biraz denk geldi gibi.

Burası daha da kuruluştan gelen insanlar gibi çok iyi.

Bir de ekibin yarısı Türkçe klavye, yarısı İngilizce klavye kullanıyor gibi.

İki kişi frontend gibi.

Mesela iki kişi geliştiriciyim dedi.

İki kişi developer dedi. Bir de PIC var.

Buradan 4 kişi var zaten.

Sizin ekip tam olarak yani kaç kişi var?

4 tane kişi var. Hepsi yazılımcı mıydı?

Tamam şu an şey yapamadım ama yani 4 kişi burada.

Onun dışında ekipte tam olarak kaç kişi var?

Nasıl bir dağılım var burada? Ben anlatayım.

Bizim 3 tane backend, 2 tane frontend, 2 tane test, 1 teknik liderimiz var, 1 tane product owner, 1 de takım liderimiz var.

Toplam 10 kişiden oluşuyoruz.

Yakın zamanda da aramızda backend, frontend ve test rollerinden birer kişi katıldı.

Bu katılımla birlikte aslında ona çıktı sayımız.

Ekipte bir tane tekliydin yani oradaki tekli sizin o kişiye.

Ekibe özel mi? Yani sadece sizin ekibe yoksa tribe'ın tekniği de mi?

Bunu soruyorum çünkü bizde tekli tribe'da oluyor.

Ve işte atıyorum 6-7 ekibe bakıyor.

Sizde de öyle mi yoksa direkt ekibe tekniği mi var?

Şöyle hani direkt olarak Özgü bu arada bizim tekniğimiz.

Direkt olarak hani ekibe bağlı gibi bir noktada değil ama tribe altında bütün ekiplere bakıyor mu gibi bir hani şey var mı tam emin değilim.

Ama bizim yakın çalıştığımız ekiplere de destek verdiğini biliyorum.

Biz aslında SPM'den bölünmüş bir ekibiz 2 yıl önce.

Yani Saplar Product Management.

Bizim teknik liderimiz de hem SPM'e hem bize bakıyor.

Süper. Bizim tarafta da öyle bu arada.

Tek lider arkadaşlar birden fazla ekibi destek veriyorlar.

Yakın zamanda anladığım kadarıyla ekibe yeni arkadaşlar katılmış.

Bu yeni gelen kişilerin onboarding süresleri nasıl oluyor?

Bunu ben yanıtlayabilirim belki.

Bunun için hazırladığımız bir onboarding Excel'imiz var.

Özellikle ilk 2 haftaya dair neler yapılacak onları netleştirdiğimiz, belirlediğimiz bir Excel bu.

Bu Excel'in içerisinde İşte domain aktarımlarından tutun, Slack kanallarını ekleme, projelerin indirilmesi gibi çalışırken ihtiyaç duyduğumuz şeylerin planlı bir süreci var.

Yeni gelen kişiye aynı rolden bir kişi daha varsa body olarak atanıyor.

Yoksa da muhtemelen orada bütün ekip destek olurdu diye tahmin ediyorum.

Bu sayede tüm süreci adaptasyonlu ve eksiklerinin tamamlanması noktasında bu.

belirlediğimiz body destek oluyor.

Mümkün olduğunca toplantılara dahil edip payer çalışma şeklini yürütmeye çalışıyoruz.

Böylece takıma, domeyine adaptasyon hızı da beraberinde artıyor.

Her sprintte farklı domeyinden bir iş almasına özellikle önem veriyoruz.

Böylece tüm domeylerimizin içine girebilmesine ve hepsinde bilgi sahibi olmasını hedefliyoruz.

Aynı zamanda ekipte herkesle birebir yapmasında Teşvik ediyoruz.

Her rolden birisi yeni başlayan arkadaşımıza kendi tarafıyla ilgili süreçlerini anlatıyor diyebilirim.

Takımda herkesin birebiri yapması çok güzel bir olay bence.

Çünkü ben ilk girdiğim zaman sadece takımdaki arkadaşlarımla birlikte değil, mesela PM'de birlikte, UI UX'i arkadaşla birlikte birebiri yapmıştım ve benim için güzel olmuştu.

Çünkü takımdaki herkesi tanıman nasıl bir kültür var.

Yani tekniği, teknolojiyi belirli bir sürede...

Kavrayabiliyorsun ne olursa olsun ama hani kültürü birlikte oturtman bence oldukça önemli.

Biraz şeyden bahsedelim istiyorum.

Şimdi product... Reward and Compliance ekibi ufaktan tanıdık ama tam olarak ne yapıyor Product Reward and Compliance ekibi?

Yani takım isminin içinde reward geçtiği için işin içerisinde bir ödül mü var bilmiyorum.

Tam olarak ne yapıyor ekip, projeleriniz nelerdir?

Bir de mesela siteyi göz önüne aldığımız zaman hangi sayfalar, hangi domainler sizde?

Ben bahsediyorum. Öncelikle ödülle hiçbir alakamız yok.

Bu eskiden kanun belirlenmiş bir isim.

Gerçekten yok yani. Kandırıldık.

Bu daha öncesinde katıcılara...

Teşvik tanımlanan bir domen vardı.

O bizdeydi. İsim de oradan geliyor aslında.

Satıcılara komisyon anlamında teşvik tanımlandığı için aslında bir nevi ödül olarak geçiyordu.

Ondan dolayı ismimiz Reward olarak kalmış.

Ancak şu an mevcuttaki projelerimizde böyle bir konu yok.

İlk kombini anlatayım.

En yeni projemiz bizim. Kombin projesinde ne yapıyoruz?

Aslında satıcıların kendi ürünleri arasında kombin tanımlayabilecekleri ekranlar sunuyoruz.

Bu kombinleri görebilecekleri, yönetebilecekleri, güncelleyebilecekleri veya düzenleyebilecekleri ekranlar.

Satıcılar buradan kombinlerini tanımlıyorlar ve bu şekilde müşteriye birlikte alma şansı sunuyorlar aslında ve satışlarını arttırabiliyorlar.

Ekran olarak yani satıcı tarafındaki ekran olarak söyleyeyim öncelikle.

Satıcıların ürün listesi altında tamamlayıcı ürünler adlı bir ekran var.

Oradan yapıyorlar bu işlemleri.

Müşterilerse ürünün detayına girdiklerinde tamamlayıcı ürünler diye bir alan var.

Orada görebiliyorlar tanımlanmış olan kombinleri diyebilirim.

Riski anlatması için de gülümsere bırakayım sözü.

Ben de evet biraz ekibimizin oradaki compliance kısmından bahsediyorum.

Diğer önemli domenlerimizden riskten geliyor aslında bu compliance yani şikayet kısmı.

Biz bu domenide ne yapıyoruz? Aslında tren yolu olarak güvenilir ürün satarak müşterimizi mutlu etmek temel hedefimiz, işimizin de bir parçası.

Bizim ekip de sistemde satılan ürünlerin orijinalliğini yöneten ekip diye açıklayabilirim.

Peki bizim ekip bunu nasıl yapıyor derseniz?

Aslında birkaç farklı belge isteme opsiyonumuz var.

Ben bunlardan bahsedeceğim.

Örneğin içerideki fraud ekiplerimiz admin ekranı üzerinden diyor ki bu marka şu kategoriden ürün satmak için Bana şu belgeleri göndermelisin.

Biz ekip olarak o marka ve kategoriden ürünü olan veya yeni ürün satan satıcıları buluyoruz.

Bunlardan bu belgeleri istiyoruz.

Ve bu satıcılarımıza belli bir süre veriyoruz.

Hani 36 saat gibi bir süre.

Eğer satıcımız o sürede belgelerini yüklemezse ürünlerin kapatılması için biz ilgili ekiplere Kafka üzerinden haber veriyoruz.

Ve ürünlerin kapatılmasını sağlıyoruz.

Bir seçeneğimiz buydu. Bir seçeneğimizle müşterimiz şikayet edebilir.

Yani müşterimiz tren yoldan bir ürün alır ve bu ürünün orijinal olmadığına karar verir.

Orijinal değil derse de iade talebinde bulunabiliyor müşterimiz.

Biz bu durumda ne yapıyoruz? Yine satıcımızdan ilgili ürün için gerekli belgeleri istiyoruz.

Verilen sürede yüklemezse aynı şekilde ürünleri kapanıyor ve müşteriye de iade yapılmış oluyor.

Bir seçenekte satıcılarımız kendileri kural yaratabilir.

Bunu nasıl yapıyor? Biz satıcılara bir tane partner ekranı veriyoruz.

Seller Center'da deniliyor bu ekrana.

Onlar bu ekrandan giriyorlar.

Marka teşkil başvurusunda bulunabiliyorlar.

Diyorlar ki bu ürünü ben satabilirim ve benim izin verdiğim kişiler satabilir.

veya ihlal bildiriminde bulunuyorlar.

Bu üründe işte görsel ihlali var, bu üründe tasarım ihlali var, bunun tasarımı bana ait diyebiliyor.

Bizim ekip bu durumda ne yapıyor?

Yine biz satıcılardan verilen sürede belge yüklemelerini istiyoruz ilgili üründe, ilgili kategori markada.

Belgeleri 3. parti bir firma onaylıyor veya reddediyor.

Bu onay veya red duruma göre de biz ürünlerin açılıp kapanmasında etkili rol oynuyoruz, ilgili ekiplere haber veriyoruz diye özetleyebilirim.

Bu teslimat domeninden de ben bahsedeyim.

Bayılıyorum bu. domeyine.

En başından beri vardım.

Çok severek çalıştığım bir yer.

Gözbebeğin gibi anlattın. Sıfırdan sen vardın.

Gözbebeği projeler olur ya böyle bazılarının.

Evet öyleydim gerçekten. Projenin en başından beri vardım.

O yüzden çok çok seviyorum Hızlı Teslimat projesini.

Kombin de bu arada bizim için şu an yeni bir bebek diyebilirim.

Onu da çok seviyoruz. Diğerlerini de seviyoruz bu arada.

Yanlış anlaşılmasın tabii. Bu Hızlı Teslimat Nasıl bir proje?

Satıcıların aslında ürünlerinin sevkiyat sürelerini belirleyebildikleri, ürünlerine hızlı teslimat gibi, bugün kargoda gibi etiketler ekleyebildikleri, bu süreci tümüyle kendileri yönetebildikleri

bir domey. Yine partner ekranında bir sayfamız var onlar için.

Oradan yönetiyorlar. Trendyol tarafında da yani son müşteri tarafında...

app tarafında bu arada.

Kullanıcılar da bunu görebiliyorlardı.

İşte şöyle şeylerle mutlaka karşılaşmışsınızdır.

İşte bir ürüne bakıyorsun diyor ki bugün saat 12'ye kadar sipariş verirsen işte ürünün kargoda, bugün kargoda vesaire gibi.

İşte o etiketlerin sahibi bizim ekip.

O siz misiniz? Siz olmuşsunuz.

Bulduk sizi. Client olarak bizim de korkulu rüyalarımızdan biri yani.

Orası bozulacak mı?

Doğru geldi mi? Çok hassas olduğumuz bir yer.

Her zaman orayla ilgili bir sıkıntı olur.

24 saat içinde kargoda da mı?

Aynı yer mi oluyor? 24 saat içinde kargoda mı?

Kargoda hızlı teslimat etiketi oluyor.

Bugün kargoda da bugün aslında kargoya verilen ama belli cut-off saatleri var işte 11 gibi 12 gibi.

Yine satıcılar onu verilen süreler aralığında kendileri hani uygunluk durumlarına göre belirleyebiliyorlar diyebiliriz.

Burası ürünle nasıl bağlantılı oluyor Sevgi?

Nasıl yani? Yani ürün bu bir ürünün özelliği olduğu için bu ürün direkt buraya çıkabilir diyorsun ama aslında ürün değil de satıcı onu çıkardığı için ama ürünü çıkardığı için bağlantılı oluyor.

Şöyle, satıcıların aslında belirli bir termin aralıkları var.

Bunu satıcı kendisi belirlemiyor.

İçeride diğer ekipler, internal ekipler ilgili satıcı için bir min ve max termin süresi belirliyor.

Ve satıcılarımız da onlara verilen bu süreler aralığında ürün bazlı, listing de deniliyor, ürün bazlı olarak o ürüne özel sevkiyat süresi tanımlayabiliyor.

Mesela şöyle düşün, işte kap var, telefon kapları.

Aslında kargolaması hani...

Çok zor olmayan işte zaten küçük bir ürün olduğu için eğer elinde stoğ varsa satıcı sipariş gelir gelmez aynı gün kargoya verebilir bunu.

Ve ürün bazlı yapıyor bunu.

İşte farklı bir şey olsun örnek veriyorum daha büyük bir şey süpürge olsun işte.

Süpürgeyi mesela bugün kargolayamıyor ama yarın kargoya verebilir.

Yine 24 saat sipariş geldikten sonra diyor ki ben bu ürünü bu listingi 24 saat içerisinde kargoya verebilirim.

arada hızlı teslimat etiketi basılıyor.

Şey çok önemli aslında.

Hepimiz hem Trendyol'da çalışıyoruz hem de aynı zamanda Trendyol'un müşterisiyiz.

Çok sık sipariş verip aslında üründe Ve burada ben de kendi tarafımda özellikle hani modern dünyanın getirisini diyeyim artık ne diyeyim en hızlı kargo olan ürünü tercih etmeye

çalışıyorum. Ve biz de hani buradaki süreci bu şekilde kabul ediyoruz gibi düşünebilirsiniz.

Bununla birlikte bu hızlı teslimatla birlikte siparişlerdeki aslında o siparişlerin verilme sayıları vesaire gibi noktalarda artışlar oldu.

Çünkü dediğim gibi hepimiz hem tüketiciyiz hem tren yolda çalışıyoruz.

Ve ne kadar hızlı elime ulaşabiliyorum.

çalışırsa ürün benim için o kadar iyi gibi görüyorum.

Benim için öyle bu arada gerçekten.

Aynı fikirdeyim. Kesinlikle.

Psikolojik yani artık ben bir şey aldığımda hemen bende olsun istiyorum.

Bazen diyorsun ki 10 lira fazla vereyim ama yarın gelsin hemen elinde olsun.

O çok büyük bir avantaj gerçekten.

Böyle bir tane caps vardı belki hatırlarsınız.

Sipariş vermiş kapıda bekliyor kargom ne zaman gelecek.

5 saniye önce falan vermiş böyle.

Tam olarak gerçekten özellikle ben kadın olduğum için belki cinsiyetçi bir yerden yaklaşmak için söylüyorum.

Söylemiyorum ama daha fazla belki hani alışveriş yapmak istiyor kadın.

Özellikle giysi vesaire noktasında.

Hemen gelsin istiyorum yani.

Elime anında ulaşsın.

Bu domain onu sağlıyor arkadaşlar ya.

Hemen geliyorum. Bu arada çok güzel bir yeri birleştirdin.

Şöyle ki sen o 24 saat içinde kargoda kısmını söylüyorsun Aslı.

Frontend kısmında Cengiz hani bu işin frontend kısmında yapıyor ya.

Ben de Full Film Depo ekibindeyim ve stok yönetimi stok kısmındayız ve o 24 saat içinde kargoda dediğimiz aslında işte bizim ST siparişler için yani depoda olan ürünlerimiz olduğu için.

Dediğin gibi cut-off'lar var ve o saate kadar operasyondan çıkması gerekiyor ve onlar da o siparişler.

Çok bağlantılı oldu böyle hepsi.

Yani aslında Data bu ekipten çıkıyor, bize geliyor, bizden kullanıcı görüyor ve siparişini veriyor.

Daha sonrasında da Fırat'lara gidiyor.

Erdem senlik bir şey yok abi burada.

Erdem senlik bir şey yok. Erdem senlik bir şey yok.

Erdem senlik bir şey yok. Erdem senlik bir şey yok. Erdem senlik bir şey yok. Erdem senlik bir şey yok.

Erdem senlik bir şey yok. Erdem senlik bir şey yok.

Bizde de vücut var bizde abi.

Yani bir noktada bizde varız yok değiliz.

Sen de varsın abi. Sen de varsın abi tabii ki.

Bu dönemde tren yolda birçok farklı ekip tabii ki birlikte çalışıyor aslında.

Az önce sizin söylediğiniz gibi.

Ve öbür tarafta da yine müşteriye böyle yani direkt dokunabildiğimiz bir yer olduğu için çok tatlı bir proje.

Ve kombin projemiz de öyle aynı zamanda.

Onu da yine aradan tekrar hatırlatmak isterim.

Evet evet. Ya bu kadar çok şey ben en başta Cahil direkt ekip ismine baktığımda hiç böyle bir şey beklemiyordum yani.

Sizdeki domainler gerçekten direkt müşteriye dokunan ve farklı farklı çeşit çeşitmiş.

Domainler işte teslimat dediğin gibi kombin kısımları vs.

Çok beğendim gerçekten. Peki burada yeni bir proje fikri falan var mı?

Tam olarak neler yapılacak başka?

Çünkü şu an başka bir proje söyleyeceksiniz ve...

çok başka bir şey de olabilecek gibi hissettim.

Potansiyeli çok yüksek gibi.

Başka bir domeniniz varsa ya şu an söyleyin ya da hiç söylemeyin arkadaşlar.

Şaşırmayacağım. Bir domenimiz daha var.

Ondan da bahsetmek isterim.

Otomatik fiyatlandırma domenimizin ismi.

Otomatik fiyatlandırma sayesinde satıcılar fiyat rekabetinde bulunabiliyorlar.

Belirledikleri kurallar çerçevesinde fiyat rekabeti oluşturabiliyorlar.

Bunu anlamak için ilk önce buybox sistemini anlasak daha güzel olur sanırım.

Yani buybox Buybox sistemi demek bir ürünü birden fazla satıcı satıyor demek.

Birden fazla satıcı sattığı durumda bu ürüne ait bir buybox fiyatı oluşuyor.

Bu buybox kazanan fiyatını referans alarak satıcılar kendilerine kurallar oluşturabiliyorlar.

Yani diyebiliyorlar ki benim ürünümün fiyatı buybox fiyatının üzerinde olsun.

Ya da altında kalsın ya da buybox fiyatına eşitlensin.

Buybox fiyatı her değiştiğinde bu kural arkada işliyor ve istediği...

Kurallar çerçevesinde ürününün fiyatı değişiyor.

Bu sayede satıcı daha kolay buy box kazananı olabiliyor.

Yani ilk gözüken, müşterinin ilk tıkladığı ürün olabiliyor diyebilirim.

Buraya bir de şey de dahil.

Otomatik fiyatlandırımın bir diğer görünümü daha var.

O da avantajlı ürün etiketleri.

Yine ön yüzde gördüğünüz, sol üstte gördüğünüz sanırım.

İşte ürünlerin üzerinde avantajlı ürün.

1 yıldız, 2 yıldız, 3 yıldız da önceden.

Şimdi avantajlı... Ürün etiketi olarak değişti onlar.

Yine bunları da avantajlı ürün etiket fiyatlarını takip ederek kurallar tanımlayabiliyorlar.

Böylece satıcılar arasında rekabetin artmasına imkan veren bir yapı sunuyoruz bu domainle.

Ya ben araya bir tane soru sıkıştırmak istiyorum.

Şimdi bütün domainlerinizi dinledik ve yani bu her bir domainde bence...

Oldukça büyük, yönetmesi güç domeniler.

Ben de merak ettim ya bu domenilerin hepsi neden sizde?

Çünkü düşündüğüm zaman genellikle böyle mikro düzeyde bölünmeler...

var bizde ve genellikle her ekip bir tarafından sorumludur.

Ama sizde neredeyse hepsi aynı büyüklükte dört tane domen var.

Bunlar neden hepsi sizde arkadaşlar?

Bunu şöyle açıklayabilirim.

Aslında daha önce de bahsetmiştik.

Biz supplier product management ekibinden bölünmüş bir ekibiz.

İki yıl önce bir bölümü gerçekleştirdi.

Bu bölümü olurken de ürünle alakalı ürünün core özellikleri supplier product management ekibinde oldu.

O sırada ürünün yanındaki projeler aslında bir ekibe gitmesi gerekiyordu ve bizim ekip Bu projeler üstlendi diyebilirim.

İşte kombin. Otomatik fiyatlandırma.

Kombin yoktu o zaman. Riskli ürün, otomatik fiyatlandırma ve daha önce bahsettiğimiz reward kısmı yani incentive kısmı, teşvik kısmı bizim ekibe verildi.

Sonrasında kombin projesi, hızlı teslimat projesi bu ekibe geldi.

Ekibimiz ürünle alakalı ama ürünün ana özelliklerini içermeyen projeleri toplayan bir ekip.

Böyle bakınca kafamda daha iyi oturdu.

Teşekkür ettim. Rica ederim.

Az önce bir sorun vardı ama o kadar çok domeniz var ki ben ortasında sormuşum.

O yüzden bir daha soracağım. Bayağı bir domeniz var şu anda.

Üstüne gelecek olan yeni bir domain herhangi bir şey var mı peki?

Domain olarak yok aslında bizde şu an yeni bir proje.

Ama mevcut domainlerimizi biliyorsunuz Trendyol genelinde bir international çalışmalar yapılıyor.

Biz de international'a geçmeyi hedefliyoruz.

Öncelikle risk tarafından başladık.

Daha henüz tamamlamadık tabii.

Ama ilk önce risk domainini geçireceğiz.

Sonrasında diğer domainleri de aslında international'a açmayı hedefliyoruz.

Bir de kombin tarafında satıcılarımızdan gelen Excel'le toplu kombin tanınama talepleri var.

Onlar için bir çalışmamız mevcut şu anda.

İleriki zamanlarda onu da satıcılara açacağız.

seçmeyi hedefliyoruz aslında. Bitti.

Şimdi çok farklı domenilerde Bayağı da böyle kapsamlı işler yapıyorsunuz.

Ekibin iş yapış sürecini merak ediyorum ben birazcık.

İş yapış süreçleriniz nasıl ilerliyor?

Birazcık oradan bahsedebilir misiniz?

Tabii ki ben backend tarafını anlatarak başlayayım.

Sonra arkadaşlarım devam eder.

Biz backend tarafında ekibe yeni bir proje ya da mevcut domainlerimize ek bir özellik geleceği zaman ilk önce sprintlerimize spike adını verdiğimiz işler alıyoruz.

Ve bu spike işleri aslında bizi bayağı rahatlatıyor.

Biz bu spike işlerinde işleri teknik açıdan inceliyoruz.

Bir iş planı çıkarıyoruz.

Ve hep birlikte sprintlerimizle bu iş planı...

Bu işleri dağıtıyoruz.

Sprintlerimiz başladığında da ilk olarak amacımız test eforu yüksek olan işleri öncelikle bitirebilmek.

Biz bu şekilde test developerlardaki iş dağılımını yönetebiliyoruz.

Yani test olan işleri Sprint'in ilk günlerinde alıyoruz.

Daha teknik veya test efor olmayan işleri Sprint'in son günlerinde alıyoruz.

Tabii ki pair programming trend yolunda çok kullanılan bir yöntem.

Biz de ekipte bunu sıkça yapmaya çalışıyoruz.

Hem onboarding süreçlerimizde hem de böyle büyük işlerde pair programming yapmaya çalışıyoruz.

zamanda kod review çok önemli bizim için de.

Projeyi geliştiren ekip arkadaşımız Merch Request açıyor.

Ekibin kalanı iki tane backend developer, üç backend developer var.

Kalan iki kişi bu Merch Request'leri review ediyor, kodları inceliyor.

Kod incelemesinden onay alan işleri testte hazır halde bekletiyoruz jira üzerinde.

Testten bir konu dönerse de onu önceliklendiriyoruz tabii ki.

Böylece bize de hataları düzeltmek için ve işlerin tekrar testinin yapılabilmesi için sprint için de zaman kalmış oluyor.

İş akışımızı backend tarafında böyle yönetebiliyoruz.

Ben de frontend tarafından bahsetmek isterim.

Frontend tarafında çalıştığımız projelerde yapı olarak micro frontend yapısı var.

O bahsettiğimiz az önce çok çok fazla olan domenlerimizi bir monorepoda tutmak yerine micro frontend yapısıyla ayrı ayrı projelerde tutuyoruz.

Bu sayede işte hepsinin release süreçleri ayrılıyor.

Yapacağımız işe ait tasarımları UI UX ekibimiz geliştiriyor.

Tasarımları daha çok baklava dizayn sisteme uygun bir şekilde geliştirdikleri için biz de baklavadaki komponentleri sayfalarımızda kullanabiliyoruz.

Onların tasarımlarından yola çıkarak işi ilgili projemize geliştirmeye başlıyoruz.

Birden fazla projemiz olduğundan, birden fazla repomuz olduğundan projeler arasında kod tekrarına düşmemek için de şöyle bir çözümümüz var.

Projelerde kullandığımız o ortak komponentleri...

bir pakete çıkartıyoruz.

Onun adına da PRC Components dedik ve o pakette tutuyoruz.

Her projemizde bu paket kurulu ve orada yaptığımız değişiklik tüm projelerimizi senkron tutabiliyor.

Tasarımda bu pakete eklememiz gereken bir şey varsa onu da ekliyoruz.

Ardından PR Review sürecinde çalışma arkadaşım Ali Yurtkulu ile ona da buradan selamlar.

Zoom'da toplanıp değişiklikleri inceliyoruz.

Ardından test edilebilir hale geliyor.

Ben de test tarafından devam edeyim.

Test aslında hani bu SDLC dediğimiz sürecin her aşamasında var.

İşte döküman geldiğinde herhangi biri biz ekip çoğunu inceliyoruz, bakıyoruz.

Düzeltilmesi gereken noktalar varsa tekrardan üstünden geçiyoruz ve düzeltiyoruz.

Ya da frontend için bir tasarım geldiğinde işte piyomuz var Emine.

Oradan buna da şey buradan ona da selam olsun bu arada.

Herkese tüm ekibe selamlar.

Evet evet bütün ekibe selamlar.

Tamam olsun. Emine bize Figma'dan tasarımları iletiyor.

Oradan tekrardan bir üstünden geçiyoruz.

Aslında bu da bir test. Ya da işte mesela kendi aralarında developerlar kocamı yaptıklarında orada da bir test süreci var.

Test tarafındaki test süreci nasıl oluyor bizim taraftaki?

O da eğer böyle çok biznessal bir iş geldiyse, çok fazla yere dokunuyorsa vesaire bir tane Excel var tuttuğumuz kendi içimizde.

Oraya mutlaka case by case ve hangi noktalar kontrol edilecekse onu...

Bunların notlarını alıyoruz. Kezleri koşuyoruz.

Herhangi bir aşamada bir problem çıkıyorsa...

Developerlarla da paylaşıyoruz o egzeli.

Developer da aslında şeyi çok net görebiliyor.

Hangi aşamada tıkanmış işte testçi, ne bekliyormuş da ne olmuş vesaire gibi.

Hem süreci offline yürütme şansı elde ediyoruz böylelikle.

Hem de ben hangi case'i koşmuştum, nerede kalmıştım vesaire.

Çok net bir şekilde görebiliyorum onu.

Bu iş bittikten sonra, manuel test tarafı bittikten sonra eğer otomasyonu yazılacaksa yine işte developerlarla bir araya gelip onun otomasyonunu yazabiliyoruz birlikte.

Ki test bakış açısı aslında tüm ekibe geçer.

Daha sonrasında da işi ilerletiyoruz.

Okey olan iş deployment, production'a kadar gidiyor gibi özetleyebilirim konuyu.

Çok özet olmadı ama. Bence çok iyiydi.

Burada bir ek sorum olacaktı.

Şimdi hem sizde frontend'ci var hem backend'ciler var ya.

Köylerde kendi arasında şey olarak bölünüyor mu?

Hani biri frontend'in? Hayır.

Yok. Direkt herkes her şeyi test mi ediyor?

Herkes her aşamada aslında bulunuyor.

Çünkü burada cross-functional bir sürece gitmek istiyoruz.

O da işte mesela testte çok ağırlık var diyelim ki sprint.

O aldığımız sprintte.

Bakıyoruz Frontend tarafında Evine'nin işte Piyo'nun test edebileceği bir şey varsa o test ediyor.

Ya da Backend tarafında developerlar kendi içerisinde de ya bunun test tarafına hani gerek yok.

Ya da onlarda çok ağırlık var.

Biz kendi içimizde Handle'e de...

biliriz dediğimiz noktalarda.

Fırlar da birbirlerinin işini test edebiliyor.

O yüzden frontend testçisi, backend testçisi vesaire gibi bir ayrım yok.

Ben olmaması tarafındayım da aynı zamanda.

Çünkü bu bir sürü farklı domen konuştuk hani ve herkesin aynı noktada olabilmesi, herkesin o domenin üzerinde bilgi sahibi olabilmesi için bu ayrımın olmaması bence

çok önemli bir yer. Onu da not olarak ekleyeyim.

Süper. Süper yani özellikle frontend ekiplerin olduğu ekiplerde ya da direct client ekiplerinde test edilebilir şekilde işleri ilerletmek ve test otomasyonlarının vesaire düzgün çalışması

falan bunlar çok önemli şeyler.

Ekibin de zaten anladığım kadarıyla test öncelikli şekilde iş geliştirme kültürü oldukça oturmuş durumda.

Ben biraz şey sormak istiyorum. Şimdi domenilerden bahsettik işte iş yapış süreçlerinden bahsettik falan.

Bu iş yapış süreçleri...

İçerisinde hangi teknolojileri kullanıyorsunuz?

Teksteyiniz işte backend için, frontend için ve test tarafı için nelerdir?

Ben frontend tarafından başlayabilirim.

Frontend olarak web tarafında Vue kullanıyoruz.

Vue 3 versiyonuyla yazıyoruz projelerimizi.

Module boundary olarak Vite kullanıyoruz.

Unit test yazmak için ise Vite test kullanıyoruz.

Paket yöneticisi olarak da PMPM kullanıyoruz.

Bunları takımımızda daha yeni kullanmaya getirdik.

geçiş yaptık. Daha önceden Vue 2, Webpack, Jest, NPM tool'ları kullanıyorduk.

Bu yeni tool'lar özellikle lokal ortamda geliştirme süreçlerimizi çok hızlandırdı.

Aynı şekilde pipeline sürelerimizde de azalma gördüğümüzü söyleyebilirim.

Mobil taraftaysa React Native kullanarak geliştirme süreçlerimizi ilerletiyoruz diyebilirim.

Ben yine testten devam edeyim.

Test tarafında mevcut bir acceptance test projemiz var Java diliyle geliştirdiğimiz ve Resteşürt Framework'ünü kullanıyoruz burada.

Test deneceği ile koşuyoruz.

Ama bekan tarafındaki testleri yine tren yolunun içindeki internal ekiplerin geliştirdiği bir yapı var.

Buradaki test ortamını steril hale getiriyor.

Testleri orada koşuyor.

Sonra test bittikten sonra indiriyor gibi düşünebiliriz.

Şimdi yapıyı biraz oraya geçirmeye çalışıyoruz ki hem stage'deki kullandığımız datalar kirlenmesin diye.

Yine backend'de bu tekrarlayan süreçlerle alakalı otomatize hale getirdiğimiz bir Python projemiz var.

Frontend tarafı için Cypress kullanıyoruz.

Load test tarafı için de yine Ares platformu var.

Internal ekiplerimizin geliştirdiği.

Oldukça kullanım kolay ve aslında bizim ihtiyaç duyabileceğimiz bütün dependencies'leri vesaireyi oraya entegre etmiş durumdalar.

O yüzden yük testi zamanlarında arası kullanıyoruz.

Farklı bir tool kullanmayı tercih etmiyoruz.

Test tarafı da böyle. Mobil kısmında da gelişme yapıyorsunuz ya React Native ile.

Ben şey sanıyordum önceden. Örneğin mobil ekibi var ve mobil ile ilgili her şeyi sadece onlar bakar gibi bir şey düşünüyordum.

Sanırım orayı yanlış biliyorum. Örneğin bir şey mi oluyor?

Sizin kendinize ait özel satıcı ile ilgili ekranınız varsa kendiniz yapıp satıcıya mı direkt veriyorsunuz?

Tam nasıl oluyor orası? Evet bir tane satıcı paneli uygulamamız var.

O uygulamada da Microfrontend var yine.

Bu Microfrontend yapısında ekipler kendilerine ait iş akış süreci oluşturabiliyorlar ve kendi ekranlarını tasarlayabiliyorlar.

Atıyorum ürün altında otomatik fiyatlandırma ekranımız var.

Otomatik fiyatlandırmaya tıklandığında benim projeme geliyor ve sadece benim yazdığım kodların derlendiği bir yerden benim ürünümü kullanmaya devam edebiliyor satıcı.

Oradaki süreçler de tamamen ayrı diyebilirim.

Orada React Native kullanıyoruz.

Süper, süper. Tamamdır. Teşekkür ederim.

Biri backend'den bahsediyordu. Çok böldüm, çok pardon.

Canan değil. Backend tarafında da aslında genel olarak Java ve Go dilinde uygulama geliştiriyoruz.

Java ile beraber Spring Framework'ünü sıkça kullanıyoruz.

Data Source olarak da Couchbase ve Postgre üstünde genelde bizim data kaynağı olarak kullandığımız kısımlar.

Genel olarak Evil Drive'ın microservice mimarisiyle uygulama geliştiriyoruz.

Bu yüzden Kafka'yı da çok sık kullanıyoruz aslında biz.

Bir de ek olarak galiba BigQuery'e besleme yaptığımız yerler var.

BigQuery'i de aslında ilgili ekiplere, business ekiplerine raporlama ve logları takip etme.

amacıyla kullanıyoruz diyebilirim.

Peki burada SPM'den bölündük demiştiniz ya.

Bu teknolojileri bahsederken büyük ihtimal şey diye tahmin ediyorum.

Onlarla beraberken zaten kullandığınız bir teknolojiler vardı.

Bölündüğünüz onları kullanmaya devam ettiniz veya sonradan yeni şeyler denediniz diye tahmin ediyorum.

O yüzden SPM ile beraber hala çalışıyorsun sanırım.

Onun dışında SPM ve Fraud'dan bahsetmiştiniz.

Onları hatırlıyorum. Bunun dışında böyle beraber çalıştığınız ekipler var mıydı?

Doğru hatırlıyorsun. Aslında o ekiplerle yakın çalışıyoruz.

SPM zaten en yakın çalıştığımız ekip diyebilirim.

Ama onun dışında bizim çalıştığımız ekipler domain bazlı değişiyor.

Nasıl mesela? Riskli ürün domeninde ana amacımız ürün açma-kapama olduğu için Restopikol ve Kafka eventleriyle ürün açan-kapatan SPM ve Listing ekibiyle birlikte çalışıyoruz.

Fraat ekibi Internal fraud kullanıcıları aslında bir panel üzerinden kural tanımlayabiliyor.

Onun dışında müşteriler şikayet edebiliyor demiştik.

Müşteri deneyim ekibi bu noktada bize geliyor.

Bizim servislerimizi kullanıyor ve müşteri şikayeti varsa bizde kural oluşturabiliyor.

Hızlı teslimat domenimizde teslimat süresi değişecek veriyi SPM, Data Science, DVH veseleri ekipleri bize besliyor.

Biz bu değişiklikleri yapıp ön yüze yansımasını istiyoruz.

Bu yüzden indexing ve listing ekibine haber veriyoruz bu noktada.

Recommendation ekibiyle ve yine SPM ekibiyle bağlantılar kuruyoruz.

Değişimleri bu ekiplere yolluyoruz ki ön yüze çıkabilsin.

Burada SPI ekibiyle de çalışıyoruz.

Son domainimiz otomatik fiyatlandırmada.

Data Science ekibinden değişecek veriyi dinleyip değişen fiyatları ürün sürecinde SPM ekibine yolluyoruz.

Özetle domain bazlı çalıştığımız ekipler de değişiyor.

Gayet iyi. Yani bayağı farklı takımla aslında yakın çalışıyorsunuz.

Bu da tahmin ettiğim kadarıyla zor oluyordur.

Yaşadığınız bir incident var mıdır?

Bizim podcast'ın en çok merak edilen konularından biri de bu oluyor.

Genelde ekiplere soruyoruz aynı.

Bir incident yaşadınız mı?

Tecrübeleriniz nelerdir? Bizlerle paylaşırsanız seviniriz.

Tabii ben anlatayım onu da.

Çok yakın zamanda yaşadık hatta.

Yakın zamanda bir tane sürecimiz bir ekipten başka bir ekibe transfer oldu.

Bu süreç içerisinde de iki taraftaki algoritmalarda aslında farklılık olduğunu production'da fark ettik.

Ve bu sebepten dolayı da birçok satıcı etkilendi.

Yaklaşık 31 milyon ürün.

Bu arada domain olarak da hızlı teslimata hit ediyor.

31 milyona yakın ürünün hızlı teslimat özelliği kaldırılma talebi geldi bize.

Neyse ki lag oluştuğu için 31 milyonun...

hepsi kalkmadı ama 11 milyon kadar ürünün zaten hızlı teslimatı kalkmıştı biz bu sorunu fark ettiğimizde.

Bizim bu tarafta daha öncesinde kurguladığımız adüt yapılarımız var.

Adüt logları bıraktığımız Kafka'ya topiklerimiz var.

O topiklerden daha önceki datayı aldık ve tekrar o 11 milyon ürün için düzeltme uyguladık.

Bu konuda o handover sırasında yeni alan ekipten de bize destek oldular.

Sorunu beraber çözdük biz.

Sorunlar yaşanabiliyor ama önemli olan birlikte çözebilmek diye düşünüyorum.

Bir şekilde çözdük diyeyim. Yani şaşkınlık içerisindeyim şu an çünkü ciddi bir probleme benziyor.

Yani bu kadar rahat andım.

Ben sizin yerinizde olsam bu kadar rahat andım.

Yani ödüler çekilmiş sonra içimdeki rehavet mi savunur?

Ya evet o gün bayağı bizi yormuştu bu arada.

Bayağı gece ikiye kadar falan bunu çözmek için uğraştık.

Ama bir sorun çözüldüğü için sanırım rahat anlatabildim diyeyim.

Ya Allah helal olsun gerçekten ellerinize sağlık ya.

Ya böyle zamanlar tabii ki olabiliyor.

Böyle şeyleri de önleyebilmek için ana...

Çözüm yollarımızdan biri de monitoring aslında.

Tam da bağlayacaktım çok iyi oldu.

Bir şey daha bahsedelim istiyorum.

Monitoring tarafında neler yapıyorsunuz ve bu monitoringlerden sonra ya da işte öncesinde herhangi bir support yapmanız gereken durumlar.

Oluyor mu? Bunlarla neler yapıyorsunuz?

Nasıl yönetiyorsunuz? Ben devam edeyim.

Test tarafından biraz bahsedeyim.

Burada acceptance testlerin içerisinde Allure Report adını verilen bir tool var aslında.

Onu implemente etmiştik.

Testler koştuktan sonra Slack'te kanallar var.

Oraya sonuçları basıyor.

Oradan kontrol edebiliyoruz aslında hangi kezler fail olmuş, neden fail olmuş diye.

Yine Gatak'tan bahsetmiştim.

Gatak tarafının kendi loglama süreci var.

ekstra bir tool vesaire kullanmamıza gerek kalmıyor.

GATEC'de koşan kezler fail olduğunda oradaki loglardan neden fail olduğunu görebiliyoruz aslında.

Frontend tarafından da ben bahsedebilirim.

Frontend tarafında error monitoring için Sentry kullanıyoruz.

Burada kullanıcıların aldığı hataları orada görebiliyoruz ve hatanın detaylarını inceleyebiliyoruz.

Aynı zamanda Sentry'de alarm tanımlarımız da var ve belirlediğimiz limitlerin üzerinde artmış varsa Slack kanalımıza bildirim olarak alıyoruz ve inceleme yapıyoruz diyebilirim.

Ben de backend kısmına değineyim.

Backend tarafında apilerimizin throughput, response time ve error rate gibi alarmlarını...

Nibirlik üzerinden yapıyoruz.

Bu trend yolda da çok kullanılan bir tool zaten.

Bir alarm tetiklendiğinde ekibin Slack kanalına mesaj düşüyor.

Ekipteki nöbetçi arkadaş bu alarmı kontrol ediyor.

Kafka, Couchbase, Elasticsearch gibi yapıları çok sık kullandığımızdan bahsetmiştik.

Yine bu yapılar içinde alarmlarımız mevcut.

Özellikle Kafka'da beklenenin üzerinde bir mesaj birikmesi olduğunda Slack kanalımıza mesaj geliyor.

Kubernetes tarafında da prot ortamında potlar ayağa kalkamadığında veya restart'a düştüğünde tetiklenen alarmlarımız var.

Bunların hepsi Slack kanallarımıza geliyor.

Öncelikle tüm kullandığımız tool'lar ve third party yapılar için alarmları tanımlıyoruz ki sistemde bir sorun olduğunda ekipteki herkes haberdar olabilse ve hemen aksiyon alabilelim.

Trendyol genelinde kullanılan onkologunu verdiğimiz bir sistem var ve bu sistem ekiptekiler arasında sıralı olarak bir nöbetçi belirlenmesini ve bir alert yaşandığında da bu kişiyle direkt olarak iletişime geçilmesini sağlıyor aslında.

Biz de bu sistemi aktif olarak kullanıyoruz ve ekip içerisinde de bir support ya da alert geldiğinde bu konularda nasıl aksiyon olacağımıza dair aktarım session'ları yaptık ve ekipte...

Herkesin aslında aynı noktaya gelmesini sağladık.

Daha önce de hiç karşılaşmadığımız bir case geldiği durumlarda Zoom'da Oncall adında bir odamız var.

O odada hep birlikte toplanıp aslında sorunu nasıl çözeriz diye hep birlikte beyin fırtınası yapıyoruz diyebilirim.

Bir de bir uygulamamız vardı. Belki Güdümser de ondan bahsetmek ister.

Onu atayım topu. Evet. Bir tane aslında içeride geliştirdiğimiz support bot uygulamamız var.

Çünkü biz ürünler üzerine işlem yapan ve birden fazla ekipe çalışan bu yüzden ürünü açmak, kapama veya hızlı teslimatın yansımaması gibi konularda support alanımız var.

Bir süre sonra fark ettik ki bu saportlar bizim işleri yaptığımızın önüne geçiyor.

Yani sprint işi yaparken bir yandan da saportlarla uğraştığımızı fark ettik.

Biz de bunların üstesinden gelebilmek için...

İçeride bir tane Slack bot uygulaması geliştirdik.

Java dilinde bu uygulama.

Bu uygulama ne yapıyor? Aslında sorunu adresliyor.

Yani satıcılarla iletişime geçen ve saporta alan kişiler sorunlu ürün bilgilerini giriyor.

Botu etiketliyor. Bot gidiyor üründeki sorunu bulmaya çalışıyor ve sorunun hangi ekipten kaynaklandığını bulmaya çalışıyor.

O ekibe bilgi geçiyor.

O ekibi etiketliyor gibi düşünebiliriz.

Bu bot sayesinde biz aslında ekibin ilgilenmesi gereken bir durum olursa ilgilenmesini sağladık.

Onkal arkadaşımız soruna bakıyor ekipten.

diğer sorunlarla diğer ekipler etiketlendiği için onlar ilgileniyor.

Support ayıracağımız sürede bölünmeden işlerimizi geliştirmeye devam ettik ve satıcılarımıza hızlı dönüş sağlayabildik.

Bu botun yani bu support işleminin bize böyle pozitif etkileri oldu.

Peki o zaman bir sonraki konuya geçmek istiyorum ben.

Sprintlerimizden bahsedebiliriz bence.

Şimdi her ekip farklı bir düzende ilerliyor trend yolda.

Örneğin bizim ekip iki haftalık sprintler koşuyor.

Tanıdığım başka arkadaşlar bir haftalık sprintler koştuklarını biliyorum.

Sizin tarafta bu Düzen nasıldır?

Birazcık şaşma düzeninizden bahseder misiniz?

Tabii ki. Burada biz haftalık sprintler koşuyoruz.

Perşembeden perşembeye olmak üzere.

Çarşamba grooming toplantımız, perşembe estimation toplantılarımız oluyor.

Groomingde işleri detaylı bir şekilde konuşuyoruz.

Burada jirada işlerimiz için oluşturduğumuz template'ler var.

O template'leri ile alana ilgili bilgileri doldurarak getiriyor piyomuz.

Net olmayan noktalar varsa sonraki toplantıya kadar netleştiriyor ve estimation'da puanlıyoruz bunu.

Estimasyon'da puanlanacak işlere label'lar veriyoruz.

Backend, frontend, test label'ları.

Böylece hangi geliştirme tarafında kaç puan alıyoruz, velocitemiz ne kadar gibi şeyleri rahatlıkla görebiliyoruz ve dengeyi çok rahat kurabiliyoruz diyebilirim.

Perşembe günleri de retro toplantılarımız var aynı zamanda.

Geçirdiğimiz sprintte bizi yoran, işte bloklandığımız noktalar var mı?

Bu noktaları konuşuyoruz.

İyi yaptığımız ve devam ettirmemiz gereken maddeleri de konuşuyoruz.

Kendimize bu toplantılarda aksiyon maddeleri çıkartıp hemen uygulamaya geçmeye çalışıyoruz.

Bende haftalık sprint deyince psikolojik şey oluyor.

Bizim ekipteki alışkanlıktan dolayı yani pazartesi planlama yapıyoruz.

Önce retro yapıp bir önceki haftanın sonra planlama yapıyoruz ve hani o haftayı komple bir haftalık ya o yüzden pazartesi başlıyor gibi kafam hep oraya gidiyor.

Hani şimdi sen perşembe dedin ya o yüzden çok ters geldi bana böyle.

Şey oluyor mu bunun herhangi bir yararı veya zararı bir pros konusu falan var mı gördüğünüz?

Şey bu arada biz de aslında pazartesiye çevirmeyi düşünüyoruz ya.

Sizin varsa öneriniz iyi mi kötü mü?

Ben tavsiye ederim.

Şöyle güzel oluyor. Yani psikolojik olarak hani hafta sonuna geldiğimde hani o hafta zaten bitmiş oluyor benim için.

Hani cuma kapattığımda gerçekten o hafta bitiyor.

Hani diployla açıkılmış oluyor vesaire.

Pazartesi gerçekten yeni bir şeye başlıyorum gibi oluyor.

Hani perşembe grubu yapmış oluyoruz.

Bir sonraki haftada ne yapacağımız belli gibi oluyor.

O yüzden ben memnunum.

Tavsiye ederim. Biz de bayramdan sonrası için planlıyoruz bu tarafta o tarz bir geçişi.

Ama toplantı tarihlerimizi değiştirmeyi planlamıyoruz sanırım.

Çünkü şey, cuma günleri biz genelde release almıyoruz.

Riskli olduğunu düşündüğümüz için.

O yüzden perşembe gününe kalırsa perşembeden release'leri bitirip işte pazartesi yeni sprint'e başlamak gibi.

gibi sanırım. Cumaları da biraz toplantı yoğunluğumuz oluyor açıkçası.

O şekilde bir deneyeceğiz bakalım. Olabilir.

Olabilir. Ya bir de ekiple ekiple çok fazla değişiyor tabii.

Cuma günü sizdeki risklerdir vesaire dediğin gibi biraz değişken oluyor.

Ama doğru. Mantıklı yani.

Peki orada işte şu gün retro yapıyoruz burada planlama yapıyoruz dediğiniz zamanlarda işte kendinize ayırdığınız zamanlar olabiliyor mu?

Ya da olduğunda ne yapıyorsunuz? Ya da Bir araya geldiğiniz sosyal etkinlikler var mı?

Örneğin mangal yapan ekipler var.

Gurme olan ekipler var.

Yani işte biz şuraya gidiyoruz, şurada şunu yiyoruz falan diye standartların çok yüksek olduğu.

BMW'lerden, arabalardan bahsettiğim ekipler de var.

Ekip ekip çok değişebiliyor kültürlerimiz.

Böyle eylem veya sosyallikte.

Sizde var mı bu tarz bir şeyler? Biz şöyle, ben biraz bahsedeyim.

Aslında bu ekip bence bizim ekip yani.

Hani çok fazla tren yolunun içerisinde diğer ekiplerin iç dinamiğini bilemiyorum tabii ki ama.

BRC ekibi bence... ekip ruhunu gerçekten yaşatan bir ekip.

İçinde olan biri olarak söylüyorum.

Burada retro toplantılarında vesaire aslında çok sık konuşuyoruz.

Hani biz neler yapıyoruz, neleri iyi yapıyoruz veya işte eğer bunaldığımız oluyorsa ki oluyor.

Yani çok yoğun çalışıyoruz çünkü hepimiz.

Zaman zaman böyle çok sıkıştığımızda kendimizi bunalmış hissettiğimiz noktalarda da retroda konuşuyoruz.

Diyoruz ki ya tamam bizim bir es verme, kısacık bir ara verme vaktimiz gelmiş artık diye.

Bu aksiyon olarak da işte o Oyun oynayalım, sohbet sesyonları düzenleyelim vesaire gibi aksiyonlar aldık.

Önümüzdeki hafta, bu hafta özür dilerim.

Hatta bu hafta böyle küçük belki bir sesyon yapacağız onun için.

Ve şunu fark ettik aslında diyeyim.

Ben iki buçuk yıldır bu ekiple çalışıyorum.

Ve gördüğüm şu açık, güvenli iletişim kurduğumuzda...

Her şey daha güzel akıyor.

Daha yumuşak bir yerden akıyor.

Sadece iyi olduğumuz şeyleri de konuşmuyoruz ekip içerisinde.

Az önce söylediğim gibi çok bunaldığımız ve dardayız.

Yardım edin. Yetişin komşular.

Evet gerçekten bu arada öyle bir retro geçirdik yani.

Böyle ben şey diyordum dardayım arkadaşlar falan diye.

Ve o noktaları da konuşuyoruz.

Yani ne yapabiliriz birbirimiz için aslında?

Çünkü ya 8-9 saat belki 10 saat hani birbirimizi görüyoruz.

Ve o noktada o yüzden aslında çözüm de bizden geçiyor gibi bir şey oluyor bence.

Ve mutlaka 2 ayda bir yüz yüze bir araya gelmeye çalışıyoruz.

Çünkü remote çalışılan bu dünyada hep böyle Zoom'da küçük bir kare olarak kalmayalım diye.

Geliyoruz bir araya işte eğlenmeye çıkıyoruz akşam.

İşte yeni dönemde böyle şeyler var.

Neydi ya? Komedyenler biliyorsunuzdur belki siz de.

Öyle bir etkinlik düzenleyeceğiz.

Öyle bir şeyler yapıyoruz yani.

Canımız ne isterse güzel yerlere biz de gitmeye çalışıyoruz.

Güzel kokteyl barlar vesaireler, restoranlar.

Öneri almak isteyen varsa bizim ekibi bulabilir.

Bugüne kadar... Biz birçok yerden de memnun kaldık.

Onu da böyle küçücük eklemiş olayım.

Harika. Harika. Çok teşekkür ederiz.

Gayet verimli süreçleri olan, verimli geçen bir ekip olduğunuzu bu podcast sonunda anlamış olduk.

Çok teşekkürler gerçekten.

Gülümser senin bir sorun var sanırım.

Onu da biz şu an alabiliriz.

Merak ettiğim bir konu var. Şimdi biz ekibimize anlattık.

Çok farklı domainlerden bahsettik ama sizin bizim ekiple ilgili aklınızda ne kaldı bunu merak ettim.

Valla bir defa ödülle bir alakanız yokmuş.

Bir kere bir beklersek insanları bir kandırıyorsunuz.

Yeni bir ekip ismine ihtiyacınız olduğunu düşünüyoruz üçümüzde.

Şahsen söyleyeyim oldukça fazla domain içeren, oldukça fazla domainle handle eden.

Ve iş süreçleri içerisinde front end, back end ve hatta mobilde olan multidisiplin bir ekip olduğunuz benim kafamda kaldı.

Ve açıkçası bir client ekibinde çalıştığım için özellikle de client ekibinin PDP tarafında çalıştığım için bizim sayfadaki birkaç yeri direkt olarak sizden aldığımızı bilmiyorduk.

Bilmiyordum yani. Benim aklımda bunlar kaldı diyebilirim.

Hakikaten quiz gibi oldu yani.

Evet aslında ben çok iyi hissettim.

Niye böyle baskı koydun? Çok güzel özetledin ama sen.

Teşekkür ederiz. Teşekkür ederiz.

Ben de şeyden bahsetmek istiyorum.

Hani buybox diye terim vardı ya.

Ben onu bir havasına atarım.

İlk defa duyduğum için. Bakın böyle bir şey var.

Bu da bu anlama geliyor falan diye.

Benim için şey bir terim oldu böyle. Hani bugün ne öğrendin dediğinizde böyle.

Hani şöyle bir şey varmış.

Bundan böyle bir şey varmış.

Gibisinden bahsedeceğim bir konu oldu yani.

Ben ilk defa duydum. Peki tamam.

Teşekkürler. İlk defa bize de bir podcast bölümünde.

Biz anlattık siz neler anladınız diye soru soruldu.

Biz de şarjına döndük.

Ama çok teşekkür ederiz.

Çok keyifli bir bölümdü bizim için.

Oldukça da böyle dolu dolu geçti.

Geldiğiniz için çok teşekkürler arkadaşlar.

Biz teşekkür ederiz bizi çağırdığınız için.

Teşekkür ederiz. Görüşmek üzere.

Çok keyifli. Süper. Bir sonraki bölümde görüşmek üzere.

Esenlikle kalın. Bay bay.

Bay bay.