Konuklar: Berrin Maralı, Barış Ay, Hasan Atasoy
44. bölümümüzde konuğumuz Fulfillment Inbound ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Transkript
Selam ekip, ben Storefront TR 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 44.
bölümünde Fulfillment Inbound ekibiyle birlikteyiz.
Fulfillment Inbound ekibini tanıyıp, ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Arkadaşlar hepiniz hoş geldiniz.
Hoş bulduk, merhabalar. Hoş bulduk, merhaba.
Bugün güzel bir bölüm olacağını umuyoruz.
Öncelikle kendinizden bahseder misiniz biraz arkadaşlar?
Tabii ben başlayayım. Selamlar tekrardan.
Ben Barış. Fufi'nin inbound ekibinde developer olarak çalışıyorum.
Trendyol'a yaklaşık bir buçuk sene önce trend programıyla katıldım.
Sözü Hasan'a bırakayım.
Teşekkürler Barış. Ben de Hasan.
Selamlar herkese. Yaklaşık iki buçuk yıldır inbound ekibinde developer olarak çalışıyorum.
Bundan önce de bir senelik bir backend developer deneyimim oldu.
Ben de sözü Berrin'e bırakayım.
Teşekkürler. Ben de Berrin.
İki senedir Trendyol'dayım.
Ben de developer, intest rolündeyim.
Şu an inbound takımındayım ama daha önce MPK ile beraber birlikte çalışıyorduk aslında.
Ghost takımındaydık.
Benim de bir 6 yıllık bir...
devin test rolünde geçmişim var diyebilirim ben de.
Miribalar efendim. Bu arada ek bilgi MFK dekleri benim Fırat.
Bu bilgiyi paylaşmamıştık.
Kim diye soracaklar. Aynen.
Alışkanlık. Ghost'an kalan alışkanlık diyebiliriz.
Evet. Arkadaşlar hoş geldiniz tekrardan.
Aynı tribe'ımdan. Kardeş ekiple beraber olmak bu bölüm benim için o yüzden eğlenceli geçecek.
O yüzden en başta böyle inbound'a inmeden önce bizim tribe ne iş yapıyor?
Yani fulfillment tribe'ı, fulfillment nedir?
Kerime olarak dışarıdan ne kadar biliniyor, bilinmiyor.
Tam emin değilim. Ama en başta bir fulfillment ne yapar?
İsterseniz... En başta onlardan bahsedelim.
Sonra inbound'un içine gireriz.
Aynen. Burada ben anlatabilirim fulfillment tribe'i ne yapıyor diye.
Daha önce aslında tribe'imizden Asteria ve Sirius bu podcast'a katılmıştı.
Onlar zaten bahsetmişti eğer dinlediyseniz.
Ama ben de bir özet geçmek isterim tabii ki de.
Biz aslında Trendyol'dan, müşterilerimiz de aynı şekilde Trendyol.com üstünden bir sipariş oluşturduğunda aslında bu tamamen saman bir sipariş oluyor.
Henüz fiziki hale gelmemiş oluyor.
Bunun fiziki hale gelmesi süreci...
Aslında bizim tribe'ımızın sorumluluğunda diyebilirim.
Onu da şöyle bir ufak özetleyeyim tekrardan.
Aslında depolarımızda bizim ürünlerimiz geliyor.
Bu ürünleri aslında biz stoklara kazandırıp daha sonrasında elimize ulaşan o turuncu paket haline gelmesini sağlıyoruz.
Ve bunu da müşterilerimize yolluyoruz aslında.
Bu tribe'ımızın ilk partı diyebilirim.
İkinci partında da tamamen iade süreçlerinin yürütüldüğü, yani müşterilerimizin yine bize iade ürünlerini gönderdiklerinde iade süreçlerini yürüttüğümüz bir akış var diyebilirim.
Böyle de özetleyebilirim ben de.
Güzel özetledin bence. Ben şimdi şeyi merak ettim.
tribe'ın içerisinde inbound ekibi tam olarak ne yapıyor?
Buna ben cevap verebilirim.
Aslında inbound'un tribe içinde sorumluluğu, ana sorumluluğu diyelim.
İki tane domain.
Bunların biri malkabül, biri de iade domeni.
Bunun dışında tabii malkabül ve iade'ye göre daha ufak diyebileceğimiz membership, identity, malkabül ve tedarikçi iade gibi sorumluluğu bize ait olan domainler bulunuyor.
Ama onların detayına çok girmeyeceğim.
Biraz malkabülden bahsedeyim.
Bu kısmı biraz ikerleştirerek anlatmak istiyorum.
Çünkü dinleyici de kafasına canlandı.
Hem daha faydalı olur diye düşünüyorum.
Malka bu sürece... Şu şekilde işliyor.
Depoya bir tır yanaşıyor.
Bu tırın içinde tedarikçilerden gelen kollenmiş ürünler oluyor.
Biz buna sevkiyat diyoruz bu arada.
Sevkiyatlar malkabıl masalarında taşınıyor.
Malkabıl masalarında aslında bu sevkiyatların içindeki ürünler teker teker veya bazen toplu da olabiliyor.
Duruma göre değişiyor orası. Kalite kontrolden geçiyor.
Bu kalite kontrolleri de şey gibi düşünebiliriz.
Ürün gerçekten görseldeki ile aynı mı?
Hasarlı mı geldi gibi kontroller olarak düşünebiliriz.
Kontrollerden geçtikten sonra aslında bir sepete adresleniyor.
Burada 3 farklı... ...farklı tipimiz var.
Flow Through, Stock Through ve Fulfilled by Trendyol diye.
Stock Through ve Fulfilled by Trendyol'da aslında bu sepete attığımız ürün...
...conveyor yardımıyla stok katlarına gidiyor ve...
Mezenin de ilgili raflara adresleniyor.
Daha sonrasında da müşterinin alımı için satışı açılıyor şeklinde düşünebiliriz.
Burada sadece Fulfillment by Trendyol'da şöyle bir ayrım var.
Ürünler aslında tedarikçiye ait oluyor.
Sadece operasyonel süreci biz yönetiyoruz.
Flow through akışında ise şöyle bir süreç işliyor.
Bu bahsettiğim süreç aslında deponun başındaki tırdan başlayan süreç.
Bu müşterinin siparişi ile çiziklenen bir süreç oluyor.
Aslında müşteri siparişi veriyor.
Tedarikçi bu ürünü temin edip bize gönderiyor.
Ardımlarını da tekrardan SPT adresleme kısmına kadar getiriyoruz.
Daha sonrasında bu hiç stok katına gitmeden.
Paketleme masalarına gidiyor.
Paketlenip müşterinin müşteriye ulaşmak için yola çıkıyor olarak düşünebiliriz.
Malkı bir sürece aslında özet olarak bu şekilde.
İAD'den bahsetmem gerekirse de İAD'de de depodan çıkan siparişin müşteri tarafından İAD kaydı oluşturulup Trendol sayfalarından İAD kaydı oluşturulup kargo verilmesiyle başlıyor.
Bu paketler depoya ulaşıyor.
Yine aynı şekilde İAD masalarına iletiliyor.
İAD masalarında yine çalışma arkadaşlarımız kontrollerini yapıyorlar.
İAD'ye uygun mu? Gerçekten müşterinin söylediği sebeple aynı sebepten.
bulayım iade edilmiş gibisinden kontrol yaptıktan sonra bunun red edilmesine veya iadesinin kabul edilmesine karar veriyorlar.
İade reddedilirse bu paket tekrardan müşteriye geri gönderiliyor.
İade kabul edilirse yine aynı şekilde flow through ve stock through diyebileceğimiz iki süreç işliyor.
Stock through da eğer ürün hasarlıysa yani tekrardan satışa açık olabilecek şekilde alınamıyorsa offline imha sürecine gönderiliyor ve imha ediliyor olarak düşünebiliriz.
Eğer hasarlı değilse de bunu iadesi alınıp tekrardan satışa açılacak şekilde FlowTrue'da da şöyle bir akış var.
Hasarlı veya hasarsız olması fark etmiyor.
Aslında tedarikçi iade modeliyle bu aldığımız ürünleri tedarikçilere tekrar geri iade ediyoruz şeklinde özetleyebilirim iadeyi de.
Bu iade de şey güzel oluyordu ya depoya gittiğimizde hatırlıyorum.
İade kısmında şimdi...
İşte gözlük veya ayakkabıların sanırım çakmasını gönderebiliyor müşteri.
O yüzden ne alıp gerçekten bu gönderdiği aynı ürün mü diye bakıyorlar ya.
Yani buradaki çalışanlar bunun üzerine böyle tecrübeli insanlar.
Gelen iade ürünü gerçekten...
bizim gönderdiğimiz ürünü diye baktıkları bir alan var.
Hani onu böyle fiziksel olarak görmek gerçekten güzel bir tecrübe oluyor.
Evet kesinlikle katılıyorum.
Ya burada bahsetmenin bir süreç daha da var aslında.
Bu yeni yeni bizim için de yeni gelişen bir süreç.
Müşteri deneyimi. Şu an bu tarz böyle müşteriyle konflikte düştüğümüz konularda müşteri deneyimine gönderip aslında müşteriliğe iletişime geçip bu problemleri çözmek.
için bir geliştirme yapıyoruz.
Daha yeni yeni sprintlerimizde yaptığımız bir iş.
Açıkçası ben de tam bununla alakalı bir şey sormak istiyordum.
Sen üzerine söyledin.
Bu sıralar sosyal medyada çok fazla görüyorum.
İade süreçleriyle ya da iade koşulları ile alakalı çok fazla şey var.
Anlaşmazlık durumları var.
Bir de tabii bu tarz konular kişiden kişiye değişen konular olduğu için birazcık yani tabii ki standartları belli olan şeyler ama herkes kendine göre yorumlayabiliyor.
Dolayısıyla böyle bir çözüm üretilmesi de bence oldukça verimli, oldukça faydalı.
Şimdiden ellerinize sağlık. Oldukça da yani şey süreçlermiş, detaylı süreçlermiş açıkçası.
Yani iade edip geçmemek gerekiyor.
Ben birazcık böyle ekip yapınızdan bahsetmek istiyorum.
Ekip yapınızla alakalı sormak istiyorum.
Ekip yapınız ve çalışma şeklinizden biraz bahsedebilir misiniz bize?
Tabii abi bahsedeyim.
Ekibimiz 7 developer, 2 developer in test, 1 product manager ve 1 team lead olmak üzere 11 kişiden oluşuyor diyebilirim.
Sprintlerimizi haftalık olarak koşuyoruz.
Her hafta pazartesi günü planlama toplantısıyla başlıyoruz.
Çarşamba akşamına kadar da developerlar olarak...
geliştirmelerimize devam ediyoruz.
Bu süre zarfında ise developer test arkadaşlarımız da şifre maddelerinin hazırlıklarına otomasyon maddelerinin geliştirmelerine devam ediyorlar.
UAT adımları tamamlanmış maddeleri de canlıya alarak buradaki metrik hedeflerimizi de korumaya çalışıyoruz.
Perşembe sabahı ise bir sonraki sprintte yapacağımız şeyleri konuştuğumuz grooming toplantımız oluyor.
Perşembe cuma günlerinde ise genel olarak groomingde konuştuğumuz maddelerin analizi ve ar-get çalışmalarımızla geçiyor.
Cuma günleri mob session düzenliyoruz.
Burada bir araştırma konusu belirliyoruz ve bir arkadaşımızın örnerliğinde örneklerle beraber o konu üzerinde tartışıyoruz.
Ayrıca cuma günü sonunda ise o sprintte neleri iyi yaptığımızı hangi konularda gelişime ihtiyacımız olduğunu konuştuğumuz retro toplantımız oluyor.
Bu toplantıları hariçinde ise sabah ve akşamları update'lerimizi verdiğimiz daily toplantılarımız oluyor.
Burada akşam closing toplantısı yapmamızdaki amaç ise ertesi güne kalmaması gereken kritik olduğunu düşündüğümüz konuları ekiple paylaşmak diyebilirim.
Abi çok güzel. Bence gayet güzel bir dağılım.
Güzel bir şey.
Benim aklıma şey takıldı.
Bundan öncesinde bir konuştuk diye hatırlıyorum.
Sanırım bir sene önce...
İki farklı ekip birleşerek FFMD inbound ekibini oluşturmuştu diye hatırlıyorum.
Bu süreç nasıl bir süreçti?
Bu süreci nasıl yönettiniz? Nasıl ilerledi bu süreç?
Evet abi ya burada her iki ekip de zaten tren yolu kültürüne adapte olduğu için.
Kültür açısından herhangi bir problem yaşamadık.
Sadece ekiplerin pratikleri arasında farklılıklar vardı diyebilirim.
Bu pratikleri de baştan değerlendirerek ekip olarak bizim için uygulu olanları seçip o şekilde devam ettik.
Tabii ki de bu süreçte aynı fikirde olmadığımız konular da oldu.
Bunları da retrolarda...
Uzun uzun konuşup çözüme kavuşturduk.
Ayrıca bir kısmının da altını çizmek istiyorum.
Burada farklı ekip know-how bilgilerinin birleşmesinde bize çok faydası oldu.
Bu durum web platforming sürecimizde de çok fazla fayda sağladı, katkı sağladı diyebilirim.
Burada evet yani bu bence güzel bir tecrübe.
Yani şu en başta bir ekibiz farklı bir kültürden aslında çok farklı bir kültür değil.
Yani yine aynı traktaydık fakat diğer ekibin aslında yaptığı iş biznes olarak aslında farklı bir yerde.
Ama bu iki ekibin birleşip de ortak bir web platformu.
girmesi böyle farklı bakış açılarını getiriyor.
Hani biz böyle yapıyorduk diğeri biz böyle yapıyorduk.
Ama bak böyle bir şey var gibisinden bir şeyler getiriyor ve sen aslında bazen şey oluyor böyle.
Biz bir şey yapıyoruz ve zaten hep bazı şeyleri yaptığımız için üzerine düşünmeden yapıyoruz.
Ama dışarıdan biri gelince ay aslında böyle bir şey de var diyor.
Ha doğru. Aynen böyle bir şey de var diyoruz bazen.
Bu tam onun için böyle uygun bir yer gibi.
Kesinlikle. Aynen öyle.
Bizim de mesela daha öncesinde dediğim gibi Fırat'la aynı ekipteydik biz.
Hasan Barış inbound ekibindelerdi.
Bizim ekip dağılınca biz direkt böyle inbound ekibine eklenmiş gibi olduk.
Ama şeyde gerçekten problem yaşamadık bence kültür açısından.
Bir problem yaşadığımızı düşünmüyorum.
Dediği gibi tamamen aslında uygulama yöntemlerimizi sorgulamamıza sebep oldu her iki tarafında.
Baya güzel işler çıkardık bu sayede de.
Peki. Inbound ekibi olarak böyle...
Birazcık tüm süreçlerin ortasında bir ekip gibi benim kafamda canlandı.
O yüzden çalıştığınız ekipleri birazcık öğrenmek istiyorum.
Ben de farklı ekiplerle çalışıyor musunuz?
Orada karşılaştığınız çalışmalar oluyor mu?
Bunu merak ettim. Tabii buna ben cevap verebilirim.
Aslında burada Tribe içinde bizim sıkça çalıştığımız 3 ekip bulunuyor.
Order Master Data, Stock Allocation ve Supply Chain ekibi.
Bunlara da bağlı olduğumuz noktalar aslında Order Master Data yani Fırat'ın ekibinde ürün, lokasyon, sipariş, bu az önce bahsettiğimiz Flow Tour süreçte sipariş bilgisine ihtiyacımız var.
Onun dışında tedarikçi gibi bilgileri almak için beraber çalışıyoruz.
Stock Allocation ekibinde de şöyle bir süreç var.
Aslında iade ve mal kapı sonrası bir stok oluşuyor.
Bu stok oluşma ve stokların bir yerden bir yere taşınma yani stok hareketi konusunda da aslında onlarla beraber çalışıyoruz diyebilirim.
Bu yine şeyde domain part'ında anlattığım tırların içindeki sevkiyatların içindeki ürün bilgileri içinde aslında bir supply chain ekibiyle beraber çalışıyoruz.
Yine ShipMut ve Sirius ekibiyle de beraber çalıştığımız noktalar var ama genellikle bu başta bahsettiğim 3 ekiple sık olarak çalışıyoruz diyebilirim.
Tribe dışında da iade süreçlerinden ötürü OMS'de çalıştığımız ERP ve finans ekipleriyle çalıştığımız noktalarımız var.
Genelde yine tribe içinden de OMS, ERP ve finans ekibini sayabilirim sık çalıştığımız ekipler olarak.
Peki inbound kısmında şu anda teknoloji olarak bile isterseniz bu kısma gelelim.
İşte mal kabuller yapılıyor.
Depoya mallar geliyor. Bunların işte içeri alınması yapılıyor.
İadeler geliyor. Bu iadelerin alınması, kontrolleri yoksa imhaları vs.
Bu tarz şeylerle oluşuluyor.
Peki bunun için şu an kullandığımız teknolojiler neler?
Hani DB olsun, backend mi, UI mi?
Ya da UI ağırlıklı mıyız, backend ağırlıklı mıyız?
Bu tarz detaylardan biraz bahsedebilir miyiz?
Tabii abi. Öncelikle teknolojilere nasıl karar verdiğimizi açıklayayım istersen.
Öncelikle teknoloji seçiminde ekip olarak kullanacağımızı düşündüğümüz teknolojileri bir araştırıyoruz.
Daha sonrasında bir araya gelip çıkarttığımız pros ve konsları gözden geçirip duruma göre karar veriyoruz.
ve nihayet sonucu erdiriyoruz.
Daha sonrasında S&M teknolojilerden bahsedeyim.
Frontend projelerimizde Angular kullanıyoruz.
Backend'de ise genellikle C Sharp ve Go dillerini tercih ediyoruz diyebilirim.
Veri tabanı olarak da şu an aktif olarak MS SQL ve Couchbase'i kullanıyoruz.
Ancak belli ihtiyaçlara göre de Elasticsearch ve Redis gibi araçlara da başvurabiliyoruz.
Otomasyon testleri için ise Java'yı tercih ediyoruz.
Ayrıca sistemlerinizin izlenmesi, performans takibi için ise New Relic, Grafana ve Sentry gibi araçları da kullanıyoruz.
Burada Sentry'den falan bahsetmiştin.
Depoda vesaire şimdi operasyonel bir kısım olduğu için 7-24 çalışan bir operasyon olduğunda herhangi bir yavaşlıkta direkt zaten haberin oluyor.
Yani support ekiplerimiz aracılığıyla işte şurada böyle bir sorun var ya da bizim aletlerden vesaire bir performans sorunu gerçekten olduğunda hemen...
hissedilebiliyor. Bu yüzden de monitoring hakikaten de depo kısmında çok önemli.
Burada bu sentry dediğin monitoring kısımlarında mal kabul de olsun, iade de olsun.
Bir sorun olduğunda nasıl aksiyon alıyorsunuz ya da monitoringlerde neler yapıyorsunuz tam olarak?
Herhangi bir sorun anında Nivelik üzerinden ilgili kontrolürde Yavaşlığı gözlemlediğimizde bunun nereden kaynaklı olduğunu da görebiliyoruz.
Database'e ilgili sorunlar varsa da orada Sentry'e başlıyoruz.
Ve Sentry'de herhangi bir yavaşlık olduğunda buradaki verilerle ilgili DB ekibine gidebiliyoruz aslında.
Monitoring demişken ben bir de test süreçlerinizle ilgili bilgi almak istiyorum aslında.
Yani anladığım kadarıyla zaten oturmuş bir süreç var uzun zamandır.
İki ekibin de birleşmesiyle çalışan, akan bir sistem var.
Test kısmında neler yapıyorsunuz?
Ben cevaplayayım onu da. Aslında Sprint'le Developer'in testi olarak da başlangıcında...
Boşluğumuz olduğu noktalarda direkt test otomasyonuna yöneliyoruz ve test otomasyonlarımızda iyileştirici geliştirmelere odaklanmaya çalışıyoruz.
Oradaki yaptığımız geliştirmeler sayesinde de aslında sistemin kalitesini oldukça arttırmış oluyoruz.
Ve testimize maddeler sprintin içinde gelmeye başladıkça da tamamlayarak UAT'ye yolluyoruz aslında.
Ayrıca bir de hızlandırmak için süreçlerimizi iki takım birleştikten sonra şifref yöntemini biraz daha benimsedik.
Ufak oraya da bir değineyim.
Yönteminde aslında daha henüz geliştirme yapılmadan maddeler geldiğinde sprint'e ve tartıştığımızda durumları yapılırken request response detayları, validation detayları gibi detayları olabildiğince
açıklayıcı şekilde yazmaya çalışıyoruz.
Planlamada da önümüze geldiğinde madde evet bu shift left maddesi deyip tagliyoruz hatta bunun için.
Shift left maddelerinde de şöyle ilerliyor.
Developerlarımız aslında geliştirmelerine normal sprint akışında nasıl başlıyorsa Biz de aynı şekilde developer'ın testi olarak sprint'in başlangıcında böyle bir şifre maddemiz varsa onlara başlıyoruz aslında.
Örnek verecek olursam böyle bir backend case'ini düşündüğümüzde benim önümde endpoint'imin ismi belli, validation'ları belli, request response detayları belli.
Benim artık otomasyon yazmak için herhangi bir engelim olmuyor.
Bu durumda da ben otomasyon testlerimi yazmaya başlıyorum.
Aynı developer'ın geliştirmeye başladığı gibi.
Böylelikle de bize bayağı bir artı sağladı açıkçası bu şifre fiyonu.
Şifre fiyon teminde bu hızlı geliştirmelerimiz, otomasyon geliştirmelerimiz sayesinde test step'imizde aslında madde çok kısa bir sürede UAT'ye ilerletilebiliyor.
Ve daha öncesinde de eğer yazarken bir şey fark edersek developerlarımıza erkenden haber verip ya burada bir problem olabilir, bunu gözden kaçırmayalım diyebileceğimiz şeyleri de önceden keşfedebiliyoruz.
Ayrıca bir de bu... Otomasyonlarda da bilindiği üzere böyle data tekrarlarına uğramamak için, data problemleri yaşamamak için bizim test platformumuzun hazırladığı GATEC var.
Aslında da CRIZE yöntemi var.
Bu bize aslında bir environment sağlıyor.
Bu environment'da da biz datalarımızı oluşturup, komponentlerimizi oluşturup...
bağımlılık yaratmadan kolayca otomasyon testlerimizi koşabiliyoruz diyebilirim ben de.
Çok güzel. Fakat yani benim aklıma şöyle bir şey takıldı.
Şimdi çok büyük bir aslında sistemde çalışıyoruz hepimiz ve ek bir yani ne olursa olsun birbiriyle bağımlı olduğu çeşitli noktalar var.
Böyle bir durumda bu bağımlılıkların kalitesinden Nasıl emin oluyorsunuz peki?
Orada da aslında şey diye bahsedebilirim.
Yani tabii ki de bağımlı olduğumuz yerlerde performans testleri koşmaya çalışıyoruz olabildiğince.
Ama onun haricinde çok çok daha öncesinde aslında geliştirme esnasında bir şeyleri keşfedebilmek adına request response alışverişlerinde veya event alışverişlerinde kontrak testler yazmaya çalışıyoruz.
Bu kontrak testler de aslında bize herhangi bir bozulduğu nokta olduğunda pipeline'ımızda patlatarak en öncesinden haber vermiş oluyor ve...
Dependent olduğumuz bir ekibi daha hiç haberi olmadan kırmayı engelliyoruz.
Bu bize bayağı bir artı sağlıyor diyebilirim.
Dediğim gibi bir de onun haricinde de performans testleri koşarak böyle dependent olduğumuz takımlara okey miyiz gibisinden böyle test ediyoruz diyebilirim.
Peki burada performans test süreçlerinden biraz bahsedebilir misiniz?
Tabii. Orada da aslında performans testleri bildiğiniz üzere Black Friday öncesi oldukça dikkat ettiğimiz bir konu hepimizin trend yolu içinde.
Biz de olabildiğince dikkat etmeye çalışıyoruz.
Bizim biraz daha Black Friday'miz aslında tam başladığı zaman değil, başlamadan önce geliyor bize biraz daha.
Kışı depo tarafı olduğu için ürünler geliyor.
O ürünlerin içeri alınması süreçleri var.
Bu baya bir yoğunluk oluşturuyor bizim tarafta.
O yüzden olabildiğince erkenden çalışmalarımıza başlıyoruz diyebiliriz.
Burada da aslında birçok ekibin kullandığı bir yöntem var performans test süreçlerinde.
Header yöntemi dediğimiz bir yöntem var.
Bir isteğin veya bir eventin headerına bir key value vererek bunun engellenmesi işte veya mocha bakması gibi böyle bir yöntem vardı.
Burada da biz inbound olarak işte birleştikten sonra şeyi fark ettik.
Herkes farklı farklı key name'i kullandığını fark ettik ve böyle çok fazla implementasyon için hem developerlarımızın uğruna...
Hem bizim takibimizin zorlaşacağı bir nokta olduğunu gördük.
Burada bir RFC yazmak istedik aslında.
Bunun için önce RFC çalışmalarına başladık.
RFC çalışmalarına başladık ve burada ekiplerle de konuşarak hatta bizim ÖDES ekibimiz var performans tesisinde.
RFC ekibiyle de biraz fikir alışverişinde bulunarak RFC'de header yöntemini standart...
Dize etmiş olduk. Aslında şöyle ufaktan da bir değinebilirim belki RFC kısmına.
Bir header'da mock veya internal ve external gelmesi durumuna göre aslında sistem tepki veriyor diyebilirim.
Eğer bir mock geliyorsa header'da bu tamamen mock apilere bakacak veya işte event fırlatmasını engelleyecek şekilde ayarlama yapıyoruz.
Bu bizim replatform...
Yaptığımız süreçlerde aslında çok çok faydasını gördük.
Hiçbir ekibe bağımlılığımız olmadan tamamen mockla simüle ederek bağımlılıklarımızı testlerimize çok rahat koşabildik.
İkinci bir yöntem olarak da internal ve external dediğimde işte sana gönderiyorum bir header içinde external var.
Bunu almayabilirsin, kullanmayabilirsin.
Bu benim performans testim.
datam dediğimde karşı ekip hiç etkilenmeden aslında akışı tamamlayabilmiş oluyoruz.
Bunu da bize oldukça yararı olduğunu gördük diyebilirim.
Süper. Gerçekten gayet güzel ellerinize sağlık.
Biraz da şeyden sormak istiyorum.
Malcomble için sanıyorum replatforming süreciniz var şu sıralar bildiğim kadarıyla.
Neden böyle bir ihtiyaç oluştu bu konuda ve bunu nasıl yönettiniz?
Bunu merak etmiştim. Tabii bundan ben bahsedebilirim.
Aslında burada bizim Motivasyon kaynağımız support'tan gelen mal kabul yavaşlıkları diyebilirim.
Nöbetlerimizde çok fazla support'tan mal kabul yavaş çalışıyor gibi sözler duymaya başlamıştık.
Buna ek olarak tabii geliştirme maliyetinin artması gibi konular da vardı.
Bunların sebebi de aslında UI'deki business kodları ve bunların karmaşık olması.
Ek olarak da böyle raporların database view'lar üzerinden alınması gibi konularımız da vardı.
Bunlar da DBA'ye ekstra yük getiriyordu.
Bunu çözmek için de aslında bir platforming motivasyonu.
oluştu bize öyle söyleyebilirim.
Replatforming'i yaparken de aslında şöyle bir yol izledik.
Ekip olarak toplanıp depoya gittik.
depoda mal kabul sürecini baştan sona bir beraber inceledik.
Aslında neleri daha sade hale getirebiliriz tartıştık.
Daha sonrasında depoda tekrardan ofis katına çıkıp ofis ve depo aynı yerde bu arada bizim.
Ofis katına çıkıp event storming düzenledik.
Event storming'de de aslında bandut kontekstlerimizi çıkardık.
Operasyonla aynı dili konuşabilir miyiz?
Neleri değiştirmemiz gerekiyor bunun için gibi konuları tartıştık.
Bunları çıkardıktan sonra da splitlerimize dahil edip pick geliştirmelerimize başladık aslında.
Yakın zamanda da cam diye almayı düşünüyoruz Malcom'un platformunu.
En azından SD tarafı için.
FT'de yakında geliyor diyebiliriz.
Bu konu hakkında bu arada detaylı bilgi almak isteyen arkadaşlar olabilir.
Ekip arkadaşlarımız Trendyol'un YouTube kanalında How to Fix It serisine bir video çekecekler.
Oradan bu konu hakkında detaylı bilgi alabilirler.
Peki o zaman teknik kısımda veya spritlerden çıkıyorum.
Biraz daha şeye geçiyorum. Ekip iletişim kısmına.
Hani remote çalışıyoruz vs. Şu anda gerçi herkes İstanbul'da değil sanırım aynı.
Burada ekiple iletişimi güçlendirmek için böyle yaptığınız aktiviteler vs.
neler var? Genel olarak çalışma içinizden başlayayım istersen Refika.
Uzaktan çalışırken...
İletişim daha da geliştirmek adına bazı adımlar attık.
O yüzden ekip içi iletişimi arttırmak amacıyla kameralarımızı sürekli olarak açıp tutmaya özen gösteriyoruz.
Ara ara ofiste buluşup beraber çalışıyoruz toplanarak.
Düzenli olarak one to one'lar atıp gelişimlerimiz için feedbackler veriyoruz.
Bu da gelişimimizi daha da arttırarak aramızdaki iletişimde kuvvetlendiriyor.
Maddelerde duruma göre peer şeklinde ilerlediğimiz zamanlar oluyor.
Bazı zorlu maddelere peer girerek orada hata yapma oranını en az indirmeye başlıyoruz.
Böylece maddeleri daha hızlı ilerletimimize de olanak sağlıyor.
Hem de burada iletişimi de çok fazla geliştiriyor Payr ilerlerken.
Ve ayrıca şunu da bahsetmek isterim ki Payr Mount'ının...
Trend yolda en sevdiğim yaklaşımlardan birisi olduğunu da söylemek isterim.
Ek olarak ekip için iletişimini arttırmak için yaptığımız başka aktiviteler de var.
Mesela kahvaltılar düzenliyoruz.
Ardından beraber çalışıyoruz.
Ara sıra akşam değilleri sonraları oyunlar oynuyoruz.
Her duruma dair ve koşulu anlatabilen oluşturduğumuz emojilerimiz var.
Bu da ekip için iletişimde bayağı fayda sağlıyor diyebilirim.
Bu konuda da şampiyon benim.
Bayağı emojim var yani sürekli.
Barış senin gerçekten neden bu kadar çok emojim var?
15-20 tane emojisi olabilir bu arada içeride.
Çok iyi ya. Belki bilmediğimiz daha fazla olur.
Kaybettiklerimiz. Aynen ya çok ama çok bize malzeme veriyor bu arada Barış yani.
O yüzden biz onun emojileri sürekli okuyoruz.
Her duruma uygun bir Barış emojisi var.
Tüm duygulu düşüncelerini.
Herhangi bir Barış emojisiyle açıklayabiliyorsun.
Bence bu müthiş bir şey. Aynen öyle artık.
Bizim kanallarımızı geçti.
Trendol genelinde de kullanılmaya başlayan kanallar.
Ama son emojisi güzel ya.
Baklava adam var mesela Barış'ın.
Bayağı iyi. Biliyorum biliyor musun da bayağı iyi.
Yeni relizleri takip edemiyorum.
Aynen baklava adam var ya.
Direkt yapıştırın baklava gördüğünüz yerlerde.
Benim favorim Filozof Barış bu arada ya.
Bayağı oradaki ifadesi çok iyi.
ya Barış'ın. Evet gördüğünüz gibi.
Bir ihtimal göremeyecek ama.
Sizin her türlü şeyinizi alıp, SS'nizi alıp emojiler yapabiliriz.
Böyle insanlar diyormuşuz.
Artık olaya nasıl baktığına bağlı.
Okeydir arkadaşlar. Çok teşekkür ederiz.
Çok güzel bir sohbet oldu. Bizler teşekkür ederiz.
Biz teşekkür ederiz.
Sağ olun. Bizi davet ettiğiniz için.
Çok teşekkür ederiz. Bu bölümde Fulfillment Inbound ekibiyle birlikteydik.
Bir sonraki bölümde görüşmek üzere.
Bye bye. Görüşürüz.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.