Konuklar: Tansu Demerci, Özge Akkol Arslan, Beril Gökçe Çiçek
55. bölümümüzde konuğumuz Customer Services ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Trendyol Talks'da Trendyol'daki kültürümüzü, kültürümüzden beslenen iş yapış biçimlerimizi ve ritüellerimizi konuşuyoruz. Trendyol Talks podcast kanalımızı takip etmeyi unutmayın!
Transkript
Selam ekip, ben Fulfillment Order Master Data ekibinden Fırat.
Ben Storefront TRPDP ekibinden Cengiz.
Teknoloji ekibini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast'inin 55.
bölümündeyiz. Bu bölümde Kasım Sersi ekibiyleyiz.
Bu ekibini tanıyacağız. İşte ekip yapısı, kullanılan teknolojiler, pratikler gibi bu konulardan bahsedeceğiz.
Arkadaşlar hoş geldiniz. Hoş bulduk.
Hoş bulduk. Hoş geldiniz, hoş geldiniz.
Bugün Tansu, Beril ve Özge ile beraberiz.
Arkadaşlar tekrardan hoş geldiniz.
Önünden bir tanıyalım. Daha sonra da ekibe gireriz.
Tansu istersen senden başlayalım.
Olur. Selam tekrardan.
Tansu ben. Otoelektrik ve elektronik mühendisliğinden mezun olup sonrasında da 3 yıl bir startupta beklenici olarak çalışmıştım.
Sonrasında da tren yola geldim aslında.
8 aydır da buradayım.
Başlamadan şeyi de söyleyeyim.
Türkçe ana dilim değil. Şimdiden kusura bakmayın yapacağım hatalar için.
Deyip topu Özge sana atayım mı?
Olur Tansu sağ ol.
Teşekkür ederim. Ben de Özge, Yeditepe Üniversitesi Bilgisayar Mühendisliği Bölümünden mezun oldum.
Üniversitenin son döneminde de bir telekomünikasyon şirketinde aslında staj yapıyordum.
Mezun olduktan sonra da orada backend developer olarak çalışmaya başladım.
Kibat ayından beri de Trendyol'da customer service ekibinde çalışıyorum deyip topu Beril'e atayım.
Selamlar, ben Beril.
Adnan Menderes Üniversitesi Bilgisayar Mühendisliği mezunuyum.
Son sınıfta bir teknoloji firmasında backend developer olarak part-time çalışıyordum.
Sonrasında Trendyol'un Frontend Bootcamp'ine katıldım.
Bootcamp sonrasında Frontend Developer olarak Trendyol'da çalışmaya başladım.
Yaklaşık 3 yıldır da burada çalışıyorum.
Hatta Cengiz yanlış hatırlamıyorsam seninle ilk kez o Bootcamp'te karşılaşmıştık.
Evet evet ben de asistanım o Bootcamp'te.
Oradan da bayağı arkadaş geldi aramıza.
Frontend işler birbirini tanıyor bir tarikat gibi yemin ederim ya.
Neden? Birbirini tanımaya fırlatan çok gerçekten.
Birbirimizi kolluyoruz.
Evet fark ettim. Bu arada Tansu ana dilimdeydin ama söyleme sen hiç fark etmezsin.
Bence yalan söylüyorsun. 9 yıl oldu artık çoğunlukla geçti aksanım da ilk geldiğimde merhaba dediğim gibi anlaşılıyordu.
Çok iyi ya güzel. Teşekkürler.
Hoş geldiniz arkadaşlar. Tekrar bugün sizi ağırlamaktan dolayı çok mutluyuz.
Güzel bir ekiple beraberiz.
Ben bu tarafı da oldukça merak ediyordum açıkçası.
Güzel sorularımız olacak sizlere.
Öncelikle biraz ekibinizden bahsedebilir misiniz?
Kaç kişisiniz? Neler yapıyorsunuz?
Tabii ben alayım isterseniz.
Şimdi Customer Services ekibi olarak Seller OMS CX Tribe'nin altında yer alıyoruz aslında.
Team Lead'imiz ile birlikte de yanılmıyorsam 10 kişiyiz.
5 kişi back-end'deyiz, 2 front-end'de.
Bir Developer in Test, bir de Product Manager'ımız var.
Bunun yanında bir de UI UX'cimiz var ama o hem bize hem başka ekiplere bakıyor.
Hani 10,5 diyebiliriz belki.
Daha çok yeni bir ekibiz açıkçası.
Zaten biraz bahsederiz ama topluca yılbaşında Global Platforms'dan Buraya geldik.
Biraz başta bir zorlanmış olabiliriz ama şu an çok sahiplenmiş durumdayız.
Heyecanlıyız burada olduğumuz için.
Yılbaşından beri çok iyiymiş ya. Hayırlı olsun.
İlk tip resmen yeni kurulmuş. Aynen.
Global platformdan geçtiniz.
Çok iyi. Biz de Fulfillment tarafında orayla beraber çalışıyoruz.
Baş akışı yönüşlerinde vs.
Ama customer services...
Alt kırılımını bilmiyorum herhalde. Belki de bölündüğü için ya da bölünmesi gerektiğinin mütehidiymiş gibidir belki de.
Tam olarak o geçiş nasıl oldu?
Çünkü global platform daha büyük ve sipariş kısımlı bir yer ya.
Oradan kastında servisli bir kırılım nasıl oldu bu geçiş?
Aslında onun altında değiliz şu an.
Direkt oranın sınırı biraz...
Yoğunluğu azalınca bir kısmımızı buraya aldılar burada da ihtiyaç olunca.
Hani böyle global platformluza şu an bir bağımlılığımız yok.
Bildiğim kadarıyla burada hali hazırda devam eden bir ekip vardı zaten.
Bu proje devam ediyordu.
Diğer taraftan global platformlardan bu ekibe bir aktarım oldu diye biliyorum.
Ben tabii sonrasında dahil oldum onu da anlatırım da.
O şey süper.
Peki bunun bir şeyi var mıydı?
Yani biraz sert bir geçiş olmuş diye anladım.
Böyle bir challenge falan var mıydı? Böyle bir geçişin en büyük böyle...
Zor yeni neydi? Ben bu geçiş sürecinin biraz başlangıcından bahsederek başlayayım.
Tavsun'un da söylediği gibi geçen yılbaşında hepimizin ekibi değişti ve Customer Service projesine geçtik.
Projeyi devraldığımız süreçte de back-endinden product'ına kadar hepimiz projeye ve böyle business'a yabancıydık.
Ekip olarak da yeniydik zaten.
O yüzden ekibin kaynaşma süreciyle bizim projeyi tanıma sürecimiz paralel ilerledi diyebiliriz.
Burada challenge'larımızdan biri projeyi kısa sürede hakim olmaktı.
Bunu da aslında o süreçte hem ekip olarak özverili bir şekilde çalıştık hem de diğer ekiplerin çok fazla desteğini aldık.
Onların da işbirliği sayesinde de o süreci atlatmış olduk diyebilirim.
Yani başlangıcı böyleydi.
Bir de teknik olarak çizdiğimiz bir yol var.
Ondan da belki Tansu sen bahsedebilir misin?
Tabii be. Neler yaptık?
Aslında dediğimiz gibi bir böyle topluca geldik.
Bir şey oldu. Başta bir onboarding süreci aldık.
Burada önceden olan ekipten bir devraldık.
İşte onlar birazcık anlattı.
Sonrasında da oturup böyle topluca Dominic Rittek akışlarının...
Çıkardığımız bir tane toplantı yaptık.
Hatta birkaç tane toplantı yaptık desem daha doğru olur.
İşte üstüne bir konuştuk.
Bizim projeye ait olmadığının düşündüğümüz akışları ilgili ekiplere devrettik.
Sonrasında geriye kalan kısımlarda bir toplu replatforming sürecine girdik.
Bunları yaparken de işte domenleri ayırıp...
Oturup hem project management ekibinden çok destek aldık hem test ekibinden çok destek aldık.
Hem böyle sürekli peri halindeydik hatta 3-4 kişi birlikteydik.
Oturup böyle her akışın çizimini çıkarmaya çalışıp sonra bunların replatformini biraz planlayıp başladığımız bir sürece girmiştik.
Öyle baya yoğun geçti ama bir yandan da şöyle bir pozitif tarafı oldu.
Birbirimizi de tanımış olduk.
Böyle sürekli birbirimizle vakit geçirip durunca sosyal açıdan da baya bir faydası oldu bence o sürecin.
Şu an biraz daha yavaşladık o konuda.
Replatforming'in büyük bir kısmını bitirdik diyebiliriz.
Çok iyi valla yani sıfırdan bir ekip oluşturmak, sıfırdan buraya adapte olmak.
Hele ki öncesinde oluşmuş bir şey işi de devralmış gibi ve buna adaptasyon oldukça zor konular.
Ama gayet de iyi kurtarmışsınız arkadaşlar.
Öncelikle tebrik ederim. Umarım bundan sonraki süreciniz çok daha kolay, çok daha güzel ilerler.
Ben biraz da projeyi merak ettim.
Projeden biraz bahsedebilir misiniz?
Tabii birazcık bahsedeyim.
Müşteri temsilcilerinin kullandığı ekranlarından sorumluyuz aslında ekipçe.
En çok kullanılan ekranımız da order ekranımız.
Bu ekranda genel olarak müşterilerimizin...
siparişleri ve onlarla alakalı olan bütün bilgileri görebiliyoruz.
Bir yandan da tren yol sizi dinliyorum altındaki bannerlardan ve anketlerden sorumluyuz.
Onlar da yine aynı şekilde bizim ekranlarımızdan oluşturulup yönetiliyor.
Bir yandan da arka taraftan İşte otomatik kupon tanımlama lojiğimiz var.
Örneğin bir sipariş çok mu gecikti ya da işte sipariş verildi ama tedarik edemedik mi?
Bu durumlarda farklı farklı durumlarda işte kriterlere bağlı olarak otomatik kupon tanımlayabiliyoruz.
Daha aslında birçok domenimiz var ama kısaca böyle diyebilirim.
Kupon tanımlama yapılıyor değil mi yani?
Kupon tanımlama... Evet yapılıyor.
Okey kupon şeyde atılıyor da bende.
Ürün alıyorsun.
Ama aslında stoğu bitmiş o ara.
Hani son kalanlardan almışsın.
İşte o ara sen de almışsın ama tedarik edilemiyorsa vs.
Onda çok fazla yapılıyor diye hatırlıyorum.
Bu arada çok fazla denk gelmiyor artık.
Ama aklımda benim orada kalmış yani.
Aynen. İşte orada farklı farklı rule setlerimiz var.
Mesela işte minimum bu kadar tutarın üstündeyse veriliyor vs.
vs. gibi farklı farklı kriterler var.
Onlara uygunsa veriliyor.
Süper. Güzel. Peki burada Özge sanırım sen...
Bu geçişte böyle ekipler arası geçişten gelenlerden biriydin.
Buradaki bu geçişte nasıl oldu?
Mesela şu anda Tansu birçok projeden bahsediyor.
Halbuki senin olayla hiç alakan yok yani.
Böyle bar platformda çok farklı şeyler yapıyordun.
Bir anda çok farklı bir yere gelmiş oldun.
Buradaki senin bu geçiş sürecin...
Bu nasıl oldu? Aynen dediğin gibi ben bambaşka bir dünyadaydım.
Telekomünikasyonda çalışıyordum.
Sonrasında Trendyol'a geçtim.
Ekip geçtikten sanırım bir ay kadar sonra ben de dahil oldum ekibe.
Onlar artık global platformdan tamamen buraya gelmişlerdi ve hani ufak ufak başlamışlardı ben geldiğimde.
Yine de bir ay geçmiş olmasına rağmen ben geldikten sonra da birlikte sorular sorduğumuz biz nasıl birlikte anlamaya çalıştığımız bir süreç oldu bence.
Hep birlikte kodu okuyup Tansun'da dediği gibi çizimlerini çıkartıp akışları anlamaya çalışıyorduk.
Toplu bir onboarding süreci yaşadık diyebilirim.
Ama bir de bireysel olarak benim yaşadığım ayrı bir onboarding vardı o dönemde.
Trend yolu olan onboarding.
O da aslında... Çok planlı ve programlı bir akıştı.
Çünkü Trendyol'un onboarding programları zaten herkesin dilinde.
Çok her şey planlı.
Gün gün, hafta hafta ne yapacaksın, Trendyol'la ilgili neler öğreneceğin sana bir liste halinde gönderiliyor neredeyse o kadar planlı.
İşte nasıl ofise gideceksin, ofiste hangi etkinlikler, hangi saat aralığında.
O yüzden aslında çok etkilenmiştim bu planı programı gördüğümde.
Bir de henüz işe başlamadan Vadim Mehmetcan, buradan kendisine de selam göndereyim.
Mehmetcan. beni aramıştım.
Ekip de neler yaptığından bahsetti.
Ekibin hangi işlerinin olduğundan bahsetti ve ekibin de yeni olduğunu orada söylemişti.
Ben de hani birlikte öğreniriz, birlikte görürüz diye söylemiştim.
Gerçekten öyle de oldu ama o gün Anlamıştım yani tren yol ben oraya gelmeden bu kadar hazırlık yapıyorsa tren yol ne kadar planlı programlı bir yerdir diye öyle de oldu gerçekten.
Evet ya özellikle bu body atanması olaylarında bende birçok body olmuştu.
Yani işte başlamadan önce iki hafta arıyoruz işte konuşuyoruz vesaire hem de tanışmış oluruz önden.
Hem de işte monitörler geldi mi işte her şey hazır mı bir sorun var mı gibisinden de konuşmuş oluyorsun.
Ve sonraki geldiği haftada yani o hafta ne yapılacağı işte ilk günden.
İşte komik çıkabilecek mi?
Bir şeyler yaptırtıyoruz vs.
İkinci gün şu ekiple tanışır.
Üçüncü gün şuradaki değeri götürürüz.
Şu ekiple tanıştırırız.
Bunu yaparız vs. gibi.
O haftayı komple planlıyorsun o kişi için.
Ve ona veriyorsun gibi bir şey oluyor.
O yüzden de o kişi için şey oluyor.
Kafası soru işareti çok az kalıyor.
Aynen öyle. Ben zaten ilk gün...
Pazar günüydü galiba yanlış hatırlamıyorsam.
Telefonum bambaşka bir numaradan çaldı.
Ben Mehmet Can işte body'nim gibi bir giriş yaptı.
Çok hani etkilendiğim bir durumdu.
Bu kadar böyle trend yolunun yeni gelen kişileri onboard etmek için özel bir body ataması.
Gerçekten keyifliydi bence.
Kesinlikle katılıyorum benim de.
Benim söyleyeceğim her şeyi Fırat zaten benden önce davranıp söyledi.
O yüzden ekstra bir yorum yapmayacağım.
Planlıydı falan diyormuş. Evet planlanmış.
Düşünmüş planlanmış.
Ben birazcık daha şeyi merak ediyorum.
Şimdi farklı bir yerden geçtiniz artık yeni bir ekipsiniz burada ve söylediğiniz kadarıyla aslında dokunduğunuz çok fazla nokta var.
Burada hangi domainlerle ve veya takımlarla yakın çalışıyorsunuz?
buna da ben cevap vereyim aslında belki de hangi takımlarla çalışmıyorsunuz demek Bizim ekip için daha doğru bir soru olabilir.
Çünkü Tansu'nun da söylediği gibi müşteri temsilcilerinin ekranları bizde.
Müşterilerin verdikleri siparişlerle ilgili birçok dataya ihtiyacımız var.
Siparişin bilgisi, statüsü, kargo durumu, ödemenin başarılı olup olmaması, müşteri fraud müşterisi mi değil mi, o siparişte kullanılan kuponlar.
Bir sürü data var aslında ulaşmamız gereken.
Yani saymaya devam edersem birçok ekibe dokunduğumuz anlaşılır ama öncelikle OMS.
T-desk, kupon, finans ekiplerini söyleyebilirim.
Zaten o emeslik diyorsan birçok bilgiyi de aslında ediniyorsun.
Peki burada aslında sizler müşteri temsilciyle beraber çalışıyorsanız anlık işler falan da geliyordur diye tahmin ediyorum.
Yani ne kadar planlı gidilebiliyor böyle bir ekipte tam olarak hakim değilim olayı ama mesela bizler işte konuştuğumuz ekiplerle de haftalık veya iki haftalık işte scramlı bir şekilde işte planlamalarla,
retrolarla vesaire götürerek işler ilerliyor.
Sizde de böyle ilerlenebiliyor mu?
Biz de aslında ilerliyoruz ya Scrum'la.
Bunun yanında bir de alertler için vesaire ayrı bir kanallarımız da var.
Ama genel olarak feature'larımız Scrum.
içerisinde geliştiriliyor.
O zaman bir haftalık sprintler koşuyoruz biz ekipçe.
Ama birazcık normalinden farklı koştuğumuz ya da yaptığımız şeyler var.
Örneğin işte normalde tek room yapılıyordu toplantı halinde.
İşte bütün ekip hep birlikte oturup rooming esnasında anlatılan taskları küçültüp teknik detaylarına girdiğimiz.
Onu mesela ortadan kaldırdık yerine.
Kişisel olarak tek roomlar yapmaya başladık.
Üstüne bir de collaboration session diye bir şey ekledik.
Kişisel olarak roomlarken herhangi bir sıkıntı yaşadığımızda o collaboration session'da konuşuluyor ve o kararlar veriliyor.
Ama hani böyle bütün ekip, bütün tasklara bakmayı bir kestik orada.
Bir yandan da eskiden tasklara puan veriyorduk.
Genelde de öyle yapılıyor zaten.
Puanlara göre sonra sprintlere alınıyor.
Direkt ortadan kaldırdık aslında.
Biraz böyle hani topluca efektif olmaya biraz vakitten kazanmaya çalışan bir ekibiz.
Şu anda da iyi gidiyoruz diyebilirim o konuda.
Anladığım kadarıyla kanban yapıyorsunuz.
Ne iş var onu alıyorsunuz.
İş bittikçe başka iş alıyorsunuz falan.
Kanban değil sprint yine bir haftalık.
Sprintin başında da hani taskları alıyoruz.
Planlayıp. Planningimiz var hala.
Belli bir sayıda task alıyoruz biz puana göre değil de şey yaptık gibi.
Scramban. Scramban aynen.
Scramban gibi geldi. Bilmiyorum şeye yine uyuyoruz.
Sprinti başlayıp bitişini bir hafif.
Yani şey biz de agile çalışıyoruz.
Sadece puanlama yapmıyoruz mu diyorsun.
Biz de agile'ız.
Güzel güzel. Yani kolay bir şey yöntemi değil bence yani iş paylaşma yöntemi.
Daha kolay olmamasını şundan dolayı söylüyorum.
Manaj etmesi oldukça zor bir yöntem.
Ama gördüğüm kadarıyla anladığım kadarıyla gayet iyi manaj ediyorsunuz.
Bu da ayrı bir başarı bence.
Tebrik ederim yani. Süper.
Teşekkür ederiz. Bir şey de bir ekleyeyim bu arada.
Puan vermiyoruz ama standartize ettik gibi task size'ları hep böyle 2-3 arası oluyor.
O şekilde alıyoruz gibi düşünebilirsiniz.
Anladım. Anladım okeydir süper.
Şeyi çok merak ettim yani bunu başından beri mi yapıyorsunuz?
Hani 6-7 ay 7 ay 8 ay her neyse yani yılbaşından beri ekip kurulduğundan beri yapıyor musunuz bunu ve memnun musunuz yoksa şey mi diyorsunuz?
Yani yaptık şu anda deneme aşamasındayız hani fena değil gibi mi?
Şu an deneme aşaması mı bu yoksa biz bundan memnunuz muyuz?
Böyle götürecek miyiz kafasında mısınız?
Tecrübenizi görmek için belki biz de yaparız belli mi olur?
Merak ettim. Yani başlangıçta aslında böyle değildi.
Normal Scrum, Poker'deki gibi işte puanlıyorduk.
Ama tabii toplantılar çok uzun sürüyor ve bu sefer taskı yapacak vakit bulamıyoruz artık.
Tek grubum da aynı şekilde çok uzun sürüyordu.
Böyle olunca planlama toplantısı...
Neredeyse yarı yarı yendi diyebiliriz.
Ama başlarda böyle değildi.
Puanlıyorduk. Sonra böyle bir yöntem izleyelim dedik.
Onu da şimdi arada toplantı atıp bu süreç işte bizim için faydalı mı, düzgün ilerliyor muyuz diye kontrol ediyoruz.
Peki analizini yapmadıysan puanı nasıl verebiliyorsun?
Tahmini mi veriyorsunuz? Yok da şöyle.
Normalde Scrum'da işte her bir task için Fibonacci serisindeki işte sayıları kullanarak puan veriyorsun.
Ama biz burada işte Tansun'da dediği gibi bir standart belirledik.
Aldığımız işleri 2-3 puana denk gelene kadar bölmeye çalışıyoruz.
Böyle olunca da aslında size'a ihtiyaç duymuyoruz.
Planning'de de belirli bir sayıda task alıyoruz.
Kaç tane task alacağımızı da şöyle belirliyoruz.
Velostiği ölçmek için işte Jira'daki estimation istatistiği var.
Onu issue count olarak güncelledik.
Oradaki data'ya göre de biz bir sprintte kaç tane task tamamladık diye bakıyoruz.
Sprint'e task alıyoruz. Yani orada kendimize bir hedef belirliyoruz.
Ben de tam aslında bu süreci nasıl analiz ediyorsunuz, nasıl yapıyorsunuz diye soracaktım.
Beril biraz açıkladı.
Şey sorayım, yani bu planlaması zor olmuyor mu sizin için sonrasında?
Yani işte işleri bölüyorsunuz ve bunları küçük parçalar halinde işte olacak şekilde oluşturup alıyorsunuz.
Daha sonrasında planlaması, birleştirmesi, bunların testi vs.
bunlar birazcık zorluk.
Bu yaratmıyor mu size? Küçük taskları böldüğümüz için testi daha kolay oluyor.
Development'ı da daha hızlı bitiyor.
Dediğim gibi sprint'e ne kadar task alacağımız da yani planlama aşamasında da aslında işte daha önceden kaç task tamamlıyoruz diye bakıyoruz.
Buna göre yeni bir hedef oluşturuyoruz.
Atıyorum 20 task yapıyormuşuz.
Hedefimiz de 23. O sprint 23 task alıyoruz.
Zaten sayıları hani 2-3 puan olduğu için bir daha puanına ya da boyutuna bakmamıza gerek kalmıyor.
O zaman aslında haftalık bir velocitenizden ziyade puan madde sayınız var.
Evet. Tam olarak öyle. Aynen.
Yani şey diyorsunuz ben haftada şu an sallıyorum 10 tane madde alıyoruz diyorsunuz.
10 tane maddeyi alıyorsunuz ama onları da mümkün olduğunca küçük hale getirmeye çalışıyorsunuz.
Çünkü aslında %100 küçük hale getiremezsiniz çünkü analizini tam yapmadınız ama tahmini olarak küçük parçalara bölüp teknik olarak.
Bunları parçalıyorsunuz. Burada pek beklenmedik şeyler çıkıyor mu?
Analizini yapıyoruz.
Yani bir tek kurum aşaması var.
O yüzden 2-3 puanla bölünmek sıkıntı olmuyor.
Okey. Sadece detaya o kadar fazla inmiyorsun diye anlıyorum.
Yani tek kurumda iniyoruz aslında.
Puan aşamasına atlıyoruz sadece aslında.
Sadece puan aşaması atlanıyor.
Okey. Buradan da aslında planlamadaki zamandan kar ediyorsunuz.
Aynen. Peki bu karın karşılığında bir puandan story point olarak feragat ediyorsunuz ya öyle diyeyim.
Tamam. Kafamda oluşturmaya çalışıyorum cümleyi.
Yani sonuçta bir şeyden kar ettiniz.
Bir zamandan kar ettiniz. Karşılığında da başka bir şey verdiniz.
Madde sayısını story pointini madde sayısını çevirdiniz.
Pros konusuna baktığınızda buna devam ederiz.
Memnunuz diyor musunuz? Çünkü en başta yapmadım demiştiniz ya.
Buna yeni geçtiniz aslında sonradan yani.
İkisini karşılaştırdığınızda ne düşünüyorsunuz böyle pros konusu gibi baktığınızda?
Burada sanki şöyle bir durum vardı.
Bizim planlamalarda da genellikle elimiz belli sayılara gidiyordu.
Sallıyorum mesela 2'ye 3'e gidiyordu çoğunlukla.
O yüzden çok uç case'lerde çok daha büyük task'lar çıkıyordu.
Benzer bir noktada olduğumuzu söyleyebilirim ben şu an için.
Ama kızlar belki başka yorum yapmak da istersiniz diye size de top atayım.
Hem fikirdeyim ben de ya.
Genel olarak zaten 2-3'deydik.
Üstüne bir de planning de tek tek üstünden geçerek birazcık vakit kaybı gibi geliyordu.
Bir deneyelim dedik. Şimdilik iyi gidiyor ama daha 2-3 ay oldu.
Sonrasında belki tekrar bir üstünden konuşuruz.
Yani yeni bir yaklaşım gibi.
Ben ilk defa duydum en azından.
Bana yeni geldi ama bence...
Gayet mantıklı yani. Bunun haricinde başka süreçte yaptığınız iş, yani işe geçmeden önce, hani geliştirme aşamasından önce yaptığınız başka pratikler, başka toplantılar ya da alıştırmalar oluyor
mu? Birkaç pratiğimizden ben bahsedeyim bu akışla ilgili.
Sprintlere başlamadan önce az önce tek grubundan bahsettik.
Oradaki tek grubu kişilere esayin ediyoruz.
Tek gurum yapılabilmesi için gurum ilk sırasında.
Ardından kişiler kendi üzerlerine assign olmuş taskları gurumluyorlar.
Bir yerde takıldığımız noktada da bu collaboration session'ından bahsetmiştik.
Orada girip birlikte beyin fırtınası yapıyoruz.
Bu sayede de ekibin aslında ekip ruhu güçlenmiş oluyor.
Birlikte beyin fırtınası yapmak bize iyi geliyor.
Onun haricinde sprint'te...
Taskların to-do'da olması ve herkesin to-do'dan task alıp bir şekilde ilerletiyor olması da bizim ekip ruhumuzu güçlendiriyor.
Çünkü bir taskın devam edebilmesi için bazen öbürüne ihtiyaç oluyor.
Hızlı bir şekilde to-do'dan alıp hem know-how'ımızı da bütün domenilerde arttıracak şekilde taskları alıp yapıyoruz.
O noktada güzel oluyor. Bir de ekibimize şu an yeni bir Scrum Master ekledik.
Scrum Master'ımız da sprintin olabildiğince hızlı akmasını sağlıyor.
Sprint'in içinde ortaya çıkan problemleri çözmek için ekibe destek oluyor.
Scrum Master'ı da dönüşümlü olarak değiştirmeyi planlıyoruz.
Bir de Sprint'in içinde de bir şeyler yolunda gidiyor mu gitmiyor mu diye arada Sprint akışlarımızı konuştuğumuz küçük toplantılar yapıyoruz.
Yine orada da beyin fırçası yapıyoruz.
Gelişim yönlerimiz varsa onları görüp daha iyi ulaşmak için aksiyonlar alıyoruz.
Ya da belki gelişim yönümüz yok.
diyorsak birbirimizi tebrik ediyoruz.
Aslında sürekli olarak...
Birbirimizi tebrik ediyorsun. Tebrikler deyip kapatıyoruz.
Gelişim yönlerimizi görüp aksiyonlarımızı alıyoruz.
Bu da bizim sürekli aslında arkaya bakıp neyi iyi yapıyoruz, neyi kötü yapıyoruz, neyi geliştirebiliriz diye düşünmemizi sağlıyor.
Böyle anlatabilirim.
Peki burada biraz daha teknik kısma geçeceğim.
Şu anda bir gelişimler yapıyorsunuz ve bu geliştirmelerin Teknolojileri tam olarak neler?
Çünkü çok fazla ekiple iletişiminiz de var.
Burada herhalde rezervisi falan da öncelikle ya da monitoring.
Çünkü müşteri hizmetlere ulaşamadığında o arabayla konuşurken ulaşamadığında herhalde sonuç güzeldir diye tahmin ediyorum.
O yüzden herhalde veri bileti en öncelikli işlerden biridir diye tahmin ediyorum.
Buradaki kullandığınız teknolojilerden falan bahsedebilir miyiz?
Özellikle ekibi ve spesifik kılan çalışmalar varsa.
Ben Frontend tarafından başlıyorum.
Frontend tarafında React kullanıyoruz.
Kısa bir süre önce de React 18'e geçiş yaptık.
Projemiz hem standalone hem de Microfrontend olarak çalışabiliyor.
Microfrontend mimarisi için Module Federation kullanıyoruz.
UI kütüphanesi olarak internal bir kütüphanemiz var, TxComponents diye.
Onu kullanıyoruz. Yeni bir feature eklemek istediğimizde o kütüphanenin kontrolü bizim altımızda olduğu için aslında yeni bir geliştirme yapmak çok hızlı oluyor.
Bir de Polyglot diye bir internal yapımız daha var Trendyol'da.
Onu da aslında dil desteği için kullanıyoruz.
Proje bazlı key'leri ve çevreleri yönetebildiğimiz bir panel sunuyor bize.
Onun dışında UI testlerini QA Engineer ile beraber yazıyoruz.
Orada Cypress kullanıyoruz.
BFF katmanında Go ve Node.js kullanıyoruz.
Paket yöneticisi olarak da NPM kullanıyoruz.
Frontend tarafı böyle.
Backend için Özge sana atayım istersen.
Tamam. Aslında Tansu az önce bahsetti, bir replatforming sürecindeyiz.
Ama bu replatforming sürecinde de servislerimizin bazılarını taşıyoruz, bazılarını yeni servislere çıkartıyoruz.
Mikro servis mimarisi kullanıyoruz aslında.
Bazı mikro servislerimiz monorepo dediğimiz yapının altında, bazıları da ayrı servisler halinde yazılı.
Replatforming sürecinde aslında servislerimizin performansını artırmaya çalışıyoruz, ayrıştırmaya çalışıyoruz.
Bazı alakasız olan işleri Tek servisi de altından ayırıp farklı servislere bölmeye çalışıyoruz.
Bunları yaparken de aslında kullandığımız bir dil olarak sınırımız yok.
Kotlin ve Java kullanılarak yazılmış mikro servislerimiz var.
Go kullanılarak yazılmış konektörlerimiz var.
Zaten Trendyol içinde de vardı.
Backend'de de genellikle Kafka ile event driven bir mimar çiziyoruz.
Bunu yaparken de Outbox pattern oldukça fazla kullanılıyor bizim ekipte.
Sipariş arama ekranlarımızdan bahsetmiştik.
Oralarda Elasticsearch kullanıyoruz.
Database'lerimizde de PostgreSQL'de tuttuğumuz datalarımız da var ama çoğunlukla Couchbase'de tuttuğumuz datalarımız var.
Couchbase'in Eventing özelliğini kullanıp servislerimiz için alertler tanımlayabiliyoruz.
Kod kalitemizi kontrol etmek için sonar köpü kullanıyoruz.
Pandora'nın Trendyol için de geliştirilmiş bir uygulama zaten.
Bunun içindeki Observability tabından otomatize alertler tanımlıyoruz.
Yine Trendyol içindeki on-call uygulamasına entegre ediyoruz.
Service maturity metriklerimizi takip ediyoruz.
Aslında backend'de özetle böyle olduğunu söyleyebilirim.
Oradaki connector'lar dediğin DSP projeleri mi?
Aynen, DSP projelerimiz var.
Süper, o projeler çok iyi.
Biz de bir süre önce süredir kullanmaya başladık.
Bayağı geliştirmeden kar falan da ediyor.
Altta reklamını da yapalım. GitHub'dan, altından GitHub'dan bakabilirsiniz GoDSP projelerine.
Kısaca bahsetmek gerekirse Couchbase'deki...
DCP'lerdeki o protokol ile değişimleri alıp işte Elasticsearch'ı Kafka'ya falan atmanıza yarıyor.
Geliştirmeden falan kar ediyor yani.
O konuda güzel teknik reklamlar falan diye böyle.
Süper. Gayet güzel teknolojiler valla.
Yani frontend tarafında Puzzle.js de kullanılabilir bu arada.
Onu da ben de araya bir frontend reklamı sokacağım.
Herkes bir şey yapıyor değil mi? Evet.
Puzzle.js, mikro frontend çözümü olarak Puzzle.js kullanılabilir diyeyim.
Peki yeni bir feature çıkıyorsunuz, yeni özellikler getiriyorsunuz, yenilikler getiriyorsunuz falan.
Bunlarda illa ki problemler yaşanıyordur.
İlla ki hepimizin günlük hayatta yaşadığımız şeyler.
Bu problemleri nasıl handle ediyorsunuz sprint içerisinde?
Okey, bundan ben bahsedeyim isterseniz.
Dediğim gibi yeni featureler çıktıktan sonra ya da sprint içinde bazı geliştirmeler yaptıktan sonra biz de alörtler yaşayabiliyoruz, sorunlar yaşayabiliyoruz.
Bunları öngörebilmek için Pandora ve Nevrelik üzerinde otomatize alörtlerimiz var.
Müşteri temsilcilerinden anlık olarak gelen bazı alörtler olabiliyor.
Bunları da bir Slack kanalı üzerinden alıyoruz.
Bu Slack kanallarından bir tanesi International siparişleri için, bir tanesi de Türkiye ve Azerbaycan siparişleri için.
Ekibe ilk geldiğimizde bu kanallara gelen alörtler hepimizin çok dikkatini çekti.
Çünkü buraya gelen alörtler şöyle oluyordu.
Mesela bir müşterinin bir siparişinin sadece bir tane statüsünde hata var diyelim.
Gelen alört şu şekilde, sipariş statülerinde sorun var.
Sonra o gün Oncall'daki olan arkadaş, ya bütün siparişlerde mi bu sorun var?
Hangi statüde sorun var?
Hangi shipment numarasıyla alakalı, hangi teslimatla alakalı sorun var?
Bir sürü data almak için o alörtü yazan kişiyle iletişim kurmak zorunda kalıyordu.
Yani bir format yoktu aslında.
Sonrasında bunu daha kolay daha etkin şekilde nasıl alırız diye bir kafa yoğurduk.
Slane Workflow diye bir özelliği varmış onu keşfettik.
Slane Workflow özelliğinde o kanala gelen mesajları kapattık.
Bir tane workflow formu oluşturduk.
Buraya artık bir sorun yaşayan müşteri temsilcisi ya da onlarla ilgilenen ekip liderleri.
Bir form doldurup gönderiyorlar.
İlgili formun içinde de ilgili sipariş numarası, ekran görüntüsü, yaşanan hata, hangi saat aralığında aldı, tüm müşteri temsilcilerinde mi yaşandı bu sorun yoksa spesifik bir yerde mi yaşandı.
Bu tarz dataları sağlıyor bize.
Dolayısıyla Oncall'daki arkadaşın da işini kolaylaştırmış oluyoruz.
Bu bizim alertleri çözmemiz için de faydalı bir feature oldu diyebiliriz.
Oncall kritik ya.
Oncom çok önemli.
Yani ekipten ekibe tabii değişiyor.
Bazı ekiplerde hiç nöbet sistemi olmayabiliyor.
Bazı ekiplerde oluyor.
İşte örneğin dizilede bu tarafında 724 çalışan bir operasyon olduğu için bir nöbetçimiz her zaman olur.
İdeali tabii son olmamasını bekleriz ama bir şeyler oluyor.
Yani database'de olur, herhangi bir yerde olur vs.
Ve Oncom'un gerçekten o anda o desteği vermesi gerekir.
Bazı ekiplerin işte... Bir kısmı servis hizmeti verdiği için hani özellikle şirket için internal bir tool da vesaire onkola daha yoğun olabiliyor.
Bazen ikisi de çok az oluyor.
Sizin ekipte mesela müşteri hizmetleri olduğu için onkolun hani önemi ve yaptığı işte bu işe ayırdığı zaman daha fazla diye tahmin ediyorum ama emin değilim sizde nasıl işliyor bu işler?
Şöyle ben cevaplayayım.
Bizde genellikle bekent ekibinden bir asil bir de yedek nöbetçi oluyor.
İşte onkol dediğimiz kişiler o nöbetçiler aslında.
Asil nöbetçinin İhtiyacı olduğu anlarda yedek nöbetçi de destek verebiliyor.
Ben bir gününden bahsederek anlatayım.
Kafamızda bir şeyler canlansın diye.
Bizde Slack kanalları var.
Sistemsel bir sorun yaşadıklarında oradan bize ulaşıyorlar ve ona da Oncall'daki arkadaşlarımız bakıyor.
Önceliğimiz orası.
Müşteri temsilcilerinden ve Nibirlik üzerinden gelen alertleri aslında inceleyip çözmeye çalışıyor.
Bazen işte sorun kendi servislerimiz ya da frontend kaynaklı oluyor.
Bazen de birlikte çalıştığımız diğer ekiplerden de kaynaklı olabiliyor.
Eğer onkoldaki arkadaşın kendi kendine çözemeyeceği bir sorun ise yaşanan problemi incelesinler diye ilgili ekibe yönlendiriyor.
Daha sonra da bunun takibini yapıyor.
Onkoldaki arkadaşımızın bir görevi daha var.
O da aslında o gün...
İçinde gelen Merch Request'lerin CodeReview'unu yapmak.
Ama burada tabii ki önceliğimiz alertler olduğundan eğer CodeReview yapacak vakti yoksa da backend ekibinden destek alabiliyor.
CodeReview ilk defa duydum ya.
Yani on-call, CodeReview'den kişi mi oluyor?
Nasıl oluyor? Yoksa sadece on-call mı Review ediyor?
Ya bu da biraz aslında sprint sürecini iyileştirmeye çalışırken getirdiğimiz bir şeydi.
Baktık core review kolumunda biraz fazla bekleyen tiketler oluyordu.
Öyle çok fazla hızlı ilerletemiyorduk taskları.
Dedik ki işte on koldaki kişi boş buldukça alert gelmedikçe işte yoğunluk sonuçta her gün aynı değil.
Çok yoğun olmadığı bir günde bir yanında core review'e baksın onları da hızlıca akıttıralım.
deyip öyle bir şey getirmiştik.
Daha hızlı aktığını gördük.
Hani şey olmamış oluyor biraz normal developer olarak.
Her an bölünmeye müsait olmayabildiğin için her an kod review'a bakamıyorsun ama Oncall'dayken zaten bölünmeye çok hazır oluyorsun.
O gün içerisinde bölüneceğini önden biliyor oluyorsun.
Bir yandan da özden kod review'ları için vakit ayırabiliyor oluyorsun.
Özge senin de eklemek istediğin bir şey var mı bu konuda?
Sadece Oncall'a da yıkmıyoruz burada.
Hep birlikte baktığımız bir süreç oluyor ama genellikle Oncall daha Tansun'da dediği gibi birçok o gün farklı kanala baktığı için PR kanalına da bakıyor.
Orayı da takip ediyor. Yetişemediği ya da yapamadığı durumlarda ya da hani belki başka birine review ettirmek istiyoruzdur.
Etiketleme yöntemini de izliyoruz.
Zaten size güzel bir şekilde PR kanalına PR açıldı gibi bildirimler düşüyor.
Ama onun haricinde etiketliyoruz.
Onkoldaki bakıyor. Aslında bir dengeye oturttuk diyebilirim.
Süper ya güzelmiş yani. Birine review için öncelik veriliyormuş.
Eğer o kişi dediğin gibi belki sprint'e daha az giriyordur ve sadece işte on kola zaman ayırdığı için zaten sprint'ten zaten bir çıkıyor kafa olarak.
O yüzden review etmesi daha kolay oluyor diye anladım.
Faydası var tabii ki.
Valla bunu bizim ekiplerde yapsak birazcık kaos oluşabilir sanırım.
Çünkü gün içerisinde o kadar çok merge request geliyor ki yani on call on'la mı uğraşsın, log'la mı uğraşsın gerçekten on call için sıkıntı bir durum oluşabilir.
Ama dediğimiz gibi handle edilen bir süreçte oldukça güzel bir pratikmiş.
Ben de beğendim. Biraz daha şey tarafından bahsedelim istiyorum.
QA süreçleri sizin ekipte...
Sizin takımda QA süreçleri nasıl ilerliyor?
Bir iş alındıktan sonra testi nasıl yapılıyor?
Nasıl ilerletiliyor?
Tabii. Bekenden başlayayım isterseniz bu sefer de.
Zaten normal iş akışı başlangıcı to do, in progress, PR dedik.
Sonrasında başlıyor aslında.
O core review bittikten sonra merge'ı aldık ve stage'e çıktık.
O esnada artık ready for test kısmına gelmiş oluyor taskımız.
QA enjinyerimiz oradan taskları alıp Testine başlıyor.
Bu süreçte işte herhangi bir sıkıntı bulursa test fail de atabiliyor.
Ya da bulmazsa da bunların screenshotlarını alıp taskın altına ekliyor.
Sonrasında da UAT kolumuna...
Burada şöyle bir ayrımımız oluyor.
Teknik tasklar için UAT kolumundan direkt geçiriyoruz tasklarımızı ve Ready for Deploy'a geçiyor.
Ama teknik olmayan, biznes tarafından bir onayı gerektiren tasklar da UAT kolumunda bekliyor.
Product Manager'ımız tarafından bir kontrol ediliyor.
Sonrasında devam ediliyor.
En sonunda Ready for Deploy'dan taskın sahibi taskı alıp canlıya çıkıp dana çekiyor oluyor.
Ben de Frontend tarafındaki süreçten biraz...
Orası bir tık farklı çünkü.
Frontend tasklarını feature branch bazlı test edebilmek için Trendyol'da internal olarak kullandığımız branch app adında bir yapımız var.
Merge request açıldıktan sonra feature branch branch app'a düşüyor.
Yani şöyle söyleyeyim branch app üzerinde Feature branch'ler listeleniyor ve her commit sonrasında ilgili branch build oluyor otomatik olarak.
Önceden kod review aşamasından sonra branch'i master'a merge ediyorduk.
İşte stage'e deploy ediyorduk.
Testler stage'de yapılıyordu.
Ama bunlar da deploy'ların birbirini bloklamasına sebep oluyordu.
Çünkü sonradan mörç edilen taskın testi bitmiş ama proda çıkamıyor.
Çünkü ondan önce mörç edilenin henüz testi bitmemiş gibi durumlarla karşılaşıyorduk.
Artık QA, kod review'dan testi attığımızda QA engineer testlerini branch up üzerinden yapıyor.
Böylece bloklanmamış oluyoruz.
Bundan sonraki süreç backend ile aynı.
Sadece task ready for deployment adımına geldiğinde biz master mörç ediyoruz.
Böyle de özetleyebilirim.
Süper. Aslında orada bir...
Zaten akış varmış dediğin gibi.
Biz de zaten direkt bu yöntemi uyguluyorduk.
Tek ufak ufak dediğim gibi o shift left'te bahsetmek istedim.
Çünkü zaten şirketteki çoğu yerde bu akış gerçekten çok iş görüyor.
Yani geçişler konusunda olsun, otomasyonlar konusunda olsun.
Zaten çünkü burada bize GitHub'daki ekipler olsun, TVP ile beraber zaten akışlar değişmeye başladı.
Onlarla da bir bölüm çekmiştik.
O yüzden direkt bahsedebiliyorum bölüm.
İlgili olanları bekleriz ADP bölümümüze.
Bu geçişlerle birlikte aslında...
ekipler arasındaki farklılıklar da azalmaya başladığı gibi.
Şimdi her bölüm bir ekiple bir konuşurken artık şeyi az çok anlayabiliyoruz.
Ortak noktaların işte ne olduğu ve ortak platform ekiplerimizin sayısı arttıkça bizim ekipler arasındaki böyle infraksajçıları daha da ortaklaşmaya başladı.
Böyle daha gözle görünür olmaya başlıyor diyeyim.
Buradan aslında biraz da artık finale doğru yavaş yavaş bağlıyoruz.
Çünkü QA'lerden, teknik şeylerden, ekipten vesaire her şeyden bahsettik.
Finale aslında daha güzel bir konuyla.
Burada ekipçe sizin yaptığınız, remote çalıştığımız için herhangi bir etkinlik olur.
Ekip gelişiminiz için yaptığınız şeyler varsa bunlar olur.
Çünkü zaman yönetimine dikkat ediyorsanız işte kişisel gelişiminiz için ayırdığınız bir zaman vardır diye tahmin ediyorum.
İşte bunları nasıl yaparsınız.
Ayrıca şey ekipleri var mesela örnek olarak vereyim.
Beraber restorana gidip yemek yiyen gurme ekipler var.
Mangal yapan ekipler var. Direkt mangal special.
Çok farklı şeyler var.
Sizler de böyle yaptığınız şeyler var mı?
Ben teknik olarak nasıl kendimizi geliştirdiğimizden kısaca bahsedeyim.
Düzenli olarak Tech Friday yapıyoruz ekip olarak.
İşte herkes ilgi alanına göre projeyi de fayda sağlayacak konularda araştırma ya da piyasi yapıyor.
Ayrıca tribe bazında lunch and learn oturumları var.
Ekipler yaşadıkları problemleri ve bu problemleri nasıl çözdüklerini anlatıyor.
Böylece aslında biz de orada kendi sorunlarımızı veya çözümlerimizi paylaşabiliyoruz.
Böylece benzer sorunlarımızı diğer ekipler nasıl çözüyor onu görmüş oluyoruz.
Bu sayede de aslında birbirimizin gelişmene destek olmuş oluyoruz ve ekipler arası işbirliği artmış oluyor.
Eğlence kısmını Tansu sana bırakayım.
Tansu eğlence'den mi sorumlu?
Eğlence mi Tansu falan.
Eğlence'den sorumlu bakanımız Tansu.
Anlatayım ufaktan.
Şimdi genel olarak ekibimiz aynı şehirde değil maalesef.
Bayağı bir dağılmış durumdayız Türkiye'nin her yanına.
O yüzden anlatacağım çoğu aktivite böyle online yaptığım şeyler olacak.
Dediğim gibi zaten kağıt yapıyoruz.
Cuma günleri her hafta bir tekrar eden seslimiz oluyor oyun game sesini.
Her hafta yapabiliyor muyuz?
Hayır. Hani yoğunluktan dolayı arada bir iptal oluyor ama çoğunlukla yapıyoruz.
Yapmaya da çalışıyoruz. Önem verdiğimiz bir şey.
Oralarda işte gelip...
Bir arada işte Code Names oynuyoruz, Joyo oynuyoruz, Smash Kart oynuyoruz, Code vs.
Joyo'yu artık oynamıyoruz çünkü Özge sürekli kazanıyor.
Zengin almış bütün ürünü.
İşte onun dışında çalışırken böyle topluca Zoom'da takılmaya çalışıyoruz.
Herkes bir tane breakout room'a falan dağılıyor oluyor.
Başka toplantı olmadıkça tabii.
Böyle olunca hem hani iş yaparken pratik oluyor tabii.
Bir desteğe falan ihtiyacımız olduğunda direkt gidip ulaşabiliyoruz.
Ama sosyal açıdan da çok güzel oluyor.
Ondan da faydasını çok gördük.
Hani ne bileyim 15 dakika bir böyle kahve molasına ihtiyacım oldu.
Gidiyorum birbirinin kapısını çalıyorum.
Gel benle. Kapı önünde bir...
Tabii içeri. Aynen.
Öyle. İşte yüz yüze de görüşüyoruz tabii ara sıra.
Orada da genelde bir böyle ofis günüyle birleştirip akşama yemek tarzında bir aktivite oluyor.
Ama bu listeyi daha çoğaltacağız diye umuyorum.
Daha hani 6 aylık bir ekibiz.
Vaktimiz var şu aralar. Şey diyorsun büyük planlarımız var.
Aynen öyle. Süper ya.
Daha çok şey çıkacak gibi ben senden umudum var.
Fark ettim onu yani. Potansiyel çok belli.
İnşallah. Çok iyi. Süper.
Arkadaşlar çok teşekkür ederiz geldiğiniz için.
Çok güzel bir sohbet oldu. Bayağı da aktı.
Tekrardan geldiğiniz için çok teşekkür ederiz.
Biz teşekkür ederiz.
Teşekkür ederiz.
Sağ olun efendim. Teşekkür ederiz.
Bugünkü bölümümüzün yanında yeni bir podcast serimiz de var.
Trendyol Talks. adı altında.
Direkt olarak onları da dinleyebilirsiniz arkadaşlar.
Trendyol içerisindeki kültürü anlatmaya başladığımız ve çok eğlenceli, çok güzel bölümlerin olduğu bir podcast serisi Trendyol Talks.
Onun linklerini de podcast bölümümüzün içerisindeki linklerde bulabilirsiniz diyelim.
Evet bu bölümde arkadaşlar Customer Service ekibiyle beraberdik.
55. bölümümüzde.
Bir sonraki bölümde görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.