Konuklar: Bilal Aksal, İlker Rişvan, Murat Can Tanrıverdi
42. bölümümüzde konuğumuz Pim Quality Control ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Transkript
Selam ekip, ben Productivity ekibinden Erdem.
Ben Fulfillment Order Master Data ekibinden Fırat.
Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 42.
bölümünde Quality Control ekibiyle birlikteyiz.
Ekibi tanıyıp, ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Evet, hoş geldiniz arkadaşlar. Hoş geldiniz.
Selam, hoş bulduk. Selamlar, hoş bulduk.
Selam, hoş bulduk. Kısaca kendinizi tanıtabilir misiniz bize?
Selamlar herkese. Yaklaşık 6 aydır Trend yoldayım.
Quality Center. Bu Trendyol'daki ilk ekibim.
Birazdan detayını veririz.
Selamlar herkese. Ben Muratcan Tanrıverdi.
Yaklaşık 1 yıl 10 aydır Trendyol'da çalışmaktayım.
Ve bu sürenin tamamında Quality Control ekibinde bulundum.
Selamlar herkese. Ben Bilal.
Ben de yaklaşık 3,5 yıldır Trendyol'da çalışıyorum.
Ben de geldiğimden beri QC ekibindeyim diyebiliriz böyle kısaca.
Teşekkürler, hoş geldiniz tekrardan.
Şimdi merak ettiğimiz şeylerle başlayalım.
Öncelikle QC ekibi ne iş yapar?
Kaç kişiden oluşur? Hangi domenide çalışır?
Bunlarla ilgili bilgi verebilirseniz süper olur.
QC nedir, ne iş yapar?
Hangi domenide çalışıyor da başlayayım.
Biz aslında PIM tribe altında yani Product Information Management tribe altında QC olarak adlandırdığımız takımdayız.
QC de deniyor, Quality Control de deniyor Trendyol içerisinde.
Yaptığımız ana iş SPM ekibinin de sanırım podcast olmuştu orada anlatıldığı gibi.
SPM'den gelen ürünleri PIM'e aktaran bir ekip var denmişti o podcast'ta.
Aslında o ekip biziz. Ürünler SPM dediğimiz yani Supply Product Management ekibinden Marketplace satış modelindeki ürün tiplerinin kontrolünü yaptığımız bu ürünleri gruplaştırdığımız ve daha sonra Trendyol
kataloğuna gönderdiğimiz bir sürecimiz var.
Bunun dışında işte video...
Aynı şekilde ürünler altında görünen videoların kontrol mekanizmasını yapıldı.
İşte burada kontrol biraz daha açarsam kalite kontrol kısmını nudity kontrolü istemediğimiz sözlükler farklı bir e-ticaret sitesine yönlendiren kelimeler veya vaat verici kelimeler gibi bu kontrolleri
yapıp ürünleri temizleyip satışa hazır hale getirip.
Daha sonra belli kontrolleri de sağlıyorsa otomatik olarak satışa çıkardığımız.
Kontrollerimizi sağlamıyorsa manuel olarak agentler vasıtasıyla ürünlerin kontrolünü sağlayıp satışa çıkardığımız süreçlerimiz var.
Kısaca böyle aktarabilir QC'yi.
Bunun dışında bir de şey international süreçlerimiz de var tabii.
International'da satılan ürünlerin de aynı şekilde kontrollerini yapıp satışa kazandırıyoruz.
Son olarak da TR ürünlerinin körfez ülkelerinde satışa açılması.
Burada da yine külse ekibi olarak bu ürünlerin satışa uygunluk kontrollerini yapıyoruz.
Mesela kısaca bir örnek verirsem kafada dahi oturması için.
Çam ağacı örneği verebilirim.
Çam ağacı Türkiye'de satılması herhangi bir problem değil veya Azerbaycan'da çam ağacının satılması bir problem değil ama...
İşte Katar'da mesela çam ağacı satılması yasak.
TR'de satılan bir ürünün Katar'da satılabilmesi için çam ağacı olmaması gerekiyor.
Burada da işte görselleri de Object Detection yapıp çam ağacı görseli ise bu ürünü Katar'da satamazsın gibi flaglememiz gerekiyor.
Bunun gibi kontrolleri yapıyoruz aslında QC içerisinde.
Deyip böyle toparlayayım.
Çam ağacı örneği çok iyiymiş ya.
Ben de en başta şey demiş yani no detail ya da işte yasaklık kelimeler vesaire.
Sadece o tarz şeyleri kontrol ediyorsunuz gibi düşünmüştüm.
Ya da sadece resimler. açıklamalar veya direkt ürünün türü de olabiliyor.
Yani ben kitap dedim ama çam ağacı resmi koydum.
Bu da quality control'in kapsamına giriyor diye anlıyorum.
Doğru mu? Burada aslında Onu da doğal yoldan yapıyoruz diyebiliriz.
Yani category detection gibi bir logik yok henüz.
Ama bu da aslında çalıştığımız yapıda var.
Şu an için görsel detection yani görselde objek detection üzerinden gidiyor bu kontroller.
Çam ağacı yazılmamış olabilir.
Yani başlıklı açıklamaya da bakıyoruz tabii ki.
Başlıklı açıklamada da çam ağacı var mı yok mu kontrolü yapıyoruz.
Ama onun dışında görselde de çam ağacı geçiyor mu geçmiyor mu gibi kontrollerle sağlıyoruz şu an bunu.
Yani temelde başlık açıklama ve görseline bakıyoruz.
ve ilerletiyoruz. Ek olarak da bir şey var.
Biznes tarafından kategori kırılımları da vardır.
İşte çam ağacı kategorisi Katar'da açılmasın gibi flagleniyordur.
Süper abi. Ben quality control deyince daha sığ düşünmüşüm herhalde.
Ama aslında kapsamı genişmiş yani güzel.
Peki burada yakın çalıştığınız hangi ekipler oluyor?
Bir SPM'den bahsetmiştik sanırım.
Direkt onlarla birebir iletişim mi oluyor?
Yani beraber Aynı ekipte değilsiniz sanırım.
Hani aynı çatıda olsak da Pim altında.
Beraber çalıştığınız ekip direkt SPM mi oluyor yoksa onun dışında farklı ekipler de oluyor mu?
Burada şöyle biraz daha açayım yelpazeyi.
SPM ile çok fazla konuşuyoruz.
SPM'den bize satıcıların yaratmış olduğu draft ürünler geliyor.
Biz bu ürünleri alıp kendi tarafımızda işleyip, gruplayıp daha sonradan Pim ekibine iletiyoruz.
Pim ekibi burada Pim ekibine giderken tabii arada yine konuştuğumuz Media Center dediğimiz ürünün görseliyle ilgili süreçleri ilerletiyoruz.
Medya Center ekibiyle konuşuyoruz.
DQ dediğimiz yani PIM'de benzer kontent arama süreçlerimizde konuştuğumuz ekip var.
Bu konuşmaları yaptıktan sonra ürünü satışa hazırlayıp PIM ekibine iletiyoruz ve süreci sonlandırıyoruz diyebilirim.
Süper süper. Peki şu anda sizin ekipte tam olarak kaç kişi var?
Şu an 3 ekip burada. 3 kişi burada.
Kalanı tam olarak kaç kişiden neyden oluşuyor?
Kalanını ben açıklamak isterim bu noktada.
Biz Trendyol'daki diğer ekiplere nazaran aslında biraz kalabalık bir çoğunluğumuz var.
Bir takım liderimiz, bir product owner'ımız, iki teknik liderimiz, altı backend liderimiz.
Bir frontend developer'ımız ve iki QA'yımız mevcut.
Yani yaklaşık 13 kişilik bir ekibiz.
Bu yüzden dolayı da yakın zamanda aslında bu ekibin ikiye bölünmesi söz konusu.
İki farklı alt ekibi bölünmesi konuşuluyor.
Muhtemelen yakın zamanda da iş akışlarından dolayı iki alt ekip olacak bu ekip.
Toplamda 13 kişilik bir ekip diyebilirim.
İki takım lead'inden anlamıştım abi.
İki takım lead var. Altı takım şey backend, bir frontend.
Bir frontend, iki QA, bir PO, bir team lead.
Okey, okey evet. Zamanı gelmiş.
Gerçi o yerine göre değişiyor tabii ama.
Bir süre sonra şey de oluyor mesela bizde de bölünmeye yakın zamanlarda genelde şey oluyor.
Değdiler biraz daha uzun sürmeye başlıyor hafiften böyle bir toplantılar.
Normalde olması gerekenden bir tık daha uzun sürebiliyor.
Sprintler uzun sürüyor falan. Aynen aynen.
Bir şey diyorsun. Böyle değildi ya.
Bir şeyler hani bir ne değişti falan oluyor.
O kadar kişi bir süre sonra kontrol aynı şeyde olmuyor.
Aynı sayıda olmuyor. Yani 2-3 kişiyken olan o kontrol ile o atiklik sayı arttıkça böyle azalıyor gibi.
Onu yavaştan böyle hissediyorsun. Tabii tabii.
Günün sonunda bir kalibrasyon ihtiyacımız oluyor.
Çünkü 3-4 kişinin birbirine kurduğu iletişim sayısıyla 13 kişinin birbirine kurmaya çalışan iletişim sayısı çok fazla oluyor.
Burada da o dinamiği güncel bir şekilde tutmamız gerekiyor.
Aynen aynen. Aynı fikirdeyim.
Peki burada... ekibe yeni gelenler mi oldu yoksa yani onboard işlemleri nasıl yapıyorsunuz?
Çünkü şu an anladığım kadarıyla üçünüz de zaten direkt bu ekiple başladınız.
Herhangi bir onboarding işlemi olmadı.
Sizde bu işlemler nasıl ilerliyor?
Ben de yeniyim. Ekibin en yeni üyesi olarak yaklaşık 6 aydır ve 5-6 aydır QCD'yim.
QC'de benim yaşadığım onboarding süreci, Triangle'daki onboarding sürecine ek olarak bütün takım arkadaşlarımla pair olarak başladı.
Çünkü biraz kompleks bir domenimiz var.
Öncelikle buradaki business novel'ı elde etmeye çalıştım.
Bütün ekip arkadaşlarıyla pair olup...
Onlardan business know-how'unu dinledikten sonra wiki'deki çoğu servisimizin dokumentasyonu şu an mevcut.
Onlarla da onboarding sürecine devam ettiriyoruz.
Ayrıca bizim ekip olarak yaptığımız yaklaşık haftada bir session'larımız var, akademi session'larımız.
Onboarding olan veya ekipteki harici biri herhangi merak ettiği teknik veya business know-how'a hakkında sheet'imize girip yani şunu bir ara...
Konuşalım dediği konuları belirtiyor.
Ekipten gönüllü ve bu konuda bilgili olan arkadaşımızla o session, session anında bize bunları iletiyor.
Bu da bizim onboarding sürecimizin önemli parçalarından biri.
Aslında herhangi bir süreç içerisinde, yani belirli bir zaman dilimi içerisinde değil, süre gelen bir sürecimiz oluyor onboardingde.
Şu an hala gerek teknik, gerekse business know-how'ında eksik olduğumuzu düşündüğümüz zaman bu akademi session'larıyla tamamlamaya ve devam ettirmeye çalışıyoruz.
Şimdi benim merak ettiğim en öncelikli konu.
Bunlardan biri aslında kullandığınız teknolojiler.
Çünkü tanıdığınız iş çok böyle keyifli, güzel bir iş gibi geliyor anlatınca.
İmajları proses ediyoruz, tarıyoruz, kontrol ediyoruz.
Bunları yaparken hangi teknolojilerden faydalanıyoruz?
Birlikte çalıştığımız muhtemelen data science ekibiyle beraber çalışıyorsunuzdur diye tahmin ediyorum.
Ekipler var mıdır? Orayı çok merak ediyorum ben de.
Burada ben söz almak isterim.
Biz takım olarak Kotlin programımı dilinlik kullanıyoruz.
Ve framework olarak da Spring kullanıyoruz.
Bir servisimiz dışındaki bütün servislerimiz günün sonunda Kotlin ile geliştiriliyor ve geliştirmeye devam ediyor.
Bununla beraber arkada infra tarafında database'lerimiz Couchbase.
Database'imizi Couchbase'den yana tercih ettik.
Ve aynı zamanda Elasticsearch'ı da kullanıyoruz.
Burada Elasticsearch'ı Couchbase ile beraber bir konnektör vasıtasıyla aslında Couchbase yazılan her bir veriyi o konnektörle sinkleyerek aslında Elasticsearch'ı burada kullanıyoruz.
Bununla beraber günün sonunda medyaları ve tekstileri kontrol etmemiz gerektiği için Data Science ekipleriyle de iletişim halindeyiz ama Data Science ekipleriyle birebir iletişim halinde değiliz de Media Center ve Video Center adını verdiğimiz ekiplerle aslında biz bu iletişimi
sağlıyoruz. Biz onların bize açmış olduğu servisleri kullanarak gerekli medyaları ve gerekli title'ları analizlere gönderip orada gerekli AI analizleri gerçekleştiriliyor ve buna göre ürünün satışa çıkması veya çıkmaması gereken kararları verebiliyoruz.
Bunun yanı sıra QC tarafında yaklaşık 27 adet servisimiz bulunuyor.
Ama bu 27 servisin yaklaşık 7 adetine legacy ve 6 tanesi de connector ve publisher tarzı.
Adı verdiğimiz servislerden oluşuyor.
Bunların yanı sıra toplam 14 tane servisimiz şu an normal ürün akış sürecimizde ve zaten Trendyol'da satışta olan ürünlerin güncelleme süreçlerinde aktif olarak kullanılıyor ve sürekli geliştiriliyor diyebilirim.
Şu an Data Science ekibiyle vesaire mi çalışılıyor yoksa kendi tarafınızdan bir şeyler vardı?
Burada AI kısmında aslında biz Media Center ve Video Center ekipleriyle iletişim halindeyiz.
Media Center ve Video Center ekipleri günün sonunda AI DS ekipleriyle iletişime geçiyorlar.
Biz mesela bir görselle mesela çam ağacını tespit etmemiz gerekiyor.
Çünkü çam ağacı belli başlı yerlerde satışa çıkmamasını istediğimiz bir durum.
Biz görselle gerekli promptlarla beraber Media Center ekibine iletiyoruz.
Media Center ekibi de Data Science ekibinden almış olduğu o modeli...
Kullanarak bize evet bu görselde çamağacı vardır ya da bu görselde çamağacı yoktur kararını veriyor.
Ve biz de günün sonunda Medya Center'dan aldığımız decision karara göre bu cevabı verip ürünün ilerlemesine veya ürünün ilerlememesine karar veriyoruz diyebilirim.
Peki bu çalıştığımız domeynin zorlukları var mıdır?
Yaşadığınız herhangi bir challenge oluyor mu domeynle ilgili?
Burada ilk başta ben... girmek isterim.
Bugün trend yolu açıp baktığımız zaman milyonlarca ürün görüyoruz ve bu ürünler aslında artmaya devam ediyor.
Ve bu ürünlerin aslında büyük çoğunluğu bizim sistemimizden geçiyor.
Bu yüzden dolayı günün sonunda bizim sistemimizin aslında 7-24 ayakta kalması gerekiyor.
Çünkü satıcılar entegratörler vasıtasıyla sürekli bir ürün gelişi yapabiliyorlar ve bu ürünlerin de mümkün mertebe hızlı bir şekilde yayına alınması gerekiyor.
Bu yüzden bizim de külsü olarak sistemlerimizi sürekli stabil halinde tutmamız gerekiyor.
Buradan sonra ben de Bilal'e söz verebilirim.
Ben de şeyden bahsediyorum.
dedim hızlıca. Bizim ürün kontrollerinde manuel süreçlerimiz de var.
Yani agentların ekranları alıp ürünleri kontrol ettiği süreçler de var.
Yani ekranlarımızın da orada sanıyorum ki iki vardiyalı olarak çalışıyor.
Outsource bir firmadan. 7-24 onlar da sabah 8 akşam 12 oluyor aslında.
7-24 değil de. 8-12 arasında ürün kontrolü yapıyorlar.
Bu süreçler yani bu saatler arasında da sistemimizin UI tarafının herhangi bir sorun olmadan akması gerekiyor.
Aynı şekilde ileride yine o QR'lar kısmında konuşuruz ama bizim ürünleri bir gün içerisinde satışa çıkarma sözümüz var satıcılara.
Burada da ürünleri olabildiğince hızlı bir şekilde tüm süreçlerini tamamlayıp işte ürün gruplama Ürün görsellerinin başlık açıklamasını ya da ürün içeriğinin kontrolünün yapılması gibi challenge'larımız oluyor.
Bunları çok hızlı bir sürede yapıp ürünü hızlı bir şekilde satışa çıkarmamız gerekiyor.
Ek olarak şeyi de ekleyebilirim.
Ürün gruplama kısmı aslında biraz daha buradaki büyük sorumluluk.
Çünkü işte çoğunuza hakimdir.
Trend yola girince 40 beden kırmızı etekle 36 beden kırmızı eteğin veya yeşil kırmızı eteğin aynı sayfa içerisinde görünmesi.
gibi bir önemli kıstasınız var.
Bunları bizim Külse ekibinde yapıyoruz diyebiliriz aslında ürün gruplamayı.
Bu ürün gruplamayı doğru yapmak en büyük aslında sorumluluklarımızdan birisi.
Bunu da olabildiğince iyi bir şekilde yapmaya çalışıyoruz diyebiliriz.
Ek olarak İngilizceyi istersen İlker sen açıkla.
Aynen biz aslında international bir ekibiz.
Ekibimizde Ukraynalı bir arkadaşımız var.
Bahsettiği gibi bilelim de kompleks bir domeyini bazı durumlarda tamamen İngilizce.
Cetrolarımız, delilerimiz, bütün toplantılarımız İngilizce.
Bu da bizi geliştiren sürecimizi de bir yandan da ayrı...
keyif katan bir challenge oluyor bizler için.
Ondan bahsedebiliriz birilerinin dediği gibi.
Ama en büyük challenge'larımızdan biri müşteriye gruplandırma işlemlerini doğru sağlayarak en hızlı sürede ürünleri sağlıklı bir şekilde gösterebilmek.
Yani en azından hazırlayabilmek diğer ekiplere giderken.
Burada throughput o zaman yüksek mi oluyor sizde abi?
Şunu düşünüyorum. Yani her yüklenilen ürün her türlü sizden geçecekse kategori bağımsız.
O zaman Yani burada hani create işlemidir bunun throughput'udur ya da ürünlerde update olunca da yine eğer şey yapıyorsanız yine bir sizin kontrolünüzden geçiyorsa hem create'ler hem update'ler tüm ürünler için throughput'unuz bayağı yüksekti anlıyorum ve bu yüksek
throughput'u direkt Kotlin olan projelerden mi geçiyor bu şeyler?
Bu yüksek throughput'lu olan yerler?
Burada evet abi yani ürünler bize Event Driven geliyor Kafka üzerinden.
Hem ürün akıtma yani sıfırdan ürün satışa çıkarma süreçlerimiz var hem de var olan ürünlere yapılan güncellemelerin kontrol süreçleri var.
throughput'umuz oldukça yüksek.
Bunların hepsi şu an için Kotlin uygulamaları üzerinden akıyor.
Süper abi. Peki burada throughput yüksek ve dediğiniz gibi dışarıdan sanırım bir şey var.
Şirket var. Onlar da bir kontrol yapıyor.
Sanırım manuel yapıyor. Yani burada bir de bir günlük sınır varsa bir sorun olduğu anda anlık bir tepki de vermek gerekiyor.
Çünkü throughput çok yüksek bir sorun olduğunda etkilenecek olan yer çok fazla.
Burada bir o yükleniş kısmı, AR kısmı için vesaire birden çok entegrasyon kısmı var.
Bunu peki monitoring kısmında neler yapıyorsunuz?
Burada monitoring kısımlarından ben bahsetmek isterim.
İlk başta zaten servislerimiz için nivrilik aletlerimiz mevcut.
Her bir servisimiz için bir nivrilik tanımlaması var ve o nivriliklerin içinde belli başlı alert tanımlarımız mevcut.
Bu alert tanımlarımızı şöyle açıklamam gerekirse, belirli Bir sürenin altında eğer throughput alamıyorsak veya fazla hata almaya başladıysak bu nivrelikler Slack kanallarımıza alert basabiliyor.
Aynı zamanda biz implementasyonlarımızı yaptığımız sırada loglar ekliyoruz.
Ve bu loglar da Kibana ile beraber ilişkili.
Günün sonunda biz Kibana'ya da alertler tanımlayarak eğer belirli sayıdaki logo belirli sürede daha fazla almaya başladıysak bize Slack kanalına mesaj bırak şeklinde bir tanımlama yapabiliyoruz.
Bununla beraber de infra olarak da eğer şu anki bu servisimiz ayakta mı?
Bu servis down oldu mu?
Ve benzeri alertlerimiz de yine mevcut.
Biz olarak ben... Bilal'e söz vermek isterim burada.
Burada biznes olarak da aslında şöyle önemli metriklerimizi takip etmek için kullanıyoruz.
Bizim için ürünü bir an önce satışa çıkarmak önemli demiştik.
Ürün uzun süredir işte 6 saattir, 12 saattir vs.
vs. gibi süreç ayrı ayrı şeylerimiz var.
Burada metrikleri takip eden scheduler'lar var.
6 saattir ürün satışa çıkmamışsa bunu alıp ilgili kanala raporluyor.
İşte şu kadar ürün 6 saattir ve 12 saattir satışa çıkmıyor gibi.
alertlerle böyle kendimize biraz daha bu ürünleri göze sokmak için yani tabiri caizse.
Ön deliğine atıyorsun gibi biraz.
Evet pushlayıp on call ekibinin de bunlara dikkate almasını incelemesini niye akmamış bir soru mu var gibi böyle ön plana çıkaran business alertlerimiz de bulunuyor.
Aynı şekilde kaç tane ürün onay bekliyor ya manuel onay bekliyor gibi gibi business alertlerimiz de mevcut.
Bunun dışında ek olarak support bot adlı böyle küçük bir yine Kotlin uygulaması yazdık.
Bu da Satışa çıkmayan ürünlerde veya satıcıların hatalı red olmuş veya bu ürün neden akmamış gibi sorularında kullandığımız küçük bir info botu.
Direkt olarak bizim support veren arkadaşlarımıza, ortak konuştuğumuz kanala kurduğumuz bu bot sayesinde ürünler hakkında basic bilgiler alıyorlar.
Ürün ne zaman reddedildi, kim etti, red reason'ı neydi gibi basic infolar veren bir botumuz var.
diyebiliriz. Monitoring anlamında da biz de gidip işte bizim support veren arkadaşlarımız hangi ürünleri incelemişler.
Bu ürün gerçekten akmış mı, akmamış mı?
Sorunu çözüldü mü, çözülmedi mi satıcının?
Bunun üzerinden takibi yapıp ürünleri ilerlettiğimiz bir uygulama bu da diyebilirim.
Buradaki support app'inden bahsetmiştin ya genel Kotlin'de yazdığınızdan.
Şirkette çok yaygın değil.
O yüzden farklı diller olunca bir ilgim oluyor genelde.
Sizde mesela Kotlin'i seçmenizin özel bir sebebi var mıydı?
Yoksa böyle gelen ya da ekip kurulduğundaki Kotlin know-how'ı çok fazla olduğu için direkt ondan mı gidelim demiştiniz?
Böyle yararını görüyor musunuz?
Memnun musunuz? Burada bence genellikle şey oluyor.
Kotlin know-how'ı çok fazla olduğu için Kotlin'de yazsak çok hızlı bir şekilde çıkarabiliriz diyoruz.
Ve hemen Kotlin'le yapıp ilerletiyoruz gibi.
Aslında bu support node biraz daha şeydi.
Arka taraftan ekipteki bir arkadaş böyle akşamları çalışarak oluşturduğu bir servisti.
Daha sonra faydasını gördük.
Ekibe dahil ettik. Ekibin sorumluluğuna dahil edip ilerletmiştik.
Ama genel olarak da sorgulamalarda benim gördüğüm biraz daha şey oluyor.
Bilgi birikim Kotlin'de fazla olduğu için know-how'ımızın da oturduğunu düşündüğümüz için Kotlin'den devam ediyoruz.
Sadece ben şöyle bir ekleme yapmak isterim.
Gelecekte şöyle bir hedefimiz var.
Biz Kotlin kullanıyoruz ama framework olarak hala Spring'e bağımlıyız.
süreçte yani QRT1'de de QRT2'de Sprig bağımlılığından uzaklaşıp aslında Cator bağımlılığına geçmeyi hedefliyoruz.
Ve uygulamamızın framework'ını Cator olarak düzenlemeye hedefliyoruz.
Bu da tabii şu an hala konuşuluyor.
Hani bu tarz şeyler pros konser ekip içinde tartışılarak aslında throughputlar ve gelen şeyler düşünülerek pros konser konuşulup buna göre kararlar alınıyor ve buna göre seçimler yapılıyor diyebilirim.
Şimdi monitörlükten bahsedince benim aklıma incidentlar geldi tuhaf olarak.
Yakın zamanda yaşadığınız ya da böyle unutamadığınız ekibin yaşadığı anlatmak istediğiniz bir incident var mıdır?
Benim hatırladığım böyle bir iki tane var uzun süredir çalışınca.
Böyle hızlıca bahsedeyim.
Az önce konuştuğumuz aslında uçam ağacı bir örnekti.
Onun geliştirilmesi aşamasında bize Bu promptları doğru bir şekilde vermemizden kaynaklı şöyle sorunlar olabiliyordu yani.
Hem arkada çalışan AI servisinin yeterince eğitilmemiş olmasından kaynaklı veya bizim promptu yanlış vermemizden kaynaklı.
Görselde işte kamuflaj deseni olup onu asker elbisesidir deyip işaretleme durumları olmuştu mesela hatırladığım.
Aynı şekilde çam ağacı örneklerinde çam ağacı olmayan bir görsele çam ağacı var gibi böyle basit sorunlarımız olmuştu.
Orada promptları yani. Yani verdiğimiz komutları biraz daha geliştirerek arkadaki AI servisinin de ilgili ekibin geliştirmesini sağlayacak feedbackler ileterek bu sorunu çözmüştük.
Hatırladığım ek olarak şey vardı benzer ürün arama mekanizmasında hatadan dolayı yanlış ürün mapleyip yanlış bir kontent altında satışa çıkarmıştık.
Satıcı kırmızı kırk beden etek yüklemişti.
Biz bunu alıp işte yine kırmızı kırk beden olarak değil de yeşil kırk beden ile maplayıp yeşil olarak satışa çıkarmıştık.
Satıcımız kırmızı ürün satmak istiyordu.
Biz bunu yeşil olarak satışa çıkarmıştık.
Bu tarz böyle arkadaki mekanizmalardan dolayı yani ürün arama mekanizmasından dolayı yanlış mappingler olabiliyor.
Bunları düzeltip ilerletmiştik, sorunu çözmüştük.
Bir de BF zamanında bir incidentımız oldu.
olmuştu. Böyle gerçek çok etkisi olan bir insanım.
Orada da abi şöyle bir sorun oldu.
İşte BF'den önce aslında bizim QC ekibinin yükü BF anında değildi.
BF'den önce oluyor. Çünkü satıcılar BF'de ürün satabilmek için veya ürünlerini güncelleştirip daha çok hit almak için ürünlerini çok fazla güncelleme hissi atıyorlar veya çok fazla yeni ürün satışa çıkarıyorlar.
Bizim tamamen yük BF'den önce oluyor.
BF biraz daha bizde monitoring olarak geçiyor diyebiliriz.
İşte BF öncesi satıcılar çok fazla ürün güncelleme isteği atmıştı ve bu güncellemeleri biz almışız.
Güncelleme isteğinde de basic olarak şey düşünebiliriz.
Bu ürün güncellemesi herhangi bir sorun içermiyor.
Bizim için valittir deyip yansıttığımız bir de işte bu güncellemeye şu şu şu sebeplerden işte görselde görseli indiremedik.
Kalitesi beklediğimiz şartlarda değildi deyip reddettiğimiz gibi ikiye aylıyor.
Onay ve red olarak. Biz güncelleme sürecini tamamlamışız.
Onay ve red kararı vermişiz ama satıcıya bunlar bilgi olarak gitmemiş.
Arada bir kopukluk olmuş. Satıcı ekranında güncelleme süreci bekleniyor olarak görünüyor ama bizde süreç tamamlanmıştı.
Burada nasıl anladık sorunu?
Direkt olarak aslında satıcılardan gelen ticketlardan anladık.
Çünkü bizim tarafımızda her şey okey görünüyor.
Süreç tamamlanmış görünüyordu.
Satıcılardan gelen ticketlardan bu aradaki farkı gördük ve bu ilgili güncellemeyi yani ilgili yere ne zaman dokunduğumuza bir bakalım dedik.
Kodlardan ilgili yere bir early return eklediğimizi gördük.
Yani işte şöyle bir koşuluş sağlamıyorsa return edip satıcıya işte güncelleme sürecinin sonucunu ileten kodu ulaşmamasını sağlamışız o early return ile.
Bunu fark etmiştik abi. Onu bunu hızlıca çözüp ilgili tarihten itibaren ürünleri tekrardan baştan tetikleyip süreçlerine olumlu ve olumsuz durumuna göre mesajlarını son haline iletip bu süreci böyle çözmüştük.
Burada fiziksel bağlılığı olan işlerde böyle instant olunca abi bunun geri dönüşü nasıl olacak gibi şeyler geliyor aklıma.
Ben de çünkü mesela full film tarafındayım.
Yani depo tarafındaki süreçlerde bir sorun oldu diyelim.
Bir ürün vardı biz iki tane gönderdik gibi böyle şeyler.
Mesela şey dedin ya ürünü maviydi yeşil diye koyduk ve o ürün satıldı hani diyelim.
Sen onu... İptal etmek için de vesaire uğraşıyorsun ya o yüzden onun maliyeti artıyor.
O yüzden böyle fiziksel şeyler olduğunda böyle incidentlar olduğu da etkisini böyle daha büyük hissediyorsun.
Değil mi? Sizde de öyle oluyordur diye tahmin ediyorum.
Kesinlikle direkt yani satıcının sonuçta siparişini de etki edecek bir durum bu.
Çünkü satıcı kırmızı yükledi ve satışta yeşil olarak görünüyor.
Bu tarz sorunlar daha böyle hızlı çözülmesi gereken sorunlar oluyor.
Orada da olabildiğince hızlı bir şekilde sorunu çözüp satıcının ürününün de aynı şekilde...
yani etkilenmiş ürünleri diyeyim, hızlı bir şekilde bulup düzeltmeye çalışıyoruz.
Dediğim gibi etkisi çok fazla oluyor bu durumlarda.
Ben de burada database ve mesaj ek sistemlerdeki yaşadığımız instantlardan bahsedebilirim.
Biz QC ekip olarak database ve mesaj ek sistemlerde başka ekibe bağımlılığımız mevcut.
Ve bazı durumlarda database'lerde ve mesaj ek sistemlerde problemler yaşayabiliyoruz.
Bu BF'in cönüsünde de meydana gelebiliyor ya da normal akışımızda da meydana gelebiliyor.
Bu tarz durumlarda ilgili ekiplerle hemen iletişime geçip aslında ilk önce sorununu anlamaya çalışıyorlar.
Ondan sonra da hemen aksiyonlara...
almaya çalışıyoruz. Günün sonunda veri kaybı yaşanmadan ya da herhangi bir kayıp yaşamadan oradaki sorunu çözüp oradaki insansı hemen bir an önce çözüp akışımızı normal bir hale getirmeye çalışıyoruz.
Bunun için uğraşıyoruz. Bu tarzda böyle ufak tefek bir iki problem geçmiş zamanda yaşanmıştı ama hızlı bir şekilde hemen çözülmüş diye açıklayabilirim.
İnsansları konuşmak güzel oldu.
Her ekipten böyle farklı hikayeler çıkıyor.
Sizin tarafta da bence güzel örnekler varmış.
Şimdi bir diğer merak ettiğim konu aslında takımın OKR'ları.
Kendinize nasıl hedefler koyuyorsunuz?
Bunları ne oranda gerçekleştirebildiniz?
aslında bunları da konuşabiliriz bence.
Burada takımımızın aslında iki ana hedefi mevcut.
Birincisi bize ürün, SPM'den ürün geldikten sonra bu ürün Ne kadar süreli satışa çıkabiliyor?
İkinci hedefimiz de toplam bize gelen ürünlerin yüzde kaçı herhangi bir manuel işleme tabi olmadan satışa çıkabiliyor.
Yani auto-approve dediğimiz bir süreçten geçerek herhangi bir şekilde takılmadan hızlı bir şekilde canlıya çıkabiliyor.
Bu iki metrimiz var. Birinci metrimiz ürünlerin canlıya çıkma süresinde şu an bir ürün ortalama 24 saat içinde trend yolda satışa çıkabiliyor.
Ana hedefimiz ilerleyen süreçlerde bu süreyi daha da azaltmak aslında ve ekip olarak bunun için de çalışmalara devam ediyoruz.
İkinci kısımda da Auto-approve dediğimiz yani ürün QC'ye geldikten sonra herhangi bir manuel işleme...
tabi olmadan hemen satışa çıkması sürecinde de %90'lık bir oranımız mevcut.
Bunda ilerleyen süreçte %95, %98, %100'e yakın sıcak şekilde bir oran olmasını hedefliyor ve bu konuda da çalışmaya devam ediyoruz diyebilirim.
Bununla beraber ekibin kendi içinde implementasyon yaparken koyduğu %90 kod coverıştır ve benzeri implementasyon kuralları var ama o biraz iş geliştirme verimliliğiyle alakalı aslında.
Durum böyle. Burada auto-improve kısmı baya önemli gibi ya.
Yani çünkü bellik sistemi daha da hızlandırıyor.
Tabii. Çünkü biz sonuçta outsource çalışan Bir ürüne karar bazı durumlarda otoyaprof sistemimiz karar veremiyor.
Çünkü otoyaprof sistemimiz bu üründe bir problem olabilir ya da bu üründe bir karar verilmesi gerekiyor diyor ve burada ürünü agent'a gösteriyoruz ve agent'ın aldığı aksiyona göre aslında biz bu ürünü yayına alıyor ya da geri.
temsilciye, satıcıya geri gönderiyoruz buradan.
Burada OTA Pro sürecini mümkün mertebe ne kadar az da arttırabilirsek eşitlere karar vermesi için o kadar az ürün sunmuş oluruz diyebilirim.
Mümkün mertebe aslında biz sistemlerimizi otomatize etmeye çalışıyoruz ve bunun için uğraşıyoruz.
Aynen aynen. Bu çok farklı bir kafa oluyor.
Bizde de aynı şekilde. Yani manuel süreçler sürekli oluyor ya da fiziksel ya da insan gücü gerektiren şeyler.
Bunlar bile olabildiğince böyle sistematik yapmaya çalışıyoruz.
Peki burada sizin ekibinizde iki tane QA vardı diye hatırlıyorum şu anda.
Burada QA tarafında ya da test tarafında yapılan işlerin testinde vs.
Bu işler nasıl ilerliyor?
Burada ben hızlıca biraz özetlemeye çalışayım.
Biraz test tarafında yapmaya çalıştığımız, denediğimiz şeyler fazla.
Bizim eski yapıda Docker Compose ile Docker içerisinde testler koşuyordu.
Event based olduğu için Dockerize etme ihtiyacı duymuştuk.
Bir de çok fazla HTTP call olunca servisler ayakta olmadığı durumlarda yani stage ortamlarında data bound veya ilgili ortamın çökmesi durumunda testlerimiz fail olabiliyordu.
Bunu Docker Compose ile çözmüştük ama Docker Compose'da da işte Docker faili ayarlama, servis bazlı Docker faili ayarlama veya işte test datasını Initial test adasını ayarlama gibi uğraşlarımız
vardı. Burada tech leadlerimizden Oğuzhan abi bu sorunu görerek buna STOV adını verdiğimiz framework ile yani Kotlin üzerinde çok hızlı bir şekilde basit bir implementasyonla çok hızlı bir şekilde ilgili projenin
içerisine eklenmiş bir çözümle hızlı bir şekilde end-to-end test yani end-to-end de diyebiliriz, acceptance test de diyebiliriz.
Adı değişebilir bakış açısına göre.
Bir servisin end-to-endini çok hızlı bir şekilde gitap...
Open Source etmiştik bu arada.
Stove girip bakabilirsiniz.
Stove üzerinden şu an için Captain's testlerimizi yazıyoruz.
Yine Ducker in Ducker kullanarak koşuyor bu testler.
Aynı şekilde pipeline'lara da ekledik bu yapıyı ve tüm kullandığımız servislerde bu testlerimiz şu an koşuyor ve pipeline'larda ilgili testler eğer geçmezse pipeline'i de kıracak şekilde ayarlı bir yapımız var.
Bunun dışında UI tarafında Cypress kullanılıyor.
Cypress ile testler yazılıyor.
Kontrakt test ile ilgili hala in progress olan bir prototipimiz var.
aslında. Bu proje henüz internal yani open source etmediğimiz bir proje.
Kendi ekibimizle ve related bizle ilişkide olan işte az önce saydığımız SPM Data Quality Media Center ekipleriyle kendi aramızda kurmaya çalıştığımız bir kontrakt folderı
üzerinden yani bir dosyalama sistemi üzerinden bu kontraktların paylaşılması prototipimiz var.
Yakın zamanda Tüm trendi yola belki de bir gün open source ederek tüm dünyaya açmayı düşündüğümüz bir prototip var diyebilirim.
Bir de şu an testleri bakış açımız şöyle end-to-end testler yani acceptance testleri.
Her iş sonunda tamamlamaya yani yazmadan çıkmamaya çalıştığımız bir bakış açımız var.
Şu anda da gayet güzel gidiyoruz.
Bazen end-to-end yani testin kapsamından dolayı süreci yani işin bitirme sürecini uzatabiliyor ama Sonuçta kaliteyi artırdığı için kaliteden ödün vermeme kısmında ilerlediğimiz
için test tarafını tamamlayarak gidiyoruz.
Burada da developerlardan destek alıyoruz.
Bizim bakış açımız burada değişiyor aslında diğer ekiplerden.
Developerlar acceptance testlerine sorumluluk alarak yazıyorlar.
Hatta isterseniz Muratcan veya İlker biraz daha detay verebilir burada.
Evet ben burada bir developer olarak detay vermek isterim.
Çünkü normalde developerdan bekleyen bir işi tamamlaması ve bir işi tamladıktan sonra yazdığı bölümlere unit testler yazması.
Tabii burada TDD adını verdiğimiz bir yaklaşım da var.
Önce testini yazıp daha sonra implementasyonu da yapabilir.
Ama bu yeni geliştirilen, ekip içinde geliştirilen stove aracı ile beraber biz developer olarak aynı zamanda acceptance testler de yazıyoruz.
Ve bu acceptance testler sayesinde aslında smoke testlere ihtiyaç duymadan günün sonunda o işin kapsamında bulunan o use case'i test etme imkanı buluyoruz.
Bu use case nedir? Mesela en basiten REST call'dan bir süreç REST call ile başladı.
Bir REST call ile geldi ya da atıyorum consumer'dan bir event konsum ettik.
Bununla beraber sürece başlıyoruz ve bunu...
Bununla beraber hangi sınıflara gireceğiz, hangi metotlara gireceğiz ve sonunda hangi çıktığı elde edeceğiz.
Bir developer bunların hepsini aslında günün sonunda kurgulayabileceği ve günün sonunda bunu hepsini çalıştırabileceği bir test yazabiliyor.
Ve bununla beraber aslında manuel test efonunu mümkün mertebede azaltabiliyoruz.
Hem bununla beraber hem manuel test efonu azaltabiliyoruz.
Manuel test efonu azalttığımız gibi de daha kaliteli kodlar çıkabiliyoruz.
Çünkü bir işi test ettiğimiz zaman işi test edilip doğru çalışması demek aynı zamanda bug'ın da az olması demektir.
Ve o kodu canlıya aldığımız zaman içimiz daha da rahat olabiliyor.
İlk başta acceptance testine yazılması biraz zor olabiliyor.
İlk başta alışması gereken bir süreç olabiliyor.
Ama alıştıktan sonra çok büyük bir rahatlık ve çok büyük bir kolaylık olduğunu da söylemek isterim.
Çok iyi ya. Developer tarafında...
Ben de yeni yeni şeyi duyuyorum ya bizde de olmaya başlıyor.
İşte hani developer testteki arkadaşlar direkt development'a giriyor ya da developer arkadaşlar direkt QA arkadaşlarımızın yazdığı işte bu acceptance test gibi application testler deniyor sanırım.
Oradaki testlere giriyor onları yazıyor vesaire gibi kısımlar var.
Hem böyle konfor alanımızdan da çıkmış oluyoruz.
O yüzden de güzel oluyor. Burada peki bu toplantı kısımları vesaire sizde süreçler nasıl ilerliyor?
Çünkü az önce bir hani işte bunun bug'a çıkmasıdır vesaire bir şeyler demiştin.
Genelde bir veya iki haftalık sprintler oluyor.
Ekipler daha önceki ekiplerde konuştuğumuzda bir iki haftalık sprint.
işte bir retro, bir grooming gibi bir süreç oluyor.
Ya da işte ayrıca aktarımlar olması için lunch and learn gibi ya da kitap sesyonları yapan ekipler oluyor.
Sizde genel böyle genel süreçler nasıl işliyor?
Bahsedeyim bu kısımdan. Biz iki haftalık sprintler koşuyoruz.
Sprintleri koşarken çoğu ekipten farklı yaptığımızı düşündüğüm bir süreç olarak groomingler var.
Biz aslında groomingler için herhangi bir toplantı vs.
düzenlemiyoruz. Groomingleri RFC templatelerine benzer bir template hazırladık groomingler için.
Bu template... etler üstünden götürüyoruz.
Bu temp date'lerde şunu edepiyoruz aynı zamanda grooming yaparken.
Hem asenkron iletişim sağlamayı hem de ekip içerisindeki bilgili işin know-how'ını tüm ekibe yaymaya amaçlıyoruz bu.
groominglerle. Aynı zamanda kalabalık bir ekip olarak grooming toplantılarını biraz uzayabileceğini varsayarak bunu daha böyle zamana yayarak sprint içerisinde çözüyoruz.
Daha sonrasında ise sprint sonlarında her sprintin son günü retrolarda gerek groomingleri gerek ise yaptığımız taskları değerlendirdiğimiz bir sürecimiz var.
Özette böyle diyebilirim.
Orayı merak ettim. Genelde grooming olmayan ekibe çok denk gelmiyorum o yüzden.
Grooming olmuyor. Onun yerine bir RFC template'i tarzında bir template olarak product'tan size PM'den istek geliyor.
O isteğin analiz, sprint içerisi analiz ederek bir sonraki sprint'e mi alıyorsunuz?
Nasıl ilerliyordu? Evet abi kesinlikle doğru tahmin.
Gelen işi önce groom ediyoruz.
Yani groom ediyoruz ama grooming üstüne herhangi bir toplantı yapmıyoruz.
Groom ederken yaptığımız grooming'i aslında bir döküman üstüne Yani şurada böyle bir şey yapacağız, böyle bir konsörlüğümüz var gibisinden.
Takım içerisinde de bu teknik detayları asenkron olarak konuşuyoruz.
Yorumlar geliyor bir iş üzerinden.
Bu yorumları bütün ekip görebiliyor.
Bunların approval'ını ekip içerisinde katılımcılarla beraber veriyoruz.
Örneğin 10 kişi inceledi, 3 kişi approve etti.
Bu işin groomingi bizim için tamamdır diyebiliyoruz.
Süreci burada böyle yönetiyoruz.
Bu çok iyi süreçmiş ya. Sevdim yani o süreci ve belli ki uzun süredir kullanıyorsunuz diye anladım.
Yeni bir geçiş miydi yoksa ne kadar süredir bu yöntemi kullanıyorsunuz?
Yaklaşık 3 aydır aslında bu yaklaşımı kullanıyoruz.
Grooming süreçlerimiz iyileştirmek için bu yeni bir yönteme geçelim dedik ve Senkron adı verdiğimiz grooming toplantısını kullanmak yerine asenkron bir şekilde bir groomingi sprinte enjekte ederek o groomingin sprint içine yönetilmesi ama yönetilirken de asenkron iletişimin
ilerletilmesi düşünüyorum.
bu şekilde açıklayabiliriz. Yararını görüyor musunuz?
Şu an memnun musunuz? Şu an aslında yararını görüyoruz.
Önceki groominglere göre başarılı olduğumuz noktalar var.
Çünkü iletişimler bir kere artık asekron olduğu için günün herhangi bir vakti, herhangi bir saatinde açık açık oraya yorum olarak yazabiliyoruz ve oradan gelen cevapları ona göre handle edebiliyoruz.
Aynı zamanda bir toplantıda sorulan sorular ve verilen cevaplar kısa olabiliyor ama bir grooming templatei yaklaşık 10 gün boyunca orada kaldığı için aslında o sorular hem orada kalıyor hem de uzunca bir threat oluşabiliyor.
Böylece ekip içindeki know-how da bir yandan sonrasında artmış oluyor.
Aynı zamanda bize şöyle bir avantajı var.
Yaptığımız işleri döküman halinde tutuyor oluyoruz.
İlerleyen zamanlarda dönüp bakmak istediğimizde bu işe burada hangi kararı aldık, ne yaptık gibisinden.
Yaptığınız işleri de dokumentasyonunu yapmış oluyorsunuz bu süreçte.
Gerçekten ilginç bir yaklaşımmış.
Aslında yani bizim ekipte de belki uygun olabilir.
Ben de ekipteki arkadaşlarla konuşacağım.
Sizden de sonradan tekrar feedbackleri almak isterim bu konuyla ilgili.
Olumlu oldunuz yine bir konuşalım.
Bunun dışında hep böyle iş bahsettik, süreçlerden bahsettik, çalışma şeklimizden bahsettik.
Bir de genelde ekipler böyle ekip ruhunu pekiştirmek için, ekibin kaynaşmasını sağlamak için bir şeyler yapıyorlar.
Bir tarafta var mıdır böyle uyguladığınız pratikler, işte buluşmalar?
İlk başta ben...
Açıklamak isterim. Yaklaşık ayda bir ya da iki ayda bir ekip buluşmalarımız oluyor.
Çünkü ekibimiz kalabalık bir ekip ve 3-4 arkadaşımız da şehir dışında.
Bu arkadaşlarımız İstanbul ofise geliyor ve beraber bir ekip yemeği düzenliyoruz.
Bu ekip yemeğinde aslında mekan çeşidinde biraz dikkat etmeye çalışıyoruz.
Bu konuda da gastronomi kültürü geniş bir ekip olduğumuzu söyleyebilirim.
Son 2-3 yemeğin çok beğenildiğini düşünüyorum.
Ve bol bol da yemek yiyoruz aslında.
Bol bol yemek yiyip sohbet ediyoruz.
Aramızda oyunlar oynuyoruz. Böyle oyunlarda güzel güzel eğlenip aslında birbirimize bir sürü mimler çıkartabiliyoruz.
bunlar ekipişle konuşulabiliyor.
Bununla beraber bizim zoomların içindeki roomlarda bir virtual office roomumuz da var.
Bu Virtual Office Room'umuzla beraber birbirimizle iletişim frekansını yüksek tutmaya çalışıyoruz.
Çünkü günün sonuçta birçoğumuz hatta neredeyse hepimiz evimizden çalışıyoruz ve bir yana sonra tek başımıza çalışmak bir yana sonra sıkıcı hale gelebiliyor.
Bu sıkıcılığın içinde kaybolmamak için aslında bu Virtual Office'lere girip orada hani beraber 3 kişi 4 kişi aynı Zoom'da beraber hem konuşarak hem çalışarak beraber sosyal ilimimizi artırmaya çalışıyoruz.
Ben ufak bir ekleme de yapayım.
Burada ek olarak şeyimiz de var yani Slack kanalımız da var aktif olarak sadece Tabiri caizse boş yapmak için kullandığımız bir kanalımız da var.
Oradan günlük konuları iletip oradan birbirimizle şakalaşmalar vesaire yapabiliyoruz.
Gündem o gün neyse onun üzerine de dönüyor.
Aylı cumalar, 1 Ocak, 2 Ocak, Ocak resmi paylaşma gibi böyle olaylar.
En sevdiğim kanal. Genel olarak boşları oradan yapıyoruz.
Bir de zaman bu aralar çok bulamadık ama toplaşıp oyun oynadığımız, online oyunlar oynadığımız bir takvimimiz de bulunuyordu.
Bu son zamanlarda biraz da kasım yoğunluğundan onu yapamadık.
Yine bir gün başlayıp tekrar devam ederiz diye düşünüyorum.
Uygun vakit bulunca tekrardan oyun oynayıp online oyunlarla vakit geçiririz.
Şu oyunlarda bir arabalı bir oyun vardı.
Crash bilmem ne. O güzel şimdi.
Smash Kart. Umarım evet.
Tavsiye ederim oynamadıysanız.
Biz abi onu oynuyoruz en çok ekipte.
Değil mi? Çok iyi. Bir Geocaster oynuyoruz.
Geocaster'ı tavsiye ederim. Tabi burada...
Marka ismi veriyoruz ama umarım şey olmaz.
Smash Kart bir de. Hexball'da da iddialıyız bu arada.
Bir Hexball turnuvası.
Bizim şeyde Tribe'de yapıldı Product Tribe'ında Hexball turnuvası.
İşte bu ya. Ordu tabii bazı takımlar için hoş şeyler olmadı.
Bazı takımlar için çok güzel şeyler oldu ama eğlenceli bir süreçti.
Güzel rekabet en iyisi.
Tabii rekabeti seviyoruz.
Ek olarak bir de çok fazla şeyimiz var böyle.
Anlık bir olaydan işte takım ofiste buluştuk.
Baklava yedik.
Hemen oradan komik bir olayın hikayesini yazıp böyle editör arkadaşlarımız da var ekipte.
Hemen bir edit yapıp anı ölümsüzleştiren arkadaşlarımız da var.
Böyle böyle ufak dokunuşlarla eğlenceli anlarımızı ölümsüzleştiriyoruz.
Ben son olarak şunu da ekliyorum. Sonra podcast'i bitirmek isterim.
Biz aynı zamanda sabah 9, akşam 6 içinde konuşmuyoruz.
Akşam Instagram ve WhatsApp kanallarımız da mevcut.
Bu Instagram ve WhatsApp kanallarımızda da komik gördüğümüz şeyleri birbirimize paylaşabiliyoruz.
Ya da bazı ekip arkadaşımız eğer uygunsa akşam bir vakti hadi kuzuya gidelim, hadi çorbaya gidelim, hadi çay içmeye gidelim, bir şeyler yapalım tarzı mesajlar olabiliyor.
Ve o lokasyonda bulunan arkadaşlarımız mesai saatten sonra da beraber oturup aslında bir şeyler paylaşabiliyor.
Günün sonunda bu ekip verimlerini bu şekilde artırmaya çalışıyoruz.
Hem ekip arkadaş hem de arkadaşız.
Gayet güzel şeyler anlattınız vallahi ya gerçekten.
Bizim ekipte benzer şeyler yapıyoruz ama sizde böyle birazcık daha kuzu falan deyince yemek odaklı güzel bir şey gördüm.
Teşekkür ederiz katıldığınız için.
Güzel, keyifli bir bölüm oldu.
Yine çok güzel bölümde teşekkür ederiz.
Rica ederim. Rica ederiz.
Çok teşekkürler. O zaman bir sonraki bölümde görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.