Selam Ekip - E72 - Payment & Financial Products Frontend Chapter

Selam ekip. Ben Fulfillment Order Master Data ekibinden Fırat.

Teknoloji ekibini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast'imizin 72.

bölümündeyiz. Bu bölümde Payment ve Payment and Financial Products ekibiyle birlikteyiz.

Ekibi tanıyacağız. Ekip yapısı ki yapısı farklı.

Bu ekibin güzel bir yapıları var.

Kullanılan teknolojileri, pratikleri vs.

konuşacağız. Arkadaşlar hoş geldiniz.

Hoş bulduk. Hoş bulduk.

Meribalar, kribalar.

Hoş geldiniz bugün. Dört tane güzel.

Misafirimiz var. Bugün Frontend'cilerle beraberiz.

Eğlenceli geçecek. Cengiz olsaydı keşke denk gelemedi.

Size selam var bu arada. Size selam söyledi.

Buradan isterseniz başlayalım.

İlk kim başlamak ister? İsterseniz bir tanıyalım.

Bakalım kim nedir, necidir vs.

Sonra oradan akarız.

Olur ben başlayabilirim Fırat.

Teşekkürler. Merhaba ben Onur Canavcı.

Payment and Financial Products Chapter ekibinde Frontend Developer olarak çalışıyorum.

Yaklaşık 4,5 yıldır trend yoldayım.

Öncesinde de 1,5-2 yıl kadar deneyimim olmuştu.

Deyip ben de damlaya bırakayım.

Selamlar. Ben de aynı şekilde Payment and Financial Products Chapter'ındayım.

Bir de ek olarak Payments Front End ekibindeyim diyebilirim.

Yaklaşık 15 aydır trend yoldayım.

Bundan önce de 3 senelik bir iş deneyimim olmuştu.

Bu şekilde topu Batuhan'a atayım.

Selam tekrar. Ben Batuhan Topçu.

Kısaca Batu diye.

Seslenebilirsiniz. Bir buçuk yıldır Trendyol'dayım.

Geldiğimden beri Chapter'dayım.

Onun dışında da 4-5 yıllık Frontend Development tecrübem var.

Ben de topu Oğuzhan'a atayım.

Herkese selam. Ben Oğuzhan.

Ben de yaklaşık 8 aydır Trendyol'dayım.

Trendyol'dan önce de 2,5 senelik bir tecrübem olmuştu benim farklı bir firmada.

Ben de Chapter ek olarak burada Financial Products ekibinde Frontend Development olarak görev alıyorum.

Tamamladık galiba ekip olarak.

toplu fratoteknoloji. Aynen.

Dört dedik gibi. Aynen.

Ben de tam ekibinizin ismini şey yaparken, ekip ismi uzun diyordum.

Hani ne söylüyorsunuz? Bazı haber kısaltma kullanıyor vesaire.

Sizlere chapter deniyor herhalde.

Chapter deniyor gibi. Zaten çünkü chapter ekibi olduğu için o yüzden chapter denilince bizim ekip.

Çok iyi.

Payment financial deyince zaten ileriki birileriyle karışacak.

Doğru mantıklı. Aslında zaten Payment and Financial Products genel tribe ismi gibi de düşünebiliriz hani içerisindekiler gibi.

Bizim chapter ekibi de onların tamamını hani alıyor isim olarak.

Anladım siz tribe'ın front end chapter ekibi isiniz.

Çok iyi güzel güzel.

Onur burada sanki şu anda en uzun tecrübeli olan sen gibisin.

Genelde ortalama 1-1.5 yıl arası gibi.

Aynen. Sen 4.

yılla maşallah. İlk gelenler direkt chapter'a gelmişler böyle.

Onlar burayı biliyorken sen oraya gezdin.

Bu ekip ne zaman kuruldu peki?

Yaklaşık iki buçuk sene oluyor bu ekip kurulalı.

Öncesinde de normalde aslında domenler içerisinde bulunuyorduk.

Okey okey. Sonradan aslında burada birleştiğiniz gibi bir şey.

Hatta birleşmişiz derken direkt oraya da geçebiliriz.

Çünkü bu ekip yapısı biraz farklı.

Ben de ekibi bilmiyordum.

Önceden şey yapınca ekibim böyle baktım ne yapıyor vesaire diye okuyunca anladın mı güzel.

Farklı bir yapı var burada. Bakalım burada ne oluyor vesaire diye.

Bu sizdeki bir yapı tam olarak nasıl çalışıyor bir kısaca bahsedebilir misiniz?

Olur ben bahsedeyim istersen.

Chapter nedir?

Chapter farklı domain takımlarındaki frontend developerların yatayda bir takım oluşturması aslında.

Biraz örnekle açmaya çalışayım burayı.

Ben Damla ile beraber payment domaininde çalışıyorum.

Ama Oğuzhan mesela kredi domaini ekibinde çalışıyor.

Hepimiz DK'de farklı domain ekiplerinde çalışıyoruz.

Çalıştığımız backend ekipleri PM ve QA arkadaşlar farklı olsa da Oğuzhan'la biz aynı ekipteyiz.

Burası biraz karışık ama umarım net olmuştur.

Aslında bizim ekip yapısının bir görseli de vardı.

Onu da yine podcast açıklamasına belki link ile ekleyebiliriz.

Görsel olarak da daha iyi olur.

Şimdi de neden böyle bir ekip yapısına ihtiyacımız oldu ve bu ekip yapısına geçişteki motivasyonumuz neydi?

Bunlardan bahsedeyim biraz da.

Bir şey sorabilir miyim olur? Tabii tabii.

Ondan geçmeden önce. Sen şey dedin ya Batu bir ekiple ben bir ekiple.

Yani sen o zaman Batu'nun ekibiyle çalışmıyorsun değil mi?

Yani cross değil. Herkes atanmış bir yeri var.

Aynen aynen. Tam olarak öyle aslında.

Dikey'de farklı ekiplerdi.

Hani Batu'nun çalıştığı backend ekipleri ayrı.

Benimki ayrı. Ama biz Batu'yla aynı ekipteyiz.

Onların backend ekipleri ayrı ama.

Burada aslında işte şeyde avantajını da kullanıyoruz.

Ben chapter'ın atıyorum bir ekipte yoğunluk oluyor.

Oraya destek verebiliyoruz falan.

Strict olarak şu domaine bakacaksın gibi değil de biraz daha ana domainlerimiz var.

Onun dışında birbirimize hep yardım ediyoruz.

Anladım, anladım. Güzel, nice.

Şimdi de neden böyle bir ekip yapısına ihtiyaç oldu?

Ondan biraz bahsedeyim isterseniz.

Bunun için de biraz eskiye gideceğim aslında.

Chapter modeli öncesinde nasıl bir ekip yapısı vardı ve ne gibi problemler yaşıyorduk?

Biz chapter yapısını kurmadan önce farklı farklı domainlerde çalışan bir iki kişilik frontend developerlardık.

Örneğin ben o dönemde alışveriş kredisi ekibinde çalışıyordum ve domain ekibi içerisindeki tek frontend developer bendim.

İhtiyaç kredisi ekibinde de iki frontend arkadaşımız vardı ve satıcı kredisinde de bir tane frontend arkadaşımız vardı.

Diğer ekiplerde de sayılarımız benzer şekildeydi.

Chapter'dan önce yakın ekiplerde çalışan frontend developerlar olarak iletişimimiz zayıftı.

Mesela burada da benzer komponentları geliştiriyor ve aynı sorunlarla karşılaşıyorduk.

Ancak birbirimizden habersiz olduğumuz için her ekip de kendi çözümünü üretmek zorunda kalıyordu.

Örneğin şirket içerisinde geliştirilen framework olan SFX framework'ü vardı.

Satıcı kredisi ekibi bunu kullanmaya başlamıştı.

Biz de aslında o framework'ü kullanmak istiyorduk.

Orada chapter yapısında olduğumuz için seller ekibindeki arkadaş bize oradaki deneyimlerini aktarmıştı.

Biz o framework'ü kullanmaya başladığımızda aslında karşılaştığımız problemlerde de bize bayağı bir faydası oldu oradaki arkadaşın.

Ama işte eski yapıda birbirimizle iletişimimiz de çok olmadığı için haberimiz de olmuyordu.

Hani SFX'i kim kullanıyor mesela?

Hani kime gidebiliriz gibi.

Chapter yapısıyla beraber aslında bunu da çözmüş olduk.

Buranın daha iyi anlaşılması için de aslında bir örnek daha verebilirim.

Alışveriş kredisinde mesela müşterilerimize hangi adımda olduğunu göstermek için bir progress bar geliştirmesi yapmıştık.

Daha sonra aynı komponent ihtiyacı ihtiyaç kredisi ekibinde de oluştu.

İhtiyaç kredisi ekibindeki arkadaşlar da bu komponentin kod reviveni yaptıkları için aslında biliyorlardı böyle bir komponent olduğunu ve direkt kendileri de aslında ufak stil değişiklikleriyle beraber

bu komponenti kullandılar.

Bunlara ek olarak da domain içerisinde frontend sayımız az olduğu için Kod revivinde olması gereken verimi alamıyorduk.

Chapter yapısıyla beraber bütün frontend developerlar olarak aslında birbirimizin kodunu reviv ediyoruz.

Bir de aslında backlog yönetimi bizim için bir problemdi.

Bizim bulunduğumuz ekiplerde backlog yoğunluğu dönem dönem değişebiliyor.

Kısa süreli ekipler arasında değişiklikler yapmak gerekiyor.

Ancak farklı domenlerde çalıştığımız için de kısa süreli bu değişiklikleri yapmak çok mümkün olmuyordu.

Chapter yapısıyla beraber aynı ekip içerisinde birbirimizin projelerini de reviv ettikçe know-how paylaşımlarıyla beraber Codebase'e hakimiyetimiz de arttı.

Hatta bu yönümüzü daha da güçlendirmek için de ekip içerisinde domain aktarımları yaptığımız session'lar da yapıyoruz.

Yaşadığımız sorunlara çözüm arayan ekip liderlerimiz de araştırmalarıyla beraber bu chapter modelini önerdiler.

Bu modelin Spotify gibi şirketlerde kullanıldığını da anlattılar.

Hatta ilgili kaynakları bizimle paylaştılar.

Medium'da da bir yazı vardı.

Merak edenler varsa oradan da yine bakabilir.

Biz de inceledikten sonra chapter yapısını yaşadığımız problemlere doğrudan çözüm getireceğine inanarak bu modele geçiş yaptık aslında.

Çok konuştum ama.

Ama çok iyi oldu zaten.

Bütün bilgileri paylaştın.

Şimdi bunların üzerinden tek tek geçeceğiz.

Kafamda birkaç soru var.

Ya da yorumunda diyeyim.

Şimdi birkaç mesela şey var.

Bizim mesela Fulfillment Tribe'ında her ekipte işte bir iki QA oluyor.

Zaten bizim trend yolda genel olarak öyle.

Ve QA'ların kendi arasında bir şey oluyor.

Böyle ayrı bir tarikat gibi. İşte Fulfillment QA'ları deyip ayrıca mesela toplantılar yapıyorlar.

İşte know-how paylaşıyorlar.

Retrolar falan yapıyorlar. Şunu şöyle yapalım.

Tribe'de bunları böyle yapalım gibisinden.

Bir ayrı bir şey oluyor.

Bir community var gibi bir şey yani.

Mesela PR açısından hiç düşünmedim.

Mesela tek bir kişi var örneğin diyelim.

O kişi yapıyor işi. PR'ını mesela developerlar yapıyor.

Halbuki sizin tarafta farklı frontendçiler yapıyor mesela.

Bu mantıkla mesela olay içeri ben bakmamıştım.

Çünkü developer tarafında daha ordu gibi olduğumuz için hiç bu tarz ihtiyaçlar hissetmiyorsun.

Şimdi sen söyleyince fark ettim aslında.

Doğru. Kod revivler vesaire.

Farklı yapıda oluyor. Aslında sanki testçilere biraz daha benzer bir mantık oluyor.

Ama onlarda tabii...

Böyle bir yapı yok ya da olsa daha mı iyi olurdu olmaz mıydı?

Hani front end de işe yaramış diye anlıyorum.

Siz iki buçuk senedir böyle yapıyorsanız, devam ediyorsanız.

Bizim için bayağı işte faydası oldu.

Az önce de bahsettiğim konularda özellikle hani yaşadığımız bazı problemler vardı.

Onlara doğrudan çözüm sağlamış oldu.

Dezavantajı yok mu? Mutlaka var ama artıları daha ağır basıyor diyebiliriz.

Ben burada bir de ufak araya girebilirim aslında.

Bizim mesela domen içerisinde de işte bir QA'yımız var.

Hatta birkaç tane var. Onları daha sonra detaylandırırım.

Orada da bir tanesiyle konuştuğumda bana şeyi sormuşlar.

Hani bu frontend chapter nasıl oluyor?

Hani biz de QA'lar olarak bazen çok yalnız kalıyoruz diye.

Böyle danışmışlığı da vardı yani.

Aslında böyle ihtiyaç da olmamış gibi evet.

Belki de burada da böyle bir dikey.

Aslında bir tel yolu var mı yani?

Gerçi yok benim bildiğim kadarıyla yok.

Yani chapter'a benzer ama testçiler için olan versiyonu sanırım yok.

Ben de hiç duymadım açıkçası.

Evet. Denk gelmedim.

Belki ona da bir bakabiliriz.

Varsa onlarda da var. Benzeri yapıda çalışan duydum ama şey doğrudan bizim gibi ekip olan yok diyebiliyorum.

Evet evet ben de yok diyebiliyorum.

Ama mantık güzel.

Çünkü şey de olabiliyor ya. Mesela dedin işte Batu'da örneğin dönem dönem ihtiyaçlar oluyor, yoğunluk oluyor.

Niye Batu üzerinden gittim bilmiyorum.

Batu'da bir yoğunluk var herhalde.

Batu'nun ekibinde bir yoğunluk var.

Şöyle biraz yoğunluğumuz ya.

Oralar evet. Yolunluk var gibi.

İşte desteğe ihtiyacı var. Birbirinizle paylaşıyorsunuz ya da aynı işi bir daha yapmıyorsunuz vesaire gibi.

Kısımları paylaşmada mantıklı hani birbirinizle beraber çalışmak.

Bir de frontençler ben direkt şeyle biliyordum ya da birkaç işte store front ekibleriyle vesaire konuşuyor.

Siz de Cengiz'den belki biliyorsunuzdur.

Ben sizinle ayrı bir tarikat olduğunu düşünüyordum bir ara.

Tüm frontençler birbirini tanıyor ve birbiriyle sürekli ilişkinin içerisindeler gibisinden.

Hani şeyler gibi. Hani o kadar bir yapılanma var mı bilmiyorum ama.

Orada da GUİD'de aslında ortak noktada buluşuyoruz diyebilirim.

Aslında yine know-how sharing kendi aranızda bir ekip içerisinde bir de tüm frontendçiler içerisinde bir şeyler var gibi anlıyorum.

Örneğin mesela baklavayı kullanıyor musunuz bilmiyorum.

Bazı projelerde. Örneğin çünkü bir yapılıyor ve herkes bunu kullanıyor mu kullanmıyor mu ya da zaten kendi aranızda iyileşim çok fazlaysa büyük ihtimalle zaten know-how'ınız oluyordur bununla ilgili tahminim.

Orada da şey olabiliyor işte farklı ekiplerdeki hani tasarımlar değişebiliyor.

Mesela bizim taraftaki işte kredi ve finans ürünlerinde benzer tasarımlar olduğu için onlara göre aslında biz ortak bir standart oluşturmaya çalışıyoruz daha çok.

Mesela baklava ise daha farklı yerleri de hit edebiliyor.

Ama bazı projelerimizde de kullanıyoruz o yüzden doğrudan hani işimize yarayan bir yer oluyor.

Mantıklı. Peki bunun dezavantajı ne oluyor?

Ya bu işi yaptık ama şöyle bir şey oldu.

Yani bunu beklemiyorduk ya da bekliyorduk ama bunu aldık çünkü porosu daha ağırdı gibi dediğiniz bir şey oluyor mu?

Burada ben gireyim araya istiyorsanız.

Bu chapter'ın ne dezavantajı var?

En büyük dezavantaj bence şey toplantı yolunu.

Çünkü iki takımımız var gibi bizim.

Herkesin domeninde bağlı olduğu takım var.

Onun bütün mitlerini takip ediyoruz.

Değiller, retrolar, planlamalar gibi.

Ama aynı zamanda...

Chapter'dan gelen toplantılarımız da var.

Günlük sync oluyoruz, retro yapıyoruz, lunch and learn session'ları yapıyoruz aramızda.

O yüzden bazen takvim yoğunluğu bizim çok artabiliyor.

Bu en büyük konusu olabilir şey.

Bunu da amaçıyla ayarlamaya çalışıyoruz.

Şimdi hibrit modelle çalışıyoruz.

İşte hafta tek gün ofise gidiyoruz.

İşte o günler async threadler yapıyoruz.

Mesela asynclerimizi gündeme olan bir blocker durumu olan varsa toplanıyoruz.

Engellememeye çalışıyoruz. Veya işte bazı domenlerin çok yoğun dönemleri veya kampanya dönemlerinde chapter toplantılarını pes geçebiliyoruz.

Onları atlayabiliyoruz.

O şekilde idare etmeye çalışıyoruz o tarafı.

Bir de şey olabilir.

Şimdi herkes bahsediyor.

Çok fazla domenle uğraşıyoruz aslında chapter ekibinde.

8 kişi artı bir lider var.

Herkes farklı farklı domenlerde neredeyse.

Dün bir saydık, 30 tane projemiz varmış aslında.

Maşallah. Bu da inanılmaz bir review demek yani.

Bizim MR'ları takip ettiğimiz bir kanal var.

Orada hiç, boş kalmaz orası hiç.

Sürekli aslında review edilecek bir MR'ımız var.

Bunların hepsi de farklı farklı tekstiklerde aslında.

Vue yazıyoruz, SFX frameworklardan bahsettik, Onurcan bahsetti galiba.

SFX yazıyoruz, Next yazıyoruz, direkt projelerimiz var, Nest var.

Damla uğraşıyor o tarafa.

Bir dünya farklı proje var.

O da biraz zorluyor bizde.

Onun dışında başka ne diyebiliriz?

Reviyevi dediğin gibi zaten çok yoğundur.

Ama toplantı yoğunluğunu ben şeye girişmiştim.

Herkes sadece kendi ekibi çalıştığı ekiple toplantı yapıyor.

Siz kendi aranızda sadece Async'le olun.

Sadece yazışıyorsunuz. Aynı ekiptesiniz ama.

Bazı günler şey yapabiliyoruz ya.

Async bazı günler Async ilerletiyoruz.

Bizim remote olduğumuz günler ortak günlerde aslında sync bir zoom'a girip hani birlikte konuştuğumuz bir şeyimiz var.

Toplantımız var güzelliğe olarak.

Kendi yani şeyleriniz oluyor mu işte retro planlama kendi yaptığınız yani bu sefer çünkü şey olacak.

İki daily, iki retro, iki planlama, iki grup mu yapıyor herkes yoksa?

Orada ben isterseniz bir araya girip özetleyebilirim toplantıları.

Ya şöyle mesela yine daily'lerimiz var Oğuzhan'ın dediği gibi.

Ama yani orada işte şeyi fark ettik.

Atıyorum ofis günlerine gelmeye başladık.

İşte çok verimli olmuyor bizim için.

Bu sefer dedik ki işte şey belli günler sadece Zoom'da olalım.

Belli günlerde şeyden devam edelim.

Threadler üzerinden işte Slack üzerinden senin düşündüğün gibi.

Onun dışında da şey var.

Yine işte grooming'dir vesairedir.

Hani bunları tabii domain'de yine devam ettiriyoruz ama.

Yani bu düzenli toplantılarımız var.

Buna ek olarak hani böyle...

Gereksiz zaman kaybını önleyelim işte hani bize çok yük de olmasın diye böyle core toplantılar ayarladık.

Onlar da işte şey retrolarımız yine oluyor.

Bu da şey için aslında cognitive load ve context switch çok var bizde.

Doğal olarak 30 proje olunca.

Evet çok mantıklı. Aynen.

O yüzden şey ya bu sefer de işte retrolar da onların üzerine bazen düştüğümüz oluyor.

Yani daha nasıl iyi hale getirebiliriz.

O da genelde ayda bir oluyordu yanlış hatırlamıyorsam.

İki ayda bir de olabilir.

Hani bu tarz o şey aralıkları arttırmamız gerekebiliyor yine çok fazla toplantı olmasından ötürü.

İşte şey game session'ımız falan var.

Orada da böyle hani chapter'dan çok kopmayalım işte.

Sonuçta gün içerisinde hep domain ekiplerindeki arkadaşlarla beraberiz.

Hani onun dışında chapter'dakilerle de böyle daily dışında şey olmak için işte game session'ı haftada bir yapıyoruz.

Orada bir oyun seçip.

Onu oynuyoruz.

Onun dışında bir de şeyimiz var.

Launch and Learn Session'larımız var.

O bayağı faydalı oluyor bizim için.

Böyle daha çok know-how aktarımı falan yapıyoruz.

İşte bu chapter yapısının aslında en çok kullandığımız yer diyebilirim kendi açımdan.

Onun detaylarını zaten Onurcan değinir diye düşünüyorum.

Burada çünkü know-how dağılımı sanki daha kritik gibi.

Çünkü sanırım Batu söylemişti emin değilim.

Yani işte burada da yazıyoruz.

İşte SFX de var bilmem ne de var.

Aslında teknolojiyi her yerde aynı kullanmıyorsunuz gibi.

O yüzden sanırım daha çok şeyi birçok şeyi aynı anda takip ediyorsunuz gibi oluyor.

Evet evet. Mesela launch sessionlarının konularından birisi mesela örnek veriyorum.

Hani SFX'i ilk kullanmaya başladığımız dönemde hani SFX'i kullanan arkadaş hani o...

framework'ü bize aktardığı bir session yapıyor gibi.

Böylelikle hani diğer ekiplerde de ihtiyacımız olması durumunda bir know-how oluyor.

Bu launch session'ları da düzenli olarak yapıyoruz aslında ve genelde de bir kişiye atıyoruz.

Bu atadığımız kişi de agendayı ve toplantıyı drive ediyor.

Konuları da hep beraber belirliyoruz.

Mesela bu sene teknoloji tarafında bizim hani Tech Vision kapsamında Q1 içerisinde reliability öncelikli.

O yüzden de mesela önümüzdeki konulardan bir tanesi sonar küp ile alakalı.

Çoğu projelerimizde aslında sonar entegrasyonu var ancak mesela buradaki sonar gate'lerimiz nasıl, ne durumda ve hani şirket tarafındaki hedeflerimize uyuyor mu?

Oradaki gate'leri mesela daha iyileştirebilir miyiz gibi aynı noktaya gelmek ve standart oluşturmak için de kullanıyoruz bu toplantıları.

Düzenli olarak yapıyoruz. O da bize bayağı katkısı oluyor.

Çok mantıklı. Peki oradaki hedefler?

şey mi oluyor? Şimdi farklı ekiplerle de çalışıyorsunuz ya.

Her ekibin de ayrı hedefi.

Hani ekip bazı KPI'larımız oluyor ya.

Siz hangi ekibin sizin chapter ekibinin de ayrı KPI'ye hedefi oluyor mu yoksa sizler herkes kendi bağlandığınız ekibin hedefine mi bağlı oluyorsunuz?

Oradaki mantık tam nasıl işliyor?

Orada şöyle özetleyebilirim sözü ben alayım yine.

Domain ekiplerine mesela yine bağımsız olarak işliyor aslında.

Yani OKR hedefleri var her ekibin.

Ama biz de chapter içerisinde yine alıyoruz.

Her sene işte başında belirliyoruz.

Aynı şekilde ilerliyor süreç.

Sadece burada amacımız daha çok şey oluyor.

Yani birbirimize destek çıkabileceğimiz, işte şirket hedeflerini de kapsayacak şekilde o aynı zamanda Nova aktarımlarını yapabileceğimiz noktaları belirleyip hani onlar üzerine OKR almaya çalışıyoruz.

Çünkü bu bize... Ters de tepebiliyor.

Yani o karları tamamlayamadığımız durum da olabiliyor çok fazla hedef aldığımızda.

O da motivasyonu haliyle etkileyebiliyor.

Bunu daha iyi aslında kullanmamız gerekiyor bu chapter yapısını.

İstersen şeyden de bahsedebilirim.

Hani bu o karları ilerletişimiz ne şekilde oluyor falan onu da değinebilirim.

Olur olur. Nasıl ilerliyor?

Çünkü bir de şey ya bunun ortasını tutturmak da çok zor ya.

Yani dengesi tutmak dediğin gibi fazla alacaksın yapamayacaksın.

Sanki bir şey yapamayacak mısın gibi de psikolojik olarak hissedebilirsin gibi bu yoğunlukta.

Aynen öyle. O yüzden aslında şey yaptık bu sefer.

Bu sene şirketin, Onurcan'ın bahsettiği gibi reliability hedefleri var.

Bunlar genel teknoloji kapsamında OKR hedefleri aslında.

O yüzden hem domeni hem de bizim chapter OKR'larına dahit edecek şekilde takip ettiğimiz bir maddemiz var.

Onu o şekilde ilerletiyoruz.

Oradaki mesela bu OKR'larda bir assign'lerimiz oluyor, bir ölçümleme yöntemimiz oluyor.

Mesela bu reliability OKR için ölçümlemeyi yaparken her domain bunu ne kadar ilerletmiş.

Çünkü o domainlerin de kendi içerisinde aldığı hedefler sonuçta farklı.

Onu da ortaklaştıramıyoruz.

O yüzden o domainlerin ilerleyişini orada takip ediyoruz.

Ama mesela şey de var, chapter içerisinde direkt olarak takip ettiklerimiz var.

Onu da bir örnek vereyim.

Mesela Code Review sürecinde daha verimli hale getirmek için bir OKR almıştık.

Onda da amaç aslında en 4K metriklerimizi iyileştirelim.

Çünkü sonuçta bu sene onda da bir şey, o tarz bir...

Bu sene verimlilik senesi yani. Evet, verimlilik ve test.

Evet, evet. O yüzden onu da iyileştirmek istedik.

İşte bir cycle time'ı optimize edelim falan dedik.

Hem de yani zaten çok fazla domeniz direkt teknolojinin büyük bir kısmına da hit ediyor aslında yaptığımız iyileştirmeler.

Orada da şöyle bir şey yaptık işte.

Kendilerimizle bir toplantı düzenledik.

İşte neleri daha iyi yapabiliriz?

Hani Oğuzhan'ın bahsettiği gibi bir botumuz var.

İşte MR Review botu.

Yani MR'leri aslında Slack'te bir kanala basıyor.

Ama bu aynı zamanda işte şey orada görüntülediği bilgileri...

Daha iyi nasıl kullanabiliriz?

İşte bunun üzerine bir toplantı yaptık.

Bir şey sorabilir miyim o ürünle alakalı?

Aynı ürünü mü kullanıyoruz bilmiyorum ama.

Onaylayınca bildirim atarken onaylayana da bildirim atıyor mu?

Yani ben mesela bir PR'ı onaylıyorum.

Tekrar reminder geliyor. Bu hala merge olmadı ya da bir onay daha ihtiyaç var.

Onaylayanı da etiketliyor. Ben onaylandığım için etiketleniyorum.

Benim çok dikkatimi daha atıyor.

Bu tarz şeylerde biraz daha şeyim ben.

Kolaydı ama. Sizlere benzeri bir şey var mı?

Aynı önemli bilmiyorum ama. Değil sesinkini kullanacağım.

Ya bizimkinde daha şey aslında.

İlk başta böyle Merge Quest açıldığında işte bir bildirim geliyor.

Atölye Batuhan işte Merge Quest açtı diye.

Ama şey. Provelarda mesela spesifik olarak bir şey atmıyoruz.

Bildirim atmıyoruz hatırladığım kadarıyla.

Çok mantıklı. Aynen. Hatta hemen bir kontrol edeyim.

Aynen. Bir şeyden bahsedebilirim ben.

Burada aslında ilk başta bir assign ediyoruz.

5 dakika MR açıldıktan 5 dakika içerisinde 2 tane farklı kişi assign ediyoruz.

Daha sonrasında da onaylandığında bildirim atmıyoruz ama gün içerisinde mesela günde 3 kere hatırlatma amaçlı biz bu MR'ları kanala basıyoruz.

Ve burada da ne kadar remaining approve ihtiyacı kaldığını veya açık thread var mı bunları gösterdiğimiz bir botumuz var.

Mantıklı ya bizim de ona göre bir update etmemiz lazım.

Burada bir de ben damlaya ek şeyden de bahsetmek istiyorum.

Mesela OKR hedeflerini belirlerken cycle time'ı mesela iyileştirme bizim hedefimiz hani teknoloji olarak.

Burada da cycle time'da da aslında tududan dana kadar geçen sürede iyileştirmemiz gereken yerler oluyor.

Mesela test sürecini iyileştirmek istesek bu aslında domain ekibinde ilerletmemiz gereken bir hedef.

Neden? QA arkadaşlar domain içerisinde bulunuyor ve orada ilerletiyoruz ama...

CodeReview tarafını chapter olarak ilerlettiğimiz için buradaki CodeReview süresini iyileştirmek bizim chapter olarak bir belirlediğimiz OKR hedefi oluyor diye ekleme yapmak istedim ben de.

Ben de burada bir şey bir önceki soruya atıfta bulunayım.

Herkes bahsetti bu metikleri takip ederken yani şeyde trend yolda chapter modeli çok yaygın değil dedik ya biz bunlara bazen entegre olurken bir dezavantaj yaşıyoruz mesela.

Çünkü işte 4-5 farklı aslında domain ekibindeyiz.

Ama aslında bir ekibiz aynı zamanda.

İşte böyle o metikleri takip ettiğimiz dashboardlarda işte Pandora belki daha önce konuşulmuştu podcastlerde bilmiyorum.

Genel metikleri takip ettiğimiz yerlerde bizim internet tool'larımızda.

Chapter uygun bir yapı olmayınca biz ekstra eforla bazen bunları takip ediyoruz chapter üzerinde.

Ayrı ayrı domainlerden şeyleri metikleri toplayıp onlarla uğraşmamız gerekebiliyor.

Veya işte o ilgili ekipten geliştirme talep edebiliyoruz.

Bize özel, spesifik olarak.

Bu da bir dezavantaj olarak aklımdaydı söyleyeyim dedim.

Özellikle housefullarda yaparken bunu düşünmüyorlardır yani.

Evet hafif. Unique kalıyoruz.

Herkes zaten domaindir veya tek bir ekipten sorumludur o ekipte ki her çalışan gibi düşünüyorlardır.

Bu sefer mesela sizde belki de bazı puanlar daha düşük gözüküyordur ama ha bir köle değildir gibi şeyler oluyordur belki.

O tarz zorluklar yaşıyoruz ya.

Değil mi? Bir açıklama ihtiyacınız oluyor.

Bakın bu böyle bir şey değil, biz böyle değiliz falan diye.

Doğru, çok doğru. Zaten ilk yazdığımızda çok net olmuyor.

Ayrıca bir daha konuşmamız gerekiyor falan hani orada talepleri iletirken.

Muhtemelen onlar da o ekip yapısını tam anlamadıkları için tek seferde anlaşamıyoruz orada.

Evet, bir açıklama ihtiyacı, bir konuşma ihtiyacı oluyordur.

Bilen birini şey yapacaksın, bir ilk başta açıklayacaksın.

Sonra hep onun üzerinden ilerleyeceksin.

Herhalde böyle yürüyecek, bilmiyorum.

Onun hakkında bir atıklama ihtiyacı oluyordur.

Çünkü alışkanlık yani böyle bir şey hani kafa her yerde yok sonuçta.

Ama bence olabilirmiş gibi geldi.

Ben hatta köylerde de olabilirim gibi düşündüm ama köylerdeki hani sanki biznes daha da fazla ya daha da biznes biznes böyle.

Onların bir arada olması sanki daha zor.

Şu andaki yapı sanki daha salkmış gibi geldi tarikat yapısı.

Emin olmasam da şu anki de akıyor.

Peki az önce sanırım...

başlardayken Batu bahsetmişti.

İşte V kullanıyoruz, JS kullanıyoruz vesaire.

Şimdi frontend değilim o yüzden çok hakimmişim gibi davranmayacağım.

Ama bu teknolojilerden kullandıklarından bahsetmişlerdi.

Genel olarak böyle bir sabit bir teksteğimiz var mı bizim?

İşte şu tekstekleri kullanıyoruz, işte şunları şunlara geçiriyoruz gibi ya da bir migrationlar vesaire oluyor mu?

Ya da işte toplam olarak genelde işte mesela backend'de bizde şeydir işte Go çok yaygındır, Java, Kotlin yaygındır vesaire.

Bizim frontend tarafımızda ya da chapter tarafında bu işler nasıl ilerliyor?

Burada ben cevaplayabilirim.

Dil olarak sadece TypeScript yazıyoruz aslında.

Hani JavaScript'in üzerine type'lar ekleyerek daha güvenli kod yazmamızı sağlıyor.

Onun dışında şirketin internal tool'larına mecburen entegre olmamız gerekebiliyor.

Atıyorum SFX'in şu an kapanıyor mesela oradan çıkışımız var.

Daha sonra Puzzle.js ve entegre olmamız gerekiyorsa kullanıyoruz.

En güncel olarak şu an tek bir tek siteye düşme hedefimiz vardı.

Birbirimiz arasında hem kod paylaşımı hem de proje değiştirdiğimizdeki o cognitive load'u düşürmek için.

Orada da ekip içerisinden XJS'i seçtik.

Bayağı bir artısı oluyor bize.

Onun dışında Vue kullanan projelerimiz oluyor, legacy.

Mecburen onları da maintain ediyoruz.

Hala hazırda var olduğu için.

Vakit buldukça domain ekiplerinde onları da en güncel teknolojiye çekmeye çalışıyoruz.

Hem kendimiz için iyi oluyor hem de.

Technical Depth'i indirmeye çalışıyoruz.

Burada bir şey sorabilir miyim?

Tabii. SFX'in, yani SFX tabi bilmeyenler için, bizim aslında BFF tolumuz, BFF'lerden diyeyim daha doğrusu, BFF'lerden siz mi sorumlu oluyorsunuz yoksa şey gibi mi oluyor?

BFF'leri işte deep backend gibi backendciler hallediyor, biz onlarla konuşuyoruz, anlaşıyoruz gibi mi oluyor?

Oradaki işleyiş nasıl oluyor? Orada...

Aslında SFX ben sözü aldım ama Batu birazdan bırakırım bir ufak ekleme yapayım.

Yok önemli değil. Dayanamadım diyeyim.

Aslında şey SFX hem BFF hem de rendering tarafında da aslında bir çözüm getiren framework.

Biz rendering tarafında da çok sık kullanıyoruz.

Tabii BFF'lerde de kullandığımız yerler var.

BFF'lerde de çoğunlukla bizim sorumluluğumuz da oluyor diyebilirim burada.

Ama şu anda bir de SFX tarafındaki rendering olan uygulamalarımızı NEX'e geçirmeye hedefimiz de bulunuyor.

Hani bir migration söz konusu orada da.

Aslında SFX'den orada Next.js'e geçiyoruz.

O zaman SFX'e daha çok burada BFF bantı ya da gateway ya da bilmiyorum artık.

O kafayla kullanıyoruz gibi.

Aynen. Ya orada işte biz aslında rendering'ini de çok aktif kullanıyorduk.

Bu web'e entegre olmak için gerekiyordu.

Ama orasının kapanacağı çıkınca bize sadece BFF gibi bakmaya başladık oraya da.

Ben zaten unutmuştum rendering olayını.

Belkente olduğum için o kafayla mı bakmışım ya da ihtiyacım kadar mı görmüşüm bilmiyorum.

Ben sanki hep BFF'den ibaretmiş gibi düşünmüştüm ama aslında öyle değildi.

Evet evet. Orada işte BFF yazarken mesela direkt NSJS yazdığımız böyle backend yazar gibi projeler de var.

Payment tarafında mesela. Dört farklı domeyine tek bir dashboard yazıldığı için orada BFF ile no end point'ler birleştiriliyor mesela.

Evet orada hatta ben şeye de ekleyeyim.

Logic eklediğimiz durumlar bile oluyor.

Ayrı servisi yazmamız gereken durumlar da olabiliyor.

O tarafta da destek veriyoruz.

Puzzle.js ince akıma bu arada şey gelmişti.

Ben ilk işte 2019 Haziran'da girmiştim şeyim.

Trendyola. O ara ilk staç programıydı.

Staç programıyla gelmiştik.

Ve şeyler yapılıyordu bize.

Biz 40 kişi orduca böyle yazı alınmıştı.

40 kişilik bir alım yapılmıştı o ara.

Ve sunumlar yapılıyordu. Bazı abiler ablalar bize geliyordu ve sunumlar yapıyordu.

Bakın böyle ekiplerimiz var. Biz bunlardan bahsediyoruz falan diye.

O ara işte Puzzle.js'den bahsedilmişti.

İşte bizim işte Puzzle.js'de bir şeyimiz var ve işte performans uşu mobil webde.

Şöyle bir performansımız var, şöyle bir sıralamadayız dünyada falan filan diye açıklama yapılmıştı ve şey olmuştu.

Neler yapıyoruz ya, neler oluyor falan burada böyle diye etkilenmiştim.

Ve o an mesela hala aklımda her puzzle chess dediğimde o sunum aklıma geliyor.

Benim için böyle nedense böyle hep aklımda kalmıştı yani.

Ona ben de şaşırmıştım.

Bayağı hani framework yazıp maintain etmemiz gerekiyor.

Böyle custom sorunlarımız olduğu için trend yolu içerisinde.

Hani özellikle bu...

projeleri ayırmak biraz daha backend'de mikro servis yazılacak olay oluyor da mikro frontend olayı biraz daha zor olduğu için.

Farklı bir kafası var ya. Çok iyi gerçekten.

Peki buradaki tech stack'ten bahsetmiştik ya az önce.

Aynen. Buradaki tech stack'te işte inha sularından bahsetmiştik.

Buradaki bunun devamında işte bizde backend'de daha çok işte ürünler olarak neveli kullanıyor mu artık daha işte open telemetriye geçiyoruz vesaire gibi tool'lar oluyor.

Frontend'de siz buradaki işte monitoring işlerini vesaire nasıl yapıyorsunuz?

Hatta oradan şey de var, incident'a bağlayayım.

Incident'ları nasıl yapıyorsunuz?

Incident'larınız olunca neler oluyor?

En sevdiğim soru böyle her bölümde illa sorarız.

Bir incident var mı?

Ki vardır, hani. Ama en güzel aklınıza gelen de...

Onu söyleyemiyoruz maalesef.

Ama isterseniz başka bir monitoring yapısından da bahsedebiliriz.

Olur abi, ben gireyim orada. Bir de aslında şey...

Daha birimlik tool'larımız var. İşte Sentry, Kibana, VF'ler için işte Nivrelit tarzı tool'larımız var.

Onları kullanıyoruz düzenli olarak.

Onun dışında intern olarak yine in-house geliştirilen Mergen diye bir yapı var.

Yine Sentry'ye çok benzer ama işte bütün şirket genelindeki bütün metrikleri takip edebildiğimiz ekranlara direkt yansıyan.

Mergen'i de artık yeni yeni bütün projelerimize entegre ettik biz.

Aynı şekilde ondan da monitoring yapıyoruz.

Bütün produkların metriklerini onunla takip ediyoruz.

Onun dışında monitoring ile ilgili daha detaylı şöyle söyleyebilirim.

Monitoring sürecimizde bizim sistem performansını ve işte birkaç iş akışlarını ölçmek için içeride kullanılan bir tabi var.

Key Business Transaction diye.

Bu kritik metikleri takip ediyoruz.

Aslında bu ne anlama geliyor? İşte kullanıcıların kritik süreçlerde, kritik case'lerde, flow'lardaki olumsuz uçabilecek durumları tanımladığımız metikler.

Bir örnek olarak belki şey söyleyebilirim.

Mesela bir siparişin başarı tamamlanması bir key bit olabilir.

Ödeme sürecinin sorunsuz ilerlemesi bir key bit olabilir.

Bu tarz kritik flow'ları özellikle bu monitoring tool'larıyla entegre edip onları takip etmeye çalışıyoruz.

Bu metiklere bağlı olarak oluşturduğumuz alertlerimiz var.

Çeşitli flow'lar var.

Bunları anlık olarak takip edip Slack kanallarına basıyoruz.

Tabii içeride şey de var, backend tarafında daha sık kullanılan on-call mekanizmaları da var.

O kanallara basarak hızlıca takip edip aksiyon almaya çalışıyoruz.

Biz chapter olarak hani chapter'ın işte faydalarından belki...

Buraya hit eden bir nokta var.

Biz chapter olarak hani ortak bir kanalda bütün product'ları takip ediyoruz.

Bu alert mekanizmalarını birlikte güncelliyoruz chapter olarak.

Bunlarla ilgili hedefler alıyoruz.

İşte fault positive gibi bizi yanlış alert veren şeyleri birlikte toplayıp, toplanıp, review edip, düzenliyoruz veya keyfleri yine birlikte çıkarıp, gerekli yerlere alertler ekliyoruz heplerimizde.

Bu tarz diyebilirim monitoring, incident.

Ben de yok ama onu cana bırakayım orada.

Ben burada girebilirim. Bu arada instant gerçekten hani bizim tarafta çok fazla yaşamıyoruz.

Çok şükür nazar değmesin diyeyim.

Böyle dedikten sonra da genelde bir instant oluşabiliyor ama.

Şu bölüm bitecek ve bu kayıt bitecek ve bir şey başlayacak şimdi.

Burada da aslında hızlıca bir bakayım dedim.

Hani RCA kayıtlarını tuttuğumuz bir Pandora'da sayfamız vardı.

Hani en son yakında ne yaşamışız diye.

Orada da gözüme çarpan bir tane şey vardı.

Bazı projelerimiz bizim mono repo.

Aslında birkaç ekip benzer ekranları geliştirdiğimiz için tek bir mono repo içerisinde geliştiriyoruz.

Orada da bir aslında User ID ile alakalı bir util function içerisinde bir değişiklik olmuş.

Bundan dolayı da hata almaya başlamışız.

Bunu da nasıl fark ettik?

Burada da aslında Oğuzhan'ın bahsettiği gibi Sentry bize bayağı yardımcı oldu.

Sentry'de daha önceden tanımladığımız alertler tetiklenmeye başladı ve orada hani incelediğimizde de neden kaynaklandığını orada User ID en son çıkan aslında MR'ı inceledik.

Orada bir hata olmuştu.

Hızlıca aksiyon alıp orayı çözdük.

Burada da ne kadar kullanıcı etkilendi bunları da analiz etmek için aslında Sentry'deki alertlerimizde hani başlama saatine göre atılan eventleri inceledik.

Biz burada işte kullanıcıların metrikleri için Delphi eventleri atıyorduk.

Bu eventlerde aslında ne kadar hata aldığımızı, kaç kullanıcının etkilendiğini hesaplamak için de böyle bir analiz yapmıştık.

Tabi bunların zaten trend yolu içerisinde de hani RCA kaydı oluşturup instant'dan nasıl etkilendik, neyi daha iyi yapabilirdik işte.

Gibi aslında bunları da daha sonrasında bir post mortemde analiz edip aksiyonlarımızı alıyoruz diyebilirim.

Bunun böyle bir de şey oluyor. Sizin tarafta nasıl oluyor emin değilim ama aslında siz müşteriyle daha birebir etkileşimlisiniz ya ve hani financial repayment gerçekten en kritik yerlerdesiniz

ve yaptığınız işin gerçekten etkisi çok fazla olabiliyor.

Bizim tarafta işte ben depo tarafındayım, fulfillment tarafında.

Bir şey olduğunda dışarıdaki müşterinin çok da haberi olmayabiliyor.

Hani çünkü yaptığımız az yer, müşteriyi daha az etkileyen yerler.

Evet var, bağlantılı olan yerler ama daha az.

Bizim müşterimiz daha çok işte hani operasyon tarafı oluyor.

Ve etkilediğimiz yerlerin maksimum sınırını biliyoruz.

Yani kaç tane depomuz var, maksimum nereye etkileyebiliriz, en kötü ne olabilirce biliyoruz.

Sizin tarafta biraz daha şey ama ne kadar kişi etkilendi, kaç müşteriye olmuştur.

Ve etkisi sayısı büyük ihtimalle çok daha fazla.

Aynen. Yani çok fazla gerçekten hani session sayısı da yüksek olabiliyor.

Bir de hani doğrudan kullanıcının deneyimini etkileyecek yerlerde daha öncelikli ve daha fazla alert hani oralarda tanımlıyoruz.

Hani Oğuzhan'ın da bahsettiği gibi aslında hani oralar bizim için her senaryoyu düşünmeye çalışıyoruz.

Yani eksik kalan bir senaryo var mı?

Ama mesela internal kullandığımız panel uygulamaları da oluyor hani kendi içerimizde.

Kullanıcı orada aslında bizim business ekibimiz oluyor.

Oralarda mesela o kadar strict değil ama son kullanıcıya dokunan yerler biraz kırmızı çizgimiz gibi.

Oralarda hani daha fazla alert tanımlaması yapıp bütün senaryoları ele almaya çalışıyoruz.

Çok mantıklı ve eğlenceli bence ya.

Burada yani çok fazla olasılık var ve hepsini kapatmak için gerçekten ekstra şeyler gerekiyor ya.

Her adamını takip ediyorsun gibi bir şey aslında o kullanıcının.

Ya şu olursa ya bu olursa gibisinden.

Evet evet. Bu kafa güzel seviyorum.

Buradaki alattaki konular her zaman.

Ve kafamda şey oluyor. Şimdi aklıma geldi.

Özellikle false alertler çok sinir bozucu olabiliyor.

Şimdi operasyonda vesaire bizde 7-24 olduğu için.

Pazar günü bir şey gelse ve asla çok dönemde ise gerçekten çok sinir bozucu olabiliyor bu arada.

Aklıma geldi. Evet.

Bu arada şey yaşadığımız o insanlıkta da şeyi değerlendirirken bu hani daha erken fark edebilir miydik?

Orada gerçekten çok düşük thresholdlara çekmemiz gerekiyor.

Bu da haliyle false positive'e de sebep olabilir ama bunu da değerlendirmiştik bizde.

Bu sanki hep bir var ya yani bu zorlu demek ki tek biz yaşamıyoruz bunu sevindim.

Hani şey o threshold ayarına yani bir şey koyuyoruz.

Ya çok sınırda ama sorun olabilirdi ama olmayabilirdi gibi bir sınır böyle.

Hep o bir dilem oluyor yani.

Bizim de sürekli güncel şeyimiz ya topiklerimizden biri yani sürekli.

Değil mi? Evet evet.

Tamam bu ortak bir problem. Biz şey yapıyoruz daha bir arada.

İki farklı kanalımız var. Bir warning bir on call.

Hani on call daha kritik olanlar.

Warningler gerçi artık kaldırıyoruz yavaş yavaş ama hani belki öyle bölebiliriz yani.

Daha mantıklı olur. Evet evet.

Biz de bazen şey yapıyoruz hani. Renklerini falan değiştiriyoruz.

Bu warningdir. Bu kırmızıdır falan diye.

Ya da support ekibimiz var.

Şey yapıyoruz. Support'a söylüyoruz.

Hani o alerti sadece support'a bağladık.

Hani gece 3 mü? Bizi telefonla ara.

Bizi evimizden alın falan diye böyle.

Böyle alertlerimiz var.

Evinden al alerti. Güzel.

Orada AI'dan beklenti mu?

Threshold'ları otomatik ayarlaması.

Doğru. Çok zor. Çok iyi önerdiğimi AI threshold şeyi setleme.

Duruma göre şey diyeceksin. Sen sürekli feedback vereceksin.

Bu threshold az geldi, bu fazla geldi, bu gereksizdi falan diye.

Öyle yapar yapar. Müthiş bir fikir.

Buradan da bir fikir. Bakın bunu dinleyenlere fikir edebiliriz.

Buradan şey yapalım. Buradan git eve yürürüz.

Aynen. Yeni bir SAS projesi olarak bunu deneyebilirler.

Hazır şu an. Bak bu ekiplere frontendçilerleyiz.

Havalı bir frontendle beraber.

3 ay sonra çok popüler bir tool çıkıp şey çok büyüyormuş botunun şeyleri.

Hezeyanı duyuyorum yani. Şey bahsediyorlar açıklama yapıyorlar şey diyorlar ya Trendyol'a bir podcast dinledim.

Orada fikir verdiler.

Yaptık bizde diye. Adamlar para kazanıyor ben ağlayarak izliyorum.

Sen o ara şeysin ama ben open source'a katkı yaptım falan diyorsun.

Adam orada parayı bulmuş gitmiş.

Çok iyi. Güzel.

Fikrimizi de sunduğumuza göre yavaştan kapanışa geçiyorum arkadaşlar.

Çok teşekkür ettim. Çok güzel bir bölümde.

Ağzınıza sağlık. Biz teşekkür ederiz.

Teşekkürler. Teşekkürler.

Çok teşekkürler.

Evet. 72.

bölümdeydik arkadaşlar. Selam ekibimizin 72.

bölümünde Payment and Financial Products ekibiyle birlikteydik.

Gördüğünüz gibi farklı bir ekip, yapısı farklı vs.

ve çok da güzel muhabbetleri var.

Tekrardan teşekkür ederim hepinize.

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

Bye bye.