Transkript
Evet, programı açmamız gerekiyor.
Çalıştığım ekibi de ben tanıtacak değilim.
Ben de, ben yolculuğum için.
Ama bence sen tanıtabilirsin, sen daha yakınsın çünkü.
O zaman SEDEM ekip programına hoş geldiniz diyerek başlayalım.
Aradan bu sefer iki hafta geçti.
Sanırım iki haftada bir yapmaya başlayacağız.
Öncelikle Barış Özaydın ve Onur Aykaç'la birlikteyiz.
Nasılsınız arkadaşlar? Teşekkürler.
Teşekkürler, iyiyim. Ben mutluyum.
İyidir, hiç görüşmüyormuş gibi.
Bu hafta Customer Service ekibiyle birlikteyiz.
Merve Çolak ve Kubilay Örcün ile beraberiz.
Arkadaşlar kendinizi tanıtabilir misiniz biraz?
Tabii ki tanıtalım. O zaman ben birazcık atlayayım hemen Merve'nin önünden.
Ben yaklaşık bir sene olacak galiba Customer Service ekibine katıldım.
Geçen sene mezun oldum zaten.
Sonrasında da bir staj programı vasıtasıyla sonrasında Trendyol yolculuğuna devam etmiş olduk.
Software Developer olarak çalışıyorum Customer Service ekibinde.
Gayet de keyifli bir şekilde ilerleyen bir süreç var şu an.
Kubilay Örcün zaten ismimde söylendi.
Başka da şu an içine ekleyeceğim bir şey yok.
Ayrıntılara birazdan gireceğiz zaten galiba.
Topu da burada Merve'ye atabilirim.
Selamlar herkese. Benim ismim Merve Çolak.
Ben de iki yılı biraz aşkın bir süredir Trendyol'da çalışıyorum.
Customer Service ekibinin ve chat ekibinin Product Owner'dan üstleniyorum.
Güzel bir ortam var burada.
Konuk olduğumuz için ve bizi davet ettiğiniz için teşekkür ederiz.
Ne demek. Çok seve seve davet ettik.
O zaman ben şeyle başlayayım.
Bizim domenimiz... Bizim domenimizde miyim?
Çalıştığınız domen ne iş yapar?
Bizim memleketimiz.
Soru sorarken her soruda böyle bir şey yaşayacağım galiba.
Arkadaşlar, Customer Service Domain ne iş yapar?
Yani burada birazcık ben bir gireyim yine tekrardan.
Sonra eksik kaldım yer oluşturan Merve sen de tamamlarsın diye ümit ediyorum.
Bizim tarafta öncelikle...
User agentlerimizin kullandığı, yani müşteri hizmetli yetkililerimizin kullandığı, yani onlar bizim clientimiz oluyor ağırlıkla, ekranlara destek veriyoruz.
O ekranlarda geliştirme yapıyoruz.
Aynı zamanda maintenance'ını üstleniyoruz ekranların.
Aynı zamanda bir sesli yanıt sistemimiz var.
Bu sesli yanıt sistemine dönen cevapları yazdığımız bir servisimiz var.
Orayla biz ilgileniyoruz. Aynı zamanda son dönemeçte de birçok iletişimi, yani push, SMS ve mail iletişimini...
%99 oranında bizim ekip üzerinden akıyor olacak artık.
Hepsi bizim üzerimizde değildi.
Bir yandan da onları taşıyoruz şu an için.
Bunun dışında da şu an düşündüğümde hemen aklıma gelen başka büyük bir domen yok galiba ilgilendiğimiz.
Merve'ye atabilirim herhangi bir eksik kaldığım bir yer olduğunu düşünüyorsa.
Yo aslında Kubilay çok güzel özetledin.
Dediğim gibi bizim müşterilerin ulaştığı noktada çağrı merkezi çalışanlarımızın kullandığı CRM suğlunu yazan ekip bizim ekip.
Burada da böyle yalınlığı ve işte...
Çok çeşitli agent grubu var.
Agent diyoruz biz temsilcilerimize.
Onların en kolay kullanımı sağlayacağı şekilde geliştirmeye çalışıyoruz.
Transaction iletişimler var aynı zamanda.
Yani siparişe dair bütün iletişimler bizim ekipten çıkıyor.
Bir de IVR'a değinebiliriz aslında.
IVR'de bizim bir ses servis uygulamamız.
Burada da müşteriler bizim çağrı merkezimizi aradıkları zaman önce bir ses yanıt sistemi karşılıyor.
Orada da işte proaktif anonslar dönüyoruz.
Ayrıca bir de ticket uygulamamız var.
Ticket'ı da şey gibi düşünebiliriz aslında hani müşterilerin ilk kontakta çözüm bulamadığı detayları böyle daha detaylı incelememiz gerekiyorsa işte kargoya ya da satıcıya sormamız gerekiyorsa bunlar
için bir ticket yaratılıyor.
Orada da bir outsource firmayla çalışıyoruz.
Oradaki servis entegrasyonlarını işte müşteri bilgilerini, sipariş bilgilerini falan besliyoruz diye özetleyebiliriz aslında bizim ekibin yaptıklarını.
Peki Ticket da outsource firma dedin.
Bunun gibi daha öncesinde de bahsettiğin IVR'da mesela bir şey kullanıyor musunuz?
Hazır bir çözüm kullanıyor musunuz?
Yoksa siz mi implement ediyorsunuz IVR'da?
Aynen Onur. Orada da bir third party ile çalışıyoruz aslında.
Hatta böyle oradaki anonslar falan da bisikletler tarafından okutuluyor.
Yine bir third party çözümle ilerliyoruz IVR'da da.
Bizim kısım birazcık daha servis besleme kısımları oluyor.
Peki, geçen hafta Women in Tech'e de katılmıştın Merve, orada da bahsetmiştin.
Yine böyle dinleyicilerimiz için de bize Customer Service ekibi hangi ekiplerle, hangi domenilerle yakın çalışır, hangi domenide ne için yakın çalışır, bunu böyle bir özetleyebilir misiniz?
Tabii ki. Ekibimiz en çok OMS dediğimiz Order Management System ekibiyle çalışıyor aslında.
Çünkü direkt ekranda da böyle gösterdiğimiz bilgiler hep order bilgileri.
Bunun yanı sıra Storefront ekiplerle yakın çalışıyoruz.
Müşterilerin bize en çok kontak kurduğu kısımlarda işte biz bu ihtiyacı nasıl ters servis kanallara taşıyabiliriz?
İşte oradaki hani bize gelmelerini engellemek için ve kendi çözümlerini direkt uygulamada bulabilmeleri için neler yapabiliriz onları konuşuyoruz.
Cüzdan ekibiyle yakın çalışıyoruz.
Çünkü hani müşterilerde cüzdanla ilgili siparişleri için geldiği zaman onların bilgilerini göstermek için de cüzdan servislerini kullanıyoruz.
Aynı zamanda payment ekibiyle yakın çalışıyoruz yine.
Özellikle fraud ekiplerimiz çok çok kullanıyor.
Bankalardan gelen fraud case'lerinde falan direkt payment bilgilerini görmemiz gerekiyor.
Kupon ekibiyle yakın çalışıyoruz.
Aslında birçok ekiple yakın çalışıyoruz biz customer service ekibi olarak.
Çet ekibiyle yakın çalışıyor musunuz?
Çet ekibiyle de çok yakın çalışıyoruz.
Çet ekibiyle yan yana çalışıyoruz.
Ben de şeyi sorayım.
Biraz ekip yapısından da bahsedebilir misiniz?
Kaç kişilik bir ekibiniz var?
Hangi rollerdeki insanlar var ekipte?
O zaman orada topu ben alayım.
Ekibimizde Merve zaten adı burada.
O PO'muz olarak çalışıyor ekipte.
Fırat var o da zaten şu an aramızda.
Yaklaşık olarak şu an için 7 developer bir product owner şeklinde.
Bir de QA arkadaşımız var.
Aynı zamanda son dönem işte ekibimize dahil olan bir arkadaş daha oldu Ruken.
O da PO olarak dahil oldu ekibimize.
Böyle bir yapımız var şu an için.
Ya back-end, front-end gibi çok keskin ayrımlar gözetmiyoruz aslında şu an takımda.
Biraz daha eskiden belki hani şöyle ayırabiliriz bir noktada belki.
Bir arkadaşımız işte front-end'de daha fazla know-how biriktirmiş oluyor ve belki front-end tasklarında pair girdiğiniz noktada daha ağırlıklı onunla pair olmaya çalışıyoruz gibi durumlar söz konusu oluyor ama işte ben back-end'im asla front-end yazmıyorum.
İşte o arkadaş front-end asla benimle gelip de bir servis yazarken bana dahil olmuyor, pair olmuyoruz gibi bir durumda söz konusu değil aslında.
O yüzden daha çok işte developer.
olarak geçiyoruz ekipteki diğer arkadaşlarla.
O şekilde söyleyebilirim görev tanımlarımızı ve ekip yapısını.
Peki hani ekibinizde yeni başlayan kişiler oldu mu yakın zamanda?
Böyle onboarding stratejinizi nasıl?
Bilmiyorum işte bir sormak çok zor gerçekten.
Aynen çok da şey oluyor zaten Fırat böyle sorarken bilerek sorduğunda belli oluyor.
Burada topu ben alayım.
Yakın zamanda Bilal de bahsetti.
Ekibimize yeni bir product arkadaşımız başladı.
Orada da aslında önce tabii bodyler belirleniyor her başlayan yeni arkadaş için.
Çünkü bu süreçte zaten uzaktan yönetiyoruz.
İşte remote çalışıyoruz ve ekibe hızlıca adapte olması çok önemli.
Bu kapsamda onboarding dökümanları hazırlanıyor.
Mesela ben kendi adıma konuşayım.
İşte en çok kullandığımız tool'lar nelerdir?
İşte hangi projeler var?
Projelerin dökümanları nelerdir?
Kullandığımız böyle en çok takip ettiğimiz raporlar nelerdir?
Bunları böyle bir onboarding dökümanına paslıyoruz.
Sonra da zaten ilk gün mutlaka ekip tanışma toplantıları oluyor.
Ve ilgili haftada da işte en yakın çalıştığımız ekiplerle tanışma toplantıları.
İşte yan ekiplerle tanışma toplantıları falan oluyor.
Burada da hani onboarding sürecinde olabildiğince birçok toplantılara dahil ederek proje aktarımlarını gerçekleştirerek hızlıca adapte olmasını sağlamayı hedefliyoruz.
Development tarafı için ben de topu kubilaya atayım.
Aldım ben de topu o zaman.
Bu benim için zaten böyle çok eski bir hatıra değil.
Yani bu geçen yaz aylarında ben de aslında ekme dahil oldum.
Biraz da şeye hoşuma gitmiştim.
İlk dahil olduğumda açıkçası onboarding süreçleri.
Şimdi HR tarafı biraz daha işte trend yoluna alışmak, kültüre alışmak tarafı.
Çok teknik bir insan olmanızdan ya da işte bir PO olmanızdan vesaire değişen şeyler olmuyor.
Ama teknik tarafta biraz da şundan bahsedebilirim.
İşte buraya geldim.
Milyonlarca insanın kullandığı sürekli 7-24 ayakta olan bir sistem var.
Ben production dediğimiz canlı ortama bir şey mi yapacağım?
Nasıl yani? Üç gündür daha buradayım gibi düşünceler oluyor insanın kafasında.
Bir de yaparsam ya bir şey olursa ya kırılırsa.
Böyle düşünceler oluyor ama sonrasında buradaki kültür birazcık sizi aslında bunlardan sıyrılmanıza sebep oluyor da diyebilirim.
Çünkü sürekli yanınızda abi onu yap korkma.
Çünkü bir şeyleri kırmaktan korkmamak lazım gibi bir bakış açısı da var bir noktada.
Yani bunu yapalım. Kırılırsa da bir şekilde tahmin ederiz.
Tabii ki kırmamaya özen gösterelim.
Tabii ki bütün önlemleri alalım.
Bütün önlemleri aldığımız, hesap ettiğimiz noktada bir şeyleri kırıyorsak, bir şeyler sıkıntıya giriyorsa da bunu yine takım olarak üstlenip beraber çözmeye özen gösteriyoruz.
O yüzden o korkuyu da aslında çok kısa sürede yeniyor insan kendi içinde.
Kendi adıma ben geldikten 3 gün sonra yeni mezun bir çiçeği bulunduğunda bir mühendis olarak aslında 3 günün sonunda biz meclislerimizin kullandığı ekranlarda onlara yardımcı olan dokümanları sergiledik.
Bu kısımla ilgili faz 2 çalışmalarına başlayıp da Prolaction'a kod göndermeye başlamıştım aslında.
Ve acayip bir tatmin etkisiydi benim için de.
Hiç beklemediğim bir süreçti serüvende.
Bir o kadar heyecanlı ve keyifli de oldu.
Bu şekilde aslında onboarding'in teknik tarafında da nasıl bir farklılık oluyor ondan bahsetmiş olabilirim.
Bulunduğun ekibin, şirketin kültürü gerçekten çok fark ediyor.
Biz de tabii pandemiden önceydi.
Barış, Fırat, üçümüz benzer zamanlarda Trendyol'a katıldık.
Ve işte bir dört günlük balt bir onboarding süreci oluyordu.
Orada böyle aralarda işte Barış'la konuşurken şeyi hatırlıyorum.
İkimiz de aynı şeyi hissetmiştik.
Böyle farklı çalışma grupları ile çalışıyoruz ama toplandığımızda sanki bu insanları yıllardır tanıyorum, bu insanlarla yıllardır beraber çalışıyor gibi hissetmiştik.
Böyle onu paylaşmıştık birbirimizle.
Gerçekten girdiğin şirket senin onboarding sürene çok ciddi katkıda bulunuyor.
Peki burada kullandığınız teknolojiler neler?
Gündelik rutininizi alan ya da şöyle hani primary olarak diyebileceğiniz APR'leriniz, konsümörleriniz hangi dille yazıyorsunuz?
Onun dışında ne teknolojileri kullanıyorsunuz?
O noktada yine böyle bir araya atlayayım, birazcık bahsedeyim genel aslında kullandığımız.
Programlama dillerini sayacağım birazcık.
Tabii ki bunların artık şeyi değişiyor.
X programlama dili var, onu aldık dümdüz yazıyoruz.
Konsol uygulaması yazıyor olmadığımız için işte kullandığımız frameworkleri, kütüphaneleri, performansı vs.
Çok multifaktorial bir iş aslında bunları seçmek de artık bizim için.
Ama yani genel olarak yaklaştığımızda dil olarak Java, Go, Kotlin, .NET yani C-Sharp aslına bakarsan bu tür diller var şu an için aslında bizim de şeyimizde.
kontrolümüzde olan ve şu an kullandığımız aktif olarak günlük günlük dozda diyeyim kesinlikle.
O şekilde bunların tabii ki işte bir REST API yazıyor olursak işte Java'nın bunu destekleyecek ve bununla alakalı en iyi çözümümüzde sunan frameworklerinden biri olan şu an için ağırlıklı olarak Spring Boot'u kullanıyoruz.
Aynı şekilde bir consumer yazacağımız zaman da eğer bunu Java'da yapıyorsak Spring'in çözümlerini tercih ediyoruz şu an için.
Ama işte Go tarafında yazdığımız servislerimiz de var REST API'larımız da var.
Onunla alakalı Go'nun sunmuş olduğu işte REST, EGIN gibi farklı teknolojiler var.
Bunu yapmamızı sağlayan. Bunları kullanıyoruz.
Ama bunların dışında bence şeyler de çok kıymetli.
Onlar çok atlanıyor bu tür şeyleri özetlerken.
İşte işin test boyutunda, işte integration testlerimiz, işte kontrakt testlerimiz.
Bunlarda ne yapıyoruz? Bunları geliştirmek için ne yapıyoruz?
Şuna bir noktada özen gösterdiğimizi söyleyebilirim.
Unit test zaten Allah'ın emri gibi bir şey oldu bir noktada.
Unit test yazalım ve coverage'imizi sağlam tutalım.
Çünkü biz bu sistemleri aylar boyunca maintain edeceğiz.
Ki başımızı ağrımasın uzun vadede.
Ama bundan sonrasında da diyoruz işte integration test yazalım.
Nasıl yazalım? Bu teknolojiyi kullanarak yazalım.
İşte cucumber ile yazalım. Ama işte çok fazla dış API'ye bağımlıyız biz.
Bunu nasıl azaltabiliriz?
Bunu azaltmak için de mesela bunları mocklayabileceğimiz ve onlara olan bağımlılığımızı minimize edebileceğimiz tool'ların arayışına çıkıyoruz.
Yani böyle temel bir aslında tek siteyimiz var.
Bunun üzerine ihtiyaca yönelik işte biz bir şeyi mocklayacağız.
Bunun için en iyi çözüm nedir?
Onu tartışıyoruz. Sonra buluyoruz.
O çözümle alakalı takımla beraber böyle bir şey yapmayı düşünüyoruz.
Böyle bir şey yapsak bize faydası ne olur, zararı ne olur?
Bunun hep tartışmalarını yapıyoruz.
Sonrasında toplu karar veriyoruz.
Hiçbir zaman zaten bireysel çıkışlar genellikle takım kararlarıyla sonuçlanmaya özen gösteriyoruz.
O şekilde özetleyebilirim sanırım.
İşin deployment ve network tarafında da Kubernetes, Docker gibi farklı teknolojilerden fayda alıyoruz deyip oraya çok fazla detaya girmeden toparlamış olayım.
Çok güzel özetledin bence.
Merak ediyorum ben de. Aslında...
Son kullanıcılar böyle genelde işte bir şeylerden şikayetçi olduğu zaman işte gelip ya chatten ya da işte IVR'dan sorunlarını dile getiriyorlar ve işte o tarafta da çok böyle bir sorunla karşılaşırlarsa
daha da böyle demorize olacak o kullanıcılar, müşterilerimiz.
Bu tarafta böyle son kullanıcıyı çok da fazla etkilemeden deepdorm süreçlerinizi nasıl yönetiyorsunuz?
Neler kullanıyorsunuz oralarda?
Açıkçası son kullanıcılarımız bizim platformu geliştiren arkadaşlardan ziyade Merve'nin de daha önce bahsettiği gibi bizim müşteri yetkililerimiz diyeyim yani müşteri hizmetlerimiz oradaki agentler daha çok bizim son kullanıcılarımız
oluyor. Onlar için de aslında çok riskli bir durum gördüğümüzde gerçekten o zaman mesela bir teknik borç biriktirdiysek geliştirme yaptığımız uygulamayla alakalı küçük bir risk görüyorsak mesela bunu...
daha böyle yoğunluğun platformda az olduğu saatlerde de canlıya çıkma durumunu gerçekleştirmek zorunda kalabiliyoruz.
Ama bu bizim için worst case senaryosu gibi bir şey.
Yani birçok uygulamamızın zaten bu noktaya gelmesini asla biz normal şartlar altında istemiyoruz.
Onun dışında da zaten biz işte stage ortamları olsun, production ortamları olsun, proda gelene kadar tostun bizim uygulamamız aslında birçok stage'den geçtiği için işte bizim QA'miz bunun üzerine manuel testlerini gerçekleştiriyor,
integration test pipeline'larımız koşuyor, unit test cover'ıcılarımız yüksek.
Zaten biz bunu mümkün olduğunca otomasyona sokuyoruz.
O yüzden beklentimiz biz production'a bir uygulamaya çıktığımızda hatasız ve pürüzsüz bir şekilde ilerlemesi.
Çıktığımızda bir hata oldu.
Onun oradan recover etmek istedik bir şeyleri.
O noktada zaten CI-CD pipeline'larımızı kullandığımız için hemen bir önceki versiyona dönüyoruz.
Bu hatadan kurtuluyoruz gibi.
Oradaki hatalar çok yoğunlaşmadan bizi sıkıntıya sokacak seviyeye gelmeden oradan recover etmeye çalışıyoruz o durumu.
O şekilde özetleyebilirim.
Burada belki şeyden bahsedebilirim.
Kuvvet'in bahsettiği gibi böyle bazen gece deployment yapmamız gereken durumlar olabildi.
Ancak onları da bir şekilde çözmemiz gerekiyor.
Çünkü aslında bizim sürekli canlıya çıkabilmemiz gerekiyor.
Onunla alakalı da bazı uygulamalarımızda test eksiği olduğunu gördük.
Örneğin agentlerin kullandığı sayfalarda test eksiği olduğunu gördük.
Ve bununla alakalı acceptance testleri yazdık.
Ve python'ımızı ntg ettik.
Şu an orada çok daha rahatlıkla ilerleyebiliyoruz.
Ki genelde zaten yolumuzda böyle oluyor.
Bir şey bizim canımızı sıkıyorsa bizim buna eğilmemiz lazım.
Çözerek devam ediyoruz. Şimdi az önce unit test yazdığınızdan bahsetmiştim Kubilay.
Bu tarafta mesela TDD uyguluyor musunuz ya da işte code review yapıyor musunuz?
O mühendislik kültürünüzün içerisinde neler var?
Biraz daha bunlardan bahsedebilir misin?
Tabii ki abi oraya da girelim birazcık.
Öncelikle bir unit test olayından bahsedeyim.
Unit testli biz birazcık bakış açımız şey.
Tabii ki biz işte elimizdeki idelerin bize sunduğu olanaklardan fayda alalım ve işte oradan kavurucu bakalım.
İşte kavurucumuz iyiyse iyidir.
Bir bakış açısından aslında tabii ki bu bir faktördür.
Yani coverage'in yüksek olması bizim için iyi bir şeydir.
Ama bu her zaman gerçekten doğru unit testi yazdığımızı da bize aslında göstermiyor her case'de.
Bu tür şikayeleri aradan kaçabiliyor.
O yüzden mümkün olduğunca bunun da çözümü olan aslında bir noktada TDD gibi metodlara da kaymaya çalışıyoruz elimizden geldiğince.
Şu an TDD'de biraz daha böyle elimizin alışık olduğu işte zaten bu servise biz bayağıdır işte yeni bir endpoint ekliyoruz.
İşte var olan endpointle değişiklik yapıyoruz.
Biz buraya zaten yeni bir end point ekleyeceğiz.
Daha önce de çok benzer bir iş yaptık.
Bu sefer bizim için de yeni bir challenge olması hem bizi hem de projeyi hem de ekibimizi daha iyi bir noktaya taşıyabilmek için neden TDD yapmayalım gibi bir bakış açısı oluyor.
O noktada bununla ilgili böyle çok fazla deneme yapıyoruz elimizden geldiğince.
TDD yazarken de her zaman şey oluyoruz yani biz bunu bazen unutuyoruz bazen yapmıyoruz ama yaptığımız noktada gerçekten neden böyle bir metodoloji var ve neden bazı şeylerin daha iyi olmasına sebep oluyor onu her seferinde görme şansı yakalıyoruz.
Onun dışında abi atladığım, cevap vermediğim bir soru kaldığımı sorduklarından ben arada kaçırmış olabilirim bir şey.
Yok gayet güzel özetledin.
Teşekkürler. Tamamdır.
Anlaştık. Peki Customer Service ekibinin monitoringi nasıl oluyor?
Yani hangi belleri topluyorsunuz ve nerelerden alert oluyorsunuz?
Incident oluştuğu zaman nasıl haberdar oluyorsunuz?
Bu noktada şunlardan bahsedebilirim.
Zaten belki dinleyen arkadaşlar da daha önceden duyduğu teknolojilerdir.
Öncelikle incident boyutunda bir APM'imizin, bir servisimizin hata oranı arttığında ya da response time'ları artık çok artmaya başladığında.
Bizim işte Nivrelik'te ekranlarımız var.
Gerek buralardan haberdar oluyoruz, gerekse işte bu alertlerin.
Düştüğü işte kanallarımız var.
Buradan bir alert aldığımızda.
Ha evet bunun error rate'i işte %1 trash olduğunun üzerine çıkmış.
Bununla ilgili bir aksiyon almamız lazım.
%1 trash olduğunun üzerinde mi seyrediyor?
Ya da bu %1 trash olduğunu mesela 5 dakikalık zaman aralığı boyunca sürdü.
Sonra indi. Peki bu 5 dakikalık zaman aralığında ne yaşandı?
Gidip hani bizim için çünkü şeyde değil bir noktada artık.
Yani sürekli 7-24 ayakta olan bir sistem olduğu için.
5 dakika çıktı indi düzeldi toparladı.
Sıkıntı yok gibi bakış açısından ziyade.
5 dakika çıktı ama bu...
Demek değil ki gidip de 15 dakika da çıkabilir bundan yarım saat sonra.
Tekrar aynı şeyi yaşayabiliriz.
O zaman bizim burada bir sıkıntımız var.
Ya da bir ekipten dolayı bağlı olduğumuz bir başka servisten dolayı bir sorun yaşadık.
Bununla alakalı nasıl hızlı bir aksiyon alıp bir çözüm üretebiliriz?
Bununla ilgili işte farklı alert mekanizmalarımız zaten var.
Niveling tarafından düşen alertlerimiz var.
Aynı zamanda işte Kafka gibi teknolojiler kullanıyoruz.
O taraftaki işte consumerlarımızın lagları nasıl?
Arttı mı? Belli bir trash oldu mu?
Üstüne çıktı mı? Error topiklerimizde çok fazla birikme var mı?
Çok fazla birikme varsa neden birikiyor?
Hangi eventlerimiz o topiklerde o an birikiyor?
Gibi işte bu alert mekanizmalarından bize dönen sonuçları aslında analiz edip şurada bir sıkıntı var, neden var ve nasıl çözebiliriz gibi aksiyonları hemen almaya çalışıyoruz.
Incident noktasında da şöyle bir şey söyleyebilirim.
Daha önce ya tabii ki instantlar yaşıyoruz, sorunlar oluyor.
Yani çok bir sürü code review sürecimiz ve test sürecimiz olmasına rağmen gözden kaçan şeyler olabiliyor her türlü bu süreçlerde.
O noktada mesela unuttuğumuz, eklemeyi unuttuğumuz bir şey var.
Bir config satırı vardı diyeyim.
Çok küçük bir alan. Time to live gibi bir konfig vermemiz gerekiyordu kullandığımız bir kütüphaneye ki içeride geliştirdiğimiz bir kütüphane o da.
C'den potent onlara ekranını yapmış olayım buradan open sourcedur.
O şekilde orada geliştiğimiz bir şey vardı.
Onu kullanıyorduk. Orada bir instanta sebep olmuştuk.
Onda başka sorularda daha ayrıntısına gireriz olmadı.
Ben Kubilay'a bir şeyin eklemesini yapabilirim.
Bizim transactional iletişimlere atan ekibiz ya aynı zamanda.
Orada da günlük raporları takip ediyoruz ve aslında bir önceki günden dramatik bir düşüş yaşandıysa burada third party tarafında bir sorun olabilir gibi bir alarm üretiyoruz.
Tekir gelen örnekler de olabiliyor bizim uygulamalarımızı kullanan ekiplerden.
Daha çok back office dediğimiz deneyimli temsilci arkadaşlarımızdan oluşuyor.
Orada da hani nöbetçilik sistemi var ekibimizde.
Nöbetçi arkadaşımız ilgili sorunu tespit edip hani ilgili kanaldan da dönüşleri sağlıyor.
Ben de şeye ekleyebilirim. Geçtiğimiz hafta bir incident oldu.
Bir hata gelmiş ve gerçekten de alarm kanallarımıza düşmüş.
Hatta alarm kanallarını ayırmıştık biz.
Selam ekipten öğrendiğimiz bilgilere göre.
Kritik hataları başka bir kanala düşürüyorduk ama akşam gelmiş ve gözümüzden kaçmış.
Böyle iki saat boyunca devam etmiş ve etkisi büyük oldu bizim için.
O alarmlar için şimdi PagerDuty entegasyonu yapıyoruz.
Bu sayede telefonla aranacağız.
Güzel bir şey gerçekten. Belki biz de düşünebiliriz böyle bir şeyi.
Ve şeyi sorayım ben de.
Cartoon Search ekibi olarak en büyük challenge nasıl?
Nedir? Burada ben mi gireyim Kubilay?
Burada topu bir sana atayım.
Ekleyeceğim bir şey olsa ben de senden sonra alırım bir topu.
Bizim şu anda hani trend yol çok büyüyor ve sipariş sayıları artıyor.
Sipariş sayıları arttıkça da bize kullanıcılarımızın ulaşma sıklığı da artıyor.
Bu durumda da bizim ekranlarımızın en kolay kullanılabilir halde yapmamız çok önemli.
Bir sürü agent var, temsilci var.
Onların en kolay şekilde kullanabilmesini sağlamak, yeni gelen temsilcileri hızlıca onboard edebilmek, ekranın yalın ve nizami olması, işte yapılan bir işlemin hata mesajları bile olsa onları çok açıkça
dile getirmek. Aslında uygulamaların kullanım kolaylığını...
sağlayabilmek bizim en büyük challenge'ımız.
Çünkü içeride de 2000'e aşkın temsilci var sadece customer tarafında.
Bunun bir yandan seller, influencer gibi detaylarda da ayrıca çağrı karşılayan kontaklar oluyor.
Bu gibi durumlar aslında bizi en çok baktığımız yerler diyebilirim.
Burada ben hemen Merve'nin arkasından biraz teknik adam bakış açısı gibi olacak ama o en büyük challenge demişken en büyük ikincisi gibi hissettirebilecek bir challenge'dan bahsetmek istiyorum ben de.
Yani teknik tarafta da bir ara değindik sanırım ona da.
Böyle birçok ekiple haberleşiyoruz işte dirsek temasında çalıştığımız birçok ekip var.
Merve'nin de daha önce bahsettiği gibi birçok ekip adı saydı.
Yani bu da bize şey olarak dönüyor aslında günün sonunda.
Yani tren yolundaki bütün ekipleri böyle bir insan vücudu gibi hayal edersek yani biz bunun kolu bile olsak.
İşte kafada bir problem var işte o yüzden parmakların seğirmeye başladık durumu yaşanabiliyor.
Bu yaşanınca da aslında evet aslında elde değil bir problem kafadan kaynaklanıyor gibi farklı bağımlılıklarımız var.
Yani bizde bir incident oluyormuş gibi hissediyoruz bir yerde bir response time'ımız belki artmış oluyor.
Ama o noktada belki de işte gittiğimiz başka bir servisteki bir incident yaşanıyor ve oradan cevap alamıyoruz belli bir süreliğine.
Bu tür bağımlılıkları özellikle test aşamalarında mümkün olduğunca azaltmaya çalışmakta.
farklı challenge'lar oluyor. Aynı zamanda alert mekanizmaları vesaire gibi gözlemlediğimiz noktalarda da belli sorunlara sebep olabiliyor.
Çünkü sorun bizdeymiş gibi hissedip de aslında başka bir ekibin bir servisinde bir sorun olduğunu sonradan fark edebiliyoruz.
Teknik tarafta da aslında böyle ufak challenge'lar da var kendi adımıza belirtmem gerekirse.
Belki burada bir eksikliğimizden bahsedebiliriz.
Bizde kontrat test çok az.
Yani şu an sadece kendi iç apillerimiz için kontrat test yazmış durumdayız bir yerde.
Ama diğer ekiplere gittiğimiz noktada kontrat test olmadığı için kırılgan bir durumdayız.
Bir sonraki hedefimiz de burayı düzeltmek olacak.
Ben bir de şeye değinebilirim aslında.
Şimdi müşterilerin bize kontak kurduğu durumlar daha çok böyle siparişiyle ilgili yaşadığı sorunlar da olduğu için hani bu noktada müşteriye doğru ve hızlı bir şekilde cevap verebilmek de çok önemli.
Bu gerek işte yaptığımız iletişimlerin zamanında atılması ya da müşterinin bize ulaştığı noktada hızlıca agentlerimizin destek olabilmesi, onun ihtiyacını giderebilmesi.
Bu gibi durumlar hani müşteri toleransının da birazcık orada esnek olmamasından dolayı bizim için çok daha fazla bir challenge yaratan süreç oluyor.
Peki sürekli iyileşme anlamında en son Retro'da konuştuğunuz konu nedir?
Ya da genel olarak böyle Retro'ların bir teması var mı?
Tekrardan bir işi var mı? Orada ben hazır birazcık hile gibi de oluyor ama son Retro ile alakalı ufak notlar da almıştım.
Onlara da göz atıyorum aynı zamanda.
En sonda... Onların genel teması var bunun aslında.
Birazcık şu noktaya geliyoruz.
Bizim sprintlerimiz var.
Haftalık sprintler koşan bir ekibiz.
Bunu da belirtmiş olalım hatta arada.
Bu haftalık sprintlerde çok hızlı gerçekleşiyor.
Bir anda cereyan ediyor aslında her şey.
Ve günün sonunda aslında bir şey vardı.
İlerletebilirdik. Bu sprint başarıya ulaşabilirdi ama birkaç şeyi gözden kaçırdık.
Tam olarak üzerine eğilemedik ve ilerletemedik.
Bunu ilerletmek için ne yapabiliriz üzerine açıkçası?
Retrolarda çok düşüyoruz.
Şey gibi çünkü bunların birinci, ikinci, üçüncü fazları var ve gerçekten bir sprinti başarıya ulaştırıyor olmak bizim için en önemli kriterlerden bir tanesi baktığımızda.
Ve bunun öncelikle bir sebebini bulmamız gerekiyor.
Yani gerçekten böyle eksternal dışarıdan bir sebep vardı ve bunu yakalayamadık mı?
Yoksa işte bizim takım olarak bir şeyi mi gözden kaçırıyoruz?
Bu yüzden sprintlerimizde işte bir gün, yarım günlük gecikmeyel yaşıyoruz.
Mesela son retromuzun temalarından bir tanesi de buydu.
Bununla ilgili farklı aksiyonlar almak için de aslında yine harekete geçtik.
PR süreçlerimizi nasıl hızlandırabiliriz?
Ve işte bug fix çok fazla yapmışız dedik mesela son sprintimizde.
Bunu nasıl minimize edebilirdik?
Neden bu kadar bug fix yapmamız gerekti?
Neden 3 tane 4 tane bug fix taskı açıldı bir anda?
Bunlar için de işte entegrasyon testi yazalım.
O projenin entegrasyon testi yokmuş.
Bunu da yapalım, yapmamız lazım.
Test containerları kullanalım gibi mesela farklı aksiyonlar aldık.
Bu aksiyonları işte gerek Merve olsun, ben olayım, diğer takım arkadaşlarımız olsun.
Belli kişilere esayn ediyoruz ki görünür kılalım ve bunların takibi daha kolay olsun.
Bunlarla ilgili de aslında Retro'dan Retro'ya bir önceki Retro'muzu açıp bu aksiyonlarla alakalı bugüne kadar neler yapabildik.
Her seferinde de konuşmaya özen gösteriyoruz.
Bir de son zamanlarda galiba şöyle bir konuyu da çok konuşur olduk.
Aslında biz puanlama yaparken doğru puan veriyoruz.
puan alıyoruz ama bir şekilde sprint'i fail ettiren durum nedir?
Acaba o iletişim noktasını daha sıkı tutabilir miyiz?
İşte hem kapanış hem de akşam yaptığımız daily'lerde ilgili task'ın progresini daha mı net ifade etsek hepimiz aynı noktada olmak için ya da bir bottleneck gördüğümüz zaman tüm ekibi bilgilendirelim
gibi konuları da konuştuk son Retro'da.
Peki biraz bahsettik bundan ama yani Takip ettiğimiz metrikler nelerdir?
Notification'lardan biraz bahsettiniz.
Başka ne tarz metrikler takip ediyorsunuz?
Belki ben biraz bahsedebilirim bundan.
Bir kere zaten en büyük uygulamamız CRM Support Tool olduğu için burada agent kalite metriklerini takip ediyoruz.
Yani call sürelerimiz nedir?
Bunları kısaltmak için neler yapabiliriz?
FCR dediğimiz First Contact Resolution, buradaki müşterinin bize ilk kontakta geldiğinde cevap alabilmesini sağlamak için hangi uygulamaları taşımalıyız?
İşte aynı zamanda...
NPS zaten birçok ekibin de metrik olarak takip ettiği bir konu.
Net Promoter Score. Burada müşteri memnuniyetini daha fazla nasıl sağlayabiliriz?
Self-Service Coverage'ı nasıl arttırabiliriz?
IVR'a gelen kullanıcıların çözüme ulaşmasını daha fazla nasıl sağlayabiliriz?
İşte yaptığımız iletişimlerin senin de dediğin gibi Fırat hani recurring atılmasını nasıl sağlayabiliriz gibi detayları takipliyoruz.
Ben şeyi sorayım ben de son olarak.
Canlı sitem en son ne zaman patlattınız ve bu işte canlıda yaşadığınız problemden öğrendiğiniz en önemli şey neydi sizin için?
Burada ben yine bir ufak topu alayım.
En son hatta deminde birazcık böyle gaza gelip buralara doğru da sıçradığım oldu.
Bir şeyden bahsedebilirim.
Bizim bu iletişimleri yaptığımız servisimizde açıkçası işte puştları, SMS'leri, mailleri attığımız servisimizde kullandığımız bir tane layberi var.
Aydan potansiyeli sağlamak için konsümürlerimizde.
Yani mükerrer mesaj atmak istemiyoruz çünkü tabii ki kullanıcılarımıza.
O şekilde ve onda yeni bir özellik getirdik aslında.
Bu özellik de işte time to live gibi bir şeydi.
Yani tamam bu mesaj geldi, burada ne kadar kalsın ki ben bunun mükerrer olduğunu anlayayım gibi bir özellik getirdik.
Biraz da yeni bir özellik olmasından kaynaklı belki de.
Orada kullanmamız gereken time to live değerini set etmemiz gerekiyordu.
Ama orada bir hata yaptık ve o değeri sıfır olarak geçtik.
O yüzden store alarak geçtiğimiz noktada bu konsümerlerde, o yeni özelliği getirdiğimiz konsümerlerde hata aldık.
O yüzden o iletişimleri yapamadık belli bir süre.
Bu da bizim için çok kritik bir hata oluyor production'da özellikle.
Çünkü burada bu servis üzerinden birçok iletişim akıyor.
Ve bu birçok iletişimde saniyede binlerce siparişin alınanı, siparişin teslim edildiği gibi iletişimler yapıyoruz.
O yüzden bununla alakalı aldığımız kısa dönem ve uzun dönem aksiyonlar gibi yaklaşıyoruz biraz daha.
Burada gözden kaçan bir şey vardı.
Bir human error diyebiliriz.
Belki insan hatası belki bir noktada.
Bununla ilgili ne yaptık? Direkt aksiyon olarak böyle bir sıkıntı var.
Ne yapalım? Hemen önceki versiyona dönelim.
Önceki versiyona döndük. Canlıdaki sistemi aslında hatasız hale getirdik.
Hatasız versiyona döndürdük.
Sonrasında da aslında bununla alakalı o an için dediğimiz gibi anlık bir hata olduğu için sistemimize şunu ekleyelim gibi bir aksiyon almaktan ziyade Bir noktada da retro konusuymuş aslında bizim için.
Oturduk yani böyle bir hata geçti.
Hepimizin gözünden kaçtı.
Takım olarak biz böyle bir şeye sebep olduk.
Yani oraya sıfır yazan arkadaş buna sebep olduğu gibi bakış açısı hiçbir zaman olmuyor.
Hiçbir hata da ve sorun da zaten.
Böyle bir şeye sebep olduk.
Buna sebep olmamak için PR süreçlerimizde mi iyileştirme yapmamız lazım?
Ya da işte buradaki sıfır olayına testlerde, unit testlerde mi atladık?
Bunu mu öngöremedik? Bunların üzerine konuştuk ve işte gerekli aksiyonlarda işte PR'lara şöyle bakalım.
daha çok üzerine konuşalım, daha çok haberleşelim gibi aslında aksiyonlar da belirledik kendimize bunları konuştuktan sonra instant özelinde.
Çok teşekkürler Merve ve Kubilay.
Çok güzel bir program oldu. Ben de bilmediğim şeyler öğrendim bu programda özellikle.
Evet özellikle sana kalkış çok olmuştur diye düşünüyorum ben de.
Evet evet kesinlikle.
Programımızı kapamadan önce tabii ki bir program geleneğimiz var.
Onur bize şarkı söyleyecek.
Evet arkadaşlar. Bugün sizinle birlikte olan Customer Service ekibinden Merve ve Kubil'e topu atıyorum ve böyle bir şey tabii ki de yapmıyorum.
Ay kaç ama bize var dendi ya.
Bence çok seri bir şekilde size sektirdim.
Artık ne tarz bir şarkı söylerseniz size kalmış.
Mikrofonumu hemen kapatıyorum.
Peki ne şarkı söyleyeceksiniz bize?
Kasım'ın şarkısının bir şarkısı vardı.
Onu mu söylüyorsunuz? Ekip olarak her değil de söylediğiniz bir şarkı.
Kubilay çok iyi söylüyor onu bu arada.
Osmi Osmi Domino ile başlayan bir şarkı.
Evet öyle bir şeydi galiba.
Vallahi hiçbir fikrim yok. Solistimiz Merve bizim ekipte.
Benim sesim kendime kadar ya.
Benim sesim o kadar bile değil Merve.
O zaman en sevdiğiniz şarkıyı soralım.
En sevdiğiniz şarkı.
Bu soruyu bugün de sordun ya Fırat.
En sevdiğin film ne diye.
Bence bunlar çok zor sorular ya.
Ama bence değil ya.
Bir tanesini seçmek zorundasın.
Ama seçemem ki.
Seçemiyorum. Mecbursun.
Sonuçta kadar sonuçta kadar değil tabii ki.
Onu izleyeceksin hayatın sonuna kadar.
Otomatik portakaldaki gibi.
Zorla izletecekler. Öyle bir seçenek var yani.
3 tane film var. Sonuçta kadar ben bu şarkıyı dinlerim dediğiniz bir şarkı.
Fırat'dan söyle o zaman. Sen de sonuçta KastroTourist ekibindensin.
Evet Fırat. Utandır Merve ve Kubilay'ı.
Evet ya. Metallica'dan Nothing Else Matters.
Gitar mı çalacaksın peki?
Hayır tabii ki ya.
Asla. Çalamıyorum yani.
Çalamıyorsam çalabilirim. Herkes başını çalar yani.
Aa doğru. En üstüne vuruyorsun sonra alttan üstten.
Aynen abi. O zaman çok teşekkürler Merve ve Kudilay.
Bu güzel programda bizlerle birlikte olduğunuz için.
Gelecek hafta görüşmek üzere ya da iki hafta sonra görüşmek üzere.
Hoşçakalın. Hoşçakalın.
Hoşçakalın. Biz teşekkür ederiz.
Biz teşekkür ederiz efendim. Hoşçakalın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.