Konuklar: Fadime Özdemir, Mehmet Reha Bayar, Selim Özdemir
99. bölümümüzde konuğumuz Customer Order Experience 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 Salon Order Experience ekibinden Fatih Han.
Ben Storefront Web Search ekibinden Ceyniz.
Teknoloji ekiplerini tanıdığımız ve süreçsel teknolojiler gibi konuları konuştuğumuz
Selam Ekip podcast serisinin 99. bölümünde OMS'den Customer Order Experience ekibiyle birlikteyiz.
Bu ekibi tanıyıp kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Bugün Coex ekibinde bizimle Reha, Selim ve Fadime birlikteler.
Sizi biz biraz tanıyalım mı?
Selamlar, ismim Selim.
Bir yıldır Coex ekibinde çalışıyorum.
Daha önce de OMS ekiplerinde görev almıştım.
Trend yoldaki beşinci yılım.
Herkese merhaba, ben de Fadime.
Ben de yaklaşık dört buçuk yıldır Trend yoldayım.
Dört yıl Storefront'ta, beş aylık da OMS'deyim.
QA olarak çalışıyorum.
Selamlar, ben de Reha.
Yaklaşık dört yıldır ben de Trend yolda.
Backend Developer olarak çalışıyorum.
Bunun ilk 1,5 yılı Tdesk ekibindeydim.
Son 2,5 yılı da Coex'teyim diyebilirim.
Tekrar hoş geldiniz arkadaşlar.
Bugün güzel bir bölüm olacağına inanıyorum.
Şimdi sizin takım Customer Order Experience fakat kısaltılması Coex diye geçiyor anladığım kadarıyla.
Şöyle başlayalım isterseniz.
Coex takımının Trendyol'daki rolü tam olarak nedir?
Nelere odaklanıyorsunuz? Ne üretiyorsunuz?
Tam olarak ne yapıyorsunuz?
Cengiz dediğin gibi yani takımın uzun ismi aslında Customer Order Experience.
Yani adından da anlaşılacağı üzere müşterilerimizin aslında siparişle alakalı olan bütün deneyimine aslında üstlenip orada elimizden geldiğince daha iyiye götürmeye çalışıyoruz.
En önemli aslında üstlendiğimiz projelerden bahsedeyim.
Müşterilerimizin aslında mobil uygulamadan veya web sitesinden siparişlerim sayfasına girdiğinde orada siparişlerini görüntüleyebilmesi, bunlar arasında arama yapabilmesi, aynı şekilde görüntülediği siparişlerin detayına girip sipariş detayına bakabilmesi gibi sayfaların aslında datasını OMS ekiplerinden, diğer OMS ekiplerinden toplayıp klantlara biz server ediyoruz.
En büyük sorumluluklarımızdan birisi bu diyebilirim.
Bir diğer yine önemli konu da yine siparişle alakalı aslında iletişimler.
SMS, mail, push hatta yakın zamanda gelen WhatsApp üzerinden,
IM iletişimlerinde yine bizim takımımız üzerinden müşterilerimize gönderiyoruz.
Siparişle ilgili olan hareketlerini bu noktada da sipariş deneyimini,
müşteri deneyimini en iyi hale getirmeye çalışıyoruz diyebilirim özetle.
Bir de ek olarak şeyden bahsedeyim çok kısa.
Bunun dışında yani bu tabii müşteriye sunduğumuz taraf içerideki bazı takımlara da ihtiyaç olan takımlara bu müşterilerin sipariş datasını sağlıyoruz.
Yani müşteri deneyimi ekiplerimize veya support ekiplerimize aynı şekilde depo ekiplerine de sağlıyoruz.
Ama görünen kısımda ilk söylediğim iki kısım en kritik nokta bizim için.
Süper müşterilere hizmet eden bir takım karşımızda.
Peki takımınızın dağılımı nasıl? QA, developer vs. hangi rolleri barındırıyor?
Burada da ben anlatayım. Şu anda toplam 6 kişiyiz ekipte. İlk developer 1 QA, 1 PM, 1 lead'den oluşuyor. Biraz da rollerden bahsedeyim. Hatta developer'dan bahsedeyim ilk başta. Tasarım aşamasında aslında geliştirmeyi ve canlıyı almaya kadar birçok aşamada rol alıyoruz.
Tabi bu süreçlerde developerlar kendi başına hareket etmiyor. Ekip içinde birçok kararı birlikte alıyoruz. Örneğin tasarım aşamasında business kapsamını derinleştirme ve netleştirme de lead ve PM'lerde teknik problemlerde ise developerlar daha yoğun çalışıyor. Test aşamasında da ise kriterlerin netleştirilmesi, testlerin verifay edilmesi bu aşamalarda yine QA arkadaşımızla birlikte çalışıyoruz.
Monitoring ve support konularımız da var tabi bunların dışında.
Burada da aslında yine ekip olarak on ediyoruz tüm sürece diyebilirim.
QA tarafı için de yine daha derinlemesini aktarım için de Halime'ye bırakayım topu.
Teşekkür ederim.
Aslında Selim dediğin gibi QA olarak da biz baştan sona tüm süreçlerin içine dahil oluyoruz.
İşte gerek challenge etme konusunda olsun, gerekse review'inde olsun, gerekse monitöründe.
Aslında baştan sona her aşamada varız.
Ekstra burada sadece QA olarak diğer ekiplerin test supportlarına destek oluyoruz.
Clientların orderla ilgili desteğe ihtiyacı olursa ek olarak bir de OMS için de test ekibimiz var.
Orada daha yakından çalışıyoruz.
Clientların ve bize bağımlı tüm ekiplerin süreçlerini iyileştirmek için.
Genel olarak böyle toparlayabilirim ben de QA olarak.
Bunlara ek bir de leadimiz var ve product manager arkadaşımız var.
Onların da teknik rolünden kısaca bahsetmek gerekirse aslında dışarıdan gelen işleri daha high level'da değerlendirip oradaki biznesleri netleştirme noktasında onlar daha aktif oluyorlar.
Ayrıca biliyorsunuz trend yolda aslında ufak bir geliştirme bile çok fazla takımımız var.
Çok fazla yere dokunabiliyor.
Yeri geliyor 5 takıma, yeri geliyor 15 takıma etkileyebiliyor.
Ve bu noktada diğer takımlarla olan iletişimi kurma, buradaki biznes konsörlerini ve teknik konsörleri daha high level'da konuşma görevi de daha çok onlarda oluyor diyebilirim.
Süper. Güzel aslında oturmuş bir yapı var ve bu yapı üzerinden güzel işler yapılıyor.
Topu ile alakalı konuşurken, takımla alakalı konuşurken şeyi de baştan bir sormak istiyorum.
Rotasyon tarafını.
Böyle rotasyonla gelen ekip üyeleri oldu mu sizin tarafa?
Rotasyon süreci nasıl ilerliyor?
Adaptasyon vesaire.
Onboarding nasıl oluyor?
Bunlarla alakalı biraz bahsedebilir misiniz?
Orada ben devralabilirim.
Aslında tüm ekip rotasyonla oluşmuş desek tam yerine oturur sanıyorum.
Ama en yeni üyesi ben olduğum için ben başlayayım.
Sonra arkadaşlarımı topa atarım.
Ben de aslında tam 1 Nisan'da Coex ekibine katıldım Storefront ve Order ekibinden.
Aslında Trendyol olarak tüm ekiplerce rotasyonu çok önemsiyor ve aslında Trendyol içinde de bu yapı çok destekleniyor ve teşvik için kariyerci alında bir tane böyle flowumuz var.
Özellikle hem kendimiz için hem bence Trendyol için çok avantajlı.
Çünkü ben client'tan geldim backend ekibine.
Keza backenddeki arkadaşım da benim yerime storefront'a geçti.
Aslında karşılıklı değişim yapmış olduk.
Ben client gözünü servise, o da servis gözünü client'e götürmüş oldu.
Hem kendimiz için bir challenge hem de sistemleri geliştirmek ve user'ın deneyimini iyileştirmek için
ve keza teknik süreçleri de iyileştirmek için bence harika bir fırsat oldu.
Ben şahsen burada 5 ayda böyle client'ların işlerini iyileştirmek için ve user gözünü buraya getirmek için daha çok böyle bu gözle bakar oldum.
Yani burada diğer tarafta hep user gözünden bakıyorduk.
Hiç servisi düşünmüyorduk.
Onun dışında genelde işte farklı ekip mindsetlerini bir araya getiriyoruz.
Birbirimizle pratiklerimizi paylaşıyoruz vs.
Bence çok kıymetli bir süreç.
Benim adıma da öyle oldu şahsen.
Selim'le Reha da rotasyonla gelmiş.
Onlara pas atayım ben.
Onlar da deneyimlerini ve onboarding süreçlerini, adaptasyon süreçlerini paylaşsınlar.
Benzer oluyor zaten.
O yüzden onları bırakayım.
Olur. Ben sözü alabilirim.
Ben de rotasyonla geldim.
İlk başta söylemiştim.
Yaklaşık iki buçuk yıl önce.
Diğer arkadaşlarım rotasyon yaptığı için bir anda en eski ben kaldım takımda gibi oldu.
Fadime zaten anlattı.
Yani rotasyon kültürü, trend yolun kültüründe olan bir şey ve çok fazla benefiti var.
Hem kişilere hem kuruma.
O anlamda ben de rotasyon yapmıştım ve onboarding sürecinde de aslında içerideki projelere onboard olmak için bir excel oluşturmuştuk.
Hem projelerin aktarımı hem gerekse business logiclerin aktarımı olsun genel aktarımları orada listelemiştik.
Ayrıca o zamanki takım arkadaşlarım sağ olsunlar ekstra talep ettiğim şeyler varsa hani onları da sordu onları da not aldık.
Onlar için de sessionlar planladık.
O yüzden güzel, smooth ve keyifli bir onboarding sürecim oldu.
Bu da tabii ki ekibi adaptasyonumu ve katkı yapmamı hızlandırdı diyebilirim.
Deyip topu Selim'e atabilirim.
Benim de aslında otasyonum diğer arkadaşlarımla benzer.
Özellikle OMS ekiplerinde daha önce çalıştığım için,
Coex ekibine geçişimle beraber aşinalığım da vardı.
Ancak tabii bu domeninde farklı problemler, farklı yüzeydeki sorunlarla aslında
daha böyle farkında olmuş oldum.
Özellikle de Reha'da sağ olsun adaptasyon sürecimi de kolaylaştırdı.
en meçhul olarak en nasıl mutlu
geçtiklerinde açımdan diyebilirim özellikle.
Reha hepimizin badisi.
Evet.
Ne demek ki her zaman?
Ne zaman isterseniz. Güzel.
Bayağı tralyonun rotasyon kültürünü
yansıtan bir takım. Ben de yan ekipten
aynı şekilde rotasyonla
gelmiştim bu yan ekibe. OMS'de
rotasyon bayağı popüler. Gelirim
şimdi OMS'de değil çok core bir tribe'dasınız.
Haliyle birçok ekiple çalışma ihtiyacınız
doğuyor. Bu kadar farklı takımla
çalışmak zor oluyor mu? Bu süreçleri nasıl
yönetiyorsunuz? İletişimi nasıl yönetiyorsunuz?
Çok güzel bir soru bu arada bu.
Aslında Coex ekip olarak çalıştığımız birçok
ekip var. Yani başta sayacak olursak da
OMS ekipleri var.
Client tarafında, Mobile Frontend,
Web Assistant, Chat,
CRM, İnternet ekipler ve
yine her zaman ekiplerin çalıştığı
SRV ve DB'de içine koyabiliriz.
Dolayısıyla bu kadar fazla ekiple
birlikte çalışırken işin doğası gereği zorluklar
yaşadığımız oluyor. Örneğin
iş planlaması, buradaki
bedbayları belirleme ya da süreçleri
birlikte yönetirken kurduğumuz iletişimler,
kontrak paylaşımları birçok ekiple
çünkü OMS içinden alıp OMS
dışındaki line mobile ekiplerine
indiriyoruz bu verileri çünkü. Hem müşteri
deneyimi açısından hem de aslında onların açısından
da bu planlamaları yapmamız gerekiyor.
Yine aynı şekilde hani süreçlerin
canlıya alınması da var. Bunların takip
edilmesi de var. Senkronize bir şekilde yürütülmesi
de var. Ekiplerle çünkü çok korunmamız
gerekiyor her süreçte neredeyse. Bunları
sayabilirim. Bunların dışında da sayabileceğim
başka konular da var. Mesela işte süreçlerin
netleştirilmesinde
Birçok toplantı yapıyoruz. Bazen bu toplantıları azaltmak istiyoruz. Bazen de doğası geriye artabiliyor.
Ya da işte süreçlerin sahiplerinin belirlenmesi. Yani ne demek bu?
Bir süreç geliştirecek ancak süreci front end'e yığmak da ilerleyen zamanlarda bir probleme yol açabiliyor.
Yani beken tarafında daha çok değişmesini isteriz biz bunların.
Ama biz de tam deep beken servisi değiliz. Arada bir beken servisiyiz.
Bu tarz konularda yine hani sahipliği belirlerken iletişimde olmamız gerekiyor.
Bazen de teknik olarak da yapılması çok mümkün olamazsa da bu konuları aktif olarak tartışıyoruz.
Tabii bunların dışında şeyi de sayabiliriz.
Yani supportlar da geliyor.
Hani OMS ekibi olarak çok fazla support alan bir ekibiz.
Coex'ti keza bu şekilde.
Bir soru geldiği zaman bu sorunun doğrudan cevabı sizde olmayabiliyor.
Siz en yakın ekipsiniz ama sizin aldığınız veri başka bir deep servisten geliyor.
Ya da o sürecin sahipliği sizde değil başka bir ekipte.
Dolayısıyla bu tarz zorluklar içeriyor işin doğası gereği.
Valla yani zaman zaman böyle çoğu ekibin yaşadığı şeyler aslında bunlar.
Yani hepimiz belirli tutalarda belirli şeyler yaşayabiliyoruz.
Artık biraz daha normalleşen şeyler gibi bakabiliyoruz bunlara.
Ama bunu tabii ki problemlerden ziyade nasıl handle ettiğimiz bir işte düzen içerisinde bunları yaptığımız daha çok önemli.
Burada takım içindeki çalışma düzeninden biraz konuşalım istiyorum.
takım içerisindeki sizin çalışma düzeninizden bahsedebilir misiniz biraz?
Yani burada sprintlerinizi nasıl koşuyorsunuz?
Daily, günlük toplantılar nasıl ilerliyor?
Başka toplantılarınız, başka pratikleriniz var mı?
Deployment süreçleriniz, request süreçleriniz vs.
Bunlar nasıl ilerliyor? Biraz bunlardan konuşalım isterseniz.
Tabii, bahsedelim hemen.
İlk önce biraz çalışma düzenimizden bahsedeyim.
Bizim takımda totalde yeni gelen bir arkadaşımız da var.
Onunla birlikte 3 tane back-endçi olduk.
Önceden de 3'lük de rotasyonla giden bir arkadaşımız da vardı.
Ama kişiyi sayısı olarak aynı kaldığımız için aslında behavior da koruyoruz.
3 kişi olduğumuz için 2 kişi genelde payer çalışıyor.
Payer çalışmanın tabii ki birçok artısı var.
Hem oradaki business'ın dağılımı anlamında hem de kod yazarken bazı teknik problemlerle alakalı kısımlarda iki gözün görmesi iyi oluyor.
Tek kalan arkadaşımız da daha biznes olarak bir tık daha görece,
now have dağılmasa da olur diyeceğimiz bir tık daha kolay olan tasklarla birlikte
on-call support tarafında daha çok görev alıyor o hafta.
Ve bunu belli bir rotasyonla kendi aramızda dönüyoruz diyebilirim.
Yani günlük aslında haftalık çalışma rutinimiz bu şekilde.
Bunun dışında genel sprint sürecimiz nasıl dersek,
her sabahları daily yapıyoruz.
Trendyol'daki çoğu takımdaki gibi.
Daily'lerde farklı görevlerde olan sonuçta arkadaşlarımız diğer görevlerde olanlardan bilgi paylaşımı yapıyor.
Örnek veriyorum Product Manager arkadaşımız bir bilgi getirebiliyor veya QA'ya, Fadime'ye bir şey yapmış oluyor onun bilgisini geçiyor.
Her sabah kısa bir daily yapıyoruz bu bilgi paylaşımlarını ve update'leri veriyoruz.
Bunun dışında çarşamba günleri grum toplantımız oluyor.
Grumda da aslında yeni gelen biznes işleri PM arkadaşımız bize anlatıyor ve orada ilk konu geldiğinde konsolilerimiz varsa veya diğer takımlarla alakalı netlenmesi gereken konular varsa bunları product arkadaşımızla konuşup onun netleştirmesini bekliyoruz.
Bu çarşamba günü oluyor bizde. Bir sonraki gün, perşembe günü de bu bir sonraki sprintte alacağımız taskların aslında tek grumunu yapıyoruz.
Bu da sonradan takımımıza aslında eklediğimiz bir behavior oldu.
Bazı konularda teknik olarak yeterli deep dive etmediğimizde, yeterli analiz yapmadığımızda
bu sefer bunu sprint içinde netleyemediğimizden kaynaklı sprintin rahat gitmesini engelleyebiliyor.
O yüzden de bu tek grum toplantılarında aslında teknik olarak konsör ne olduğunu düşündüğümüz konuları deep dive edip bakıyoruz.
En sonunda da cuma günü estimation toplantısında taskları puanlıyoruz ve pazartesi günü de puanladığımız tasklara göre takımın velocitesine göre sprint'i başlatıyoruz diyebilirim.
Çok kısa şeyden de bahsedebilirim.
Bazen tek grumda netleyemeyeceğimiz kadar kısa olmayan, daha uzun soluklu bakılması gereken, belki 5-6 projeyi etkileyen konular olabiliyor teknik olarak bakılması gereken
veya bir proof of concept POC yapmak gerekebiliyor.
Bu tarz konularda da spike taskları açıyoruz ve bu taskların aslında sprintte bir development olarak bir çıktısı olmuyor.
Aslında daha çok inceleme ve bir sonraki implementasyon kartının da neler yapılacağının netlendiği ve incelendiği analizinin yapıldığı kısım oluyor.
Bunların dışında daha böyle aylık, iki haftalık veya quarter bazlı toplantılarımız da oluyor.
Biraz onlardan bahsetmesi için topu ben Fadime'ye atayım.
Ben de aylık ve toplantılarımızdan bahsedeyim. Diyorsunuz tüm yıl aslında kuartır bazlı hedefler alıyoruz OKR'lar olarak. Bunların health check'i, bunların kontrolü için tüm ekip birlikte kontrol ediyoruz. Ne durumdayız, nereye gidiyoruz, ne durumdayız vs. diye aslında bir genel kontrol ve sürekli birbirimize updateleşmece ve eğer sprint'i alamadıysak oradan sonra daha çok işte birbirini sprint'e getirme işlerini zaten esayini olan kişi takip ediyor.
Fakat Sprint'e de özellikle yer açmak için tüm ekipçi olmamız böyle birbirimizin bilincini canlı tutmamızı yardım ediyor.
Aynı şekilde KPI'ler de onun da head check'in kontrolünü yapıyoruz düzenli olarak.
Orada da işte servislerimizin sağlıklarını, Sprint'in cycle time'ını, lead time'ını, bazen de kod simellerimizi yani
tüm kullandığımız projelerin sağlıklarını kontrol ettiğimiz, oradaki geliştirmelerimizin durumlarını kontrol ettiğimiz
gerekirse tasklaştırdığımız ve esan ettiğimiz bir yapıda toplantıları yapıyoruz.
Yine tüm ekipçe yapıyoruz tüm toplantılarımızı.
Diployment süreçlerimizden bahsedeyim bir de.
Burada aslında bir pipeline yapısında zaten unit testlerimiz yazılıyor.
Keza acceptance testlerimiz yazılıyor.
Burada hep QA ve developer birlikte çalışıyoruz yine.
Daha sonra stage'e geldiğinde eğer manuel bir test yapılması gerekirse
manuel test yapıyoruz. Eğer yapılmasına
gerek yoksa işte journey testlerimizi
çalıştırıyoruz. Daha sonra canlıyı
alıp monitoringle tüm bu
akışı bitiriyoruz.
İşte manuel test eforunu
azaltmaya çalışıyoruz burada zaten.
Olabildiğince yapmamaya çalışıyoruz ama
bazen her şeyi otomatize
edemiyoruz ya da
tek seferlik bir iş geliyor. Onu
otomatize edene kadar bakıp geçiyoruz
vesaire. Zaten burada azaltmaya
çalışıyoruz. Test agent'tan
destek alıyoruz zaten. Testlerin yazılması,
kriteryaların oluşması
için de burada da süreci böyle
iyileştirmeye çalışıyoruz diyebilirim.
Ve o forkingten bahsederken pay programından
bahsettiğiniz baya. AI'nin
hayatımıza girmesiyle birçok şey değişti.
Sizin pay'lerinizi nasıl etkiledi
AI? Ayrıca mob session
gibi yöntemlerde uyguluyor musunuz
sizin taraftan? Biraz önce bahsettiğim
gibi yani pay'er aslında
kültürümüze devam ediyoruz
büyük ölçüde ama tabii ki burada
taskların tipi de önemli oluyor.
Yani bazen projede X bir API'ya veya X bir listener projesine,
bir servise, düz bir field ekleme işinin kompleksitesiyle
yeni gelen bir biznesin bir örnek veriyorum,
siparişteki X bir sayının hesaplanması, X bir fiyatın değişmesi,
ekstra bir lojik koşulması gibi durumlarda
daha demin de söylediğim gibi payer olmanın büyük artısı oluyor.
O biznes dağılıyor.
Daha demin de dedik yani herkes bu takıma da rotasyonla geldi.
O biznes dağılmadığında tek bir kişi ağır bir işi yaparsa bu sefer şey olabiliyor yani bir atıyorum birkaç sprint o kişi de kaldı o iş.
Sonraki sprint başka bir kişi aldığında bu sefer oradaki biznesa tam hakim olamayabiliyor.
Zaten pair programming'in başka faydaları da var normal teknik olarak.
Onlardan bahsetmeyeceğim zaten ekstra şimdi.
Biz yine devam etmeye çalışıyoruz ama bazı sprintlerde görece daha böyle düz kompleks olmayan tasklar olabiliyor.
Onlarda payr yapmayıp A-Agent'in de gelişmesiyle özellikle işte içeride A-Agent platformumuz var.
Bilmiyorum diğer şeylerde bahsedildi mi podcastlerde hepsini dinlemedim.
O platform üzerinden aslında Jira'daki tasklarımıza A-Agent üzerinden çalıştırıp development yaptırabiliyoruz.
Bu tarz durumlarda çok payr olmadığımız sprintlerde olmaya başladı A-Agent'in de aslında kullanımının artmasıyla diyebilirim.
Modstation'dan da çok kısa bahsedeyim.
Bahsedeyim, içeride bazen yani diyorum ya kompleksite burada çok önemli.
Bazen çok daha böyle X large veya large diyeceğimiz boyutta işler gelebiliyor.
Örnek veriyorum bir database'in taşınması ya da 3-4 projede kullanılan bir mimarinin tek bir projede dinamik bir altyapıya kavuşturulması
ya da eski bir projenin refactoringi.
Bu gibi konularda aslında konuşulması gereken çok fazla konu ve dikkat edilmesi gereken çok nokta olduğu için
bir kişinin iki kişinin bakması bile bazen çok verimli olmayabiliyor.
Yani verimli olsa da gözden bir şeyler kaçabiliyor diyeyim.
O noktada da mobstation yapıp örnek veriyorum bir refactoring'in
ilk bir iki taskını yapacağız.
Oradaki mimariyi oturtacağız.
Onlarla mobstation yapabiliyoruz veya işte bir geçiş yapacağız.
Onunla alakalı durumlarda yine mobstation takımca yapmaya çalışıyoruz diyebilirim özetle.
Valla AI konuları özellikle çok artık hepimizin şeyi her gün konuştuğumuz konular
Konuşmayı da geçiyorum artık hayatımıza çok fazla bir şekilde etki eden ve yapışan konular diyebiliriz.
Yani biz genellikle AI'den bahsetmekte işte 100. bölümümüzde de bu bölümden bir sonraki bölümde göreceksiniz çok fazla konuştuk AI'yi.
Konuşmaya da devam ediyoruz ama tabii eski teknoloji konularını konuşmanın keyfi de bir farklı yani.
Şimdi biraz daha tekstek üzerinden konuşalım isterseniz.
Direkt aslında kullanıldığınız teknolojileri merak ettim.
Kullandığınız teknolojiler nelerdir?
Tabi buraya da ben cevaplayayım.
Teknolojik deyimiz aslında oldukça geniş.
Örnek vermek gerekirse programa dillerinde Java ve Go ağırlıklı yerliyoruz.
Çünkü deneyim olarak hem bu dillere hakimiz hem de çözüm ödeteceğimiz problemler için daha uygun dillerde.
Aynı zamanda trend yolu içinde de dilin hakimiyeti de birazcık önemli.
Çünkü çok aşırı daha fazla dil kullanıldığı zaman hem onun geliştirilmesi hem de başka kişilerin de bu ekiplere ilgili rotasyonlarla da zorluklar çıkarabiliyor.
Dolayısıyla bizim de tercihimiz bu yönde olmuştu.
Bu dillerden örneğin Java'dan örnek verecek olursak hem Spring Framework gibi çok yerleşik uzun yıllardır geliştirilen bir framework'e sahip.
Onun dışında YouTube'aniler de var.
Go tabi görece yeni ama Go'da bu alanda gelişmeye başladı.
Java için böyle söyleyebilirim.
O tarafında da zaten herkesin bildiği gibi biraz performans odaklı bir dil.
Yani CVSE++'a daha yakın bir dil.
Aynı zamanda kaynak tüketimini de oldukça düşürüyor.
Uygun projelerde tercih etmeye çalışıyoruz bu dilleri.
Dillerin dışında da veri taban teknolojilerini sayabiliriz belki.
Oscura SQL, Couchbase, Elasticsearch gibi aslında teknolojileri de kullanıyoruz.
Ağırlıklı olarak Couchbase kullanıldık şimdiye kadar ancak biliyorsunuz ki trend yolda
Couchbase tarafındaki enterprise desteğinin azalmasıyla birlikte Oscura'ya geçişler artmaya başladı.
Biz de aslında buradan ilk başta etkilen ekiplerden birisiyiz.
Bizim her ne kadar Nuvex Fee'le daha yakın olsak da artık Postgre tarafında da benzer bir çözüm meglitmeye başladık.
Elasticsearch için de zaten biliyorsunuz biz hani müşteri odaklı, müşteriye çok yakın bir ekibiz ve müşterinin vereceği arama sorgularına da hızlı cevap verebilmemiz gerekiyor.
Postgre'deki indeks desteğinin full-text searchta zayıf olması ya da couch phase'de ve secondary index gibi teknolojilerin de yavaş olması ile birlikte Elasticsearch burada çok güçlü bir çözüm üretiyor bizim için.
Bunların dışında şeyler de söyleyebiliriz bu arada.
DB'lerle indeks sistemler arasında aslında bir de iletişim kurulması gerekiyor.
Bunu da konnektörler yapıyor.
Trendyol'da da bu konnektörlerin aslında geliştirildiği bir sistemimiz var.
Couchbase'de Elasticsearch konnektör ya da Postgre'den Elastia, Postgre'den Kafka'ya
ve başka başka sistemlerden başka başka sistemlere diyebiliriz özetle.
Burada da biz şu ana kadar Couchbase'den Elastik'e attırabileceğimiz bir konnektör kullanıyorduk.
Go tabanlı olan. Yakın zamanda
zaten Postgre'ye geçişimizle birlikte
Postgre'yi elastikle kullanmaya başlayacağız.
Bu teknolojinin dışında tabii şeyler de
var. Yine Trendyol'da daha önceki
sunularda anlatılmıştır muhtemelen.
TDP denilen bir platform var.
Altyapıyı yönetiyor. Yani Kubernetes
gibi, konflikt yönetimi gibi, servislerin
bağımlılıkları. Çok farklı alanlarda
aslında çözüm üretiyor. Biz de burayı aktif olarak
kullanıyoruz. Diplomut süreçlerimizde,
hem rollbacklerde bir hatta problem
çıktığı zaman geri almak istersek ya da
aşamalı olarak diplomat yapmak
isteyebiliriz, kanal diplomat yapmak isteyebiliriz.
Bu aşamada oldukça
işimizi kolaylaştırıyor. Sizde de oldukça
geniş bir teknoloji listeyi
varmış gerçekten. Özellikle
database olarak bayağı bir teknolojiyi deneyimleme
fırsatınız olmuş. Bayağı güzel.
Peki takım içinde teknik kararları
nasıl alıyorsunuz? Herkes bu karar
aşamasına dair oluyor mu? Nasıl ilerliyorsunuz?
Orada da ben devralayım.
Evet bizim takımda herkes
genel olarak tüm süreçlere dahil oluyor.
Zaten Reha'da, MobSation'da bunun
kısa bir ön infosunu
verdi. Hem takım içinde
biz bir karar alırken
birlikte oluyoruz ama bizim OMS içinde de
aynı pratiğimiz baki.
Yani biz dört OMS
ekibi olarak zaten birbirimize çok bağımlı
olduğumuz için ortak
kararları ve akışları da
birlikte tasarlıyoruz genelde.
Zaten aylık bir
toplantımız dahi oluyor yani.
Orada genel olarak
OMS ekiplerinin hem bilgi alışverişi
hem de genel olarak
karar aşamalarında hep birlikteyiz.
Burada bir diğer ortak karar verme aşamamızda ekip dışı yani OMS dışı ve ekip dışı takımlarla olanlar oluyor.
Genelde DB'lerle oluyor, messaging platformuyla oluyor.
Bizim işte bu notificationları onların üzerinden gönderdiğimiz bir platform.
Keza notificationları paydaşlarımızdan biri olan CRM ekipleriyle genelde birlikte karar veriyoruz.
Hem ihtiyaca yönelik hem de tüm ekiplerin birbiriyle konsörünü daha rahat paylaşabildiği, bilgi alışverişinin daha kolay olduğu ve en optimal çözüme daha kolay yaklaşabildiğimizi düşünüyoruz böylece.
Dediğimiz gibi tüm herkes, tüm sürecin en başından beri hep içinde olduğu için hiçbir aksaklık olmadan bilgi alışverişini ekstra tekrar sağlamak zorunda kalmıyoruz.
Tüm herkesi sürece dahil ederek diyebilirim.
Süper süper. Biraz daha böyle artık yavaş yavaş QA taraflarına alakalı her şeyde her kestimizde geçtiğimiz gibi bu tarafta da geçelim istiyoruz.
Böyle QA taraflarıyla alakalı bir şey sormak istiyorum. Takım içerisinde QA süreçleriniz nasıl ilerliyor?
Yani işte bir iş aldıktan sonra testi nasıl yapılıyor, nasıl ilerletiyor, teste kadar nasıl geliyor, test içerisinde spesifik yaptığınız şeyler var mı falan bu süreçlerle alakalı biraz bahsedebilir misin?
Tabii hemen. Burada aslında bir işe teste alırken ya da o tüm test aşamasına gelene kadar zaten QA olarak başından sonuna kadar tüm sürecin zaten içindeyiz. O bir cepte. Zaten MR açılırken unit ve acceptance testleri de yazılmış oluyor genelde bizim ekibin içinde. Onların review'lerine vesaire dahil olarak başlıyoruz ve yorumumuz falan vesaire varsa orada yapıyoruz.
Genel olarak manuel test yapmamaya çalışıyoruz ama dediğim gibi olduk yaptı vesaire bir şey oldu ya da kontrol etmemiz gereken yeni bir biznes vesaire oldu.
Oralarda da işte bazen işte biz dört OMS ekibine birbirimize bağlıyız dedik.
İşte biz tam ortadayız ve diğer ekiplerden aldığınız data ile iş yapıyoruz ama bazen hep birlikte aynı anda geliştirme yapıyoruz.
Orada datayı bekleyemiyoruz ya da kontraktı bekleyemiyoruz.
Daha çok MOOC üzerinden ilerliyoruz.
İşte acceptance'ını zaten yazmıştık. Orada kriteriyelerini ekliyoruz zaten teste gelmeden. Daha sonra test aşamasındayken bunlar işimizi kolaylaştırıyor. Böyle durumlarda çok fazla mokladığımız zaman entent göremiyoruz haliyle.
Bu bizi biraz şey biznes işlerde daha emin olmak adına büyük projelerde client ekipleriyle yani tüm servis ekipleriyle end-to-end şeklinde ilerliyoruz. Orasını öyle söyleyebilirim.
Bir de paydaşlarımızdan birisinin CRM olduğunu söylemiştik.
Bu notificationları, içeriklerini yöneten biznes ekibimiz.
Orada biz aslında Coex olarak notification'ın gönderiminden sorumluyuz.
Yani gönderene kadar görevimiz.
Daha sonra gönderdikten sonra içeriğinin kontrolünü tam olarak bilmiyoruz aslında.
Burada da CRM'den destek alıyoruz.
Notification'larda büyük bir değişiklik yaptığımızda
ya da istenilen şekilde gönderebiliyor muyuz kontrolünü genelde CRM ile Coex birlikte kontrol ediyoruz.
Daha sonra client tarafında ise clientlerle onlar bizim servisimizi kullanıyorlar.
Her zaman bizden bir kontrat ya da bir data ihtiyaçları oluyor.
Biz bir geliştirme yaptıktan sonra muhakkak onlara bir kontrat data paylaşımı yapıyoruz.
Ben de bir client, geçmişli biri olarak clientların bloklanmamasına ve datalarını mümkün olduğunca çeşitlendirerek onların testlerine de destek olmaya çalışıyorum.
Bu noktada data oymes, data create agent'ımız var.
Buraya da geliştirme yapıyoruz ki onlar daha farklı datalara her zaman ulaşabilsinler.
Biz sprint ekledikten sonra bir özelliği, bir flow'u muhakkak oraya da eklemeye çalışıyoruz ki gelecekte data ihtiyaçlarını oradan karşılayabilsinler.
Bir de journey testlerimiz var.
Onlar da eğer böyle smoke gibi çalışıyorlar şu an için, eğer servislerimizde büyük bir değişiklik varsa muhakkak orayı da update ederek ilerliyoruz.
Ki tüm süreçleri kaliteli bir şekilde yönetebilelim.
Böyle toparlayabilirim.
Biraz da observability'e değinelim.
Servislerimizi monitör etmemiz işimizin çok çok önemli bir parçası hepimiz için.
Coex ekibinde monitoring ve alert yapısı nasıldır?
Hangi araçları kullanıyorsunuz?
Burada da ben alayım.
Monitoring kısmından dinleyeyim ilk başta.
Trendyol'da aslında monitoring çözümleri her yıl değişiyor bir miktar ama artık daha stabil hale gelmeye başlamıştı.
Dolayısıyla biz eskiden servislerin tam olarak ne kadar hata aldığını, ne kadar response time'a döndüğünü,
nelere bağlı olduğunu bazı observatör araçları verirken bazıları veremiyordu
ya da detaylı olarak göremiyorduk bu kırılımları.
Dolayısıyla buradaki Trendyol'daki adaption da arttığından dolayı
uçtan uca aslında birçok servis birbirlerine daha bağımlı hale gelmeye başladı.
Biz de dolayısıyla burada kullandığımız araçlar Trendyol'un hem kendi internal geliştirdiği
Mergen Beholder gibi böyle grafana çözüm aslında.
Bu araçları kullanmaya başladık.
Distributed Tracing amacıyla cepleri kullanıyoruz.
Buralarda şeyleri görebiliyoruz.
Örneğin hangi servisin hangi endpointine kim gelmiş, ne zaman gelmiş, ne kadar sürede gelmiş, ne zaman artmaya başlamış buradaki gecikmeler.
Bunları çok daha rahat takip ediyoruz.
Hatta internal proseslerini de görebiliyoruz.
Dolayısıyla bizim buradaki yaşadığımız sorunlara daha iyi bir çözüm üretmeye başladı monitoringdeki konular.
Alert kısmına gelecek olursak da aslında biraz iç içe bir konu bu monitoring ve alert.
Alertte bir tık daha böyle şey sürekli takip etmektense sistem biz otomatik uyarabilsin diye bir yapıya geçiyoruz.
Yani bir diplo emuti yaptığımız zaman elbette monitörlük yapıyoruz ama alertle birlikte daha keskin olarak ya da insan hatasını daha elimine ediyor buradaki alertler.
Alert yapımızı da şöyle kurulur.
Özetleyecek olursak biliyorsunuz tren yolunda P1, P2, P3 gibi böyle farklı kılınlar var.
P1 dediğimiz etkinin büyük olduğu ve finansal etkinin de olduğu.
P2'de daha küçük ölçekli bir etki oldu ve P3'te de P2'de hatta finansal etkinin devam ederken P3'te artık finansal etkinin olmadığı gibi farklı kategorilere doğru gidiyor.
Biz de burada aslında müşteriye etkisine göre, client'e etkisine göre ya da müşteri deneyimini olumsuz etkileyebilecek arka plandaki gecikmeler, illa doğrudan bir hata değil, bir gecikmeyi de takip edebilmemiz gerekiyordu.
Dolayısıyla kurduğumuz sistemler hem client katmanında hem gönderdiğimiz iletişim katmanında hem buradaki kibana gibi, anomali gibi farklı farklı konularda yani bir dalgalanma bile bizim için bir sorun yaratabiliyor bazen kaynaklarımızda.
Ya da şey de bahsedebiliriz burada, kaynaklarımız işte podlar, Kubernetes clusterları, database'ler, buradaki alertleri de takip ediyoruz.
Çünkü her zaman SRE, DBA, oradaki problem o kadar vakıf olamayabiliyor.
O anda bizim gördüğümüz ve onların gördüğü problem aynı şey değil.
Dolayısıyla alertlerin tanımı bayağı geniş bir yer fazlada.
Bir de şeyden bahsedebiliriz belki bu alert konusunda.
Biliyorsunuz Trendyol'da yine bir KeyBT denilen bir sistem daha var.
Key Business Transaction yani müşterinin ya da satıcının.
Burada hep müşteri diye bahsediyoruz da tren yol açısından ticaret denemini etkilediği ya da önemli olarak operasyonların etkilendiği süreçlere KBT tanımlanıyor.
KBT'de uçlamaca frontend'den backend sistemine kadar bir akış düşünelim.
O akıştaki yaşanan sorunları daha hızlı bir şekilde gösteren hangi katmanda, hangi ekipte, hangi uygulamada hangi sorun yaşandığını belirtebilen bir sistem.
Dolayısıyla biz KBT yapısına da entegre olduk.
KBT tabii ikiye de ayrılıyor bu arada.
Sink ve async diye. Sink dediğimizde
oradan client'in geldiği async dediğimizde
biliyorsunuz gecikmeleri ölçebilen bir sistem.
Yani biz bir modelde
sunduğumuz için siparişin müşteriye
yansıması da aslında bir sorun yaratıyor.
Buraya da entegre olmaya başladık ve
artık yakın zamanda da
çiftleştirme üzeriz diyebilirim. Süper.
Valla dolu dolu anlattığınızda
arkadaşlar ağzınıza sağlık. Güzel
oturmuş bir yapı var. Yani birçok ekipte
gördüğümüz pratikleri burada da görebiliyoruz.
Ve hani her
alanında işte ağzından
z'sine kadar güzel
kurgulanmış, güzel oturmuş bir yapının
olmasını görmek de gayet güzel.
Yavaştan son sorumuza geliyoruz.
Ondan sonra ufaktan kapatacağız.
Böyle geçmişte
karşılaştığınız büyük
problem, işte büyük bir
sorunda nasıl ilerlediniz?
Buradaki etkili çözümü
nasıl uyguladınız? Yani
bir de bunun yanında tabii mesela
sizin öğrendiğiniz şeyleri ya da işte
uyguladığınız, yaptığınız şeyleri
paylaşma gibi bir pratiğiniz var mı?
Medium yazısı olabilir, bir open source contribution olabilir vs.
Buradaki yaptığınız şeyler neler oldu acaba?
Şeyden bahsedebiliriz belki burada.
İlk başta aslında yaşadığımız etkili bir çözüm.
Yaşanan büyük bir sorun kısmında.
Bizim bundan bir yıl öncesine kadar, bir yıldan da biraz fazla olmuş olabilir.
International ve Domestic gibi iki farklı sipariş sistemimiz, servislerimiz ve database'lerimiz vardı aslında iki farklı katmanda.
Burada da ekip olarak aslında iki farklı şeye hizmet ediyoruz.
Yani süreçler olarak yakın olmasına rağmen iki farklı projeye hizmet ediyorduk.
Bir backlog'a bir şey geldiği zaman iki tarafı da düşünüyorduk.
Geliştirme yapılacağımız zaman iki tarafın amenizi yapılıyordu.
Bir şey ekleneceği zaman farklı klantlarla iletişime geçmek çeşitli zorluklar doğuruyor.
Hem de kaynak olarak da israf ediyoruz düşündüğümüz zaman.
Buradaki aslında sorunumuz dediğimiz gibi yani hem ekip olarak cognitive load'umuzu artırıyor.
Hem sprintlerimizdeki tas sayısını artırıyor.
Dolayısıyla bu kısma çözümü aramak için de uzunca bir çalışma yaptık.
Çalışmaya da kaliteler de belki rehaya bırakabilirim.
Olur tabii bahsedeyim.
Burada Selim'in bahsettiği gibi aslında iki servis vardı ama totalde dört tane projeye hizmet ediyordu.
Yani hem datanın yazılması hem de server edilmesi anlamında.
Hal ile bir iş gelince dört tane projeye development yapmamız gerekiyordu.
Buradaki süreci yalınlaştırmak için de ilk önce şey yaptık tabii ki.
International taraf görece daha az o an kullanıldığı için ve domestik tarafta daha çok business olduğu için
international tarafı domestiğe mörşlemek istedik.
O noktada da tabii aslında 3 tane nokta vardı.
Domestiğe özel businessler, international'a özel businessler ve kesişim kümesi.
O yüzden buraların hepsini çokça böyle analiz taskı alarak hepsinin büyük bir uzun bir listesini çıkarttık.
İleride sıkıntı yaşamamak için.
Buradaki en büyük challenge şey oldu bizim için.
Yani çok uzun soluklu bir iki tane projeyi birleştiriyoruz ve bütün sipariş datasının yazılması, eski dataların migration'ı, bunların müşterilere sunulması aslında uzun soluklu bir iş.
One shot yapılacak bir iş değil.
Bu yüzden de bu süreçte sürekli sadece bu işle alakalı taskları alıp ilerleyemedik.
Araya başka tasklar da girdi.
Yani uzun süreli bir işti bu gerçekten.
O yüzden de uzunca bir süre International'a gelen işleri de mecburen DAP2 olarak Domestic projesine de toggle'lı bir şekilde yapmamız gerekti.
Çünkü günün sonunda oraya geçmek istiyorduk ve analizi bitirdikten sonra yeni gelen işleri oraya yapmazsak bu sefer bütün işler bittikten sonra bir tur daha analiz yapmak falan gibi problem yaşayacaktık.
Günün sonunda bu projeyi tamamladık.
Buradaki etkili bir çözümden bahsedebilirim.
Şimdi günün sonunda bizim clientlerimiz International datasını eski servisten alıyordu ve yeni servise gelip düzgün bir şekilde aynı şekilde birebir aynı şekilde çekmek istiyorlardı.
Onlara ekstra iş çıkartmak istemiyorduk.
Bunun için bir data checker yazmıştık ve random olarak eski database'deki bazı kayıtlar için ilk önce International hapisine sonra da yeni migration olmuş ve artık toggle açınca insanların kullanmaya başlayacağı elindeki domestic hapimize de aynı şekilde aynı datayı çektik.
ve buradaki dataları JSON olarak field by field check etmiştik.
Ve burada bu çözüm sayesinde belki production'a çıktıktan sonra fark edebileceğimiz
ufak tefek gözden kaçan bug'ları da tespit edebilmiştik.
Bunu söyleyebilirim.
Bu açıkçası iyi ki yapmışız diyebileceğim bir nokta oldu.
Son olarak da öğrendiğimiz şeyleri paylaşma noktasında
Selim'le bir AI özellikle ilk kullanılmaya başlandığında daha yoğun bir şekilde içeride.
Aklımıza bir fikir gelmişti.
Çoğu takım içeride Pandora diye bir ortamımız var ve burada kendi biz lıslarını dokümante ediyorlar.
Bu dokümentasyon niye önemli?
Çünkü AI bazı noktalarda koda bakarak karar verse de bazı şeyleri aslında dokümante edilmiş şekilde öğrenmesi gerekiyor.
Her şeyi koddan öğrenemeyebiliyor.
Biz de burada şey düşünmüştük.
Bir takım herhangi bir şekilde bir geliştirme yaptığında eğer taskının içine etkileyeceğini düşündüğü bir dökümanı varsa o takımın yazdığı dökümanlardan bunu taskın içine eklesin ve AI o projeye bir merge request geldiğinde ve merge'lendiğinde oradaki koddaki diff'i analiz edip bunu analiz sonrasında dökümanı da analiz edip eğer dökümanda bir güncellenmesi gereken bir şey varsa dökümanı güncellemesiydi.
Bu dokümanlar tamamen böyle normal yani teknik demeyeyim de daha clear text kodun olmadığı daha biznesin anlatıldığı dokümanlardı.
Bunu yapıp hatta şirket içinde de Sight Project Pro web sitesinden yayınlamıştık ve kullanan başka takımlarda oldu.
Diyebilirim ilk o aklıma o geldi.
Bir de Mongo ile alakalı bir şeyimiz vardı ama ondan şimdi bahsetmeyeyim zaten.
Mongo'dan çıktık biz de.
Özetle böyle diyebilirim.
Çok teşekkürler Reha.
Customer Order Experience takımı ile
Selam ekibinin 99. bölümünü geride bıraktık.
Fatime, Reyha ve Selim'e katılımlar için
çok teşekkür ederiz. Bizim için çok keyifli
bir sohbet oldu. Umarım dinleyicilerimiz de
keyif almıştır. Bu bölümden sonraki bölümümüz
100. bölüm. 100. bölümümüzü hem
sesli hem görüntülü kayıt edeceğiz ve sürpriz
konuklarımız da olacak. 100. bölümümüz için
bizi takipte kalmayı unutmayın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.