Konuklar: Utku Kılınçcı, Cebrail İnanç, Yasin Duvarcı
91. bölümümüzde konuğumuz ProductAds 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 Fulfillment Order Master Data ekibinden Fırat.
Bugün sizlerle beraber teknoloji ekiplerini tanıdığımız süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast'imizin 91.
bölümündeyiz. Bu bölümde Product Ads ile beraberiz.
Bu ekibi tanıyacağız. Ekip yapısı, kullanılan teknolojiler, pratikler gibi konuların hepsini konuşacağız.
Arkadaşlar hoş geldiniz. Hoş bulduk.
Hoş bulduk. Hoş geldiniz.
Hoş geldiniz. Bugün ayrıca tek değilim.
İkinci bir... Kişi var.
Bir co-host'umuz. Yeni bir co-host'umuz.
Fatih'e var. Fatih'e hoş geldin.
Hoş buldum. Selamlar herkese.
Ben de Seller Order Experience takımından Fatih'e.
Çok iyi. Sen kaç senedir buradaydın Fatih'e?
Ben 7 yıldır. Neredeyse 7 yıl olacaktı.
Aynı yoldayım. Hiç bilmemiş gibi yapmak istedim böyle.
Fatih'le beraber işe başladık.
Aynı gün. Aynı gün stajyer olarak girmiştik.
2019 Haziran'da.
Üzerinden 6-7 sene geçmiş.
Güzel. Efendim hoş geldiniz.
Hoş bulduk. O zaman isterseniz böyle ilk sorudan başlayalım bakalım bugün kimlerleyiz, hangi ekipteyiz, neler varmış biraz konuşalım.
Arkadaşlar tekrardan hoş geldiniz.
İsterseniz böyle kısaca kendinizi tanıtabilir misiniz?
Böyle kime vereyim topu bakayım.
Yasin istersen senden başlayalım.
Merhabalar ben Yasin Duvarcı.
Product Edge ekibinde Backend Developer olarak çalışıyorum.
Sektörde 9 yıldır çalışıyorum.
Trend yolda da 6 yıldan fazla, benim de 7 yıla doğru yaklaştı.
Merhabalar, ben Cevrail.
Trendyol'da Product Ads ekibinde Backend Developer olarak görev alıyorum.
Açık Trendyol'da 5. yılıma giriyorum.
Selam, ben Utku.
Toplam 5,5 yıllık tecrübemin son 5 yılını Trendyol'da Ads domeninde Developer'in test olarak sürdürüyorum.
Peki bize Product Ads hakkının Trendyol'daki sorumluluğundan bahsedebilir misiniz?
Utku istersen seninle devam edelim.
Öncelikle bir Ads domeninden çok kısa bahsedeyim.
Kiana Platform... S-Domain'in amacı satıcıların veya markaların ürünlerine veya mağazalarına çeşitli reklam çözümleri sağlamak.
Bu reklam çözümleri sayesinde satıcılar ürünlerini veya mağazalarını Trendol içinde üst sıralarda gösterebiliyor veya sosyal platformlarda.
İnflüansörler aracılığıyla mağazalarını veya ürünlerini tanıtabiliyor.
Product Ads olarak da S-Domain'in altında bizim görevimiz satıcıların veya markaların ürünlerini Trendyol platformunda daha ön sıralarda listelemesine olanak sağlamak.
Sağladığımız platform ve altyapı sayesinde satıcılar açtıkları reklamlarla ürün aramada olsun, ürün önerme gibi ekranlarda ürünlerini daha ön plana çıkarabilme fırsatı buluyorlar diyebilirim.
İlk aklıma geleni böyle çok cahilce dışarıdan baktığımda söyleyebilir miyim?
Şöyle sanki mesela diyelim ben yarın mesela bir ürüne reklam vermem gerekiyor ve yarın bir yerde trend yolda şey gözüksün istiyorum.
En yüksek parayı verdiğim anda en üstte benim şeyim adım çıkacak gibi böyle sanki açık arttırma olacak ve en yüksek parayı veren Direkt birinci sırada oluyor gibi.
Bir şey gelmiş diye kalkmam.
Böyle bir çalışma yoksa bu sistem algoritması farklı.
Bu kadar şey değiliz.
Bu kadar basit değiliz diyeyim.
Şöyle oluyor aslında.
Ben süreci anlatayım doğrudan.
Oraya da değinmiş olacağız. Reklam oluşturma sürecinde aslında satıcımız gelip ürünleri seçiyor.
Tıklama başına maliyeti de girdikten sonra reklam...
oluşturmuş oluyor ama bahsettiğim gibi bu sistemde direkt aktifleşmiyor.
Bu sistem üzerinde bazı kontrol ve skorlamalara gidiyor ve buradaki temel amacımız müşterilere faydası olan ve Aldığında daha fazla mutlu olabileceği ürünleri devamlı plana çıkarmak.
Ayrıca satıcıların da daha çok kazanç yapacağı, daha çok öne çıkaracağı ürünleri listelemek.
Bundan dolayı tek kriterimiz buradaki ücretlendirme olmuyor aslında.
Daha sonra kontrollerimizi yaptıktan sonra biz burada bu akışı tek başına yöneten bir ekipteyiz aslında.
Bu akışın büyük bir parçası search ve recommendation ekipleri.
Biz ürünün reklam verilebilir olduğunu...
Karar verdikten sonra bu bilgileri search ve recommendation ekipleriyle paylaşıyoruz.
Burada da Trendyol'un sayfalarında sponsorluk ürünü olarak gösterilmeye başlıyor.
Bu aslında yayına alınmış hali olmuş oluyor diyebilirim.
Bir ürünün aslında reklamına ne kadar verilebilir ya da onun detaylarını, kararını aslında Product Ads ekibi veriyor diyebilir miyiz?
Beraber veriyoruz diyelim. Çünkü biz bu ürünü Product Ads olarak, DS olarak beraber kararlaştırıyoruz aslında.
Burada DS de bizim büyük bir iş ortağımız.
Beraber DS ve Product Ads beraber bunu karar veriyor.
Çok iyi, çok iyi. Bu arada bilmeyenler için DS dediğimiz Data Science ekibi oluyor.
Bazen biz böyle alışkanlıktan çok fazla şeyler söylüyoruz böyle dışarıdan.
Zor olabiliyor. Peki buradaki Product Ads ekibi tam olarak...
Şu an burada iki dev ve bir QA var.
Toplamda ekibin dağılımı nasıl?
Ekibin dağılımı 10 kişiden oluşuyor toplamda.
Bir takım liderimiz var. Bir tane product managerımız var.
6 tane developerımız bir de QA'miz var.
Bir tane de staff engineer arkadaşımız var.
Toplam 10 kişiden oluşuyoruz. Çok iyi çok iyi.
Genelde bizim konuştuğumuz ekipler 6-7 vesaire olur ortalama.
6 developerla ekip ilk sizde görmüş olabilirim.
En kalabalık bence benim gördüğüm yükseklerden birisiniz yani.
Bir de birçok ekiple birlikte çalıştığınızdan bahsettiniz.
Sayı olarak da ekibiniz büyük.
Ekiplerle iletişim, orta çalışma konusunu nasıl handle ediyorsunuz?
Sağlıklı bir süreç nasıl yürütüyorsunuz burada?
Şöyle, bu bizim aslında en büyük challenge'larımızdan bir tanesi.
Ben Trendyol'da aslında başka bir ekipte de çalışmıştım.
Bu ekibin iletişim aslında en büyük challenge'ı ve en doğru yönetilmesi gereken challenge'larından bir tanesi.
Bu noktada Product Manager'ımız bize çok destek oluyor.
İletişim süreçlerini başlatıyor, ilerlemesini sağlıyor ve bu süreç başladığında çoğunlukla birden fazla ekip bir iş için katkıda bulunmamız gerekiyor.
Beraber aynı hedefe odaklanmamızı sağlıyor.
Bundan sonra biz teknik ekip olarak analizlerimizi oluşturuyoruz.
Bu analizlerde kontrat first yaklaşımı bizim için çok önemli.
Kontratları netleştiriyoruz.
Ekstradan bir de analiz dokümanı oluşturuyoruz ve bunu ortak site kanalları üzerinde ilgili ekiplerle paylaşıyoruz.
Ve bu paylaşılan doküman üzerinde approve kısmı oluyor aslında.
İlgili ekipler bunu inceleyip onaylıyor aslında.
Bu da... analizin takip edildiği, onaylandığı bilgisini içinde barındırmış oluyor.
Daha sonra takımlar el sıkıştıktan sonra biz geliştirmelerimize hem paralel şekilde başlamış oluyoruz hem de el sıkıştığımız için işin sonunda yanlış anlamaların önüne geçmiş oluyoruz.
Böyle bir iletişim kültürümüz var.
Peki bu çoğu işleriniz de böyle mi?
Yani sizde gelen çoğu işler bu şekilde mi ilerliyor?
Yani biz bunu çoğu işte yapıyoruz açıkçası.
Çok ufak bir değişiklik olursa belki istisna olmuştur ama çoğu işimizde yapıyoruz.
Çünkü bu işi böyle yapmadığımız durumlarda bir iki defa şey yedik.
Beklentilerimiz uyuşmadığını fark ettik aslında.
Bir işimizde rework yapmamız gerekti.
Biz bu nedenle tüm işlerimizde bu standartı benimsedik aslında ekip olarak.
Çünkü sadece iki ekip de genelde geliştirme yapmıyor.
Bizim ikiden fazla ekip geliştirme yapıyor.
Mesela Search tarafında üç farklı ekiple çalışıyoruz ama aynı ürüne hizmet veriyorlar.
Bundan dolayı bu bizim aslında ana çalışma bücevimiz diyebiliriz.
Peki benim bir sorum olacak. Müşteri bir reklam veriyor.
Peki bu reklamın gerçekten işe yarayıp yaramadığını, nasıl bir çıktı, ürettiğini nereden görebiliyor?
Görebiliyor mu? Tabii. Burada ben yardımcı olayım.
Burada açılan bir reklam, aslında trend yolu uygulamasına artık gözükmeye başlıyor kullanıcıların önünde.
Kullanıcılar gördükçe de her platform kendi içinde clickstream ve impression eventleri oluşturuyor.
Bunları Kafka'ya göndermeye başlıyor.
Kafka aracılığı ile de hem bizim tarafımızdaki Kafka'mızın hem de BigQuery'de farklı tabloları akıyor.
Bizim Kafka'ya akan kısımda da bizim Kafka Stream diye bir uygulamamız var.
Real time olarak gelen klik eventlerini işliyor.
Birlik consumption hesaplamaları yapılıyor.
Gelen klikler üzerinde fraudsal bir kontrol yapıyoruz.
Böyle case'lerimizde olduğu için.
Gerçek klikleri de real time olarak işleyerek seller'ın belirlediği bütçeyi aşıp aşmadığı kontrolü yapılıyor.
Eğer aşmışsa da real time olarak anlık hemen reklamın kapanması yapılıyor.
Burada da reklamdan nasıl bir yarar sağladığını da revenue ve impression hesaplamalarına göre yani hesaplamalar yapılıyor.
Burada ayrı bir uygulama üzerinden BigQuery'deki tablolar üzerinden bir hesaplama yapıyoruz ve seller'a panel aracılığı ile yine tekrardan bu dataları veriyoruz.
O da reklamın perform edişine göre bütçesini arttırabiliyor ya da tıklama maliyetini değiştirebiliyor gibi aksiyonlar alabiliyor.
Çok güzelmiş. Hazır biraz teknolojilerden de değindik.
Kafka, BigQuery vs. dedik.
Biraz da tekstilinizden bahsetmek ister misiniz?
Tabii. Teknoloji siteyimiz biraz geniş.
Burada ilk olarak backend ile başlayayım.
Backend ile biraz teknoloji site olarak Node.js, Java, Scala, Kotlin ve Go kullanıyoruz.
Buradaki çeşitliliğin iki temel sebebi var.
Biraz fazla gözüküyor. Bunun ilk sebebi ekip olarak biraz farklı siteklere bakmayı seviyoruz o yüzden.
Ayrıca replatform sürecimiz var.
Şu anda devam eden bazı repolarımızın replatform sürecine giriyor.
Önceden ağırlığımız Node.js idi.
Şu anda bu biraz daha Java ve...
Scale gerektiren projelerde de Go'ya doğru geçiş yapıyoruz.
Ayrıca az önce dediğim gibi Kafka Stream uygulamaları bir tane konsantrasyon hesabı için yapan uygulamamız var.
Ayrıca farklı akışlarımız içinde farklı Kafka Stream uygulamamız var.
Bunlar için de Kotlin ve Scala kullanıyoruz, tercih ediyoruz.
Database tarafında Couchbase ve PostgreSQL kullanıyoruz ağır olarak.
Şu anda da Couchbase ağırlıyız ama...
Zamanla PostgreSQL'e göre, use cases'lerimize göre geçişimizi yapıyoruz.
Ayrıca TMS ve Data Science ekibiyle çok birebir çalıştığımız için ayrıca birçok clickstream eventlerinin meşheden BigQuery tarafında da akış oluyor.
Ve oraya göre de farklı akışlarımız olduğu için BigQuery'i de aktif olarak, yoğun olarak kullanıyoruz.
Frontend tarafında ise Microfrontend mimarisiyle çalışıyoruz.
İki panelimiz var. Brand Center ve Seller Center.
Bu iki panel üzerinden de reklam verilebiliyor.
Seller Center React.js ile yazılmış bir...
proje. Yine microservice gibi.
Microfrontend mimarisiyle geliştiriliyor.
Brand center ise Svelte kullanılıyor.
Burada bir dönüşüm sürecimiz var şu anda.
Seller center mobilya uygulamasında reklam yönetim sekmesinde yer alan product S'e ait tane sayfalar web web üzerine hizmet verecek şekilde değiştiriliyor.
Bunun sebebi de mobil versiyonların bağlantılarını azaltmaya planlıyoruz aslında.
Geçiş durumlarında eski versiyonda Desteklemek gerektiği için kodlar daha kötü yazıldığı için o yüzden WebView yapısına geçiriliyor.
Şu anda belli ekranlar geçiş yapıyor.
Diğerleri de Seder Center ekranları hepsini taşımaya planlıyoruz.
Test tarafını da ben ufaktan bahsedeyim.
Aslında bahsettiği gibi backend, frontend ve mobil uygulamalarımız var.
Tüm bu projeler için de aslında bizim bir test otomasyon sürecimiz var.
Backend projelerimizdeki API ve Consumer Producer uygulamalarımızın test otomasyonlarını Kotlin ile yazıyoruz.
Direkt, pür bir şekilde herhangi bir BDD framework kullanmadan REST Assurance kütüphanesi, Kafka, Postgre, Couchbase, ClientTrip kullanarak testlerimizi gerçekleştiriyoruz.
Bağımlı olduğumuz uygulamalar var.
Hani mikroservis mimarisi kullanılıyor Trendyol'da.
Bağımlı olduğumuz uygulamalar yani dış ekiplere ait uygulamaları Wiremark ile mokluyoruz.
Bu uygulamalar ile aramızdaki kontraktı da tabii ki de kontrakt test ile güvence altına alıyoruz.
Ayrıca tabii smoke testlerimiz de mevcut.
İntegrasyon ve garanti altına alabilmek adına smoke testlerle diplomatik seçimlerinde çalışıyor.
Ve ayrıca da branch based bir Test yaklaşımımız var.
Prense özel, feature özel test ortamı ayağa kalkıyor.
Burada Trendyol içinde RS ekibinin gelişmiş olduğu tool'ları kullanarak test özel ortamlarda testlerimizi koşuyoruz.
O yüzden hani ortamsal sıkıntılar, başka ekiplerin bağımlı olduğumuz herhangi bir problem yaşamıyoruz bu ortamlarda.
UI projelerimizde de functional testlerimizi TypeScript ve Playwright ile ilerletiyoruz, otomatize ediyoruz.
Onun dışında fonksiyonel testin yanında bir visual test pratiğimiz de var.
fonksiyonel olarak kabul edemediğimiz visual problemleri de yine otomatik bir şekilde bu visual test pratiğimizde pipeline'da anlık bir şekilde yakalayabiliyoruz.
Burada da yine branch-based testlerimizi gerçekleştirebiliyoruz.
GitHub'in VWAP feature'ünü kullanıyoruz.
Mobil projemizde de detox tool'u kullanılıyor.
Oradaki React Native projesinde detox ile otomasyon yazılıyor.
Ama Yasin'de bahsettiği gibi VWAP'e, VWAP'e geçiş.
Ve birlikte orada da aslında tek projeden Playwright ile testlerimizi kabul ediyor olacağız.
Bunlar dışında işte performans testleri için yine ARS ekibimizin geliştirmiş olduğu performans tool'unu kullanıyoruz.
Kaos testimizi yine gerçekleştirebiliyoruz ARS ekibimizin geliştirmiş olduğu tool'larla diyebilirim şimdilik.
Tekstiliniz bayağı genişmiş.
Test konularında da bayağı kapsamlı testler yapıyorsunuz diye anlıyorum.
Elinize sağlık. Peki biraz da monitoring ve alert mekanizmalarınızdan bahsedelim.
Bir incident olduğunda nasıl önceden haberdar oluyorsunuz?
Ya da bize güzel bir incident örneğinizden bahsedebilir misiniz?
Tabii. Biz ekipçe monitoring'e çok önem veriyoruz ve bunu çok ciddi bir şekilde takip ediyoruz.
Trento'nun sağlamış olduğu Grafana, Kibana, Neurilik ve internal APM tool'umuz olan Mergen'i kullanıyoruz.
Ve tüm projelerimizde Error Rate, Kafka...
Log ve Kafka inaktif mesaj yani bir süre boyunca Kafka'ya mesaj gelmiyorsa alert oluşturma durumu kesinlikle oluyor tüm projelerimizde.
Buna ekstra dikkat ediyoruz.
Bir de alerting konusunda dikkat ettiğimiz değerli bir konu ise noisy alert olmasın.
Yani aksiyona dönüşmeyen bir alert varsa bunları kesinlikle temizliyoruz.
Bu bizim üzerimize bir cognitive load oluşturmasını istemiyoruz ve kanalın önemi ve hassasiyetini azaltmasını da istemiyoruz.
Bu da bizim için önemli. Ekipçe bir kütüphane yazıldı aslında.
Bu kütüphane TypeCube alertlerin kolay oluşmasını sağlıyor.
Bir alert oluştururken CronQL ve Kibana sorgusu yazmanız gerekiyor.
Buradaki karmaşık sorguları yazmadan sistemde aktif edeceğimiz bir kütüphane.
Kütüphanemiz var aslında. Bu süreçleri kolaylaştıran, otomatize eden güzel bir kütüphane.
Düşünüyorum güzel bir incident.
Ekipçe bizi uğraştıran bir Demeter geçişinden dolayı yaşadığımız bir incident vardı.
Buradaki problem aslında bir Kafka clusterından başka bir Kafka clusterına replikasyon gerekiyordu ve Kafka Stream kullanarak iki topiyi joinlememiz gerekiyordu.
Bu iki topiyin joinlenmesinde keyler önemli bir değer oluşturuyor aslında.
Bunun üzerinde sağlanmış oluyor.
Bizim prodüsöden topiğimiz Java uygulaması altyapısındaydı.
Diğer tarafta replication yapan uygulama ise Go ile yazılmıştı.
Aslında bu kütüphanelerin partition'ı set ettiği keyleri hesapladığı algoritmalar farklılık gösteriyormuş.
Biz bunu fark edip aslında bunu fiksemiş olduk.
Yani bu algoritma dip dahil işlere çok girme ihtiyacımız olmamıştı ama bu geçişle beraber bu sorunu görünce buradaki know-how'umuzu arttırıp bilgili ekipleri de bilgilendirdik ve yaydık.
Bizim için öğrenmesi bol, keyifli bir incident diyeceğim.
Yaşarken keyifsizdi ama fiksledikten sonra öğrendiğiniz bilgilerden dolayı keyifliydi açıkçası.
Burada bizim biznes alörtlerimizin direkt triggerlanmasıyla direkt aksiyon aldık aslında.
Burada aslında alörtten dolayı çok hızlı haberdar olup, geçiş yapar yapmaz haberdar olup sorunu fiksediğimiz bir incident olmuştu.
Güzel. Aslında tatsız ama güzel sonuçlanmış.
Çok da şey öğretmiş olarak anlıyorum.
Bu arada teknolojilerden vesaire yani bir ara bahsederken şeyden bahsetmiştim.
PromQL'den. Ben PromQL'i uzun süre kullanan çok görmemiştim.
Ve bizim Trendyol'da ne kadar kullanılıyor bilmiyorum ama.
Kullanan birine denk geldim. Demek ki böyle kullanımı varmış yani.
Çok hakim değilim. Siz mesela memnun musunuz bu arada?
Yani yaşına ihtiyacınız vardı büyük ihtimalle ondan olmuştur da.
Yoksa böyle deneyelim hani nasıl bir şeymiş görelim dediniz de öyle mi kullanmıştınız?
Yoksa eski bir projemi çoktan mı vardı?
Ya PromQ'li biz bazı metrikleri, dashboardları göstermek için sık kullanıyorduk.
Bu aslında TypeScript uygulamamız dashboard da bize oluşturabiliyor.
Bundan dolayı oluşturuyoruz.
Ama genelde yaklaşım genelde şey oluyor.
Çok az girilen bir yer olduğu için var olan query'i kopyalayıp böyle alanları değiştirip ilerleyen bir yaklaşım oluyordu.
Buradaki bazı metrikleri ve değerleri göstermek için kullanıyoruz aslında.
Kafka'lı eklerindeki falan değerleri göstermek için.
Aslında onları abstrak etmiş olduk.
Artık kendimizi bu konuda yormuyoruz.
Bu kütüphane sayesinde. Okey güzel nice.
Biz de normalde şu an şeyi kullanıyoruz.
Bir .NET bir de Golang kullanıyoruz projelerde.
Ve bu söylediğiniz şey hani işte partitionları publish ederken key algoritmasının hani farklılaşması dil bazında.
Onu tahmin etmemiştim mesela.
Biz de acaba hani kritik bir biznesimiz yok ama olsaydı belki de etkilenebilirdik bundan.
Çünkü .NET'teki kütüphane ile Go'daki kütüphane farklı karar veriyor olabilir.
Bunu böyle bilmek güzel oldu yani.
Teşekkür ettik. .NET'te mesela bizde Fulfillment Tribe'ında bir .NET'ler var ama işte bunların çoğunu genelde Go'ya geçirmeye başladık.
Hem böyle ekipler arası rotasyonlar vesaireden daha kolay olsun, adaptör olsun, ortak kütüphaneleri daha rahat kullanalım vesaire diye.
O yüzden herhangi bir projeyle platform edeceksek ya da yeni bir proje gelecekse Go'ya geçiriyoruz.
Sizde mesela bu işin düzeni var mıdır?
Ya da mesela yeni bir proje geldi ya da platform...
Bu işin böyle akışı tam olarak sizde nasıl oluyor?
Bir replatform ya da yeni bir proje geldiğinde ilk olarak neden yapmalıyız diye bir soru soruyoruz kendimize.
Direkt koda girelim gibi yaldıklaşımız olmuyor.
Oturup ilk detaylı bir pronsponsor yapıyoruz.
Sonrasında mevcut yapıyı bizim neler kısıtlıyor diye bir bakıyoruz.
Sonrasında bunu da neler kazandırır diye product manager ile bir bunu tartışıyoruz.
Çünkü yapacağımız teknik değişiminin business impact'i de olacak mı diye bir ilk olarak şey yapıyoruz, değerlendiriyoruz.
Eğer hem teknik hem de business tarafında sıkışarak iş teknik analiz kısmına geçiriyoruz.
Sonrasında teknik analizler sonrasında OKR'ı alabilir miyiz diye bir konuşuyoruz.
Sonrasında OKR'ı dahil edip geliştirmeni devam ediyoruz.
Burada son önerebileceğim şey sponsor, content, consumer ve platform sürecimiz vardı.
Orada da mesela Node.js bir projemiz vardı.
Önceki senelerde BF'lerde filan scale sorunları yaşatıyordu bize.
Burada da mesela hem içinde bizi nasıl çok barındırıyordu.
O yüzden onu mesela Java'ya geçirme kararı almıştık.
Java'da biraz daha kolay yazılıyor diye.
Bazı yerlerde de Go'ya geçtik.
Biz nasıl biraz daha basit olan yerlerde de Go kararı alıyoruz şu anda.
Biraz daha yaklaşımımızı alıyor.
Genel alanımız Java ve Go'ya doğru kayıyor.
Genel şirket içinde de biraz aynı yaklaşım düşünüldüğü için bizde de aynı yaklaşım devam ediyor.
Evet evet aynı mantıkla gidiyoruz. Hatta şey yani bu onboarding süreçlerinde falan da böyle işlerimizi kolaylaştırıyor.
Özellikle rotasyonla gelenlerde.
Hani benzeri kütüphaneleri kullanıyor çünkü benzeri mantık.
Zaten işte daha önce TPP, Application Weather Platform 2 bile de mesela konuşmuştuk.
İşte bu tarz böyle internal zaten tool'larımız ortakken bir de böyle dil açısından da ortak kütüphaneleri yapıları kullanınca o zaman dedik okey hani daha da rahat oluyor bu işler.
Bu kısmı görmüştük tabii şirket dışından gelince tabii farklı olabiliyor ama o için de bir onboarding süreci oluyor vesaire.
İlla ki işler daha da kolaylaşıyor.
Sizde böyle... Rotasyonla gelen, siz ikiniz de mesela hatta üçünüz uzun yıllardır 5-6 yıllık idiniz hepiniz.
Yeni gelenler oluyor mu bilmiyorum ama oluyorsa mesela burada onboarding ile ilgili bir süreciniz oluyor mu?
Oluyor. Şöyle cevap vereyim.
Senin de dediğin gibi aslında özellikle şirket içi rotasyonlarda benzer tool'ların kullanılması onboarding sürecini kolaylaştırıyor.
Ama biz takımımıza yeni gelen bir kişi teknik olarak ne kadar güçlü olursa olsun aynı zamanda bir domain ekibiyiz.
Domainimiz çok büyük ve domaine de alışma sürecine çok fazla önem veriyoruz.
O yüzden gelen ekip arkadaşımızın tecrübesini bir kenara bırakarak kesinlikle izlediğimiz bir süreç var.
Ve bu ekip arkadaşımız da aslında...
Televizyon ekiplerinde birçok ekiplerinde de olduğu gibi bir body atanıyor.
Bu yeni arkadaşımız ve atanan body birlikte bir program oluşturuyorlar.
Ekip arkadaşlarımızla tek teken birebir sesyonlar düzenleniyor.
Her ekip arkadaşımız ekibimizdeki süreçlerin bir kısmını anlatıyor.
Ben test süreçlerini anlatıyorum diyebilirim, Yasin geliştirme süreçlerini vs.
Domainimizi, akışlarımızı, sprint işleyişlerimizi anlattığımız bir program oluşturuyoruz hep beraber.
Ve domaine'e alışması için aslında ona sürekli destekçi oluyoruz, takımca destekçi oluyoruz.
Ampades'i ekstra bir destek veriyor.
Takıma katıldığı ilk günden itibaren aslında direkt işlere dahil etmeye çalışıyoruz.
Ama asla yeni gelen ekip arkadaşımızı tek başına bir işin içine atmıyoruz.
Bir süre hatta uzunca bir süre peer programming yapıyoruz kendisiyle birlikte.
Tabii bu takımın aslında kültüründe de var.
Peer sadece yeni gelen ekip arkadaşları değil.
Genel olarak peer programming'e de önem verdiğimiz için burada da bir zorluk çekmiyoruz.
Takıma ve teknik olarak hani domeyine alışma sürecinin yanında takıma alışması için de desteklediğimiz kültürel anlamda süreçlerimiz var.
Takıma yeni birisi gelirse direkt ekip etkinliği düzenlemeye özen gösteriyoruz.
Aslında ekip etkinliği yapmayı seviyoruz.
Biraz bahane de olmuş oluyor.
Ekip etkinliklerimiz de genelde o yeme içme üzerinde kurulu.
Bu ekip etkinliğiyle birlikte zaten Trendyol'da oturmuş bir şirket kültürü var.
Bu kültürde dışarıdan gelen bir ekip arkadaşımız olduğunda da takıma alışması çok kolay olabiliyor.
Bir haftadır takımda olan bir ekip arkadaşımızla sanki yıllardır beraber çalışıyormuş hissine çok hızlı kavuşabiliyoruz.
Yani şöyle ben anlatırken düşündüğümde takıma yeni katılan bir arkadaşımız var aslında.
Yani birkaç ay oldu ama sanki senelerdir beraber çalışıyormuşuz gibi diyebilirim.
Çok iyi. Ekip etkinliklerinden bahsettim.
Daha önceki ekiplerde şey oluyor.
Gerçekten böyle beraber gidip bir yerlerde bir şeyler deneyen daha gurme ekipler var.
Onun dışında böyle oyunlar oynayan ekipler var.
Kar Smash mıydı?
Unuttum oyunun adını. Bu tarz böyle Discord üzerinden vesaire oyunlar oynayan ekipler oluyor.
Böyle arabalarla ilgili olan bir ekip vardı.
Mesela farklı farklı böyle ilgisi olan ekiplerimiz var.
Sizde mesela... ekibinin böyle iletişimini geliştirmek için yaptığınız, iş dışında yaptığınız bir şeyler oluyor mu?
Evet abi oluyor. Bizde de Smash Kart oynanıyor.
Ondan sonra X-Ball'umuz var.
Gartik var yine. Yani online'da haftalık rutin olarak bir perşembe günü sonumuzu mesela Game Station diye bir şey atıyoruz, takvim atıyoruz.
Orada mesela böyle oyunlar, yeni bir şey de olur ya da en sevdiğimiz oyun olur.
Aynı şey yapıyoruz, karalaştırıp hani.
Birisine oynuyorum mesela. Güzel oluyor yani.
İş yoğunluğundan kendimiz iş yapıyoruz.
Offline'da da şey en son laser tag'e gitmişliğimiz var.
Bowling. Hani bu tarz şeyler yapıyoruz.
Aaa çok iyiymiş. Aynen.
Yani laser tag baya yorucuydu ama.
Laser tag yorar. Aynen.
Bir de süreyi uzun almışız.
Yani normalde yarım saati geçemez.
Biz bir saate bile almıştık.
Çok zor olmuştu bizim için.
Abi bir saat bu arada fazla ya.
İyi ya. İyi gitmişsiniz yani.
Bir saat çok. Kondisyon ister.
Kesinlikle. Onun dışında teknik olarak da lunch and learn'imiz oluyor abi.
Yani son zamanlarda yapamadık hani bu şeyde ama normalde belli takvimimiz oluyor.
O takvime göre de yani herkes yani takvimdeki gününe göre bir konu belirleyip lunch and learn'de konuyu anlatabiliyor.
Ya da şey de yapabiliyoruz abi ekip içinde.
Refactor süreçleri ya da co-tribute session'larımız oluyor.
Burada refactor yapılan bir proje ya da büyük bir işlem yapıldıysa ona bir küçük bir session atıp hani ekip gibi üzerinden geçiyoruz.
Hani yorumları falan daha böyle hızlı, interaktif olsun diye.
Ya da code review sessionlarımız dışı oluyor.
Analizlerimiz falan böyle büyük olursa ya da hani atıyorum bir code review süresi artmaması adına küçük böyle sessionlar atıyoruz birbirimize.
Ama şey hani sabit şöyle olmalı diye bir kuralımız yok.
Ama hani o yapan kişi onun büyüklüğüne göre ya da durumuna göre hani gecikmeler olacağını hissettiyse böyle küçük sessionlar atıyor ve oralarda hem teknik şeylerimizi karşılaştırmış oluyoruz hem de anlık yorumlarımızı daha hızlı vermiş oluyoruz.
Güzel güzel çok iyi. Özellikle bu lunch and learn'ı bizde de şey oluyor.
Cuma günleri biz yapıyoruz.
İşte biz ona RG time diyoruz.
Ben lunch and learn'ı bu arada şeyde öğrendim.
Bu podcast'e de başlayınca öğrendim.
Zaten şey buymuş genel isimlendirmesi.
Biz hep RG zamanı diye diye kafamız hep RG kalmış.
Lunch and learn'ı ben çok sonradan öğrendim ama daha çok zaten bu kullanılıyormuş yani.
Okey onun dışında peki 6 kişilik bir developer ekibinin olması aslında şey.
Yanında köy var, işte staff var.
vesaire derken büyük bir ekip.
Ben de mesela daha önceki ekiplerimdi.
Bu benim dördüncü ekibim. Ekip böyle büyüdükçe bazı şeyler örneğin toplantılar işte daha zor geliyor.
Yani o kadar insanın bir adı olması kolay bir şey değil aslında.
Ya da sync çalışması, toplantıların verimli geçmesi vesaire zorlaşabiliyor.
Böyle ekiplerin böyle aldığı...
yaptıkları pratiklerde değişiklikler olabiliyor, ihtiyaçlar olabiliyor.
O yüzden böyle retro'larda daha fazla aksiyon olabiliyor vs.
duruma göre. Sizlerde bu tarz şeyler oluyor mu?
Retro'larınız genelde nasıl geçer aldığınız mesela şöyle şeyler oluyor ve şöyle aksiyonlar aldık daha önce veya böyle şeyler yapıyoruz gibi var mıdır sizlerde örnek?
Tabii. Biz aslında retro'larımızı şöyle planladık.
Retro'nun hemen öncesinde bir sprint review yapıyoruz.
Sprint'in kapanışıyla beraber.
Burada işte aslında hem sprintte yaptıklarımızı kısaca bir düşünmüş oluyoruz, hatırlamış oluyoruz.
Burada aslında oluşan...
anomalileri beraber konuşuyoruz aslında.
Bunların bazen bir kısmı da Retro'ya koyuyor.
Hemen arkasından da kısa bir ara, 5-10 dakikalık bir ara sonrasında Retro'ya başlamış oluyoruz.
Set Metcred şablonuyla aslında Retro boardumuzu oluşturuyoruz.
Orada inputlar alınıyor.
Yani takımın sayısı kalabalık ama ben kalabalık hiç hissetmemiştim.
Sen şu an söyleyene kadar.
Çünkü şey oluyor. Orada maddeler yazılıyor.
Proaktif bir şekilde herkes katkıda bulunuyor maddeleri.
Bu maddeler üzerinden daha yapacağımız aksiyonlar belirlenip aslında bunu Bunlar bir sonraki Retro'da tekrar revvetiliyor.
Bu maddelerde bir gelişme gözlem yaptık mı?
İlerlemeler var mı? Bunları konuşup aslında bulduğumuz çözüm Next Retro'ya kadar belki de handel etmemiş bir çözüm oluyor.
Alternatif bir çözüm üretiyoruz.
Bunun aksiyon maddesini oluşturup ilerletiyoruz aslında.
Böyle geçiyor Retro'larımız diyebilirim.
Çok iyi. Peki diğerleri de mi aynı mantıklı?
Yani mesela daily'lerdir.
Mesela haftalık sprint mi yapıyorsunuz?
Mesela planlamalar. Verimli geçebiliyor mu?
Nasıl oluyor? Şöyle oluyor.
Aslında biz takımda bir ara şeyin kavusunu yaşadık.
Daily'de online'da yaptığımız için update'i kim verecek?
Sıra kimde? Ona mı atsam?
Şuna mı atsam? Bu sorunları tamamen çözecek bir şekilde alfabetik sırayla update'lerimizi veriyoruz.
Ve aslında kalabalık bir ekip olduğumuz için...
Mevcuttaki jira taskı da çok fazla oluyor.
Bunları da filtreleme ile çözdük.
Jira üzerinde update'i veren kişiyi filtreliyoruz aslında.
Hangi tasta şu an uğraştığı deride görülmüş oluyor ve bununla ilgili update'leri paylaşıyor.
Buradaki moderasyon akışını da onkola arkadaşımıza devrettik.
Aslında her gün onkolu süreci modere edip alfabetik sırayla update'leri paylaştığımız bir akış oluyor.
Jira'daki olay çokymuş. Ben de Kasım gibi iki aylığına bizim yan ekipten birine geçmiştim Stock Allocation ekibine.
Orada görmüştüm böyle kim update'i verecekse ekranı paylaşan kişi o kişinin filtresine geçiyordu ve sadece onun maddeleri aynı gözüküyordu.
Bizim ekipteken daha toplu oluyor mesela ama orada şeyin farkını görmüştüm.
Mesela madde aşağıda bir şeyden bahsediyor, yaptığı bir task'tan, işten bahsediyorken sadece on ikilerin gözükmesi gerçekten daha böyle temiz ve...
hani takip edilmesi kolay oluyormuş.
Gerçekten fark yaratıyor yani. Biz de çok verim aldık gerçekten bu yaklaşımda.
Değili dışında aslında sprint'e hazırlık olarak da technical grooming ve sprint grooming'ler yapmaya önem gösteriyoruz.
Aslında her sprint öncesinde technical grooming'lerimiz bizim işin mühendisliğini ve teknik kalitesini konuştuğumuz faydalı toplantılar oluyor.
Burada teknik borçları, refaktör ihtiyaçlarını, altyapısal iyileştirmeleri, önümüzde oluşabilecek teknik riskleri değerlendiriyoruz aslında.
Bu toplantıların şöyle bir faydasını da gördük.
Bu toplantıda daha önce alınan kararların neden alındığını ve hangi çerçevede, hangi şartlarda aldığı da paylaşılıyor.
Böylece takıma sonradan katılan biri aslında o problemi, o çözümü sorgularken kendi bakış açısıyla sorguluyor.
O kararın neden verildiğini de öğrenmiş oluyor.
Böylece hem know-how yayılmış oluyor, hem sorunlar ve çözümler yayılmış oluyor.
Technical groomingde de ekipçe bayağı faydalanıyoruz ve böylece backlog'a buradan maddeler oluşturup eritiyoruz teknik sorunlarımızı.
Bunun yanında sprint groominglerde de product manager'la beraber next sprint'in gündemini oluşturuyoruz.
Backdock'taki işleri gözden geçirip user storylerini etkileştiriyoruz.
Exertions kriteryaları oluşturuyoruz aslında.
Tastların boyutlarını büyüklüğü konuşulup küçültülebiliyor.
Ekip olarak 2 haftalık sprintleri bu şekilde planlayıp ilerletebiliyoruz.
Gelelim bir de biraz AI konularından bahsedelim.
Günümüzde tüm süreçlerimizde artık AI yer almaya başlıyor.
Siz süreçlerinizi dahil ediyormuşsunuz, nasıl dahil ediyorsunuz?
Biraz bahseder misiniz? Süper.
Bu konu... Çok sevdiğimiz ve ilgi duyduğumuz bir konu.
Hem Trendyol olarak hem de Product Ads olarak.
2025'in ikinci yarısından itibaren geçtiğimiz 6-7 aylık süreçte çok tatlı işler yaptık, yapmaya çalıştık.
Trendyol içindeki AI Agents platformunun da desteğiyle.
Zaten bir kısmı takip edenler zaten görmüşler.
Trendyol tek kanallarından, Medium yazısı olarak vs.
olsun paylaşıldı. Product Ads olarak da süreçlerimizi aslında iyileştirmek adına şuralara dokunduk.
başlığı altında. Öncelikle şeyden bahsetmiştik Jira'dan.
İşlerimizi Jira üzerinden, Jira Task'lar üzerinden ilerletiyoruz.
Bir Jira Task'ın içeriği de hani takdir edersiniz ki hem geliştirme, hem test süreçleri, hem de bir dokümentasyon anlamında çok bir öneme sahip.
O yüzden Jira Task'ların içeriklerinin zengin olması çok önemli.
Buradaki zenginlikten kastım ne iş yapıldı, işte hangi koşullar yeterli bu işi dana çekebilmek için, nereye ne yapıldı, kontraktlar neler vs.
İşte bu içeriğin zenginleştirmesi adına ve bu konuya verilen önemini de arttırmak adına bir AI agent oluşturduk.
Bu agent jira taskını alıyor, açılan bir jira taskını veya update edilen jira taskını.
Direkt triggerlanıyor ilgili workspace ve agent jira taskını değerlendiriyor belli başlıklar altında.
İşte description'ı açık ve net mi, motivasyon belirtilmiş mi?
İşte bir servis yazılıyorsa, endpoint yazılıyorsa, kontrakları var mı?
Acceptance kriteryalar eklenmiş mi?
Hangi projeler etkileniyor?
Dokümentasyon yazılacak mı?
Test yazılacak mı? Vesaire gibi başlıklar altında, temel başlıklar altında değerlendiriyor ve bu task'a bir kalite skoru belirliyor.
Estimation değil. Quality score adı da bir custom field.
Puanı yazıyor. Sadece puan da yazmıyor.
Bu değerlendirme sonucunda bir analiz raporu oluşturuyor aslında.
Bir feedback oluşturuyor. İşte diyor ki acceptance kriteri yazmamışsın veya end point yazılacak demişsin.
Ama kontraktı belirtmemişsin gibi.
Bu analiz raporunu da taskı açan kişiye veya taskın description'ını update eden kişiye Slack üzerinden mesaj atıyor.
Bu da ne işe yarıyor? Ne işe yaradı diyeyim hatta.
Gerçekten takımımızda açılan...
taskların içeriğinin doğru anlamda dolu olmasına itti bizi.
Gerçekten o task'a baktığında ne iş yapmamız gerektiğini anlayabiliyoruz.
5 yıllık takımdayız mesela.
Biz bile bazen bazı task'larda işte bir task var sadece açan dışında kimse yapamaz.
Hatta açan bile uzun süre geçmişse unutur.
Aynen unutur. Yaşandı ben yaptım.
Oradan gerçekten hani takıma bugün birisi gelsin, ojotaskın okusun ne yapacağını bilecek konuma geldi bu tool sayesinde.
Ve bu tool da hani Trendle içerisinde birçok takım kullanmaya başladı.
Siz kullanmıyorsanız size de öneriyorum diyeyim.
Ben çok beğendim bu arada bir bakmak isterim neymiş diye ilk defa duydum.
Enize sağlık çok iyiymiş. Teşekkürler.
Onun dışında özellikle AI Agent platformunun zaten üzerine çok çalıştığı bizim de test tarafında Product Ads ekipleri olarak katkılarda bulunduğumuz bir coding ve test planner agent
olaylarımız var. Elimizde zaten artık ayrıntılı JTASK'larımız var.
Bu JTASK'ları üzerinden yine sadece bir koment ile geliştirmeyi yaptırabiliyoruz.
Önce bir teknik plan çıkartıyor ve bize Slack üzerinden bir planı sunuyor.
Onaylarsak geliştirmesini yapıp MR'ı açıyor.
Aynı şekilde test tarafı için de bir geliştirme yaptık.
Katkıda bulunduk. Aynı süreç test tarafı için de geçerli.
Bir koment ile test planner dedike olan agent triggerlanıyor ve Jira taskını alıyor.
Uygulamanın geliştirileceği Feature'ın geliştireceği uygulamanın reposunu alıyor ve o repoya ait test projesinin reposunu alıp bu üç kaynağı analiz edip test case çıkartıyor ve bu test case'lerin test projesine nasıl implement edileceğinin
analizini, planını çıkartıp onaya sunuyor.
Onu onaylayınca da bu sefer o geliştirme yapılıyor gibi bir sürecimiz var.
Burası hala geliştirme aşamasında.
Buradaki en önemli konu reviewer olarak yine bize düşüyor aslında.
Sadece... Hani biraz da amelasyon diyeyim.
Agent'a yıkmış oluyoruz.
Biz onu yönlendiriyoruz, review ediyoruz ve bunu yaptırıyoruz.
Yani bu sayede aynı anda 3-4 çıtır şeres task'ı yaptırabiliyoruz diyebilirim.
Bir de hani işte test stack'den falan bahsettik.
Artık hani test ve kalite süreçlerinde biz şeyi açtık işte.
Testleri yazalım, paralel koşalım.
İşte test sonuçlarını raporlayalım falan.
Onlar zaten hani fabrika verimiz olarak bizde var.
Burada... Bir agent daha yaptık.
Olayı da şu, feature-based, branch-based testlerimiz her komütte koşuyor demiştik.
Bu testler patlayabiliyor yapılan geliştirmeyle birlikte veya direkt test ortamını patlatıyor.
Yani merge testi mesela ortamda patlayacak.
Burada bir change-failure ilişkisi kuran bir agent tasarladık.
Testler patlarsa veya ortam kalkamazsa triggerlanıyor AI workspace'imiz ve neden testler patlamış veya ortam neden kalkmamış önce oranın bir raporunu alıyor.
Sonra bir de bu testleri triggerlayan komiti, branch'i alıyor.
Oradaki değişikliklere bakıyor ve dediğim gibi change failure ilişkisi kurup bak sen böyle bir değişiklik yapmışsın.
Bundan dolayı testin patlamış.
Testte şu bekleniyor ve ortam bu sebepten dolayı kalkmamış.
İşte config eklemişsin ama test ortamında config yok gibi bir analiz raporu sunup bunu yine pipeline triggerlayan, komite atan kişiye rapor olarak sunuyor.
Bu da gerçekten... kullanışlı bir araç.
Bu sayede işte developer arkadaş developer in test'e gidip test patladı neden acaba gibi sorularını azaltıyor veya patlayan testlerle ilişki kuramayabilir.
Domain'e pek hakim olmayan yeni gelen bir arkadaş.
Ona ayrıntılı bir rapor sunuyor bu tool.
Burada yararlanıyoruz AI'dan.
Sprintlerden konuştuk.
Sprintlerimiz işte retrolardan konuştuk.
Her sprintin sonunda retrodan önce bir sprintimiz bir review ediyor.
İşte neye bakarız? 4K metriklere bakarız.
Sprinti tamamlama oranlarımıza bakarız.
Scope grip işler almış mıyız?
Bizi bloklayan işler neler?
Gibi birçok metre bakıyoruz.
İşte bu metrikler aslında kimisi işte Jira'dan, kimisi 4K'yi takip ettiğimiz tool'lardan vs.
Toparlanabilecek şeyler ama...
Hem toplantı süremizi yönetebilmek hem de daha ayrıntılı ve tek elden, tek bir sayfadan takip ettiğiniz tüm metrikleri görebilmek adına bir de Sprint Reviewer Agent'ımız var.
Biz ona Jira'daki Sprint'imizi veriyoruz.
O gidip bizim istediğimiz tüm metrikleri topluyor.
Forky metriklerini önümüze getiriyor, analiz ediyor, yorumluyor hatta bir önceki Sprint'e karşılaştırıyor.
Sprint tamamlama oranlarımızı, bloklayan işleri, işte AI ile yapılan işler vs.
birçok metriği bize yorumlayan bir Agent'ımız var.
Bir de On-Call Agent'ımız var.
Burada şu an üzerine aktif olarak çalıştığımız bir agent.
Aslında AI'ye ilk on-call agent ile girdik.
Sonra işte biraz park ettik vesaire.
Şu an ufak tefek işleri halleden flow'larımız var.
En eğitimde olsun vesaire ama on-call agent'taki de hedeflediğimiz olay anlık olarak bir alert durumunda, bir hata durumunda on-call agent'ın devreye girip bu problemi yorumlaması.
bize en hızlı ve en doğru şekilde çözüm veya sebep sunması.
Bu sayede manuel birçok yükten kurtulmak, problemleri hızlıca dönüş sağlayabilmeyi hedefliyoruz diyebilirim.
Sizin bir iki agent'ınız yok mu?
Sizin ordunuz varmış agent'tan.
Aynen. Biz çalışmıyoruz abi.
Çalıştırıyoruz. Aynen.
Siz köle gibi kullanıyorsunuz aslında agent'ları.
Ben sizi bulacağım.
Aynen. EY'i seviyoruz.
Onu fark ettik yani.
Ben bu kadar çok herhalde her yerine, her sürecine adapte eden.
Herhalde duyduğum en iyi ekiplerden bilirsiniz yani.
Hem tabii ki şey planlama gibi yani sprintin genel bakışıdır vesaire olsun.
Hem kodlama yani bu işin aslında sprintten bir maddenin başlangıcından alıp da bitişine kadar olan aslında birçok süreci ki yani nöbet dahil sprint dışı da aslında bir işler var.
On call süreçleri.
Hepsi aslında dahil bir şekilde.
Her yerde bu iş nasıl da verimli olur.
İşte workflow'lar vesaire.
Araya bir şeyler koymuşsunuz.
Enize sağlık. Buradan bence birçok kişi beni dinleyen böyle bir kafa açar fikir verir yani bir şeyler yapar.
Kesinlikle. AI'ın işimizi bitireceğini düşünmüyoruz.
İşimizi kolaylaştıracağını biliyoruz.
O yüzden işimiz çok rahat bir şekilde bu güzel işleri çıkartabiliyoruz.
Çok iyi. Güzel. Buradan AI mesajı ve AI agentlarımızı.
Bu arada AI agent platformu gerçekten çok işleri kolaylaştırıyor.
Oradan da bu ekibin, agentlik experience ekibinin de eline sağlık diyelim.
Evet arkadaşlar. Gerçekten dolu dolu bir bölüm oldu.
Sonundaki Utku'nun AI bombardımanıyla beraber böyle ekibin gerçekten Product Edge'sinin en başta neler yapıyor, bir ürün açık arttırmayla satılıyor mudan nerelere geldik.
Hepinizin ağzına sağlık.
Çok teşekkür ederiz. Güzel bir sohbet oldu.
91. bölümümüzde Product Edge ekibiyle beraberdik.
Bir sonraki bölümde görüşmek üzere.
Bye bye.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.