Konuklar: Sude Kılıç, Ekin Şuataman, Onur Temiz
77. bölümümüzde konuğumuz Engagement Products ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Trendyol Talks'da Trendyol'daki kültürümüzü, kültürümüzden beslenen iş yapış biçimlerimizi ve ritüellerimizi konuşuyoruz. Trendyol Talks podcast kanalımızı takip etmeyi unutmayın!
Transkript
Selam ekip, ben Storefront ve Browsing ekibinden Cengiz.
Ben de Collection Favorites ekibinden Kübra.
Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 77.
bölümündeyiz. Ve 77.
bölümde yine çok güzel bir ekip bizlerle beraber Engagement Products ekibiyle birlikteyiz bugün.
Bu ekibi tanıyacağız. Kullanılan teknolojiler, ekip yapısı, pratikler gibi konuları konuşacağız.
Arkadaşlar hepiniz hoş geldiniz.
Hoş bulduk. Merhaba.
Bugün çok heyecanlıyız.
Güzel bir ekip yine bizlerle beraber.
Enerjimiz yüksek, gençliğimiz var diyerek ufaktan başlayalım.
Kısaca kendisini tanıtabilir misiniz arkadaşlar?
Tabii ben başlayayım.
Ben Sude Kılıç.
Trendyol'da 3 senedir backend developer olarak çalışıyorum.
Engagement products'dan önce de yaklaşık 1,5 senedir financial services ekibindeydim.
Hatta Onur'la birlikteydik orada da.
Sonrasında bu ekibe geçiş yaptık.
Onur'a atayım topu.
Merhaba, ben Donur. Ben de Suriye'yle benzer zamanda tren yolda başladım.
Yakın zamanda dondurma makinesi aldım, evde dondurma yapıyorum.
Bunu söyleyebilirim kendimle ilgili.
Bu yani podcast'e başlarken bu detayı vermen muhteşem oldu.
Hani ekip yapısı, kaç senedir buradasın, ne yapıyorsun falan.
Hayır, önce dondurma makinesi.
Evet. Çok güzel, hoş geldin.
Ben de topu o zaman Ekin'e atayım.
Selamlar, ben Ekin. Ben de Trendyol'da yaklaşık bir buçuk senedir Development Test Rönü'nde çalışıyorum.
Ekibe ben Nisan ayında dair olmuştum, geçen sene Nisan'da.
Ondan önce altı ay kadar da Coin ekibindeydim.
Benim de bu şekilde diyebiliriz.
Süper, hoş geldiniz. Anladığım kadarıyla Sude ve Ekin'in dondurma makinesi yok, değil mi?
Doğruyuz. Evet bizi daha ikna edemedi.
Onlar biraz çalışmalar mevcut o açıdan.
Baya böyle tanıtım videosu falan paylaştı ama daha tam ikna olmadık.
Bu arada Şarkın İnce'den, aynen Şarkın İnce'den affiliate alacağım yakında.
Yani review falan yapıyorum. Goygoy kanallarında ama daha bütün ekibe yayamadım dondurma makinesiyle.
Slash reklam diye de araya sıkıştıralım bir makyajı da geçti.
Bu arada Onur seni anlayabiliyorum.
Çünkü ben de eşimi ikna edebilsem ben de alacağım açıkçası.
Yani fakat ne gerek var cevaplarıyla karşı karşıya kaldığım için alamıyordum.
Hayırlı uğurlu olsun. Umarım güzel güzel dondurmalar yapar yersin.
Okey dondurma konusunu bir kenara bıraktığımıza göre takımla alakalı devam edebiliriz.
Ufaktan şeyle başlayalım.
Engagement Products ekibi ne yapar, hangi ürünlerden, nelerden sorumludur arkadaşlar?
Ya şöyle aslında isminden de anlaşıldığı gibi amacımız Engagement'ı artırmak kullanıcıların.
Bunun içinde çeşitli tool'larımız var.
Biz ilk kurulduğumuz zaman başka bir ekipten iki tane tool aldık, devre aldık.
Birincisi Daily Check-in tool'u.
Mantığı da aslında çok basit.
Her gün uygulamaya girdiğin zaman daily check-in sayfasına gidebiliyorsun.
Gittiğin zaman da check-in yapıyorsun.
Check-in yaptığında da kullanıcıya işte bir miktar coin veriyoruz.
Bu coin'i ardından bir şeyler satın alırken kullanabiliyor, harcayabiliyor.
İkinci devre aldığımız ürün de şans çekilişti.
O da zaten TR'de çok popüler bir uygulama.
Daha fazla onunla ilgili detay vermeme gerek yok.
Daily Check'in tarafında hatta yakın zamanda bir A-B uygulaması, A-B'yi de yaptık hani ne kadar etkili bir tool diye.
Baktığımız zaman da hani Cost Per Session metriğinde çoğu tool'a kıyasla bayağı iyi değerlere sahip.
Hani çok az para verip aslında kullanıcıları engeç ettiğimiz bir tool diyebilirim.
Şu anda Gulf bölgesinde var bir de bazı Avrupa ülkelerinde var Daily Check'in uygulaması.
Daily Check'inden sonra... Daily Quest uygulamasını yaptık.
O da aslında şu şekilde çalışıyor.
Sayfaya geldiğiniz zaman sizin segmentinize göre sağlıyorum.
Mesela push açık değildir, e-post açık değildir.
Bu tarz questler gösteriyoruz.
Pushunu açarsan şu kadar coin veririz sana, e-postunu açarsan şu kadar veririz.
Bir de mesela yakın zamanda bir ürün almışsındır, ona yorum yazmamışsındır.
O zaman da şey diyoruz, yorum yazarsan şu kadar coin veririz.
Eğer bu tarz segmentlerde değilsen de ekstra olarak görevlerimiz var.
Şu sayfaya git hani bestseller sayfasına git orada biraz 10 saniye 15 saniye takıl ürünlere bak sana coin verelim.
Hani burada gene sayfalar arası engagement'ı da arttırıyoruz.
Öyle diyebilirim. Şey olarak anlıyorum aslında biraz böyle sitedeki aslında kullanıcıların bir nevi oyunlaştırmaya yönelik hani böyle oyunlaştırmayla birlikte etkileşimi arttırmak.
Gibi amaçları var öyleyse.
Evet aynen aslında o şekilde.
Yakın zamanlarda da yayınladığımız Share&Win tool'u var.
O da gene Türkiye'de paylaş kazan diye geçiyor.
Bu tool aslında o engagement'ı daha da arttırır.
Sadece uygulama içinde değil de uygulama dışında da taşımaya çalıştığımız bir şey.
Ondan o mantık şu. Kullanıcı sayfaya gelir bir journey başlatır.
Journey başlattıktan sonra paylaştığı, uygulama içerisinde paylaştığı linklerden başka kullanıcılar satın alırsa %5 eğer teknolojisi %2 civarında coin kazanıyor gene.
Bir de hani bu ürün paylaşma dışında koleksiyon da oluşturabilir.
Eğer oluşturduğu koleksiyonları da gene insanlar takip ederse, kaydederse bu durumda gene belli bir miktar coin kazanıyor.
Bu tool'umuz da TR'de de var aslında, Türkiye'de de var.
Gene Gulf, EU ülkelerinde de olan bir tool diyebilirim.
Aslında Onur da o yüzden bize dondurma makinesi pazarlamaya çalışıyor.
Bizle paylaşıp onun üzerinden muhtemelen coin kazanmaya çalışacak diye düşünüyorum ben artık.
Aynen foyamız ortaya çıktı.
Vallahi ne desem bilemedim.
Şu an bu podcast'ı terk mi etsem yoksa link mi üstü ben bilemedim açıkçası.
Ekmeğindesin kardeşim. Aynen %5 %5 toplamaya çalışıyoruz.
Onu bana link atabilirsin.
Ben direkt dondurma deyince ikna oldum çünkü.
Olur kank. Harika süper.
Valla çok güzelmiş. Aslında bizim trend yolu kullanırken herhangi bir yerde karşımıza çıkabiliyorsunuz.
Bence bu çok keyifli bir şey yani.
Bu süreçleri yapmak da oldukça eğlenceli olsa gerek.
Peki ekip yapısı nasıldır sizde?
Ekip kaç kişiden oluşuyor, roller neler?
Nasıl bir yapılandırma var içeride?
Şöyle aslında ekip kurulduktan sonra yani bir sene kadar ekip 9 kişiydi.
Bu yılın Şubat ayından itibaren de 2 bekentçi arkadaşımız daha bize katıldı.
Şu anda da totalde 11 kişiden oluşan bir ekip.
ekibiz. Ekipte 6 backend, 2 frontend, 1 QA, 1 product manager ve 1 staff engineer var.
Bir de ekip liderimiz var.
Onu da katarsak 12 kişi olduk diyebilirim şu an.
Evet gerçekten kalabalık bir ekipmişsiniz Sude.
Peki hiç ben bu ekibime rotasyona geldim de sizi de merak ediyorum.
Hiç böyle durumlar oldu mu?
Buradaki olduysa da eğer nasıl ilerliyor süreçler?
Her ekipte aynı mı onboarding?
Biraz onları merak ediyorum.
Tabii ondan da ben bahsedeyim.
Şubat ayında Ekin'in de dediği gibi iki yeni arkadaş katıldı aramıza.
Yani aslında trend yolu için rotasyonla geldikleri için onboarding süreci biraz daha hızlı ilerledi.
Çünkü hani normalde trend yolu yapısı, kültür gibi konuları da aktarıyoruz.
Ama biz burada daha çok böyle takıma özel konulara odaklandık.
Burada da şöyle ilerledik.
Bir haftalık bir onboarding takvimi oluşturduk.
Burada da işte tüm projelerimiz için önce PM'imiz Sinan proje aktarımını yaptı.
Sonra da Bekent ekibinden bir kişi de teknik mimariyi anladı.
Proje aktarımları dışında işte Onur Frontend teknolojilerini, Ekin QA süreçleri, Tech Lead'imiz Aycan'da Technical Backlog gibi konularda bilgi verdi.
Böylelikle de aslında hani ilk haftadan böyle herkesle tanışma, birebir konuşma fırsatı yaratmış olduk.
Haftanın sonunda da Buddy ile birebir organize ettik.
Hani ilk hafta deneyimini onların gözünden dinledik, soruları, feedbackleri aldık.
Zaten sonraki haftalarda da artık böyle bizlerle de payrolup işlerin içine girmeye başladılar.
Güzel bir süreç valla yani zaten Trendyol'a çoğu ekip rotasyonla alakalı kendi özel süreçlerini oluşturuyor.
Hani burada çok fazla yoğurt yeme biçimi var.
Fakat hepsinde aslında bir ana düşünce var.
O ana düşüncede hani yeni gelen arkadaş, rotasyonla gelen arkadaş nasıl rahat edebilir, nasıl ekibe uyum sağlayabilir?
Ana concern bu olmuş durumda.
Bu da benim çok beğendiğim bir yaklaşım açıkçası.
Elinize sağlık burada. Biraz teknoloji tarafından...
konuşalım isterseniz. Burada Engaging Products ekibi içerisinde siz hangi teknolojileri kullanıyorsunuz?
Ben Frontend ile başlayabilirim.
Biz React kullanıyoruz aslında.
İki farklı projemiz var şu anda.
Bir daha önceden devraldığımız şans çekiliş projesi.
Bir de yeni yazdığımız Daily Check-in Projesi vesaire projelerin yer aldığı.
İkisinde de React kullanıyoruz.
Yeni projede aslında Next.js ile devam ettik.
Şans çekilişte de normalde Create React hep kullanıyordu ama yakın zamanda onu da Next.js'e geçirdik.
Ekip olarak Next.js'i seviyoruz.
Onun dışında CSS yazarken de Tailwind kullanıyoruz.
Bir de bizim sayfalarda animasyon çok önemli oluyor.
Dediğim gibi biraz da oyun hissi yaratmak istediğimiz için animasyon yazmak için de Framework Motion kütüphanesini kullanıyoruz diyebilirim.
Çok güzel ya. Yani ben Client ekibinde çalışan biri olarak diğer teknolojileri duymadan önce araya girmek istedim.
Yani Frame Remotion kullanan ilk sizi duydum ve çok mutlu oldum açıkçası.
Benim çok sevdiğim bir kütüphanedir.
Araya bu mutluluğunu paylaşmak istedim.
Teşekkür ederim beni mutlu ettiğiniz için.
Aynen Frame Remotion'da baya bir şey yapılabiliyor.
Yani biz de çok kullanmayı seviyoruz.
Hani belki bir gün Gülük'te de paylaşabiliriz yaptığımız şeyleri.
Güzel olabilir. Ben de o zaman backend tarafından bahsedeyim.
Biz de programlama dili olarak ağırlıklı Kotlin kullanıyoruz.
Bunun dışında işte Go servislerimiz var.
Gateway'imiz bunlardan biri.
Java projelerimiz de mevcut.
Database olarak ağırlıklı Couchbase kullanıyoruz.
Tabi ihtiyaca göre Elasticsearch kullandığımız veya Postgre integrasyon olan servislerimiz de var.
Ve tabi Trendyol geneli gibi Event Streaming içinde Kafka kullanıyoruz.
Ben de test tarafından bahsedeyim kısaca.
Test tarafında da backend testler için her proje için oluşturulmuş acceptance test projeleri var.
Ağırlıklı olarak çoğu test projesi kod dinliliğinde bir acceptance test projesi de Java'yı kullanıyoruz.
Test framework olarak da tüm projelerde yine test deniciyi kullanıyoruz.
Backend tarafına ekstra olarak GATEC entegrasyonu da yapıyoruz şu anda.
Frontend tarafında da end-to-end testler var.
O projede de JavaScript kullanıldı.
End-to-end testler ek olarak bir de mobil cihazlardan yapılan ön yüz testlerimiz oluyor.
Her projeyi canlıya çıkmadan önce bir de load test yapıyoruz.
Bunun için de şirket içerisinde kullanılan Ares ekibinin geliştirdiği performans testing tool'unu kullanıyoruz.
Test tarafı da bu şekilde.
Test tarafında zaten Trendyol içerisinde çoğumuzun kullandığı ortak tool'lar gerçekten hepsi.
Ve işte şey son olarak böyle gateye geçirme durumları falan nasıl gidiyor Ekin peki?
Hani hepimizi ortaklaştıran bir durum bu gateye geçiş.
Evet doğru. Bir tık şu anda GT'ye çok zaman ayıramıyoruz.
Yeni bir proje başlangıcımız olduğu için, daha doğrusu proje yaptığımız için.
En sonunda sanırım bu hafta bir vakit bulabilirsek tekrar komponentleri bağlamak için projeye tekrar giriş yapacağız gibi duruyor.
Şimdiden elinize sağlık.
Peki sprintler nasıl koşuluyor bu ekipte?
Kaç haftalık koşuyorsunuz ya da ekstra düzenli olarak yaptığınız toplantılar var mı?
Sprintlerimiz bir haftalık oluyor.
Her salıdan salıya gibi.
Sanırım sadece bir defa iki haftalık bir sprint planlamıştık.
O da geçen sene kurban bayramı tatiline denk geliyordu.
Resmi tatil olduğu için çoğunluğu iki haftalık planlamıştık.
Onun dışında daily toplantılarımızı da her sabah yapıyoruz.
Günlük olarak daily'leri ilerletiyoruz.
Her salı yine 10.45'te böyle planning grooming birleşik bir toplantı akışımız var.
İki toplantıyı blok şeklinde yapıyoruz.
İlk planning yaptıktan hemen sonra grooming'e geçmek bize daha mantıklı gelmişti.
O akışı denedikten sonra hala strik bir şekilde devam ediyoruz.
Onlardan önce de pazartesi günü hani groominglerden önce estimationlar oluyor.
Hem backend hem frontend tarafında ayrı ayrı estimationda aslında bütün taskları yapılması gerekenleri ve test kezlerini konuşup ona göre test telefonunda katarak puanlıyoruz.
Sanırım bu şekilde bir de retro var.
Retro'yu da iki haftalık yapıyoruz.
Yine yoğunluğumuza göre bazen üç hafta oluyor.
Bazen iki hafta gibi ilerliyoruz.
Peki retro sizin overall retro mu oluyor yoksa sprint review sprint retro tarzında toplantılar koşuyor musunuz?
Yok ayrıntılı yapmıyoruz o kadar.
Genel bir retro gibi oluyor.
Anladım. Aslında bizim takımda da mesela önerebilirim bunu size düşünürseniz.
Çünkü sprint review'lar özellikle haftalık koşulan sprintlerde neler yanlış gitti, neler doğru gitti, bu hafta neleri işte biz böyle önemli şekilde yaptık ya da nelere dikkat etmemiz lazım
haftaya gibi konularda sprint review ya da sprint retroaktif ne derseniz bence oldukça faydalı oluyor.
Biz birçok ekibe de öneriyoruz.
Bizde bayağıdır yani birkaç aydır.
bu şekilde ilerliyoruz ve çok faydasını gördüğümüzü söyleyebilirim.
Size de öneririm. Belki biz de bunu bir denemeye alırız olmadı.
Siz bir kenara not edin isterseniz.
Ben de Ekin'in sprint ritüellerinden biraz bahsettim.
Ben de böyle düzenli toplantılardan bahsedeyim.
Orada da böyle epey bir toplantı var.
Atlamamak için sıklığa göre sırayla gideceğim.
Her ay 4K review metrik toplantısı yapıyoruz.
Burada böyle takımcı metrikleri inceleyip, işte iyileşim alanları varsa nedenlerini konuşup, onlar üzerine aksiyonlar alıyoruz.
Yine aynı toplantıda işte servislerin response time'larını, servis müşteri skorlarını, security issue sayılarını da gözden geçiriyoruz.
Bunun dışında yine aylık yaptığımız OKR review toplantısı var.
Burada da aslında takım OKR'larının üzerinden geçerek, OKR'larda ne kadar ilerleme kaydettiğimizi, hangi OKR'lara biraz daha fazla odaklanmamız gerektiğini konuşuyoruz.
Son aylık toplantımız da roadmap.
İçinde bulunduğumuz çeyrekte ve ayda hangi projelere odaklanacağımızı, önümüzde de nelerin olduğunu konuşup roadmap üzerinde aslında sync oluyoruz.
Bunun dışında 3 haftada bir yaptığımız anomaly detecting toplantısı var.
Burada servislerin error ve warning loglarını inceleyip aslında potansiyel bir sorunu fazla büyümeden fark etmeyi ve varsa false pozitifleri gidermeyi amaçlıyoruz.
Bunlar dışında takımda herkes zaten takım liderimiz Fırat'la haftalık birebir yapıyor ama içi birbirimizle de böyle en az iki ayda bir olacak şekilde birebir yapıyoruz.
Bunun için de bir takvim oluşturduk.
Yani böyle her haftaya bir iki tane birebir düşüyor gibi oluyor.
Buna ek olarak haftalık yaptığımız işte oyun ve sohbet sesyonu için gathering toplantımız var.
Ve son olarak da daha tam düzene oturtamadık ama ara ara yaptığımız takım içi tech talkslarımız var.
Çok iyi. Bu en son bahsettiğin anomali toplantısı da bu arada biz de yine haftalık.
Ya onu da biz haftalık yapıyoruz ama hani tabii ki şey yok yani.
Taşa yazılmış bir kural yok burada.
Hani sizin için bu faydalıysa bu şekilde yapılması daha iyi tabii ki.
Sonuçta şeyler ağırlıklar takımdan takıma göre değişiyor.
Biti'de yani böyle başlangıçta biraz daha sık yapıyorduk.
Sonra hani oraları biraz temizleyip toparlayınca 3 haftada bir yaptık ama ihtiyaca göre yine hani sıklığını değiştiriyoruz arada.
Süper süper ellerinize sağlık tekrardan.
Okey, birazcık da şeyden konuşalım istiyorum.
Şimdi ekip yapısından bahsettik, toplantılardan bahsettik.
Biraz da aslında bir sizin tarafta bir iş başlangıcından sonuna nasıl oluyor?
Biraz bundan konuşalım istiyorum.
Bir işin bir fikirden çıkıp, ortaya çıkıp son kullanıcıya ulaşma serüveni sizin ekipte tam olarak nasıl oluyor?
Tabii bunu da ben etikliyim.
Böyle fikrin oluşma kısmına geçip daha hayatı nasıl geçiyor o kısmı özetlemeye çalışacağım.
İlk önce bize draft bir dizaynla project proposition geliyor.
Biz bu arada genelde DDD'ye uygun ilerlemeye çalışıyoruz.
Ve önce hep birlikte event storming seçimleri yapıyoruz.
Burada da aslında işte eventler, aktörler, bounded konteksler belli oluyor.
Tabii yüklü kütüsü language de bir yandan oluşmaya başlıyor.
Ardından işte PM, QA ve Kent Frontend ekibinden en az birer kişiyle example mappingler çıkartılıyor.
Tabii case'lerin üzerinden hep birlikte de geçiyoruz ve architectural design'e başlıyoruz.
Burada genelde Excal'i kullanıyoruz biz.
Excal'i üzerinden teknik mimariyi çizip işte servisler, endpoint'ler, DB modelleri, collection'lar, scope'lar onlar belirleniyor.
Netleşmesi gereken yerleri not alıyoruz.
İşte sorulacak sorular varsa onları not alıyoruz.
Ve artık bu aşamada backend tarafı için raf ve estimation verebiliyoruz.
Paralelde de dizayn kısmı ilerliyor biz bunları yaparken.
Bizdeki contract ve endpointler belli olduktan sonra da frontend mimari yanımız başlıyor.
Sonrasında işte kartları açıyoruz.
Bir yandan groom edip bir yandan daha net olanları planlamalarda sprint'e dahil ediyoruz.
Geliştirmeler tamamlandıktan sonra da UAT ve load test yapılıyor.
En son aşamada da artık application security taraması da başarılı geçtiyse production checklist'imizi kontrol edip projeyi canlıya alıyoruz.
Peki ben burada şeyi merak ediyorum biraz da.
Bu işler alındı.
Bundan sonra test süreçleri nasıl ilerleniyor peki?
Çünkü her ekipte burası biraz daha özelleşiyor.
Onu merak ediyorum. Aslında bizde de öyle.
Çünkü şöyle yani eğer yeni bir projeye başlayacaksak ki geçen sene bizim için fazlaca yeni proje yaptığımız bir seneydi.
Test süreçlerini de ona entegre olacak şekilde ilerlettik.
Sude'nin de dediği gibi event storming'den sonra example mapping çalışması yapıyoruz.
Example mapping de aslında yeni yapılacak bir projedeki ya da eğer yine kapsamlı bir feature geliştirilecekse de uygulanabilecek bir çalışma.
Story, example, rule ve question olmak üzere dört ana kriteri hesaba katarak projenin test case'lerini çıkarıyorsunuz.
Queue olarak ilk önce ben projede üzerinden geçeceğimiz akıştan test case'lerini çıkıyorum.
Ardından Sinan'la, Sinan da bizim ekibimizin PM'i bu arada, üzerinden geçiyoruz.
Son olarak da ekipçe bir toplantıda hep birlikte çıkarılan case'lerin üzerinden geçip test case'leri aslında netleştirmiş oluyoruz.
Genelde edge case'ler varsa da hani konuştuğumuz toplantı aslında buraya hit ediyor.
Projenin geliştirmesi başlandığında da aslında task'lar açıldıkça task'lara hit eden case'ler aşağı yukarı belli olmuş olduğu için ben acceptance test'e ne yazmaya başlıyorum.
Frontend tarafında da şöyle oluyor.
Projenin canlıya çıkmasına yakın stage ve pre-prot ortamlarında ön yüz testleri yapıyoruz.
Genelde Onur'la orada tüm akışların üzerine en son bir konuşup UET için test kezlerini çıkartıyorum ben bu sefer.
Bug'lar varsa onlar fiksendikten sonra da UET toplantısını set ediyoruz.
UET'de de bazen internal olarak kendi içimizde Sinan Frontend ekibi, Backend ve ben olarak.
Bazen de diğer ekiplere proje göstermemiz gerekiyorsa external bilgi üyesi set ediyoruz.
Yük testi aşaması var.
Bir de onu da en son tam artık canlıya çıkmadan önce bütün front end, back end takışları tamamlandığında bir ülke seçip trafiğin özellikle fazla olduğu bir ülke seçip saatini
de artık o ülkenin trafiği ne zaman düşükse ki genelde gece saattir oluyor.
Gece saatinde bir load test oluşturup Onu koşuyoruz ve aslında tüm canlıya çıkış serüvenimiz böyle tamamlanmış oluyor diyebiliriz.
Peki Ekim bir şey daha soracağım.
Burada mesela diyelim ki bir işin hem backend hem frontend hem de yük testi aşaması var ya bunların hepsini mesela aynı taskta otomatize edebiliyor musunuz?
Hepsi aynı taskta.
Pardon sen devam et.
Hem ön yüz testleri, end-to-end testler, acceptance testler gerçekten otomatize edilip mi ilerleniyor?
Yoksa hani otomasyonlar yazılıyor işte backend tarafa atıyorum.
İşte frontend tarafı manuel bir test edilip daha sonradan bir kezler ekleniyor gibi.
Şöyle backend'de acceptance testlerin otomasyonunu zaten hep yazıyoruz.
O tasklarla paralel gidiyor.
Frontend tarafını da genelde manuel yapıp hani sonrasında testlerini ekleyebiliyoruz.
Bu canlı çıkış sürecinde genelde böyle bir deadline'ımız olduğu için hani yetiştirmek amacıyla ilk başta aslında böyle bir akış oturtuyoruz.
Elinize sağlık. Ben de gerçekten şey çok iyi bir test süreci oturtmuşsunuz.
Hatta böyle bir iki not daha aldım.
Bu toplantı kısımlarında falan UAE tık kısımlarına.
Onları belki bizim ekibe de yedirebilirim.
Teşekkür ediyoruz o yüzden.
Tamam. Süper.
Ellerinize sağlık tekrardan.
Birazcık da aslında her bölümde konuştuğumuz ve acı dolu, daha doğrusu deneyim dolu kısma gelmiş bulunmaktayız.
İşte alert mekanizmaları, monitoring süreçleri, incidentlar falan filan.
Burada sizin alert mekanizmanız, monitoring süreçleriniz vs.
nasıl işliyor? Öncelikle onkoldan başlayayım.
Çoğu ekip gibi muhtemelen günlük nöbetçi oluyoruz.
Ertesi günkü nöbetçi de backup oluyor.
Genelde böyle zaten nöbetçinin gün içerisinde birkaç kere Kibana'ya nöbreliği kontrol etmesini bekliyoruz.
Ama bizim takım gerçekten böyle bu konuda çok mütevazı olamayacağım.
Çok bilinçli davranıyoruz yani.
Mesela bir kart işte proda çıktıktan sonra geliştirme sahibi bir süre monitör ediyor.
Veya işte kanala alert düştüyse böyle nöbetçi beklenmeden ilk gören kişi inceleyip gerekli iletişimi kuruyor.
Hatta... Böyle PM'imizin bir derfi eventlerinden oluşan raporu var.
Onun bile işte hata eventlerinde bir artış olmuş, burada bir sıkıntı olabilir mi deyip böyle bizi uyardığı bir case bile olmuştu.
Tabii hani alert tanımlarımız da gayet kapsamlı.
Zaten hani klasik olarak Kibana'da Sile'yi, Onkola'yı thresholdlarda tetikleyen alert polislerimiz var.
Nürilik ve Beholder'da biraz daha performans odaklı alarmlarımız var.
Onlar dışında mesela bir Kafka eventi konzüm edilirken hata oluşursa retryleyip böyle 3-4 deneme sonrasında error topiğine yazıyoruz.
Eğer error topiğine bir mesaj yazılırsa gelen alarmımız var.
Daha önce dediğim gibi bizim datamız genelde Couchbase'de duruyor ama raporlama veya kampanya iletişimlerinin kurulması için biz bu datayı BigQuery'e aktarıyoruz.
O aradaki Couchbase konektörü veya data product fail olursa alarmlarımız var.
Mergen'de frontend alertleri var.
Ve son olarak da aklıma gelen böyle daha hani business related ne örnek verebilirim?
Mesela şey şüpheli deli çekin sayısı artışı gibi konuları yakalamak için de PG alarmlarımız var.
Peki Sude yaşadığınız böyle bir incident anısı var mı?
İşte şimdi bittik, nasıl doperleyeceğiz dediğiniz.
Burada böyle çok yakın bir zamanda olmadı ama geçen sene olan bir incidentımız var.
Gerçekten yani böyle ibretlik bir incident.
Hatta işte anlatalım falan da demiştik ama sonrasında çok zaman olmadı.
Couchbase kaynaklı bir...
Sıkıntı yaşadık biz. Burada işte notlar fail oluyordu.
Zaten işte Mars'ı DC kullanıyoruz Mars ve Venüs'te.
İşte Mars tarafında timeout almaya başlıyoruz.
Mars'ı restart ediyorlar.
Bu sefer Venüs'ten timeout almaya başlıyoruz.
Böyle hani günlerce bunun üzerine böyle işte çalıştık.
DBA ekibiyle çalıştık.
Hani artık işin içinden çıkamıyoruz.
İşte daha sonra şey yaptık hatta yeni bir Couchbase cluster oluşturdular.
Uygulamaları oraya taşıdık.
İşte bizim de zaten böyle beş tane falan uygulamamız var.
Tek tek taşıyoruz ki hangi projede sıkıntı var onu da anlamaya çalışıyoruz bir yandan.
Yani o da hiç belli değil. Sorunu anlayamadığımız için de tabii çözümü de bulamıyoruz.
Sonra tabii böyle bayağı bir uğraştık.
Geceleri alarmlar yağıyor falan.
Sonra Couchbase'in kendi direkt Couchbase'den ekipten destek istedik.
Orada bir kayıt açıldı.
Sonra onların incelemesi sonucu tamamen onların tarafından kaynaklanan ve bizim bir tane projemizde bir sorun varmış.
Yani orada da gerçekten şaşırdık çünkü Trendyol'daki çoğu ekip hani Couchbase kullanıyor.
Burada da işte böyle transactional işlemlerle ilgili bir sıkıntı olmuş.
Bizim işte ShareMVim projesinde transaction işlemlerden dolayı işte Couchbase tarafındaki bir bug nedeniyle bizim Couchbase notları sürekli işte düşüyordu.
Biz sürekli işte restart ediyorduk.
Böyle bir döngüye girdi.
Sonra tabii Couchbase'de de çok hızlı çözülmedi sorun.
Hani onlar tıkıtı oluşturdu, onaylanması sürdü.
Sonra işte geliştirme yaptılar.
Code review'ları bile böyle iki hafta falan sürdü yani.
Sonra da işte hemen yeni sürümü çıktılar.
Tabii hani bizim bu sefer DBA ekiplerin yeni sürümü de biz bir test ediyoruz.
Ödelim hani hemen direkt geçirmeyelim falan gibi orada da böyle bir bekleme oldu.
O sırada biz bu problemle hani şey renvini ayırdık.
XTCR'ı kapattık.
İşte ayrı bir Couchbase Cluster'ını aldık.
Bir süre işte o şekilde hani ilerlettik.
Sonra da yeni sürüme geçtikten sonra düzeldi.
Tekrar XTCR'ı açıp aktif aktif kullanmaya devam ettik.
Valla yani yaşanan incidentlerden herhalde benim şahsi olarak en çok üzüldüğüm şeyler bizim elimizde olmayan incidentler.
Yani böyle dışarıdan yaşanan işte kullandığımız tool'larla işte ne bileyim farklı şirketlerle vesaire ilgili olarak yaşanan incidentler benim en çok üzüldüğüm incidentler açıkçası.
Çünkü o an yani ne yaparsan yap aslında elinden bir şey gelmiyor.
Hani oraya koşuyorsun, buraya yapıyorsun, bir şeyleri düzeltiyorsun ama günün sonunda onlar da bittiği için tamamen oraya bağımlısın.
Zaten işte Trendyol tarihinde de böyle incidentler yaşayıp, bunlardan ders alıp işte bunlara yönelik aksiyonlar geliştirdiğimizde çok zaten şey var, çok örneğimiz var.
Bu da oldukça üzücü olmuş, geçmiş olsun.
Çok teşekkürler.
Kesinlikle hani bir de problemi...
Anlamayınca sorun da bulunamıyor.
Diyoruz yani tüm ekipler Couchbase kullanıyor.
Tüm ekipler de vardır Transactional.
Bizde hani direkt bir sorun olacağı hiç aklımıza gelmemişti.
Neyse ki çözüldü. Süper.
Tekrar geçmiş olsun. Şimdi ufaktan böyle artık son 3-4 sorumuza gelmeye başladık.
Onları geçelim.
Şimdi Engagement Product'tan bahsettik işte çeşitli oyunlaştırmalar vs.
konuları. Fakat şimdi mesela bir koyun kazanma konusu var.
İşte bununla alakalı bir şeyimiz var, bir feature'ımız var.
Fakat burada tabii şeyler de var.
Biz bunu mesela kupon ekipleriyle konuştuğumuz zaman da çok şey yapmıştık, yaşamıştık, çok konuşmuştuk.
Bu tarafta da aslında kullanıcılar coin kazanırken farklı şeyler deneyebilir.
İşte bir fraud durumları olabilir burada.
Siz en genç mut ürünlerinde fraud durumları yaşıyor musunuz?
Yaşıyorsanız burada ne gibi şeyler yaşıyorsunuz ve engellemek için neler yapıyorsunuz?
Şöyle, aslında fraud girişimleri hep oluyor.
O yüzden bizim de özellikle proje yaparken odaklandığımız bir kısım burası.
Burayı çok ön plana çıkartıyoruz.
Burada ürün bazlı fraud engellediğimiz yerler her projede var.
Onur Deliçek'inden bahsetmiş de ondan bir örnek.
ilerleyeyim ben de. Kullanıcıların her gün gelip check-in yapmasını bekliyoruz biz aslında daily check-in ürününde.
Ardından da ödül tanımlıyoruz.
Ama birden fazla kullanıcı aynı mobil cihazdan gelip check-in yaptığında tabii ki engelleme gibi bir akışımız var.
Her kullanıcının hangi Unicaid'i ya da Device ID'den check-in yaptığı bilgisini DB'de biz tutuyoruz ki aynı kullanıcı sürekli yeni hesap açıp check-in işlemi yapamasın diye.
Quest tarafında da aslında buna benzer bir yakış var.
İşte kullanıcı Quest tamamladığında bu görevi tamamladığı cihaz bilgisini yine device side'i kendi tarafımıza tutuyoruz.
Gün içerisinde Quest sayfasına girdiğinde ilgili Quest'i zaten tamamlamışsa tekrar tamamlayamıyor.
Gün sonunda o device bilgisini siliyoruz.
Ertesi gün tekrar bir yeni akış başlıyor aslında kullanıcı için.
Böyle böyle örnekler var aslında her projede.
Biz bunu kontrol ediyoruz diyebiliriz.
Paylaş kazan ürünümüzde de mesela collection oluşturma ya da collection'ı takip etme kısımları var.
Hani bu işlemlerde heşediğimiz değerle uyuşmayan bir event aldığımızda bu event'i işlemiyoruz mesela.
Mobile Edge ile ilgili de bir problem yaşamıştık.
Onur bayağı iyi bilir.
Delphoi problemi diye geçiyor.
O topu Onur'a atayım Onur daha iyi açıklar orayı.
Aynen ya şöyle mobil tarafta işte çeşitli kullanıcının sahip olduğu değerlerle ve kendi liste katıldığı zaman hani o değerler uyuşmuyorsa kullanıcılara herhangi bir aksiyon yaptırmıyoruz.
Burada da işte bir garip bir sıkıntı yaşadık hani biz animali toplantılarında hani loglara vesaire bakarken şeyi fark ediyoruz işte böyle sürekli hani hash hataları var.
Hash hataları da hani hash uyuşmuyor hataları fazla yani hani şey düşünüyoruz ya diyoruz ki bu kadar da aslında olmaz hani bu kadar da kişi frad yapmıyordur diye düşünüyoruz.
İşte biraz daha detaylı baktığımızda şeyi fark ettik işte.
Bazı kullanıcılar mesela pit değeri var bizim bu gene hash için kullandığımız.
Pit değeri mobilin normal set dediği bir değer.
Döküyoruz bir süre sonra farklı bir pit değeriyle istek atılmaya başlanıyor.
Ve mesela normalde mobilin setleri de sağlıyorum 20 karakterden oluşuyorsa bir anda 10 karakteri iniyor filan.
Mobile toplantılar yapıyoruz.
Debuglıyoruz nasıl böyle bir anda değişiyor olabilir hani cookie.
Çünkü oradaki pidin değişmesinin tek sebebi bir şey olabilir.
Hani mobil o pidi cookie olarak setlemiştir.
Biz de o cookieyi okuyup her seferinde işte backend'e yolluyoruz filan.
Biraz daha bakarken işte bizim...
Yine kardeş ekipten CoinCoin'de de aynı hash mevzuları var.
Oradan botu durumu fark etti.
Olay da şöyle. Biz Delphoi'u kullanıyoruz eventleri yollamak için.
İşte kullanıcının aksiyonlarını falan takip etmek için.
Delphoi'nin de hani WebView olduğumuz için web script'ini kullanıyoruz.
Orada da şöyle bir lojik varmış.
Eğer o an Delphoi atılacağı zaman işte pit ya da seed değerleri falan okunmuyorsa Delphoi kendi pit seed değerlerini oluşturup web siteye setliyormuş.
Hani bu işte Trendyol.com'dan filan girerken mantıklı tabii.
Çünkü orada her zaman pit sit değeri setlenmiyor.
Bir anda web'e özel pit sit değerlerini setleyip devam ediyorlar.
Ama bizim özelimizde o pit değerinin değişmesi bile aslında bizimki fraud risk oluşturduğu için böyle bir durumu fark ettiğimizde hani bir o önceki kullanıcılara bakıp orada bir temizleme yaptık.
Ardından da... Bu skripti kendimize çektik.
Normalde başka bir ortak bir yerden alıyorduk o skripti.
Modifiye edip hani o şekilde kendi aramıza kullanmaya başladık.
Hani bu tarz basit durumlarda bile sıkıntı çıkabiliyor.
O yüzden çok dikkatli takip ediyoruz hash problemlerini.
Valla oldukça sıkıntılı bir konu gerçekten.
Yani özellikle dikkat edilip özellikle aksiyon alması gerekiyor.
Siz de burada sık ne denir?
Sık dokuyup ne elemekte?
İnce eleyip sık dokumak.
İnce eleyip sık dokuyorsunuz.
Gerçekten Türkçe bilgime de ayrıca hayran kaldım şu an.
Süper. Gerçekten ellerinize sağlık.
Biraz şeyden bahsedelim sona doğru.
Şimdi aslında baktığınız zaman birçok yerde sizin feature'larınız var.
Birçok yerde tool kullanıyorsunuz.
Dolayısıyla da birçok ekiple de birlikte çalışıyorsunuz.
Burada ekiple çalışmak, bu kadar çok ekiple iletişim kurmak vs.
zor olmuyor mu?
Bir de şeyi de soracağım aslında araya sıkıştıracağım.
Bunun yanında çok fazla ülkeye de ürün geliştiriyorsunuz.
Yani ekiple çalıştırmanın yanında çok fazla ülkeye de ürünler geliştiriliyor.
Tane tane sorayım aslında.
Önce ekiple alakalı sorayım.
Bu birçok ekiple olan süreci nasıl sağlıklı yürütüyorsunuz?
Sonrasında da şeyi sorayım. Çok fazla ülkeye bu derece ürün geliştirmenin ne gibi zorlukları oluyor?
Ben başlayayım. Yani aslında Engagement Products ekibi olarak biz genelde diğer takımlardan bir şey isteyen tarafta oluyoruz.
Dolayısıyla ilgili ekiplerin backlog'unu olabildiğince erken girmeye özen gösteriyoruz.
Zaten hem projenin en başında hem mimari tasarım toplantılarında hangi bilgilere ihtiyacımız olduğunu, nereden alabileceğimizi bunları erkenden çıkarıyoruz.
Sonrasında proje kick-off toplantıları oluyor.
Burada da aslında diğer takımlara sürece dahil edip projeyi anlatıyoruz.
Bu sayede hem hani bizdeki ihtiyacı daha iyi anlayabiliyorlar hem de böyle kendi domenleri kapsamından da dinledikleri için bizim aklımıza gelmeyen konuları da adresleyebiliyorlar.
Sonrasında her projeye özel Slack kanalı kuruyoruz mutlaka.
İşte groomingde veya analiz süreçlerinde bir soru aklımıza gelirse oradan ilerletiyoruz genelde.
Bir de entegre olduğumuz takımların domenini anlamaya çalışıyoruz diyebilirim.
Yani böyle çok çok basit bir örnek vereyim.
Line item status inamı kullanacaksak bunu OMS'dekiyle aynı isimlendirmede yapıyoruz ki hani oradaki iletişim daha kolay sağlansın, daha paralel bir yapı oluşsun diye.
Tabii bunlar böyle nasıl hani sağlıklı yürütüyoruz kısmıydı.
Ama hani takımların işte farklı farklı yoğunlukları, hedefleri olduğu için kesinlikle zorluk yaşadığımız, işte disagree and commit ettiğimiz yerler oluyor.
Ama yine de bence trend oldu.
O collaboration kası gerçekten çok güçlü.
Herkes elinden geldiğince birbirine yardımcı olmaya çalışıyor veya ortak noktayı bulmaya çalışıyor.
Bu açıdan da şanslıydım.
Ben de mobil kısmı anlatabilirim aslında.
Frontend'de biz WebView yazdığımız için daha çok mobil tarafla iletişim halindeyiz.
İlk başta hani kurulduğumuz zaman da bir Engagement Products Mobile Slack kanalı oluşturmuştuk.
Hani genelde iletişimler oradan ilerliyordu.
Ama zaman geçtikten sonra hani o akışın çok akmadığını gördüğümüz için farklı bir yönteme geçtik.
Sebebi de aslında şöyle hani bir bizim tarafta...
Hani bir soru soracağımız zaman tam hangi ekibe soracağız?
Çünkü herkes mesela sağlıyorum Checkout Mobile'da orada işte Account Mobile'da orada falan.
Herkes orada olduğu için bir problem olduğunda tam hangi kişilere tiketleyeceğiz?
Ya da mesela bir sıkıntı incident yaşadığımız zaman tam hangi kişilere yazmamız gerekiyor falan?
Ya da süreçleri nasıl ilerletebiliriz vesaire?
Sıkıntı oluyordu. Bir de mobil tarafta da hani onlar her domeninde de olduğu için sağlıyorum.
Engagement Slack kanalında da varlar, Coin'de de varlar vs.
Onlar tarafında da biraz yoğunluk oluyordu.
Hani o Slack kanallarını kaçırırlarsa bizim hani tekrar hatırlatmamız gerekiyordu.
Böyle bir mevzu var hani tekrar bakabilir misiniz vs.
diye. Ve yeni seneyle beraber daha farklı bir yöntemle ilerliyoruz.
Şu anda artık hani biz kendi Engagement Mobile kanalından yazmıyoruz da her ekibin hangi sorumlulukları var onları belirlediğimiz bir Pandora'da bir dokümanımız var.
İşte mesela bizim 3 farklı web birimimiz var.
Bir tanesi account tarafında, bir tanesi browsing tarafında.
vesaire. O her ekibinde kendi Pandora'da QA'leri var.
Biz mesela bir yerlerde debug yapmamız gerektiği zaman ya da bir sıkıntı olduğu zaman QA'yi açıp oradan birisi atanıyor.
O şekilde ilerletiyoruz. Ya da her ekibinde yine PM'leri belli olduğu için feature geliştireceğimiz zaman PM'ler üzerinden ilerliyoruz.
Hani instant vesaire durumları da anlık aksiyon olacağı zaman da hani sonuçta sallıyorum.
mobilya iş geliştiriyorum. Hani ben daha çok mobilcileri tanıyorum ama o insanın sırasında ben müsait olmayabilirim belki.
Onun içine bir dökümanımız var.
Orada da hani başka birisi varsa o sırada bakıp tamam işte Gamification WebView hangi mobil ekibin altında, hangi onkola yazmam gerekiyor vesaire.
Bilgi alabiliyor. Hani bu yeni süre işte biraz bu şekilde ilerlemeye çalışıyoruz.
Şu ana kadar da hani faydalı diyebilirim.
Diğer ekiplere de tavsiye ederim bu şekilde mobilya çalışmalarını.
Mobil taraf bu şekilde. Hani çok fazla ülkeyle çalışma mevzusuna gelince o biraz bizi zorladı açıkçası.
Özellikle Arapça kısmı çok sıkıntı.
Çünkü mesela ilk başta Şiit saldırıyor.
Yeni bir ülke açılacağımız zaman...
PM Translation ekibiyle çalışıp bir tane sheet veriyor bize.
O sheet'te de hani eğer Gulf bölgesinde bir ülkeye açılacaksak Arapça tekstler oluyor.
Onları dökümana aktarmak şeyden zor oluyor.
Sağlıyorum o mesela tekstlerin içerisinde bazı değişkenler oluyor.
O değişkenler tabii Latince yazılıyor.
Hem Latince hem de Arapça tekstler olunca onları kopyalaması, yapıştırması ya da mesela bazen biz kodla o değişkene farklı bir isim veriyoruz vesaire.
Bir de aynı zamanda kopyalı yapıştıra çok iyi bir çözüm olmuyor.
Hani belki kopyalı yapıştıra da bir yer atlandı falan hani.
O yüzden orada Ekin de birazdan bahsediyor hani manuel test süreci de çok biraz zorlu geçiyordu açıkçası.
Ama şimdi yeni seneyle beraber CTMS'e geçiş yaptık.
Burada da aslında biz sadece artık Türkçe şu anda bizim sorsumuz.
Türkçe textleri oluşturduktan sonra Translation ekibi hangi ülkelerde o textleri istiyorsak o ülkelerde...
JSON'ları bir tane translation reposuna atıyor.
Biz de otomatik olarak o repodan çektiğimiz için hiç böyle hani kopyala yapıştırdır ya da dur bu variable'ı işte translation ekibi şöyle demiş ama bu daha mantıklı tarzı problemler yaşamadan daha otomatize bir sistemle ilerletiyoruz
aslında. Süper.
Valla burada yani ayrı ayrı sordum tabii ki.
İki tarafı da çok güzel yönetiyorsunuz.
Tabii şimdi Ülke tarafı daha zor bir taraf.
Hani birçok ülkeye ürün geliştirmek vesaire gerçekten zor bir taraf.
Yani bizim client bandında, client hekiminde olduğum için ben de biliyorum.
Dolayısıyla bunu handle etmesi, hakkıyla handle etmesi oldukça güç bir durum.
Burada tekrar ellerinize sağlık diyeyim.
Artık son iki sorumuza geldik.
Onları da soralım. Sonradan ufaktan kapanışa geçelim.
Peki şimdi Engagement Products ekibi ileride ne yapmak istiyor?
Yani önümüzdeki dönemde ekip olarak gelecekte hangi projeleri hayata geçirmeyi planlıyorsunuz?
Şu anda aslında harıl harıl Azerbaycan tarafına Türkiye'deki şans çekiliş projesini geliştirmeye çalışıyoruz.
Şu an bütün ekibin odak noktası AZ Raffle diyebilirim.
AZ Raffle projesini tamamladıktan sonra da aslında aklımıza iki tane proje var.
Birincisi eşyalı kazakazan.
Şu anda aslında Türkiye'de bir kazı kazan uygulaması var.
O da gene kardeş ekip coin tarafından geliştirildi.
Orada ama bildiğim kadarıyla kupondur, coindir tarzı şeyler kazanıyorsunuz.
Biz eşyalı kazı kazan projesinde hani sallıyorum kazı kazan sonucunda bir playstation belki bilmiyorum.
Hani o tarz daha fiziksel şeyler kazanmaya odaklı bir tool geliştireceğiz.
Gene engagement arttıracak bir tool olduğunu düşünüyoruz.
Eşyalı kazı kazandan sonra daha şu an pişme aşamasında ama bir kazan diye bir projemiz var.
Bunda da hani kullanıcılara çeşitli sorular sorarak ve onlar da eğer doğru cevaplar verirlerse gene çeşitli ödüller kazanabileceği bir uygulama.
Ama hani o daha pişme aşamasında olduğu için çok fazla bilgi veremem ama bu şekilde şu anda odaklılarımız bunlar diyebilirim sonraki aylar için.
Süper hepsi. Peki bu kadar zorluklarla boğuşan bir ekip.
Eğlenmek için neler yapıyor?
Ekip etkinlikleri olsun, ayrı toplantılar olsun?
Bunu böyle organize etmeye çok çabalıyoruz aslında.
Her hafta toplantımız oluyor.
Cuma günleri MSI çıkışına doğru böyle dörtte gelirim toplantımız oluyor.
Orada işte online oyun oynuyoruz ya da sohbet ediyoruz gibi ya da oyun oynarken sohbet ediyoruz tarzı ilerliyor.
Sanırım en çok oynadığımız oyunda Codenames olabilir.
Bir de bir ara Onur Tetris'teki yeteneklerini göstermek ve kendisini geliştirmek için bizi Tetris'e bulaştırdı.
Bayağı eğlendiğimiz bir şeydi zaman da o da.
Onun dışında yani ben ekipte dört kişi ben, Onur, Merve ve Ali Can hani farklı şehirlerdeyiz.
İstanbul'da olmadığımız için.
Ekip etkinliklerine gelmeye çalışıyoruz olabildiğince.
Orada da işte ekip bütçesini artık el verdiği kadarıyla yapmaya çalışıyoruz.
En son Nisan'da ekipçe İstanbul'a bir araya geldik.
Onun dışında da hani Şubat ayında bayağı akşam hep birlikte böyle bir eğlenceye gittiğimiz hatta orada diğer kardeş ekiplerimiz Coin ve Financial Products'la birlikte gittiğimiz bir eğlence vardı.
Böyle galiba hani özetle.
Süper. Çok teşekkürler arkadaşlar geldiğiniz için.
Bence çok güzel bir bölüm oldu.
Yani yine yeni bir ekibi tanıdığımız ve Engelic'in Prolux ne yapar?
Yani benim için güzel bir bölüm oldu açıkçası.
Böyle oyunlaştırmayla alakalı Trendle içerisinde de çalışan bir ekip olmasını bilmek beni mutlu etti.
O yüzden tekrar geldiğiniz için çok teşekkür ederiz.
Biz teşekkür ederiz ayrıldığımız için.
Teşekkürler. Teşekkürler sağ olun.
Bunun yanında... Trendyol Talks adında bir podcast serimiz daha var.
Trendyol Talks podcastinde de Trendyol kültüründen, kültürümüzden beslenen iş yapış biçimlerimizden ve ritüellerimizden bahsediyoruz.
Trendyol Talks podcast serisinde bütün podcast mecralarını da bulabilirsiniz.
Selam ekibin bu bölümünde Engagement Products ekibiyle beraberdik.
Bir sonraki bölümde başka bir ekiple tekrar görüşmek üzere.
Kendinize iyi bakın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.