Selam Ekip - E41 - Storefront TR Account & Checkout

Selam ekip. Ben Storefront TR ekibinden Cengiz.

Ben Fulfillment Order Masterplot ekibinden Fırat.

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

bölümünde Storefront TR Account Checkout ekibiyle birlikteyiz.

Storefront TR Account Checkout ekibini tanıyıp ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.

Arkadaşlar hoş geldiniz. Efendim hoş geldiniz.

Hoş geldiniz. Hoş bulduk.

Hoş bulduk. Keyifli, güzel bir bölüm olacağını düşünüyorum.

Storefront.tr, Count Checkout ekibi bizlerle.

Kendinizi tanıtabilir misiniz?

Kendinizden biraz bahsedebilir misiniz arkadaşlar?

Elif'le başlayabiliriz. Selam ekip, ben Elif Fırtan'ım.

3 seneden fazladır Trendyol'da çalışıyorum.

Frontend Developer'ım. Geldiğimden beri çalıştığım süre boyunca Storefront Türkiye altındaki ekiplerde çalışmıştım.

Son 1 senedir de yine Storefront Türkiye altındaki Account Checkout ekibimle çalışıyorum.

Hoş geldin. Berat'la devam edelim isterseniz.

Selamlar. Berat ben de.

Ben de QA tarafındayım.

Yaklaşık 2 senedir Trendyol'da çalışıyorum.

Ben de başından beri Storefront Türkiye altındayım.

Önce Mobile Web Disco'yla sonra Mobile Web Checkout'la şimdi de Web ve Mobile Web Checkout'la.

tarafında bu serüvene devam ediyorum.

Hoş geldin abi. Aslan senden devam edebiliriz.

Selamlar. Ben Aslıhan Özfidan.

Ben de iki yılı geçti aynı ekipteyim Storefront Türkiye altında.

Ben de de bu şekilde. Hoş geldin.

Son olarak Cihat senden devam edelim abi.

Selamlar herkese. Ben de ekibin Product Manager'ı Trendyol'da iki buçuk yılı doldurdum.

İlk olarak Mobilyap'e bakıyordum.

Sonrasında Mobilyap artı webin checkout ekran tarafına bakmaya başladım.

Şimdi bunların yanında da Azerbaycan Trendyol'la ilgileniyorum.

41... kere maşallah deyip inşallah podcastımızda güzel olacak diyeyim.

Abi 41. bölüme geldiniz tekrardan.

Hoş geldiniz. 41 kere maşallahı Storefront'tan sizin ekibe ilan ediyoruz.

Hayırlı uğurlu olsun 41 kere maşallah diyelim tekrardan.

Tekrar hoş geldiniz.

Ekipte ekibin bir kısmını tanıdık.

Ekibin kalanındaki dağılımı merak ediyorum.

Ekibin dağılımı nasıl? Ekip içerisinde kaç developer, kaç tester, kaç product manager?

Dağılımı tam olarak nasıl acaba?

Ben orada detaylardan bahsedeyim.

Dönem dönem değişebiliyor bu.

Proje bazlı olarak geçici rotasyonlarımız oluyor.

Sonra geri gelen arkadaşlarımız oluyor.

Ama bu podcast'ı yaptığım sırada takımda 8 developer arkadaşımız var.

3 tane QA yani test mühendisi arkadaşımız var.

1 tane tasarımı getiren, user experience'ı toparlayan UX UI.

dizaynımız var. Şu anda iki product manager.

Toplamda da 8-3 dediğimizde 11.

İki tane product 13. Bir tane tasarımcımız 14.

Bir de developerların takım lead'i olan bir arkadaşımız var Barış.

Onunla beraber 15 kişiyiz.

Toplam ekibimiz. 15 kişi bir ekip mi yoksa yani atıyorum.

Tek bir ekip. Tek ekip değil mi?

Aynen. Kurum iş planlamayı tek götüren Bulk ekip.

Okey yani burada aslında 15'i herhalde şimdiye kadarkilerden böyle kalabalık çünkü yapınız daha farklı diye anlıyorum.

Orada mesela şey mi oluyor? Atıyorum buradaki olay biznesin büyüklüğünden dolayı mı bölünme mi oluyor?

Mesela çünkü 2pm de varmış ya.

İstese yürür gibi. İstese 2 ekip olursunuz ama atıyorum o yapımı ona uymadığı için yoksa...

Böyle daha verimli olduğu için ne oluyor?

15 kişi tabii ki verim açısından yüksek bir adet.

Orada yeni başlayan ekip arkadaşımız çok fazla.

Product Manager arkadaşımız bir ayı daha doldurmadı.

Onun bir alışma süreci var.

Yeni gelen arkadaşların bir adaptasyonu.

süreci var. İleride değişebilir mi bu yapı?

Değişebilir. Ama şimdilik proje yoğunlukları da yüksek.

İşte Azerbaycan'a da TR'ye de aynı ekip içinde bakıyoruz.

Ekstra gelen yeni konular da oluyor.

Ama bir noktada takımdan da gelecek feedbacklerle beraber bu yapı değişebilir.

Anladım anladım. Süper abi.

Peki şu anda ekipte kaç kişi olduğunu öğrendik.

Peki Storefront, Account and Checkout ekibi.

Direkt tam ismi sanırım böyle değil mi?

Storefront TR, Account and Checkout.

Peki bu Account and Checkout ekibi tam olarak nelerden sorumlu?

Yani neler yapıyor tam olarak ekip?

Burada da direkt 100 Kullanıcı akışı üzerinden örneklendireyim.

Trend.com'a girdiniz.

Herhangi bir ürün aradınız.

Ürünü sepete ekledikten sonraki akışlar bizim ekibin domain scope'una giriyor.

Yani sepetindeki ürünler, sepette verdiğin recommendation alanları, sonrasında sepeti satın almak istediğinde gittiğin checkout sayfası, buradaki adres funnel'ları.

Final olarak da payment yine bu ekibin kapsamına giriyor.

Aslında checkout domain dediğimiz akış burası.

Kullanıcı ödemeyi de... Başarılı bir şekilde tanımaktan sonra checkout success dediğimiz başarılı ödeme alındı sayfasını görüyor.

Bu da yine bizim kapsamımıza giriyor.

Bu bölüm yani basket, checkout ve checkout success sayfaları checkout domeni gibi düşünebiliriz.

Account tarafında ise verilmiş siparişlerin statüleri.

Aslında en büyük konularımız orada oluyor.

İlk olarak onu söyleyebilirim.

İşte kullanıcı bilgilerim altından değişiklik yapmak istediğinde yine bizim domenimize gidiyor.

Her şey o profilim kısımları gibi yerler.

Account sayfasının altında gördüğünüz bütün ekranlar.

aslında bizim ekibimiz konuda gibi düşünebiliriz.

Ha çok iyi. O zaman baya bir sayfanız var abi aslında.

Hem ödeme kısımları hem kişisel yerler falan derken.

Şu anda 15 kişinin ne yaptığını kafamda oluşturdum yani.

Boş durmuyoruz. Evet fark ettim.

Kolay gelsin abi şimdiden.

Peki şimdi 15 kişilik burada bir developer vardı.

Peki burası hani mesela atıyorum bizim tarafta işte atıyorum 6-7 kişiyiz abim ve hani haftalık bir sprint koşuyoruz örneğin.

Oradaki yapıya uyduğu için işte deployment sürecine uyduğu için vesaire vesaire.

Sizde de şu an mesela sprintler koşuyor musunuz ya da haftalık mı oluyor?

Oradaki o çalışma düzeni bir arada nasıl gidiyor?

Bir arada şöyle gidiyoruz.

Haftalık sprintlerle gidiyoruz.

Pazartesiden pazartesi.

Perşembe günleri bir sonraki sprint'in işlerini konuştuğumuz grooming'imizi yapıyoruz.

Evet detaylı da konuştuğumuz bir toplantı olduğu için bu bir buçuk iki saate yakın bir toplantı oluyor ama tüm detayları orada netleşmeye çalışıp anlamada daha az detay bırakmaya çalışıyoruz.

Pazartesi günü de o perşembe konuştuğumuz ve puanladığımız işleri yerimize kaynağımıza göre planlayıp sprint'imizi başlatıyoruz.

Hani haftalık sprint bize uygun çünkü deployment iOS ve Android gibi yeni bir versiyona ihtiyacı olmadığı için ve sürekli bir deployment halimiz var.

Yani A işi başladı, development yapıyor.

Testten geçti.

YET aşamasında bir sorun olmadığı görüldü.

O statü bizim için dana geliyor A taskında.

Ve anında proda çıkıyor.

Yani bizim böyle işleri toplayalım 15 günde bir şey yapamayız.

Sürekli böyle bir deployment halindeyiz.

O yüzden haftalık sprint de uygun oluyor.

Haftalık sprint bir diğer avantajı da dinamik bir firmadayız.

Sürekli ihtiyaçlar değişebiliyor.

Hani bir konu geldiğinde ve aciliyet seviyesi çok yüksekse 2 hafta beklemek yerine hemen bir sonraki haftalık sprint'e dahil edip çok daha hızlı...

Respons vermemizi yani o işi çözmemizi sağlıyor.

Böyle bir akışımız var. Çiçek konusunda aynı fikirdeyim abi.

Biz mesela integrasyon kısmındayız.

İntegrasyon olunca böyle çoğu ekipten istekler gelebiliyor vs.

ve onu 2 hafta sonra yaratır etmek maliyetli bir iş oluyor.

Haftalık sprint bu tarz şeylere çok uyuyor gibi.

Aynen öyle. Mesela ne yapıyoruz? Normalde her sprint sonunda bir retro yapılır.

İşte retroya her hafta zaman ayırmak yerine aylık retrolar yapıyoruz.

Yani bir tık daha ecail metodisini trend yola uydurduğumuz bir versiyonuna gidiyoruz.

Retronun bir yararını gördünüz mü?

Peki mesela atıyorum... Hayırlık olmuş ya mesela ben onu ilk defa duyuyorum.

Haftalık sprint ama 4 sprintte bir retro.

Mesela bunun yararını gördünüz mü?

Sizin tecrübeniz nasıl orada? Orada...

Daha önceki firmalarında haftalık yaptığım akışlar da vardı.

Her hafta konuşmak bıkkınlık yaratıyor.

Yeni konu da çıkmıyor.

Şöyle bir şey var. Boardlarda tutuyoruz retroda konuşulacak konuları.

4 haftalık işin mesela en başındaki birinci haftada da bir retro maddesi çıkmış olabilir.

Yani beklenti şu takımdan birinci haftada da retroda konuşmak istediği bir madde varsa direkt o retro boarduna girmesi.

Bu 4 haftalık konular birikiyor ve 4 haftanın sonunda konuşuyoruz.

Yani retronun faydası...

Var. Bence haftalık olması ya da 4 hafta bir olmasına ziyade o konuların detaylı konuşulması orada kritik.

Onu yapmaya çalışıyoruz genel olarak.

Evet retro çıkları da oluyor.

Sürecimizi geliştirmek için iyi gidiyoruz orada diyebilirim yani.

Valla bu çok sıkı bir...

Düzen abi yani gayet düzgün işleyen.

Ben direkt birebir de gördüğüm için biz de benzer bir şey yaptığımız için.

Çok kı bir şekilde işleyen, güzel bir şekilde işleyen ama hani oldukça da tutturması, ilerlemesi, düzenli bir şekilde yapması.

zor olan bir sistem.

Burada şeyi merak ediyorum ben bu sıkı çalışma düzeni yani daha doğrusu sıkı bir düzen içerisinde kültür nasıl işliyor?

Yani remote çalıştığımızı zaten biliyoruz.

Hani remote'da bu düzende herhangi bir aksama oluyor mu?

Ekipte nasıl bir kültür?

işliyor çalışırken?

Buna ben cevap verebilirim isterseniz.

Bu trend yolda aslında bahsedilen o güzel kültür, uyum işte bazı maddelerimiz var ya bizim hani samimiyiz, mütevazıyız, açık ve iyi iletişim kurarız gibi güzel maddelerimiz var.

Aslında biz bunları ekip içerisinde çok güzel devam ettirdiğimiz için bu sorunların, aksamaların işte işleyişin her türlü güzel bir şekilde devam etmesini sağlayabiliyoruz.

Mesela ben 3 senedir fazladır remote olarak çalışıyorum ama hiçbir zaman Müt olarak çalışıyorum.

İş arkadaşım yok. Asosyallik yaşıyorum gibi durumların içerisinde hiç hissetmedim.

Yeni gelen ekip arkadaşlarımızdan aslında bunları çokça duyduğumuz için bu da bizim bu düşüncemizi destekliyor.

Bizim çok fazla iletişim kanalımız var.

Discord grubumuz var. Sileğimiz var.

İşte Zoom mesela. Bunun üzerinden o kadar çok birbirimiz iletişime geçiyoruz ki yaşadığımız aksamaları atlatabiliyoruz ve bu katı düzeni aslında devam ettirebiliyoruz.

Mesela Discord'da bir araya gelip Geldiğimiz zaman mesela boş vaktim var diyelim.

Discord'a geçiyorum. İşte bir kişiyim bir kanalda.

Bir anda beş kişi olabiliyoruz.

Birlikte güzelce iletişim kuruyoruz.

İletişimizi güçlendiriyoruz.

Sorunlarımızı giderebiliyoruz.

İşte development aşamasında ben bir sıkıntı yaşadım diyelim.

Ve bunu çözmek için birisine Slack üzerinden yazdığım zaman o kişinin bana hadı atıp ya da zoom'a dönmesi saniyeleri buluyor.

Gel birlikte çözelim. İşte iki kişi çözemiyorsak 3-4-5 bir anda böyle kalabalıkça ekipçe o sorunu...

üstesinden gelir hale geliyoruz.

Böyle çok güzel bir kültür işliyor aslında ekip içerisinde.

Bu şekilde bahsedebilirim.

Aksamalarda her ekip içerisinde aslında olur.

Biz bunları nasıl çözüyoruz dersek de Cihat'ın bahsettiği gibi retroboardumuz var.

Bu açık ve yalın iletişimimizi retroboardlarımıza taşıyoruz.

Oralarda aksiyon maddesi olarak biz bunları yazıyoruz ve bu aksiyon maddelerimize gerçekten değer verip bir sonraki portlarda tekrardan üzerinden geçip oralarda gerçekten de bunun release olması için çaba

gösteriyoruz. Diyelim bir

iş alındı ve sonuçta herkes tekil olarak esayin ediliyor.

Bir iş üzerinde yürütme esnasında payirleşme...

Özellikle teşvik edilen bir şey mi oluyor ekip içerisinde yoksa bir şey alışkanlık haline geldi mi?

Yani örneğin bir işe başladığınız zaman abi hadi gel beraber bakalım ya da birinin söylemesine de gerek kalmadan şuna bakıyoruz hadi beraber bakalım o zaman tarzında bir düzen mi oluşturuluyor o konuda?

Payrollmanın birçok çeşidi var.

Mesela şu şekilde bir işleyiş olabiliyor.

İşte pazartesi günü bizim planlamalarımız var.

Planlamalarda bir task var.

Birden fazla onu kişi o taskı istiyorsa birden fazla kişi.

ya biz bunu Payr olarak ilerletelim diyebiliyoruz.

Orada biz Jira'da işte Jira kullanıyorduk.

İki kişiyi esayen edebiliyoruz Payr olarak.

Birden fazla kişiyi de esayen edebiliriz.

Şöyle bir durum da olabilir.

Sen bu işi yapıyorsun. Nasıl yapacağını biliyorsun ama ben senin nasıl yaptığını bilmiyorum.

Ben kendimi burada eksik hissediyorum.

Ben de senin yanına gelebilir miyim dediğim zaman burada da her zaman birbirimize kapılar açık.

Şöyle bir şey de olabilir. Ben bu işi alıyorum.

Yapmasını bilmiyorum. Birisinin bana destek olması gerekiyor.

Her zaman burada da herkesin birbirine kapısı o kadar açık ki burada da...

Bir kişi gelip ben biliyorum sana Payr olabilirim diyebiliyor.

Bunları planlamalar üzerinden halledebiliyoruz.

Onun dışında Payr atamamış işler de olabiliyor.

Tek başına ilerletiyorsun. Ama belli bir noktada sıkıntı yaşıyorsun.

Burada bayrak kaldırabilirsin.

Benim Payr'e ihtiyacım var.

Sonradan sana Payr'e sayın edebiliriz.

Discord'a geçiyorum. Gerçekten bir sorunum var.

Payr'e desteğe ihtiyacım var dediğimiz zaman herkes orada desteğe geliyor açıkçası.

Payr aslında bizde gerçekten bir kültür, bir işleyiş biçimi oldu diyebilirim.

Ve herkesi de payer'e teşvik edebiliyoruz.

Yeni gelen arkadaşlarımıza da onboarding sürecinde mesela ekipteki herkese payer olması için tüm şartlarda sağlanılıyor.

Süper. Gerçekten harika.

Yani bu insanların birbirlerine bayrak kaldırması, ben işte yardıma ihtiyacım var denildiğinde belki de bazı zamanlar bu yardım çığlığı olmadan da...

Birinin abi iyi misin nasıl gidiyor bu iş işte yardıma ihtiyacın var mı tarzında gelip sorması etmesi gerçekten çok değerli ve ekip içerisinde bence olmazsa olmaz noktalardan biri.

Bir şey merak ettim. Şimdi siz account checkout tarafında işte hesap kısmı da var işte sepet kısmı da var.

Burada hem anladığım kadarıyla client tarafı var hem de işte BFF tarafları da sanırım var.

Burada teknoloji olarak neler kullanıyorsunuz içeride bu tarafları geliştirmek için?

Bunu da ben cevap verebilirim.

Biz ekip olarak frontend tarafına daha yatkınız aslında.

İki ayrı client'ımız var web ve mobil web.

Ve bildiğiniz işte bu masaüstü cihazlarınızdan, laptoplarınızdan girdiniz.

web sitesi oluyor. Bir de bu mobil cihazlarınızdan girdiğiniz, browser üzerine ulaştığınız bir sitemiz var.

Bu da mobil web olarak geçiyor ve mobil web bizde responsif değil aslında.

İki ayrı repodan, iki ayrı geliştirme yaparak devam ettirmemiz gerekiyor.

Onun dışında kullandığımız teknolojileri sormuştum ve mobil web aslında burada teknolojiler konusunda bir tık ortaklaşıyor.

Biz frontend ekibiyiz.

Gözüne canlandırman gerekirse işte Trendyol'un web sitesini açıyorsun.

İşte sepete gidiyorsun, sipariş detaya gidiyorsun.

çok fazla data görüyorsun.

İşte neler var, fiyatlar var, ürünün ismi, işte onun dışında adresin vesaire var.

Bunların bir şekilde orada doldurulması gerekiyor.

Bunlar için biz birden fazla ekiple çalışıyoruz.

Birden fazla da ekibin birden fazla servisini kullanıyoruz.

Burada onlardan aldığımız dataları manipüle ediyoruz.

Çok fazla mapping işlemi yapıyoruz.

İşte buradaki BFF kısmında biz Node.js'i SFX kullanıyoruz.

SFX de belki biliyorsunuzdur.

Trendle içerisinde geliştiren bir frekans.

Mwork. BFF kısmında mümkün olduğunca SFX kullanmaya başladık artık.

UI'da da SFX'i kullandığımız yerler mevcut.

Account altındaki bazı kayıtlı kartlarım sayfası olur.

Yardım iletişim sayfalarında web ve mobil web'i responsive olarak veriyoruz ve hem UI'nin hem BFF'in de SFX'den alıyoruz.

Onun dışında responsive olmayan diğer artık ayrı olarak çalıştırdığımız sayfalarında client tarafına react kullanıyoruz.

Type script kullanıyoruz.

Bizneslerimizi gateway'lerdeki fragment'lardan, routing storefrontlarımız üzerinden alıyoruz.

Mobil webin storefrontında Puzzle.js, webin storefrontında ise .NET kullanıyoruz diyebilirim.

Aa .NET de mi var? Süper.

Kendi rutin aşamasında kullanıyoruz.

.NET kullandığım için bir anda şey yaptım.

Aa .NET falan. Puzzle.js'i ben de şeyden hatırlıyorum.

Bir 3-4 sene önce Puzzle.js'le ilgili bir sunum gibi bir şey yapılmıştı sanırım.

Sonradan Open Source'da yapılmıştı. Sanırım Open Source hatta Puzzle.js değil mi?

Aynen. Yani mobil web'deki sayfa açılış saniyesi aşırı yüksekti diye hatırlıyorum.

Yani çok hızlı yükleniyordu sayfa.

Onunla ilgili bir bilgi vardı böyle.

Arkamda o kalmış. Microfrontend ile alakalıydı sanırım.

Bayağı havalı bir şeye benziyordu yani.

Böyle performansı çok yüksekti.

Orada iki ayrı client'ten bahsettik.

Bir bu işe web kısmı var.

Bir de mobil web kısmı var. Bu da aslında bunların bir de test aşamasını getiriyor.

Yani hem mobil webde testler yapılması lazım, hep webde yapılması lazım.

Birinde güzelken diğerinde yamuk yumuksuz aşama sapan bir şeyler oluyor belki de bilmiyorum.

Bunların böyle test aşamaları nasıl oluyor?

Hazır burada da Berat da vardı. Berat üzerinden gidebiliriz belki.

Tabii. Test tarafından önce aslında biraz bunun bütün ekibe genel olarak...

sağladığı faydalardan da bahsedeyim.

Biz client bazında ayrı ekiplerken aslında aynı feature'ları geliştirip PM'lerimiz aynı toplantılara katılıp işte groominglerde, planlamalarda aynı task'ları konuşuyorduk aslında.

Ama şu anda iki client business olarak, feature olarak birbirine çok yakın ilerlediği için aslında biz birçok yapıyı ortak konuşup, ortak tartışıp iki client'a da ayrı işlerle entegre edip aslında

çok fazla zaman kazanıyoruz burada.

Bu client bazlı Birleşmenin domain bazında ayrışmanın bizim bu Storefront TR'ye getirdiği en büyük artılardan biriydi bence.

Burada bize çok fazla vakit ve iş yükü açısından fayda sağladı.

Burada tasklar ayrı gidiyor.

Elif'in de bahsettiği gibi responsive değil.

İki client içinde geliştirmeleri ayrı yapıyoruz.

Ama bazen ortaklaştırabildiğimiz noktalar da oluyor.

BFF'lere ortak olabiliyor bu iki client'ın.

Ve bu da aslında bize...

Tek seferde kişi yapma imkanı sunuyor yine.

Bu da bir avantaj olarak sayılabilir.

Biraz da dezavantajlarından ya da daha doğrusu zorluklarından bahsedeyim.

İki farklı client ve bunları kullanan kullanıcıların profili aslında biraz farklı.

Webde daha böyle sürekli kullanan, kendi evindeki bilgisayarından kullanan, genelde login olmuş kişi sayısının daha fazla olduğu böyle bir profil bizi karşılıyor.

Ama mobil webde ise daha fazla Trendyol'a ilk defa gelmiş, Trendyol'a yeni tanışmış, ilk defa...

bizim sitemizde, bizim bir uygulamamızda gezen kullanıcılar oluyor.

Bu da aslında bizim case süreçlerinde önem verdiğimiz noktaları client bazında değiştirmemizi gerektiriyor.

Bir senaryoda login kullanıcı ile ilgili akışın önemi diğerine göre farklılık gösterebiliyor.

Hepsi çok önemli oluyor ama günün sonunda test ettiğimiz durumun kullanıcının karşılaşacağı ya da önemseyeceği derece biraz değişebiliyor.

Bu ilk başlarda hepimizi bir tık zorladı ama artık uzun süredir Ekip yapısı bu şekilde ve bence ekipteki herkesin bu farkındalığa erişebildiğini düşünüyorum ben açıkçası.

Diğer konuda mesela MWeb'de böyle çok sınırlı bir alanımız var ekran olarak.

Kullanıcıya gösterebileceğimiz şey sayısı çok az.

Böyle tekstleri kesmemiz gerekiyor, üç noktaya düşürmemiz gerekiyor.

Sayfada çok küçük bir alanda kullanıcıya birçok şey vermek istiyoruz.

Bu bizi zorlayan bir konu mesela ama webde bu çok rahat.

Kocaman sayfalarımız istediğimiz gibi daha rahat bir şekilde aslında oraları...

dizayn edebiliyoruz. Test ederken mesela web'e alıştığın zaman o rahatlığa, o geniş sayfaya MWeb'de bu rahatlığı sürdüremiyorsun mesela.

Daha dikkatli olman gerekiyor.

Ya da birden fazla ekran boyutunu da aslında hesaba katman lazım.

Çünkü iPhone 5 kullanan kişi de var.

Kocaman işte büyük cihazlar kullanan insanlar da var.

Bunların MWeb'deki yaşadığı deneyim farklılaşabiliyor.

Genel olarak aslında bu şekilde.

Düşündüğüm zaman toplamda bence iki client'ın da domen bazı bölünüp aynı ekipte olması bir avantaj ama getirdiği zorluklar da var.

Bunların hepsini de çözebildiğimizi ben düşünüyorum açıkçası.

Valla biraz sen anlattıkça Clyde'lar arası geçişte yaşadıklarımız gözümün önünden film şeridi gibi geçti.

Yani avantajı tabii ki çok fazla bize fakat bize bir yanda da yaşattıkları.

Hepimizin hayatından bir süre aldı bazı zamanlar.

Anlatırken biraz şey konusu kafama takıldı.

Şimdi bunlar tabii ki işte client bazlı süreçlerin getirdiği avantajlar, dezavantajlar.

Peki account checkout ekibi içerisinde bir iş alındıktan sonra QA süreçleri nasıl ilerliyor?

Yani bir iş alıyoruz, geliştiriyoruz.

Testi nasıl yapılıyor ya da geliştirme sürecinde testin bir katkısı oluyor mu?

Ya da sizin direkt olarak test içerisinde aldığınız...

işte otomasyonlar vesaireler pardon geliştirme süreçleri içerisinde aldığınız otomasyonlar vesaireler oluyor mu?

Tabii bahsedeyim bundan da.

Bence bizim ekipte test...

Grooming'de başlıyor. Grooming'de biz o taskı konuşurken onun hakkında bir test açısından da fikir yürütme durumunu sergiliyoruz ve bunun bize faydası oluyor.

Biraz klişe ama testin zaten ne kadar önce başlaması, development sürecinde o kadar faydalı oluyor.

Bence ve bunun Grooming'de böyle bütün ekip olarak testi üzerine de düşündüğümüz işte datasını nasıl bulacağız, hangi ekibe gideceğiz, burada şöyle bir case olabilir mi gibi taskın üstünde konuşmamız bize o task sprint'e geldiği zaman fayda sağlıyor.

Task sprint'e geldikten sonra da MR açılmadan önce henüz draftken müsaitlik durumlarımıza göre bu değişebiliyor ama bunu yapmaya çalışıyoruz.

Lokal test diye bir yeni bir gelenek gibi bir durumumuz var.

Burada developer MR'ını açmadan önce kod review istemeden önce bir QA ile birlikte ufak task'ın üstünden geçiyor ve hani orada bazen Bulgularımız oluyor.

Daha MR açılmamışken onu bulmuş, halletmiş oluyoruz.

Ya da edge bir case'i orada developerla düşünürken fark etmiş olabiliyoruz.

Ya da developerın karşılaştığı bir sorun, QA'in de ekstra bakması gerekiyorsa bunlarla ilgili önden haberleşmiş oluyoruz.

Bu da bizim yeni yeni yapmaya başladığımız, verimli olduğunu düşündüğümüz bir yol.

Ama standart işleyişte de MR açılır, code review'a gelir.

İki tane... Developer'dan onay alır ya da yorum gelirse fixlenir vs.

Daha sonra Task QA'nin sorumluluğuna girmiş oluyor burada.

Birçok test ortamımız var.

Bu ortamlarda aslında Task'ı test ederek başlıyoruz manuel olarak.

Bu manuel testlerin içinde en başta Happy Path senaryolar koşuluyor.

Task'ın business ihtiyaçlarını karşılayıp karşılamadığım konusudur.

Daha sonra da genel olarak etki alanını, bu Task'ın etki verebileceği bir yer var mı?

Bir şeyi bozuyor muyuz? Ya da işte TR'de yaptık, Azerbaycan'da bir etkisi var mı?

Azerbaycan'da yaptık, TR'de etkisi var mı?

var mı gibi sorular sorup bunları test edip aslında tasklarımızı master'a merge'lıyoruz.

Master'dan sonra da bütün kodla birleştiğinde test ortamlarında ki durumunu bir kontrol edip son kez daha sonra bu task'ı UAT'ye ilerletiyoruz bir sorun göremediğimiz durumda.

Bu da biraz happy path oldu. Bir sorun gördüğümüzde nasıl ilerliyoruz aslında?

Burada daha önceden arkadaşlarım da bahsettiği gibi şey bir sorun bulduğu zaman bunu Developer'la paylaşıyor ve burada aslında iş birliği başlıyor.

Buradaki ilişkiler de önemli.

Burada bir sorun olması aslında bütün takımın büyük sorunudur.

Ama bizim ekipte genel olarak bir sıkıntı çıktığı zaman taskın sahibi bununla ilgili her türlü desteği vermeye hazır oluyor.

Ve QA'de aslında o task onunmuş gibi bu konuda developer'a sunabildiği desteği sağlamaya başlıyor.

Ve bu sorunlar hızlıca çözülüyor ve tekrardan test aşamasında başa dönüyor, tekrar ilerliyor.

başka bir sorun olmadığı takdirde de UAT'de cihatla buluşmuş oluyor aslında.

Daha sonra onlar da son kullanıcı olarak kullanıcı kabul testini yaptıktan sonra da çıkabildiğimiz en erken sürede yani UAT'den geçer geçmez beklediğimiz durum.

Production'da kullanıcılarla buluşuyor bu.

Ve biz hani en son olarak da bir monitoring süreci developerlarla birlikte bu task'ın çıkmasıyla bir etki var mı gibi son kontrollerimizi de production üstüne yapıp task'ı release etmiş oluyoruz aslında.

Burada otomasyon nerede dahil oluyor diyecek olursak sprint'in sonlarında o sprint geliştirdiğimiz task'ları bir analiz ediyoruz.

Bunun otomasyonunu yazmalı mıyız?

Yazabilir miyiz? Gerçek detaylı oluyor mu?

Mocklamamız mı lazım? Bunun testi daha önce var mı?

gibi ufak bir şeyler arasında bir toplantıya tasklarımızı açıyoruz otomasyon üzerinde ve daha sonra da next sprintlerde yeni çıkmış feature'ların otomasyon tasklarını sprintlere alıp o tarafı

da business'la senkronize tutmaya çalışıyoruz.

Burada otomasyonlardan bahsetmişken Berat otomasyon ve işte böyle yük testi vs.

sonuçta entegre çalışıyor ya orayı da bir açabilir misin?

Mesela sizde neler oluyor? Biz de mesela entegrasyon kısmıyız.

Birçok ekiple bir arada oluyoruz vs.

Sizin taraftan nasıl işliyor oralar?

Tabii bizim Testlerimiz birçok test ortamında koşacak şekilde aslında kurgulanmış durumda.

Yeni eklediğimiz testler de bu yapıya entegre olarak ekleniyor sürekli.

İki saatte bir production'da bütün testlerimiz koşar.

Her şey yolunda mı? cevabını bize verir aslında.

Orada gördüğümüz hataları inceleriz.

Oradan bir sıkıntıyı bize işaret ediyorsa onu hemen çözmeye çalışırız.

Otomasyonun en büyük rolü aslında her şey yolunda mı?

Trendyol.com'da bunun cevabını bize vermek aslında.

Bunun dışında yeni bir kod entegre olduğunda yani bir MR merge edildiği zaman da bizim test ortamlarında içlerinden spesifik olarak seçtiğimiz uygulamalarımızın etki edebileceği yerleri cover eden test

senaryoları bu test ortamlarında çalışır.

Ve bu da otomatik olarak bir MR merge edildiğinde pipeline'ın son aşamasında çalışır ve bunu da bize raporlar.

Otomasyonda genel tercihimiz aslında hep gerçek data ile koşalım.

gerçek data ile handle etmeye çalışalım.

Bunun bize getirdiği artılar ve eksiler var ama artıların daha büyük olduğunu düşünüyoruz.

Ama gerçek datayı elde edemediğimiz zaman bir orderdaki statülere bakmak istediğimiz zaman vs.

mock data da kullanıyoruz.

Genelde BFF'lerimizin responsunu mocklayarak UI'ın düzgün çizildiğini aslında doğrulamak istiyoruz testlerde de.

Load test konusunda da aslında burada ekip olarak ayrı bir işleyişimiz yok.

Genel olarak Storefront Türkiye'nin load testlerinde Bizim de endpointlerimiz, bizim de uygulamalarımız yük altına sokulup test ediliyor.

Burada ama client ekibi olarak farklı bir rolümüz oluyor bizim.

Daha gerçekçi bir test olması için aslında API'lara da bizim uygulamalarımız, bizim BFF'lerimiz üzerinden yük gidiyor.

Burada bizim oynadığımız rol biraz daha kritikleşiyor.

Hem kendi uygulamalarımızın sağlığı hem de o API'lara gerçek kullanıcının da götüreceği gibi bir yükü götürebilmemiz gerekiyor.

Ve sürekli de yeni endpointler, yeni BFF'ler, yeni feature...

çırlar eklendikçe load testteki senaryolarımızı da güncellememiz gerekiyor bu durumda.

Bunun için de genel olarak Storefront TR'deki akış aslında bizim için de geçerli oluyor.

Planlı olan ya da kendi ekibimizin içinde iki ayda bir yaptığımız load testlerde de uygulamanın yük altındaki davranışlarını izliyoruz.

Süperdir abim. Oradaki çünkü entegrasyon kısımlarında yük testinde vesaire hep bir hazırlık, önceden bir şey gerekiyor böyle bir planlama vesaire düzen.

Size zaten belirli şeyler yapılmış yani böyle.

Ben oradan aslında Başka bir kısma geçeyim.

O da product kısmı aslında. Ekipte zaten Cihat PM'im demiştim.

Sizde mesela product manager'ın rolü burada nasıl işliyor?

Şu anda sanırım bir de iki tane var.

Çok fazla entegrasyon var. UI kısmıyla ilgileniyorsunuz.

15 kişilik bir ekip vs. Burada mesela PM tam olarak burada hangi rollere sahip?

Nasıl bir işleyiş var? Tabii ondan da bahsedeyim.

Şimdi software devleti arkadaş önüne gelen task'ı geliştiriyor.

İşte QA tarafındaki arkadaş o geliştirilen task'ta herhangi bir problem var mı?

İşte işin kapsamına göre onları test ediyor.

Bu şirket bazı çok da değişen roller değil.

Ama product rolü her şirketin bakış açısının farklı olduğu, farklılaşabilen bir rol.

Orada dört tane pozisyondan bahsetmek istiyorum.

Bir business development analizsiz dediğimiz yani iş geliştirme analizleri var.

Bir product manager'lar var.

Bir product owner'lar var.

Bir de teknik analizler var. Şimdi bu dört ayrı rolü de dört ayrı kişiye veren firmalarda var.

Ama trend yolda şöyle işliyor.

Tamam business ekipleri yani iş ekiplerine yakın olan bir iş geliştirme analizleri var.

Bu ayrı bir kişi. Product manager, scrum yöneten product...

Yeri geldiğinde taskı teknik olarak analiz eden teknik analiz tek bir rol trend yolcu.

Tabi bu şunu da getiriyor.

Ne %100 product manager ne %100 teknik analiz.

Ortayı bulmak gerekiyor.

Bizim takımımızda teknik analizler yok.

O yüzden şöyle yapıyoruz oradaki akışlarda.

Bir kısmını product manager götürüyor teknik analizlerin.

Devamında da software developer arkadaşlar analizi devam ettiriyor ve işi yapılabilir hale getiriyor.

Product manager rolünde ise trend yolda şunu yapıyoruz.

Bizim önümüze belki 100 tane konu geliyor.

Hayır deme bir product manager en kritik konulardan biridir.

Bu işlerin %80'ine 90'ına hayır diyoruz zaten.

Bir iş grümke geliyorsa zaten bir eleme ile geliyor.

Peki biz bu hayır dediklerimizi neye göre hayır diyoruz?

Bir, şirketin stratejileri olabilir.

İki, getirisi development cost'una göre.

Çok daha az olabilir. Bu kriterlere göre bu işi yapamayız ya da ileride şu anında yapabiliriz gibi yorumları iş geliştirme analistleriyle ya da diğer business ekip teki partnerlerle konuşuyoruz.

Sonrasında o işleri product owner rolümüz başlıyor.

Hangi parçayla bölüp işi tamamlayabiliriz?

Burada product owner rolünde işleri yani epiklerden storylere doğru bölmeye çalışıyoruz.

Sonraki aşamamız ise bu storyleri teknik analist...

bakış açısıyla. Teknik olarak nasıl çözeriz?

Bunları da task'lara eklemeye çalışıyoruz.

Description'ları definition of done'ları bellemeye çalışıyoruz.

Bu aşamalar geçtikten sonra o iş artık grooming'de konuşabilir hale geliyor.

Bundan sonraki süreçte zaten biraz önce bahsettiğimiz gibi perşembe grooming'de konu konuşuluyor, tartışılıyor, eksik noktalar çıkarılıyor ve product manager'ın bellediği definition of done'da da değişiklikler oluyor bu toplantıda.

Sonrasında da sürecimiz devam ediyor.

Grooming'den sonra Product Manager o işle beraber yaşıyor diyebiliriz.

planı aldık. Sonra developer işi geliştiriyor.

Developer'ın eksikleri soruları oluyor.

O sorulara cevap veriyorsun. Sonrasında o iş teste geliyor.

Test tarafında sorularımız oluyor.

Bazen test adı sıkıntılarımız oluyor.

Başka ekiplerden beklediğimiz. Oralarda işin içine giriyorsun.

Finalinde de artık son kontrol olarak Product Manager'ın UAT'sine iş geliyor.

Biz burada UAT'i yaptıktan sonra o iş artık son kullanıcıya çıkabilir durumdadır diyoruz.

Ve oradan da deploy mutlarımızı yaptıktan sonra iş canlıya çıkıyor.

Yani bir Product Manager'ın yaşam döngüsünü de böyle özetleyebilirim sizler için.

Çok iyi abi. Bir baştan sona bir görmüş olduk.

Orada küçük bir sorun var sadece Cihat.

Mesela bizim tarafta örneğin Fulfillment tarafında işte bizim planlama ekibimiz var.

İşte Operasyon Experience vesaire.

Hani operasyonun verimliliği için çalışan bir müşteri ekibi var.

Hani onlarla çalışıp yeni işleri alıyoruz vesaire.

Burası Frontend tarafı ya.

Burada mesela yeni işe, yeni size kimden nasıl geliyor?

Orada yeni bir projeye başladık diyelim.

Azerbaycan projesinden gideyim.

Öncelikle MVP, business ekipleri dediğimiz bunun içinde pazarlama kategori, işte müşteri deneyimi gibi çok fazla ekibin içinde var.

Hatta legali de bunun içine sokalım.

Onlarla beraber bir MVP'de bizim sahip olmamız gereken feature'ları başlık seviyesinde oluşturuyoruz.

İşte bu ne olabilir? Ürün detay sayfasında ürünün Azerbaycan'a uygun olduğunu bir konferante verelim.

Yani bu seviyede kalıyor iş.

O bacağı var yeni başlayan projelerde.

Yani iş ekipleriyle beraber beklek oluşturuyoruz.

Ama asıl prodakçıyı prodakçı yapan taraf kendi ürettiği feature'lardır.

Burada da şöyle bir akış oluyor. Bir sorun var.

Sorun şu diyelim.

Basketten check out sayfasına geçişlerimiz, benchmarklarımız...

Trendyol içinde de olabilir. Mesela şu olabilir.

Trendyol'daki TY Core dediğimiz Türkiye satışlarındaki basketten check-out'a geçiş oranımız Almanya'daki international'dan daha düşük olabilir.

Bu bize bir paying point'tır. Demek ki bir şeylerde gelişim alanımız var.

Bunun üstüne işte baskete hangi feature'ı getirirsek bu funnel'ı...

daha ileriye taşıyabiliriz.

Siparişe doğru götürebiliriz.

Burada ürettiğimiz feature'lar oluyor.

Bunlar da bizim kendi oluşturduğumuz backloglar.

Bu hem biziz ekiplerle oluşturduğumuz üzerine product'ların oluşturduğu backloglar çarpışıyor ve sprintler ortaya çıkıyor diyebilirim.

Okey. Birden fazla şey var aslında.

Parametre var gibi duruyor bu. Evet.

Orada da şeyi söyleyeyim, product manager rolünün %60'ı iletişim, %40'ı teknik gibi düşünebilirsiniz.

Çok fazla paydaşla teanında konuşman gerektiği için iyi bir product manager olabilmen iletişim özelliğine, yeteneğine bağlı bir durum.

Onu da eklemiş olayım.

Çünkü bu herkesi bir şekilde şirket stratejileri doğrultusunda idare etmen, yönetmen gerekiyor.

Durumumuz o. Gerçekten çok ince işlenen süreçler, çok yoğun süreçler.

Allah kolaylık versin.

alışıyorsun hepimiz gibi hani her pozisyonun rolünün kendine yönelik zorlukları var.

Bu tecrübe dediğimizde şey tam olarak bu.

Bu zorluklara ne kadar çok dayanıklısın.

Bu da tecrübe olarak ortaya çıkıyor.

Evet. Ben biraz da şeyi Sorusunu getirmek istiyorum.

Şimdi çok fazla süreç var.

Hani account checkout dediğimizde sadece işte hesap ve sepet gibi görünse de aslında baktığımız zaman içeride çok fazla ekiple iletişim halinde olduğunuz.

Mesela diğer Storefront bölümünde de bu konuyor.

Sizin tarafta bununla alakalı düşünceleri merak ediyorum.

Çok fazla ekiple birlikte çalışıyorsunuz.

Bu ekiplerle iletişim, ortak çalışma durumları vs.

sizin için zor olmuyor mu?

Sağlıklı böyle temiz bir şekilde yürütebiliyorsunuz bu süreçleri.

Buna da ben cevap verebilirim.

Evet kesinlikle zorluğu var.

Şöyle ki biz client ekibi olduğumuz için hem diğer clientlerle paralel olmamız gerekiyor.

Hem de birçok AP ekibiyle çalışıyoruz günün sonunda.

Bunun da zor olduğunu kabul ediyoruz açıkçası.

O yüzden de bunu birbirimiz için en kolay hale getirmeye çalışıyoruz.

Şöyle ki projelere ya da böyle büyük feature'lara başlamadan önce genellikle bir business ve teknik süreci konuşmak için toplantılarımız oluyor.

Bunlara katılıp... Partişiyoruz aslında ve süreci değerlendiriyoruz.

Sonrasında da... Ama mutlaka ekip içerisinde bir teknik analiz yapıyoruz.

Nasıl ilerleyebiliriz bizim için?

Optimal çözüm ne olabilir diye.

Bunda da genellikle toplantı da olabiliyor.

Ama bizim için best practice burada ADR ya da RFC duruma göre bunları yazmak oluyor.

Ve bunlar üzerinden yine ekip ile paylaşıp tartışmayı açıyoruz.

Ve dediğim gibi en iyi çözümü bulmak günün sonunda hedefimiz olduğu için bu şekilde ilerliyoruz.

Tabii şimdi bunları yapsak bile sorunlar bitmeyebiliyor çok normal olarak.

Çok ekip var, çok client var.

O yüzden de bu süreç...

Arkadaşlar sırasında da hem diğer client ekipleriyle hem de API ekipleriyle aslında iletişim kurmaktan hiç çekinmemeye çalışıyoruz.

Çekinmiyoruz hatta. Çünkü çözüm odaklı bir yaklaşım belirledik kendimize ve bunu asla aşmamaya çalışıyoruz.

Bu şekilde sağlıklı yürüttüğümüzü düşünüyoruz.

Süper, teşekkürler. Peki burada şimdi mesela client ekibi olduğumuz için müşterinin böyle ilk gördüğü ekranlarda...

Direkt müşteri geliyor dışarıdan ve diyorsun ki burayı ben yaptım.

Direkt karşılaştığı kişi direkt sizin yaptığınız iş oluyor.

Burası büyük ihtimalle böyle şeydir.

Bir hata olduğunda direkt müşteriyi görüyor, birebir oluyor.

Buradaki mesela bir hata olduğunda ya da oldu mu bilmiyorum.

En sevdiğim konular bunlardır.

Bir yapmışsın, buton çalışmıyor aslında vesaire.

Bu tarz böyle bir şeyler olur mu?

Incident'lar. vesaire şeyler oluyor mu ya da olduğunda nasıl aksiyonlar?

Hani alınabiliyor mu? Bunların rollback'i hızlı olabiliyor mu gibi.

Böyle varsa güzel bir örnek vesaire o da olur.

Evet biz bir client ekibiyiz.

Client ekibi olduğumuz için de bizim herhangi bir deployment'ımız, config push'umuz direkt son kullanıcı yani müşteriye hit ediyor.

Bunda olan herhangi bir olası hatada da aslında ciro kaybına kadar süreç ilerliyor.

Payment ve checkout taraflarına çalıştığımız için de Bu da maalesef başımıza gelebilen şeyler oluyor.

Bu da stresli bir ortam yaratabiliyor.

Biz de burada stresi minimize etmek için olabildiğince safe ilerlemeye çalışıyoruz.

Hataları Berat'ın anlattığı gibi manuel testlerle ve otomasyonlarla burada çıkmadan evvel yakalamak ilk önceliğimiz oluyor.

Yine de hani oldu ya dersek de burada çıktıktan sonra yine otomasyonlar ve loglar sayesinde en erken şekilde kullanıcıdan önce fark edip bunlar fixlemek ilk adımımız oluyor.

Böyle bir durumda... direkt bir Zoom ya da başka bir iletişim kanalından hemen böyle Slack üzerine bir toplanıyoruz.

Mesela... Bizim on call nöbetçilerimiz de oluyor.

Bizim haftalık bir nöbet sistemimiz oluyor.

Ama mesai saatinde olduğumuz zaman asla bu sorumluluk tek başına nöbetçiye kalmıyor.

Bütün ekip böyle bir anda el birliğiyle sorunu sattırıyoruz.

İşte bir alert geldi, bir logomuz var, sıkıntılı bir durum var.

Bunun için ne yapabiliriz diye hemen böyle toplanıyoruz.

Sonuca göre eğer bizim ekip içerisinden kaynaklanan bir sorunsa bunun için o an direkt hotfix'ini hazırlıyoruz.

Production'a kadar olabildiğince hızlı bir şekilde sorunun gidiyor.

ilerletiyoruz.

Eğer bizim ekipten Çıkan bir sıkıntı değil.

Birlikte çalıştığımız başka ekiplerle alakalı.

Bir neden sonuç ilişkisi olduysa sorunun kökünü ilerlemek için de public kanallarımızdan diğer ekiplerle iletişime geçiyoruz.

Ve yine en hızlı şekilde sorunun giderilmesi için çalışıyoruz.

Bir incident olduysa incident'ın kim tarafından yapıldığı değil de neden olduğu aslında bizim sorguladığımız şey oluyor.

Bir daha olmaması için neler yapmamız gerekiyor?

Yaptı değil de neden oldu bizim aslında ana düşüncemiz.

Çünkü bu iş hekimin yaptığı önemli değil.

Sonuçta bu bir reviv aşamasından, test aşamasından geçiyor.

Ama bir daha olmaması için neler yapmamız gerektiği bizim elimizde bir sonuç oluyor.

Bu da tekrarlanmaması için.

bizim elimizde bir örnek oluyor.

Benim de ufak bir tane ilk girdiğim zamanlarda instantanım vardı.

İlk işe girdiğim zamanlarda o zaman checkout tarafına değil de başka bir ekipte yine Storefront Türkiye'nin altındaki başka bir sayfada çalışıyordum.

Ve böyle hani artık şey tek başına deployment çıkabilirsin bence demişlerdi bana.

Ve orada ben bir tık böyle şey kafa karışıklığıyla japları karıştırdım ve konfiklerimi çıkmadan işte böyle bir şekilde hatalı bir deployment gerçekleştirdim.

Ve siteye girdiğim zaman bir türlü bir Tık dalgalanıyor gibi geldi.

Böyle bir sıkıntılar var gibiydi.

İşte böyle hemen direkt herkes etiketleyerek gerçekten şu anda sıkıntılı bir durum var.

Bunu çözmemiz gerekiyor demiştim.

Ve hani o an herkes gelip şey yapmıştık.

Birlikte çözmüştük.

Ama hani Elif bir daha yapma.

Neden yaptın gibi şeyden değil.

Ekibe yeni arkadaşlar geliyor.

Onlar da yine aynı durumu yaşayabilir.

Onların yaşamaması için bizim neler yapmamız gerekiyor diye aksiyonlar aldık.

Kendimize bir gelişim alanı bulmuştuk.

Bu şekilde. çözmüştük.

Bu kadar. Bahsedebilirim.

Biz böyle bir kültüre sahibiz ekip içerisinde.

İyi sanatlara bayılıyorum ya.

Bende de çok yaşa ve çok şey oluyor.

Güzel anılar oluyor böyle.

Ben de seviyorum yani. Evet yani instant olayı her ekibin karşılaştığı ve oldukça keyif kaçıran bir şey.

Fakat instantlardan da ne ders çıkardığımız, bize ne katkıları olduğunu öğrenmek de oldukça keyifli.

Oldukça daha doğrusu besleyen bir.

süreç olarak karşımıza çıkıyor.

Şeyi mesela biliyorum böyle sıkı bir loglama durumu olduğu işte logları takip ettiğimiz ve loglardan çıkan datalarla öğrenerek ilerlediğimizi biliyorum.

Burada loglarla alakalı işte size gelen loglarla alakalı komik ya da trajikomik bir anınız var mı?

Hani böyle servis tarafından olur, sizin loglarınız olur, öyle yaşadığınız ilginç olaylar oluyor mu?

Evet bu soruyu da ben cevaplayabilirim.

Yarı komik, yarı yaratıcı bir örneğim olabilir bununla ilgili.

Sepet sayfasında kupon kodu girmek için bir inputumuz var.

Burada sorun olduğunda hata loglarından sorunu anlayabilmek için de bu girilen kuponu da loglara yazdırıyoruz.

Özellikle kampanya dönemlerinde kullanıcı tarafından çok fazla kupon denemesi yapılıyor.

Öyle bu konuda biraz yaratıcı ve eğlenceli örnekler oluyor bizden oldukça.

Mesela bir kampanya döneminde loglar, error loglarımız düşmüştü ve kupon ver şeklinde bir log görmüştük.

Kullanıcı böyle bir deneme yapmış.

Bayağı eğlenmiştik açıkçası ekipçe.

Gülmüştük, renk atmıştı diyelim.

Buna benzer bir tane örnek de bizim ekip kanalında paylaşılmıştı.

Log gelmişti. Bizim siparişlerin sayfasında siparişlerini arayabiliyorsun.

Orada bir search barımız var.

Orada da search etmek için de bir karakter sınırı var.

Yani atıyorum 50 karakterden uzun bir şey arayamıyorsun.

Daha doğrusu Api bizden bu şekilde bekliyordu.

Birileri böyle şey 52, 53, 55 böyle 60 karakterli şeyler search termleri yollamaya başladı.

Logları incelediğimiz zaman da Elif Elif Elif Elif diye böyle şey olmuştu.

Arama geldi. Benim adım da Elif olduğu için hani şey dedim.

Gerçekten ben yapmadım.

Bir de prodda denemek gerçekten ben yapmıyorum diye böyle bir kendimi savunma ihtiyacı hissetmiştim.

Yani kim, neden sipariş detaylarında Elif Elif diye bir şeyler aradığını gerçekten ona çok merak etmiştim.

Bu da yani fix dediğimiz taskında Elif Elif diye arama geliyor.

Bunu fixleyelim diye bir task açtığımız işte.

Eğlendiğimiz, biz güldürdüğü bir işte.

Ya da o kişiyi gerçekten sendin ve hala...

cover ediyorsun. Hala ben değilim diye devam ediyorsun böyle.

Hayır ben değilim.

Olsun bir test fix dedik sonuçta.

Bir şey yaradı diyelim o zaman.

Tamamdır. O zaman buradan son soruya yavaştan geliyoruz.

Bölümün sonuna da geldik. Burada her bölümde ekiplere genelde sorduğumuz bir soru vardır.

Sizin böyle sprint dışında yapabildiğiniz şeyler var mı?

Örneğin bazıları işte kitap okuma sesyonları yapıyorlar.

Ondan sonra işte etkinlikler vesaire yapıyorlar.

Mangal yapan var. BMW'den bahseden biri vardı hiç unutmuyorum.

Herhalde araba sevdası vardı.

Sprint dışında sizin de ekipçe ve kişisel olarak da ayrıca kendinize zaman ayırabiliyor musunuz?

Ekipçe yaptığınız şey? Evet, verdiğin örnekler çok güzelmiş.

Bizim ekipte de benzer şeyler var.

Bir tanesi haftalık olarak yaptığımız weekly update.

Bunu cuma günleri yapıyoruz ve bütün Storefront TR'deki ekipler aslında katılıyor.

Burada updateleşiyoruz. Hem de bazen de non-teknik ya da teknik konularda birbirimize sunumlar yapıyoruz.

Ek olarak bir de ekip içinde yaptığımız bir Q&A session'ımız var.

Bunu da iki haftada bir yapıyoruz.

Burada da biraz böyle ekip içerisinde yaşadığımız teknik konuları yapıyoruz.

Teknik problemleri birbirimize anlattığımız püf noktalarından bahsettiğimiz bir station aslında.

Bunlar sayesinde böyle biraz güncel konuları takip ediyoruz.

Birbirimizle update'leşiyoruz ve aslında iletişimde kalmamızı da sağlıyor.

O yüzden sevdiğimiz stationlar bu şekilde.

Var mıydı burada başka bilgisi olan?

Sanırım bir de Berat senin vardı. Aynen eğlenmek için olan kısımdan bahsediğim en sevdiğim.

Eğlence vermelisin. Bu BMW arkadaşı bence rotate edebiliriz.

Bizde genelde araba lastiği, arabalar...

Böyle ben açıyorum konuyu.

Ama böyle bir iki aydır kışta gelmesiyle birlikte işte kış lastiği takalım.

İşte şu lastik şöyle.

Lastikçilerle yaşadığımız tecrübeler ya da arabalarla ilgili komik şeyler bize de bir şekilde gündeme giriyor.

Bunları da kahve molalarında konuşuyoruz aslında.

Çarşamba günleri de kahve molalarımız oluyor.

Orada aslında tamamen goy goy yaptığımız ya da oyun oynadığımız sesyonlar var.

Biraz remote çalışmadaki sıkıntılara da iyi geliyor aslında.

Böyle birbirimizin yüzünü görmek, işte şunu test ettik bunu proda çıktıktan ziyade böyle kendi anılarımızı paylaştığımız, gerçekten diz olduğumuz anlar aslında.

Burada da hani genelde bu ekipten ekibe zamandan zamana değişiyor ama böyle ekip toplantıları sonrası daha çok oyun oynamak istediğimiz ama ekip toplantılarının arası açıldığında daha çok böyle goy goy yapmak istediğimiz

sessionlar oluyor. Bayağı da eğlenceli oluyor.

Ama o araba sevdası...

arkadaşla tanışmak isterim.

Belki fatah edelim. Bir arkadaşı size yöneldirelim.

Bu tam Pınar kendisi.

Konuğumuzdur aynısında.

Süper. Harika arkadaşlar.

Vallahi çok güzel muhabbet oldu.

Ben çok keyif aldım.

Aklı da yine ara bu kadar zaman geçti açıkçası.

fark etmedim. Çok teşekkürler geldiğiniz için.

Teşekkür ederiz. Keyifli bir bölümdü.

O zaman yavaştan kapatalım.

Herkesi dinlediği için çok teşekkürler.

Bir sonraki bölümümüzde görüşmek üzere.

Hoşçakalın. Görüşürüz.

Güç sizinle olsun.