
Konuklar: Çağatay Şama, Çağla Bayrak, Gökhan Birinci
31. bölümümüzde konuğumuz Echo ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Transkript
Merhabalar. Merhabalar.
Merhabalar. Şimdi sizlerden kısaca bir kendinizi tanıtmanızı isteyeceğiz.
Çağla istersen senden başlayalım.
Sonra Gökhan, sonra Çağatay diye gidelim.
Tabii. Selamlar. Ben Çağla.
Eko ekibinde Product Manager olarak görev alıyorum.
Toplamda 2018'den beri çalışıyorum.
Yaklaşık son bir buçuk yıldır da Trendyol'dayım.
Süper. Selamlar. Ben de Gökhan.
Ben de yaklaşık... Üç seneden fazla oldu galiba.
Trendyol'da çalışıyorum. Öncesinde asistanla başladık.
Ardından da in-house live chat uygulamasıyla devam ettik.
Şimdi Eko ekibimle Trendyol chat uygulamasında beraber çalışıyoruz.
Selamlar. Ben de Gökhan Plasman şeklinde.
İki buçuk sene oldu. Ben de asistandan daha sonrasında in-house geliştirdiğimiz Connect uygulamasını geliştiren Eko ekibine katıldım.
Bende de durumlar böyle. Süper abi.
Hoş geldiniz tekrardan. O zaman bir kısaca bir ekibi tanıtabilir miyiz abi?
Eko ekibi nedir?
Ne yapar? Eko ismi nereden çıktı?
Bunun kaynağı nedir?
Bunlardan bahsedebilir miyiz?
Aynen abi ben biraz bahsedeyim.
Bizim takım 10 kişilik bir scrum takımıyız.
İşte Piyo'muz, Frontend, Backend, QA şeklinde ayrı ayrı pozisyonlar var.
Bizim ekibin aslında Beyza Hollanda'da şu anda.
Hatta ekibin çoğunluğu Hollanda'da olduğu için de yakın zamanda bir Hollanda eventi de oldu.
Çok iyi. Aynen aynen gezdik gördük falan.
Neyse iki arkadaş bize frontend developer olarak destek atıyorlar.
Onun dışında bir tane köy arkadaş var.
O da Ukrayna'dan bize katılıyor.
Onun dışında da altı tane backend developer olarak normal scrum team olarak da çalışıyoruz.
Valla ekibin adını, eco adını aslında birazcık ben buldum gibi oldu.
Ama o kadar hasbelkader oldu ki.
Daha öncesinde Cassandra ile ilgili böyle sunumlar vesaire yapıyordum.
İşte Cassandra'nın adı nereden geliyor diye baktığın zaman böyle Yunan tanrılarından vesaire geliyor ediyor.
Aynen Yunan tanrılarını çok seviyoruz.
Evet evet aynen. Ben de bu arada kişisel ilgim böyle mitoloji falan biraz kurcalayan bir insanım.
Eko da böyle en çok konuşan tanrılardan birisi aslında Yunan mitolojisine göre.
Bilim kadarıyla bu arada. Ondan dolayı bizim de uygulama biraz da böyle işte chat'tir, konuşmadır vesaire de.
Hem de Yunan tanrısı birleşince işte Eko şeklinde bir şey oldu.
Ekip de hoşuna gitti falan, beğendi.
Öyle bir Eko isminin hikayesi var.
Valla ekip yapısı hani... Dediğim gibi işte 10 kişi sıklantıyım.
Onun dışında ekip aktiviteli olarak da hani gidiyoruz işte Hollanda'ya gittik gecen.
Onun dışında da Türkiye'ye de geliyorlar işte.
Odottur vesairedir. Onun dışında mümkün olduğunca vakit buldukça Eksbol oynamaya çalışıyoruz.
Fena da bir ekip değiliz. Hatta Eksbol turnuvasında da bir ikinciliğimiz oldu.
Umarım sonrakine de birinci oluruz yani.
Güzel. Evet. Aynen.
Kısaca bizim ekip böyle küçük tatlı bir ekip yani kendi aramızda.
Çok iyi abi. Peki burada...
şey mi ekip yapısında şimdi Hollanda var dedim.
Bir de QA var dedim.
QA arkadaşlar Franya'da aynen abi.
Aynen yani şey mi international bir ekip diye anladım.
O zaman. Evet. Yani herkes İngilizce konuşuyor toplantılarda.
Orası nasıl ilerliyordu süreç?
Bizim bütün toplantılarda hep İngilizce konuşuyoruz.
Yani Anastasia işte bizim köy arkadaş.
Olmadığı zaman bazı böyle çok teknik defi fazla olan konuları Türkçe'ye geçebiliyoruz ama %90 hep İngilizce konuşmaya çalışıyoruz.
Slack kanallarında zaten hep İngilizce konuşuyoruz.
Onun dışında grooming, tech grooming değiller vesaire, retolar hepsi İngilizce devam ediyor.
Bizim için epey güzel oldu. Yani hani Anastasia'nın olması bizim için de hiç şey yapamıyoruz.
Yani hani Türkçe konuşma gibi bir ihtimalimiz olmadığı için İngilizce konuşmaya da puştlayan bir süreç var.
Aynen, konfor alandan çıkarıyordur böyle.
Aynen, kişisel gelişimimize de bence bayağı bir katkısı oluyor.
Süper abi, gerçekten ekip yapınız harikaymış.
Ben çok beğendim. International'da ekip olmanız, İngilizceyi base olarak alarak hayatınıza katmanız da oldukça güzel bence.
Ben biraz daha çalıştığınız ürün...
Ve bu ürünün amacıyla alakalı bir şeyler sormak istiyorum.
Nasıl bir ürün üzerinde çalışıyorsunuz?
Bir chat ürünü olduğunu şu an öğrendik.
Bir chat ile alakalı bir ürün olduğunu öğrendik.
Fakat bu chat ürünü nasıl çalışıyor?
Amacı nedir? Nasıl bir üründür?
Verimlilik aksiyonları nelerdir?
Diğer ekranlarla integrasyon nasıl olur?
Biraz bunlardan bahsedebilir misiniz?
Burada topu ben alayım.
Ekibin adından Çağatay bahsetmişti.
Bizim geliştirdiğimiz ürünün adı da Connect.
Genel anlamda aslında müşterilerle temsilcileri bir araya getirdiği için de yaptığı görevde de bağlantılı bir ismi var.
Bizim isim koyma sürecimizde birazcık hem amacına yönelik hem de kullanacak kişilere aslında bir anket falan çıkmıştık.
Onlardan da oylarıyla ne olsun ürünün ismi demiştik.
Bu şekilde karar verdik.
Müşterilerin bu üründeki akışından da bahsetmek gerekirse aslında talep, şikayet, bilgiye ulaşma gibi ihtiyacı olan müşteriler.
Bize web sayfası üzerinden ya da application üzerine asistana bağlanıyorlar öncelikle.
Bir bot aracılığıyla sorularına cevapları aramaya çalışıyorlar.
Eğer müşteriler bu sorularına verilen cevapların yeterli olmadığını düşünüyorlarsa da bu noktada bot onları bir canlı bir temsilciye yönlendiriyor.
Bu noktada da biz devreye giriyoruz.
Ve temsilcilerle müşterileri...
bir anlamda buluşturuyoruz.
Amacından bahsetmek gerekirse de aslında temel amacımız yalın ve stabil bir arayüz sağlayarak temsilcilerin kolay ve hızlı bir şekilde müşterilerin sorularına cevap vermesini ve hizmet verebilmelerini sağlamak.
Daha öncesinde burada bu teknolojiyi outsource ediyorduk.
Fakat burada zamanla yaşanan bazı hem scalable sorunları oldu hem de cost efficiency gibi sebeplerle in-house dolu yazmaya karar verdik.
Aslında Trendyol'un genel yapısını düşündüğümde buna da paralel teknolojileri in-house'da geçirebildiğimiz kadar in-house'da tutmaya çalıştık.
Ve burada da aslında amacımıza yönelik daha sonra yeni tuğla geçtikten sonraki analizlerde de şeyleri görebildik.
Hem cost anlamında bir efficiency yakaladığımızı hem de takip ettiğimiz bazı temsilci metrikleri var.
Bunlarda iyileşmeler de görebildik.
Burada da farklı olarak neler yaptık derseniz de ilk olarak aslında diğer tuğla göre daha iyi bir daha detaylı raporlar sunabiliyoruz biz müşteri deneyimi ekiplerine.
Onlar da bu raporlardan daha doğru analizler yaparak doğru noktalara aksiyonlar üretiyorlar.
Ya da bize daha doğru geri bildirimler vererek gerekli noktalara değinebiliyoruz.
Burada Çağla şey mi oluyor?
Yani üçüncü parti müşteri temsilcileri var birden fazla şirket.
Onlarla müşteri arasında mı bir entegrasyon kuruluyor?
Üçüncü partiler hala hayatımızda var.
Temsilciler bacağında aslında outsource tarafta.
Ama bir de teknoloji tarafında da üçüncü parti bir şirketin turunu kullanıyorduk Connect'den önce.
Oradaki aslında entegrasyon kısmını biz inha su aldık.
Temsilciler hala outsource firmaların çalışanları.
Biz onlara yeni ekranlarımızı vermiş olduk.
Tam bu aşamada aslında şeyi sormak istiyorum.
Connect. Şu anki uygulamamızın adı, şu anki ürünümüzün adı.
Bundan önce kullandığınız ürüne göre Connect'in farklılıkları nelerdir bir önceki ürüne göre?
Burada da devam edebilirim ben.
Örnek olarak vermek gerekirse mesela biz Q-Management dediğimiz farklı bir sistem kullanıyoruz.
Yani müşterilerin geldikleri sıralara göre temsilcilere gönderiyoruz.
Buradaki yapımızı değiştirdik ve bununla birlikte de aslında daha verimli bir şekilde temsilcilerin chatleri karşılamalarını sağlayabildik.
Bekleme sürelerini düşürdük.
Temsilcilerin chat karşılama hızlarını yükselttik.
Ya da temsilciler chatleri karşılarken sadece bizim toolumuzu değil bazı bilgileri aramak için yazılan diğer in-house tool'ları da kullanıyorlar.
Bu in-house tool'larla da custom çözümler sunabiliyoruz.
Biz de in-house bir yazılım yazabildiğimiz için.
Ve bu custom çözümlerle de onların cevaplılara daha hızlı ulaşmalarını da sağladık.
Bu şekilde farklılıklarımız var diyebiliriz.
Çok iyi. Ben de küçük bir araya girebilirim burada.
Belki teknik anlamında daha önce çalıştığımız third party tool hakkında.
Orada benim biraz daha... Fazla tecrübem oldu.
Daha önce Asistan'la beraber çalışırken de in-house live chat uygulamasını yazmadan önce onları kullanıyorduk.
Aslında oradaki uygulama baya legacy idi.
Örnek vermek gerekirse instant chat yaparken long polling yapıyorduk.
İşte şu an tam oradaki süreyi hatırlamıyorum ama 6 ya da 10 saniyede bir benim yeni chatim var mı, yeni chatim var mı diye sormamız falan gerektiği durumlar oluyordu.
Instant messaging yapan protokollerin libraries düzgün çalışmıyordu.
Biz onlara long polling yapıp, biz dışarıda trend yolu userlarına soketten chat'i atma durumunda kalıyorduk.
Bir de bazı durumlarda şey sorunları yaşamıştık.
Mesela event dönemlerinde, daha doğrusu event dönemlerinin sonrasında genellikle bize daha çok yük geliyor.
Sizin de zaten tahmin edeceğiniz üzere.
Kullanıcılar herhangi bir problem yaşadığı zaman ya da ürün iadeye gideceği zaman ilk...
asistan. Sonrasında da bizim uygulamayla aslında muhatap oluyorlar.
Orada da bir yük gelince yine böyle bir senaryo olmuştu.
Şeyle karşılaşmıştık. Star Chat yapacağız.
Biz sürekli hatalar alıyoruz.
Onlara gittik falan. Şey gibi geri dönüşler geliyor.
Post benden hani request atıyor.
Sonra anlamak adına. Bir 20 saniye falan sonra cevap geliyor.
Ya abi bu çalışıyor. Tabii o saniyeye kadar yani bizim hiçbir timeout thresholdları kalmıyor yani.
Böyle sorunlar yaşıyorduk.
Teknik anlamda da destek almamız gereken noktalarda da bazı sorunlar yaşıyorduk.
Zaten biz de hani içeride teknik olarak genellikle zaten yazılımcılar hani biraz daha böyle şey isteriz ya challenge işler.
Hep istiyorduk zaten farklı uygulama yani ne bileyim biraz kradın dışında biz yapsak olur mu gibi.
Evet abi ya yani her yerde bulabileceğin bir tarzda problemler değil gibi bunlar.
Evet zaten onun üstüne de içeride biziz takımıyla bizim teknik tarafa daha yakın kişilerle beraber scorecardlar yapıldı.
Hani bunun fizibilitesi çalışıldı.
Ondan sonrasında bir şekilde ikna olup cost saving de tabii artıbıyor.
Biz içeride yazmaya karar verdik.
Sonrasında da zaten connect tool'u şu anda da herhalde bir seneydi biraz geçti diye tahmin ediyorum canlı da olma süreci.
İlk dediniz buradan yürür.
Çağatay Connect Tool'u için bir Yunan ismi yok muydu önerin?
Abi onunla valla şey oldu ya.
Bir aylık bir asistana gittim geldim ben.
Oraya bir destek gerekti.
İlk chat o tarafına. Oraya gittikten sonra abi geldim.
İsmi Connect olmuş uygulama.
Takım Eko kaldı. Orada yoksa bir Yunan ismi uydururduk yani.
Ben sana güvenemem.
Bir şey çıkardı da oradan. Evet evet çıkardı da.
Gelince baktım uygulama Connect olmuş.
Sonra devam edildi yani.
Ama orada gene isimlerden bir liste yapıp yine bizim tribe'da bir oylama yapıp Tool'un ismini seçtik.
Öyle. O zaman o şey.
Demokrasiyle geçilmiş abi.
Yapacak bir şey yok. Demokrasi işte ya.
Peki abi burada on kişilik bir ekip var.
Fizik ve teçhizatçıması vesaire oldu demiştiniz.
Burada peki okey şimdi bir eko ekibi var.
Bu ekip peki şu an kimlerle çalışıyor?
Hangi ekiplerle yakınsınız?
Çok fazla iletişim kuruyorsunuz?
Ya da kurmanız gerekiyor mu? Belki de biz tek başımıza takılıyoruz.
Kimseye de ihtiyacımız yok falan mı oluyor?
Nasıl dönüyor orada işler? Aslında burada biznes tarafta kimlerle çalıştığımızdan ben bir bahsedeyim.
Sonra teknik taraf içinde arkadaşlara sözü bırakırım.
Burada tool üzerinde biz 12 farklı segmentten temsilcilerle çalıştığımız için aslında 12 farklı ekiple çalışıyoruz.
Burada müşteri tarafından, satıcıdan, kurye, influencer, international tarafta dolap dolu gibi.
Aslında bir sürü farklı ekiple çalışıyoruz.
Burada da her hizmet verdiğimiz segmentin bir müşteri deneyimi ekibiyle kol kola çalışıyoruz.
Onlar bize deneyim ekipleri son kullanıcının aldıkları feedbackleri iletiyorlar.
Ya da yeni bir projeleri varsa onlarla ilgili gerekliliklerine, ihtiyaçlarını paylaşıyorlar.
Bunlar için de böyle her hafta weekly toplantılar yapıp o ekiplerle bir araya gelip ihtiyaçlarını ya da yaşadıkları sorunları ya da geliştirme taleplerini dinliyoruz.
Bir de bunun dışında böyle tüm ekiplerle dokunduğunu düşündüğümüz projeleri konuşmak için haftada böyle tüm stakeholderların olduğu falan bir toplantımız oluyor.
Aslında burada böyle 12 farklı ekiple çalışıyoruz biz bu tarafta diyebilirim.
Biz bu tarafta başını kaçırdım da çok özür dilerim.
İlk tarafta kim getiriyor demiştin işi?
Birileri bize... Müşteri deneyimi ekipleri.
Müşteri deneyimi ekipleri. Müşteri...
Satıcı, kurye, influencer, international customer gibi böyle farklı farklı segmentler var içeride.
Her bir ekibin de ayrı bir müşteri deneyimi ekibi var.
O ekipler getiriyorlar bize.
Bazen işte müşteri tarafında okudukları feedbackleri bize paylaşıp işte chatte şöyle bir süreç yapmak istiyoruz diye gelebiliyorlar.
Bazen de tool'u kullanan işte takım liderleri, agentlerden feedbackler geliyorlar.
Biz böyle olsa daha kolay çalışırız gibi onları bize taşıyorlar.
Aslında bu ekiplerle çok sıkı çalışıyoruz tool'u geliştirebilmek için.
Anladım. Farklı farklı yerlerden böyle aslında ihtiyaçlar geliyor gibi.
Aynen. Teknik taraftaki ekipler için de sözü Çağatay'a bırakayım ben.
Teknik olarak bizim Trending içerisinden işte genel olarak asistan, mobil ekip ve de vekse beraber çalışmalarımız oluyor.
Asistanın zaten... Gittiği noktada connect başlıyor diyebiliriz.
Yani chatbot'ta eğer kullanıcı tam olarak sorununu çözemedi, isteğini bulamadıysa bir şekilde bize bağlandığı kısım var.
Burada zaten kullanıcının bütün metadata'sını bir şekilde echo tarafına geçiyor olması gerekiyor.
Ondan sonraki aşamaya kadar zaten artık şey hani asistanda cevap yeterli değil deyip create chat yapıldığı anına itibaren...
Bizim de orada bir entegrasyonumuz var.
Asistan ile işte ortak kod yazdığımız sınıflar, repositorlar vesaire var.
Orada birbirimizin komitlerini vesaire bazen rüya edip onlarla aradığımız zamanlar olabiliyor.
Onun dışında yine asistan tarafında bizim aslında uygulamanın bir şekilde skorlarını, anket skorlarını vesaire yine asistan üzerinden skorlanıyor.
Orada bir user konuşmadan memnun kalıp kalmadığını, anketi çıktığı yer aslında asistan tarafında anket çıkıyor.
Buradaki anket bilgilerini de aslında bizim tarafı Adibesim üzerinden getiriyoruz.
Burada da yine Çağla'nın bahsettiği de bizans ekiplerinin vesaire.
yine baktığı yerler oluyor buralar.
Onun dışında mobil ekiple de hani ihtiyacımız oluyor onlara da konuşmaya.
Mesela native eventlerde bazı ihtiyaçlarımız oluyor.
Uygulamanın işte arka plana, ön plana geldiği zamanki eventleri hep native event olarak sağlamaları gerekiyor.
Mobilcilerle hani bu şekilde böyle bir bazı isteklerimiz, ricalarımız olabiliyor.
Onun dışında mesela böyle bir danışmanlık alma gereksinleri oluyor mesela bizim.
Yine mobil ekipte işte arka planı aldığımız zaman mesela soket bağlantısının işte telefonun güç kaynağı moduna göre işte kapanıp açılmasıyla ilgili konularda onlardan destek alıp hani kendi testlerimizde bir şeyler bulup onlarla da bir verifikasyon
şeyi yapıyoruz aslında bu doğru mu değil mi şeklinde.
Onun dışında bir Devex ekibiyle de beraber aslında Key Clock altyapısıyla onu da değiştiriyorlar zaten yakında.
Otorizasyon altyapısını aslında Devex'in sağladığı bir ürünle sağlıyoruz aslında.
O şekilde tren yolu içerisinde kitlerle çalışmalarımız var.
Onun dışında bir de third party olarak kullandığımız outbound call için başka bir firmayla da çalışmalarımız oluyor.
Onlarla genelde hani bir problem yaşadığımız zaman direktman yazıyoruz.
Onlar kendi zaten bir built-in productları var.
Call'u aslında şu anda bizim tarafta third party tool ile yapıyoruz.
yaptığımız için entegre olduğumuz ekiplerden onu da bahsedebilirim.
O şekilde. Çok iyi.
Valla süper yani birçok ekiple böyle karşılıklı omuz omuza çalışmanız gerçekten harika.
Ben de araya çok küçük girebilir miyim?
Tabii tabii. Çağatay'ın söyledikleri demek.
Aslında biz Connect ismini verirken bizim tool'a biraz daha kapsayıcı olmasını istemiştik.
Daha çok biraz da workspace tool'u gibi.
Çağatay'ın da söylediği ekiplerek aslında bizim kullanıcı ekranlarına yani agent taraflarında biz müşteri temsilcilerine içeride agent diyoruz.
Şey ekranları da sağlıyoruz. Mesela örneğin müşteriler bağlanıyor.
Bu ilgili sorunla alakalı ticket açmaları gerekiyor.
Onun için içeride uygulaması var T-Desk diye.
T-Desk açıyoruz. Onun dışında yine farklı işlemler yapmaları gerekiyor.
Seller tarafında S6 uygulaması, yine Customer tarafında CX uygulamalarını da açıyoruz.
Yani tamamıyla aslında bir chat tool'u değil.
Müşteri temsilcilerine de bir ekosistem sağlayan bir tool aslında.
O zaman aslında sadece müşteri tarafı için değil.
Yani müşteri temsilcisinin de kullandığı bir arayüz var.
Orayı da handle ediyoruz ya da seller'ın da...
konuştuğu bir yer var. Oralar da handle ediyor diye anladım.
Topla hepsi. Connectörünün altında mı oluyor?
Aslında şöyle. Biraz segmentlerden de bahsetmek gerekir galiba.
Bizim Trendyol asistandan yine Çağla'nın bahsettiği gibi kullanıcıların doğrudan hazır cevaplardan bir şeyler bulamadığı noktada bize bağlanıyor.
Orada da segmentler olarak influencer'lar var, seller'lar var, işte yemek kullanıcıları var.
Yani bizim her zaman müşterimiz trend yol end user'ı olmayabilir.
Dolap da işte dolap user'ı, seller'da da satıcılar, influencer'da da influencer'lar.
Tabii onlara göre müşteri temsilcilerinin de farklı uygulamalara ihtiyaçları olmuş oluyor.
O durumda işte customer tarafı için CX uygulaması, T-desk uygulaması, seller, agentler için SX uygulaması gibi gibi uygulamalarda da çalışıyoruz aslında.
Bizim uygulama biraz daha orada müşteri tepsilcilerine kapsayıcı bir ekran vermeye de yarıyor aynı zamanda.
Süper. Geniş kapsamlı.
Süper. Aynen yani aslında bir chat uygulaması ya da işte chat tool'u değil de uçtan uca bir iletişim sağlayacak bir uygulama diyebiliriz.
Ben açıkçası bu kadar kapsamlı olduğunu, bu kadar detaylı olduğunu bilmiyordum.
Çok güzel oldu. Dinlerken...
Şeyi merak ettim yani böyle sofistike bir tool'u geliştirmek için, sofistike bir ürünü geliştirmek için hangi teknolojileri şu an aktif olarak kullanıyorsunuz?
Burada da ben girebilirim yine araya.
Aslında böyle bir sofistike tool için sofistike de insanlar gerekiyor biraz.
Genellikle biz ekipçe de böyle çok iletişim gücü yüksek ve araştırmayı seven bir ekibiz.
Başlangıçta hani biz asistan tarafında POC'ler yapmıştık.
Nasıl live chat uygulaması yazarız, neler yapmak gerekir gibi.
Aslında o araştırmaların sonucunda belki chat'in en koruyla ilgili bahsedeceğim şu anda da en önemli noktalardan birisi.
diye bir tane server var abi.
Bu da XMPP diye well known bir protokol.
Aslında genel sektörde de chat uygulamalarında kullanılan bir protokol.
Onu da implement eden bir tane servis.
Bizim chat uygulamasının aslında en core kısmı burası.
Bunun etrafında da aslında bizim iki tane uygulamamız var.
User tarafı için bir servis sağlıyoruz.
Bir de agent tarafı için bir servis sağlıyoruz.
Orada da Biz sürekli IO işlemleri yapacağımız için biraz da efficiency düşündük açıkçası.
O da hani ne yapabiliriz, ne yapabiliriz.
Non-blocking bir şeyler lazım bize.
O yüzden hani biraz Go tarafında bir şeyler baktık.
Ondan sonra takımın da hani tek siteyi Java tarafında olduğu için Reactive'le ilerlemeye karar verdik.
Hani Reactive'de de birkaç PO'su yaptık.
Sonrasında genel core mimari de Reactive'le devam ediyoruz.
Onun dışında tabii yine az önce de bahsettiğimiz gibi bizim uygulama sadece hani bir chat feature'ı sağlıyor.
Kullanıcıların historilerine de bazen agentların ihtiyacı oluyor.
Şöyle ki mesela ben bir kullanıcı olarak agenta bağlandığım sorunumla alakalı.
Mesela daha önce de yine bağlanmıştım.
Orada agentların bu kullanıcının daha önceki historilerine bakıp daha yararlı bir feedback verebilme adına historilerini görebiliyor.
Burada bizim histori göstermemiz gerekiyor.
Elastik search de tutuyoruz search kısımları için.
Onun dışında bizim aslında en temel şeylerden birisi de genellikle bir şeyleri yap boz gibi yapıyoruz.
O sebeple de yani yarın bir gün atıyorum biz elastiği kullanmayacağız ya da postgre kullanmayacağız ya da redis kullanmayacağız gibi kararları kolay verebilmek adına heksagonal mimariyle ilerletiyoruz
genellikle projelerimizi.
Gökhan burada bir araya gireceğim bir şey soracağım abi.
Burada şimdi dışarıdan baktığımda mesela ne kadar bana yük gelecek diyelim.
tahmin edemiyorum şu an. Bana bir yük geliyor.
Ya da ilk başta bilmiyorum ne kadar yük geleceğini.
Hani chat dışarıdan bir insana bağlıyız ya.
Şey nasıl oluyor? Mesela bu teknolojiyi seçtin.
Abi aslında bu teknoloji bizim ihtiyacımızı görmüyormuş deyip de değiştirdiğiniz mesela oldu mu bu tarz bir şey?
Açıkçası bu zamana kadar öyle bir şeyle karşılaşmadık.
Daha önce load testler koşmuştuk ilk influencer'ı almadığın önce.
Tabii oralarda da projection yapabiliyorduk.
Çünkü daha öncesinde de hani bizim kampanya dönemlerinden sonraki günler genellikle trafiğimiz çok fazla olduğu için ortalama ne kadar chat gelebileceğini yani biz de bunun bilmem atıyorum 5 katı vurup sonrasında
da bizim servisin bunu handle...
edip edemediğini kontrol ederek aslında buna bir problem yaşamadık açıkçası.
Süper. Peki ben şu tarafta aklıma bir soru geldi.
Normalde başka bir soru soracaktım ama onu daha sonrasında soracağım.
Sonuçta real time bir şey yapıyoruz.
Arada bir soket bağlantısı var.
Fakat bu soketin de belirli seçenekleri, belirli çeşitleri vesairesi oluyor.
Soket tarafında nasıl bir yol izlediniz burada?
Nasıl çözümler ürettiniz? Aslında burada da zaten bizim uygulamanın en challenge'i kısımlarından birisi.
En önemli yerlerinden birisi.
Çok reliable bir protokol değil aslında soket.
Çünkü kopmalar olabiliyor, kullanıcı düşebilir.
Telefon uygulamasından geliyorsa arka plana alabiliyor.
Bizim disconnect olduğu kezlerde direkt chat'i bitirmememiz gerekiyor.
Belirli thresholdlar gerekiyor.
Burada da aslında biz custom çözüme gittik.
Daha öncesinde kullandığımız third party tool'da stomp protokolünü kullanmıştık.
Orada yaşadığımız bazı problemlerden dolayı biraz o taraf da legacy'di.
Bir de bir şeyler araştırdığımızda çok cevabını bulamıyorduk.
Custom yerlere itiyordu bizi.
Sonrasında yine Rsocket diye bir tane tool.
denedik. Orada da genellikle service mimariye yönelik çözümler vardı.
Biz de daha önce tecrübe ettiğimiz şeylerden yola çıkarak biz hani custom bir çözüm yapabilir miyiz gibi bir yola girdik.
Aslında biz de biraz olan WebSocket protokolünün üstüne bir şeyler daha ekleyerek custom bir protokol yazlıkta denebilir.
Yani extended WebSocket gibi düşünebiliriz aslında.
Böyle. Çok iyi.
Çok iyi. Yani custom bir Çözüm geliştirmeniz de bayağı iyiydi.
Sonuçta buradaki problemleriniz kastım uzunca.
Yani işte özel problemler çıkınca özel çözümler üretmek de oldukça faydalı oluyor.
Kesinlikle. Benim aklıma gelen başka bir soru da bu tarz peer-to-peer bir uygulamada stability çok önemli diye biliyorum.
Hani stabil bir uygulama olması ve işte bunun her zaman daha iyiye gitmesi oldukça önemli bence.
Siz burada stabilitenin önemi ve bu stabiliteyi iyileştirmek için neler yapıyorsunuz?
Ne gibi pratikler uyguluyorsunuz?
Orada da ben toplu olabilirim.
Öncelikle bir kere bizim uygulamayı kullanan, müşteriler genelde bazı konularda problem yaşayan, en ufak bir erora, soruna bile aslında çok fazla tahmin edemeyecek kullanıcılar geliyor.
Ondan dolayı aslında bizim uygulamada hakikaten dikkatli bir şekilde eror olmadan, sorun yaşatmadan kullanıcıya bir deneyim sunmamız hakikaten çok önemli oluyor burada.
Ve bizim uygulama yani neredeyse 7-24 Eylül hatta Ramazan'da vesaire işte bu sabura kadar olan kısımda işte...
Goal kuryeler, marketler vesaire çalışabiliyor hala.
Ondan dolayı neredeyse 7-24 çalışan bir sistemimiz var.
Ve bu down durumlarında memnunsuz customer'lar daha da memnunsuz olabiliyorlar.
Ayrıca bizim aslında bu availability'ye, aslında bir stability'yi sağlayabilmemizin en önemli konularından birisi de bu agentların aslında işte ay sonunda firma almalarını vesaire sağlayacak konularda çeşitli raporlamaları
var ve bu raporlamalarda bizden kaynaklanan bazı problemlerden dolayı onlara bayağı olumsuz şekilde yansıma ihtimalleri oluyor.
Dolayısıyla biz bazı konuları manuel de bir şekilde düzeltmeye çalışsak da günün sonunda bizim buradaki stabiliteyi en yüksek seviyede tutmaya çalışıp oradaki raporlama, monitörlük gibi konularda da yanlış yönlendirmemek adına çalışmalar
yapmamız gerekiyor. Biz neler yapıyoruz bunun için aslında?
Günün sonunda stabiliteyi sağlamak adına bizim Resilience'a vesaire de dikkat etmemiz gerekiyor burada.
Gökhan'ın da bahsettiği, iyice bildiği aslında bizim...
Bütün uygulamanın core kısmını oluşturuyor diyebiliriz.
Bu EJBRD'nin mesela olası bir fail look down senaryolarında vesaire bizim anlık olarak hemen başka bir tane EJBRD'ye geçebileceğimiz şekilde bir architecture dizayn ettik.
Malt EJBRD architecture şekilde.
Bizim aslında core kullandığımız yazılım bir probleme sebep olduğu zaman, yaşandığı zaman direktman tüm segmentleri direktman anlık olarak oraya geçebileceğimiz bir yapı var şu anda.
Bu şekilde aslında bir şekilde availability'de hiç sıkıntı yaşamadan.
devam ettirebiliriz. Onun dışında hani en az farklı bir şekilde deployment yapmak bizim için çok önemli burada stabiliteyi devam ettirebilmek adına.
Ondan dolayı köye arkadaş gerçekten çok...
Kompleks bütün senaryoları neredeyse kapsayabilecek regresyon testlerimiz var otomatik koşan.
Bunları da mesela düzenli biz işte her akşam koştuklarımız var.
İşte deploymentlardan önce bir koşalım bir soru var mı diye kontrol ettiğimiz senaryolar var.
Onları vesaire yaparak birçok konuda işte commit attıktan sonra stage'e çıktığımızda bu testleri yapıp ya burası bozulmuş vesaire deyip onu burada çıkmadığımız birçok senaryo oldu.
Bu şekilde stabiliteyi aslında sağlamaya çalışıyoruz bu şekilde.
Peki o zaman güzel bir soruyla geleyim.
Madem 7.24 destek dedin abi.
Evet abi. Tam tersi en kötü olayların yaşandığı.
Incidentler, akışlar böyle işte alertler vesaire.
Burada böyle yaşadığınız şeyler oluyor mu?
Mesela incident alert akışlarında işte alertler geldiğinde incident yaşandığında tam olarak nasıl aksiyonlar alınıyor sizin taraftan?
Abi şöyle söyleyeyim. Alert incident aslında bizim şu anda daha ideal düzeyde değiliz.
Şu anki durum şöyle oluyor.
Bizim business channel'larımız var.
Bu business channel'larında direktman Trendyol çalışanlarından var.
Direktman bu vendorların çalışanları oluyor.
Temsilcilerin vesaire, team leadleri vesaire.
Onlar bir problem olduğu zaman işte temsilcilerin onlara, onlarda bize aktardıkları channel'lar var.
Açıkçası şu anda alert'lar, bize incident'lar bunların üzerinden geliyor.
%80-%90 oranında.
Bizim aslında nihai amacımız bizim kendi alert'larımız var.
İşte elastik üzerinden basıp, ekipman üzerinden basıp onları alıp Slack'ten...
gelecek otomatik alertlar var.
Keşke aslında onlar bize yazmadan biz o alertları alıp ondan sonrasında bizim biznesine söyleyeceğimiz bir akış aslında bizim en ideal düşündüğümüz senaryo.
Oraya doğru evolve etmeye çalışıyoruz.
Yani işlerden bir şekilde vakit buldukça alertlarımızı arttırıp işte o biznesin verdiği alertları biz nasıl daha önceden görürdük diye biraz böyle analiz yapmaya çalışıyoruz.
Ama daha tam istediğimiz noktaya gelemedik.
Kısacası biznes çalınan üzerinden gelen bir süreç var.
Onun dışında daha yeni entegre ettiğimiz bir konu var.
İşte böyle herhangi bir şekilde bir süre teanında chat gelmezse eğer bizde alert basıyor çünkü sürekli bir şekilde chat gelmesi aslında.
mesai saatleri içerisinde expected olan bir durum.
Ama örnek veriyorum işte 10 dakika içerisinde 200 chatten az geldiyse bir sorun var şeklinde direktman kendi koyduğumuz rule setler var.
Aynen. Onlar da direktman bize uyarı verebiliyor işte.
Şu kadar süredir chat gelmiyor şeklinde.
Aslında alert incident yönetimleri biraz böyle biznes kanalından biraz kendi otomatik alertlarımızla görerek yapıyoruz.
Ama yani hemen hızlı bir şekilde müdahale edip genelde bütün incidentları çözmüş oluyoruz yani.
Var mı abi böyle güzel incident hikayenin?
Bir şeyiniz böyle şurada indirdik falan ne bileyim.
Abi şöyle aslında bizim incidentler gece olduğu zaman süper oluyor.
Ben bu incidentı mesela anlatıyorum ama burada ben hikayelerden yola çıkarak anlatıyorum.
Çünkü o gün şansıma ben yoktum.
Gece 1'de başlayıp sabaha kadar süren bir incident vardı.
Gökhan da ekstra şeylerini anlatır ama.
Orada sadece bir tane EJBD'nin yeni bir versiyona çıkmakla alakalı bir konu vardı.
Bu arada Incident'ları karıştırıyor bile olabilirim.
İki tane konu vardı. Incident, EJB'nin versiyonunu arttırırken de bir sorun yaşanmıştı.
Onun dışında gene bu DevOps'la beraber çalışarak yine bir deployment yaptığımız rollerle alakalı geniş kapsamlı bir değişiklik yapmıştık.
Orada epey bütün kullanıcılar şey yapamamıştı.
Sisteme girememişlerdi yani.
Biz oradan channel'lardan yazıyorlar, sisteme giremiyoruz, kullanıcılar bekliyor falan filan.
Biz orada şey yani bildiğin elin kolun bağlı bir şekilde neredeyse.
DevOps'da konuşuyorsun, şunu yapalım, geri alalım şeklinde vesaire iletişimler devam ediyor ama zaten gün içerisinde sürekli bir konu geliyor.
Mesela incident olarak değerlendirmeyeceğimiz bir alısı olarak geleceğimiz konular geliyor zaten ama incidentlar genelde geceleri vesaire böyle yaptığımız bazı hatalı ya da eksik konfigürasyonlardan olabiliyor.
Gökhan'ın ekstra böyle bir incidentla ilgili aklına gelen bir anı varsa belki o da paylaşabilir.
O gece zaten hepimiz epey heyecanlanmıştık.
Aslında... Şöyle olmuştu bizim yine kullandığımız EWD tool'un da yine versiyon geçişi miydi?
Tam emin değilim. Galiba cache size arttırıyorduk.
Orada da cache in memory'e yazan bir yapısı var.
Bir tane data verize corrupted olmuş data yüzünde.
Cache yazarken hata alıyordu.
Onu da biz anlamlandıramadık.
Çünkü aynı geçişi stage'de yaptık.
Bir sorun yaşamadık.
Kurulum tarafları da bizim daha çok SRE takımlı olduğu için hani o kusumlarda da hani anlık nasıl şeyler...
yapabiliriz kısmında çok tecrübemiz yoktu o esnada.
Baya işte biz gece bir buçukta falan başladık.
Aslında bir tane config update edip restart atıp devam etmeyi planlıyorduk.
Ya beş oldu, altı oldu, bitmiyor.
Yani geri döndürebilecek bir şey yok.
Hepimiz şey diyoruz.
Ya bir de biz 3 podu da aynı anda şey yapmadık.
Bir tane instance ayakta Allah'tan.
Bütün trafiği de oraya yönlendirdik.
Ama eskilerde hani o anda bir problem yaşamıştık.
O esnada diğer nodda olan kullanıcılarla alakalı.
Bir yandan diyoruz trafik işte bizim de günlük chatler 60-70k'larda oluyor normal bir günde.
100k'lara da çıkıyor. Tek nodda...
O kadar olur mu? Acaba bazı tekniklerleri kapatsak mı falan bir yandan düşünüyoruz.
Nasıl çözüm? Sonrasında o core-opted data'yı bulduk.
Ondan sonra onu silip tekrar installation'ı tamamlamıştık.
Bir data nelere kadir abi değil mi?
Evet, heyecanlıydı.
Valla böyle durumlar insanın hayatından hayat götürse de büyük dersler kazandırıyor, büyük dersler veriyor bence insana.
Takım olarak da knowledge bilgisinin, knowledge'ın artmasının vesaire çok büyük etkeni.
Tabii anlık hoş olmayan durumlar yaşanabiliyor.
Bayağı iyi handle etmişsiniz ama elinize sağlık.
Biraz şeyden bahsedelim istiyorum.
Şimdi Connect gayet güzel bir ürün, gayet sofistike olarak geliştirilmiş.
Fakat tabii biz burada teknolojisinden konuşurken aslında amacı kullanıcılar için vesaire önemli oluyor.
Bu ürününüzden agentler ya da işte team leadler, genel olarak kullanan ve dışarıdan bakan ya da işte maintain eden kişiler memnun mu?
Yani bu uygulamayla alakalı neler düşünülüyor?
Ne gibi yorumlar var?
uygulamamızla alakalı. Yani biraz önce incidentlardan hep böyle memnuniyetsizlik yaratabilecek durumlardan bahsettik.
Tabii böyle şeyler yaşandığında onlar da olumsuz etkileniyorlar.
Fakat tabii bunların hem gece oluyor olması hem de çözüm sağlayabiliyor onun.
Etkilenen kişilerin daha küçük olması o saatlerde bizim için olumlu oluyor.
Yakan'ın da bahsettiği gibi gün içerisinde 100K'lara kadar çıkan chatler olurken gece böyle 3-4 temsilciyle çünkü 3'ten 4'ten sonraya bazılarını planlıyoruz biz geçişleri.
3-4 temsilciyle hizmet veriyoruz.
En azından etkilenen kısmı küçük tutabiliyoruz.
Memnuniyet kısmına da gelirsek aslında hepimizin de bildiği gibi Trendyol'daki bu feedback kültürü...
çok önem verilen bir konu.
Biz de bu değeri aslında tool'un gelişimi için çok önemsiyoruz.
Bu noktada da hem müşteriler tarafına hem de tool'u kullanan işte bahsettiğim back office çalışanı olur, takım lideridir, agent'tir.
Bunların geri bildirimlerini alabilmek ve daha iyi bir tool'a dönüşüm sağlayabilmek için aslında herhalde düzenli bir memnuniyet anketi çıkıyoruz bu kullanıcılara.
Oralardan da feedbacklerini topluyoruz.
Bu feedbackler doğrultusunda şimdiye kadar aslında herhalde belirli düzenli alıklarla işleri aldık.
Ve planladık ve o anket sonuçlarına da bunların pozitif yansımalarını gördük.
Bir de buraya şey ekleyebilirim.
Bu feedbacklerde sadece yeni bir özellik ekleyelim gibi bir noktada değil de farkında olmadığımız çok edge case'ler yaşanabiliyor.
Bunları da paylaşmak için kullanıyorlar temsilciler bazen.
Yaşadıkları case'leri paylaşıyorlar.
Bunları fark edebilmek için de güzel oluyor.
Bir de hani böyle offline'de yaptığımız anketler dışında online olarak da temsilcilerle ya da kullananlarla birebir görüşme fırsatı var.
O da saha ziyaretleriyle oluyor.
3-4 ayda bir bir lokasyona gidip orada birebir de aslında bu tool'u nasıl kullanıyorlar, biz dizayn ederken hayal ettiğimiz şekilde mi kullanıyorlar bunları görebilme şansımız oluyor.
Buradan da hem gözlemliyoruz hem birebir de onların feedbacklerini alıyoruz ve bunların üzerinde de çalışıp onları daha memnun edebilecek hale getirmeye çalışıyoruz tool'u.
Şey gibi durumlar kesin yaşanıyor değil mi Çağla?
Yani mesela siz product geliştirme esnasında ya da işte ürünü geliştirirken feature ekleyeceğiniz zaman diyorsunuz ki ya bu acayip bir feature olacak.
İşte kullanıcı girecek şöyle yapacak böyle yapacak falan filan.
Halbuki hiç beklediğiniz gibi kullanılmayan case'leri oluyor.
Yani böyle hani bizde mesela bizim tarafta çok olur.
Hani örnek vermek ilgisi bir tane input yaparız.
Mesela deriz ki input'a şifre yazacak ya da örnek veriyorum sadece sayı yazması gereken bir şey.
İşte regeksini vesairesini yazarız.
Deriz ki ya şunu... da yapmaz deriz ve her zaman hiç sekmez onu yapar kullanıcı.
Yani hani her şekilde bizi şaşırtır.
Böyle kezlerde yaşıyorsunuzdur muhtemelen.
Aynen yani hem öyle hiç beklemediğimiz şekilde kullanıcılara uyuyor.
Mesela bir alan açıyoruz.
Oraya belirli bir şey yazmalarını bekliyoruz.
Hiç alakasız orasına hani aaa yazıp dolduruyorlar mesela.
O tarz şeylerde yaşıyoruz. Bir de bunun gibi çok etse böyle fraud case'de yaşayabileceğimiz bir case'imiz de oldu.
Mesela agentlerin işte molaya çıkmaları gerektiğinde falan bir kahve molası, yemek molası gibi biz onlara statüler veriyoruz.
Bunları kullanarak da aslında molalarına çıkıyorlar.
Şöyle bir şey var, ben kahve molaya çıkacağım diyen bir temsilciye de yeni bir chat atamıyoruz mesela buna.
Çünkü chatleri bitmeden çıkamayacak ve hiç molaya çıkamayacak hale gelebilir.
Yani biz analizlerde falan şeyleri gördük.
Bunu işte biz gerçekten kahve molası çıkacağız.
zaman kullanmasını beklerken aslında 3 chat'te değil de tek chat'te çalışmak için bu molaları kullandıklarını hani 150 kere falan kahve molası tıkladıklarını ama asla kahve molası da çıkmadıklarını falan gördük.
Mesela böyle kullanımları da şart ediyoruz.
Analizlerin, raporların da böyle buralarda etkisi oluyor bize.
Böyle güzel yönlendirmelere sebep oluyor.
Bunlara çözümler buluyoruz falan sonra.
Valla case'ler inanılmaz.
Yani özellikle dışarıdan insanların yani sistemlerle çalışan insanlar ya da servislerle sürekli çalışan insanlar, sürekli API yazan insanlar mesela sistem tarafından gelebilecek ya da teknolojik sıkıntılar açısından
kendilerini geliştirebiliyorlar ya da bunları öngörebiliyorlar ama ben de client ekiplerinde çalıştığım için biliyorum.
Kullanıcının direkt olarak kullandığı ve interaktif şekilde bir şeyler yaptığı bir uygulamada edge case'leri bulmak gerçekten oldukça zor.
Bu taraf sizin için de eminim bayağı sıkıntıdır.
Ama çok güzel handle ettiğinizi ben buradan emin olmuşum.
Bir de ben de orada arayabilirim.
Çok ufak. Zaten teknik anlamda çok challenge'lar var.
Hani bizim mesela bir müşteri işte sırada bekliyorsa, o an bütün agentler diğer müşterilerle konuşuyorsa, sonra bir agent boşa çıktığı zaman sonuçta bekleyen kullanıcıyı alacak.
O anda iki tane kullanıcı boşa çıkabilir.
Hani böyle race condition'lar falan olabiliyor.
Bu tarz problemleri de çözmeye çalışıyoruz.
Tabii bu tarafta da kullanılan agentler de bazen yani iş yüküne göre abuse etmeye de çalışabiliyorlar.
Çağla'nın da az önce söylediği gibi aslında oradaki 3 chat konusu normalde her segmente göre konfigüre edilebiliyor ama işte segmentler maksimum 3 chat alanı segmentler var.
Tabii agentlerinde biraz işine geliyor günde bir chat alarak devam etmek.
Hem teknik çözümlerin yanında bir yandan da...
bazı restriksiyonlar yapmak zorunda kalıyoruz.
Yani onların mesela bizim aklımıza gelmeyen çeşitli şeyleri de olmuş oluyor bu durumda.
Yani gidip mesela ek sekmeden daha açıp kendini bir yerde uygunda tutuyor, bir yerde çevrim dışı.
Çevrim dışı olduğu için biz ona chat vermiyoruz.
O esnada onların da team linkleri diyor sen neden chat almıyorsun?
Ben uygundayım chat gelmiyor diyor.
Gibi gibi sorunlar da yaşıyoruz aslında.
Tabii bütün agent'ların da hani günahını almamak gerek ama bazen böyle ebüz eden agent'lar da olabiliyor bir anda.
Bunlara da kafa yoruyoruz aslında.
Ama ebüz deyince aklıma şey de geldi ya.
Mesela Keyzer'den bir tanesi de normalde bazı agentler chat aldıkları sırada call da yapabiliyorlar.
Yanlış hatırlamıyorsam şöyle bir şey bulmuşlardı.
Call sırasında biz oradaki agent'a atabileceğimiz chat sayısını azaltıyoruz.
Hani çok sorun olması ona vesaire diye.
O call da gidip böyle hani aslında call'u uzatacak şekilde işte ne bileyim bir tanıdığını aramaya da...
işte aradığı kişiyle daha da uzatma vesaire şeklinde olan kezler de oluyordu.
Call bitmesin ki işte chat biraz daha geç gelsin şeklinde de ebüzler var.
Yani agentların yaratıcılığıyla bizim de çözümleri olan yaratıcılığımız aynı zamanda bir şekilde artmaya başlıyor yani.
Dolayısıyla bir şekilde çalışlar hep devam ediyor yani.
Güzelmiş ya. Çok beğendim bunu.
Gerçekten bu podcast'tan sonra bunu yapmayan agentler de bunu deneyecektir.
Artık bunu yapacağız. Ama zaten engelledik yani.
Tamam diyecektim.
Buradan bunu da duyururum diye artık böyle abuzlara chat uygulamasında yer yok.
Agentler yapmayın. Buradan agentler de seslenebiliriz.
Yani bütün yapılanların hepsi loglanıyor.
Auditleri var, şeyleri var. Agentler yapmayın bunları.
Zaten bu, Çağla'nın da az önce bahsettiği MPS anketlerinde hani şey falan da oluyor işte.
İşte burada soketten mesajlar geliyor.
Burası şöyle olmalı falan.
Bazıları da herhalde çok paralelde bakıyorlar bu tarz şeylere.
Artık evinize etmek için mi bilmiyorum.
Süper. Vallahi gayet güzel handle ediyorsunuz.
Ben çok beğendim açıkçası. Burada aklıma şey sorusu takıldı.
Şimdi çok güzel bir uygulama var.
Çok güzel bir ürün var ve bu ürün sonuçta sürekli bir geliştirme halinde.
Burada ürünü geliştirirken, yazılımı geliştirirken süreçleri de geliştirmek için ekstra neler yapıyorsunuz?
Yani işte ekstra peer'lar gibi ya da işte başka tek grubunikleri daha efektif yapmak vesaire gibi.
Nelere başvuruyorsunuz burada? Orada topu ben alabilirim aslında.
Zaten tren yol kültüründe de hani pair programming yeri geldiği zaman more programming gibi gibi bazı yaklaşımlar kullanılıyor efektif olarak.
Biz de zaten ekipçe genellikle pair programming yapıyoruz.
Zaten genellikle gelen issue'ların çoğu hatta task'ların diyeyim.
Hani bizim de zaten çok...
zor anladığımız, edge case'ler olduğu için iki göz bakmak, o şekilde implement etmek hem daha az hatalı kod çıkmamızı sağlıyor hem de süreci daha hızlı anlayıp daha kısa sürede geliştirmemizi
yapmamızı sağlıyor.
Onun dışında belki genel süreç anlamında çeşitli ekipler farklı farklı çözümler kullanıyor bu noktada benim bildiğim kadarıyla.
Bazı ekipler taslar gelince analiz tasları alıp bir önceki sprintte bu tasları detaylandırıyorlar.
Orada da kişisel olarak galiba taslar.
Biz ilk başta technical grooming yapmaya karar vermiştik.
Bizim grooming sesyonlarından sonra taskları detaylandırmak anlamında.
Tabii orada da bir kişi ekran paylaşıp hep beraber yapıyoruz.
Facilitation sürecinde de paylaşan kişi ekipte yeni olabilir.
Ondan sonra tecrübesi o domain bazında daha az olmuş olabilir.
O yüzden siz de fark edersiniz ki herkesin her taskı ilerletme şekli aynı olmuyor.
o süreçleri hani ilerletmek adına.
Bazı predefined sorular tanımladık.
Yani genellikle bizim işte bug'larda kullandığımız, yeni feature'larda kullandığımız, örnek vermek gerekirse yeni bir feature geliyor.
İşte sorulardan birisi şey işte, bu taskta başka bir ekibe bağlı mıyız?
Bu taskın sonucunda bir Kibana'dan alert oluşturmalı mıyız?
Gibi gibi. Yani facilitation transition'ı, geçişi daha smooth olsun diye.
Yani atıyorum Çağatay bir facilitation yaptığı zamanki tasklar çok detaylı oluyor.
Gökhan'da daha az detaylı oluyor.
Biz bunu neden konuşmadık?
Burada şu konular kalmış aslında bunları da yapmamız gerekiyor gibi gibi.
Noktaları da eksik bırakmamak adına kendimize böyle bir yöntem geliştirdik.
En azından tabii bu sorularla da tamamen bağlı kalmıyoruz.
Ama atladığımız bir nokta olmuyor.
Genellikle de bu şekilde ilerletiyoruz aslında.
Çok iyi abi. Peki bunlar da şimdi atomun planlaması oluyor, groomingi oluyor, işte retrosu oluyor vs.
İşte geliştirme için zamana gerek var.
Aslında... zaman ayırdığımız çok fazla şey var bir mesai saati içerisinde.
Peki burada örneğin RG yapmak istediğin zaman ya da hedeflerimiz oluyor onlar için olur.
Mesai saatleri içerisinde gerçekten çok yoğun geçiyor mu yoksa kendine de zaman ayırabiliyor musun?
O yoğunluğu bir şekilde nasıl o zaman yönetimini yapabiliyor musunuz?
Burada böyle bir fikriniz var mı?
Aslında yani genel kendimize geliştirme noktalarında aldığımız taslar için bir tane time slotumuz var.
Cuma günleri öğleden önce.
Ornunda bir haftasını böyle teknik işlere ayırmak istiyoruz.
İşte bir hafta teknik böyle işler.
Bir haftası da takımda atıyorum.
İşte Çağatay'la ben bir işe ilerlettim ya da ben tek başıma ilerlettim.
Orada da ne olduğu için yapmamız gereken noktalar olabiliyor.
Çünkü bazen konteksler çok değişiyor.
Yani ben bu hafta Soket'le uğraşırken atıyorum.
Çağatay aramayla ilgili bir şey yapmış.
Hani oraları da kaçırmamak adına review'da da edememe şansım olabilir.
Bu tarz serileri de kaçırmamak adına öyle bir seçimimiz var.
Tabii bunu çok düzenli takip ediyor muyuz?
O noktada da o haftaki sprint'in iş yüküne göre yapabiliyoruz ya da...
yapamıyoruz gibi diyebilirim.
Biz de zaten aslında senin de bahsettiğim gibi gün içerisinde aslında bir sürü yaptığımız gereken şey var.
Hem task ilerletmemiz gerekiyor.
Hem bir yandan hani tek grumu yapmamız gerekiyor.
Grooming yapmamız gerekiyor.
Yani bir task için birileriyle toplantı yapmamız gerekiyor.
O yüzden bir haftalık sprintler bizim için çok verimli.
Geçmiyor maddesi çıkmıştı Retro'da.
Onun ardından en azından bu grooming ve planlama toplantılarını bir kere yapabilmek adına, günü de çok yememek adına iki haftaya taşıdık bizim sprintleri.
Şu anda da o şekilde ilerliyoruz.
Peki benimle yeni gördünüz mü? Biz mesela bir haftalık yapıyoruz da.
İki hafta olunca nasıl olur sizde?
Belki orada Çağla'nın daha sağlıklı yorumları olabilir aslında.
Aslında biz görebildik diyebilirim orada.
Çünkü şu an ilk aşamada konnektici anlayanmak gibi böyle büyük bir proje takvimimiz vardı önümüzde.
Ve tasklar da daha büyüktü.
İşte yeni yeni analizler yapmamız gerekiyordu.
Şimdi mesela kalite özelliği eklemek gibi ayrıca büyük bir projemiz var.
Büyük projelerin olduğu noktada da aslında daha uzun sprintler bizim için daha faydalı oluyor.
Odaklanabiliyoruz, toplantılarla çok bölünmüyoruz.
Çünkü tek sprint olduğunda Gökhan'ın da bahsettiği gibi bir günümüz böyle.
işte grooming yapalım, arkasına tek grooming yapalım, bir günde de planlamayı yapalım gibi böyle sprintin büyük bir kısmını ayırabiliyorduk.
Aslında projenin adımları çok belli olduğu için bunlara çok fazla vakit ayırmamız gerekmemişti.
Şimdi o yüzden ikisi haftalık sprintler bizim için daha verimli oldu diyebiliriz.
Pastaların hani gelişimini daha iyi görebiliyoruz.
Ya da işte sprint versiyonu falan takip edebilir hale geldik.
Daha bize doğru sonuçlar verebiliyor en azından.
Tabii bu büyük projeler çıktıktan sonra daha increment increment gittiğimiz noktada tekrar iki haftalık, bir haftalık bir de değerlendirebiliriz tabii.
Anladım. Güzelmiş ha. Ben bunu hiç düşünmemişim.
Hatta bir podcast meselesini ekiple konuşurken bir düşüneceğim ben onu bir düşünelim mi diye aklıma geldi şimdilik.
Süper. Peki bu kadar konuştuk.
Burada şimdi bu connect tool'undan vesaire bahsettik.
Bunun böyle artık diğerlerde, diğer uygulamalarda nasıl olabilir bilmiyorum ama ileri seviyesinde neler yapılabilir ya da Sizin planlarınızda neler var?
İleride neler gelecek böyle Connect Tool'larıyla ilgili?
Biraz gelecek planlarından bahsedebilirim ben.
Bir de Connect'i anlatırken de aslında şey söylemiştik.
Şu anda biz sadece chat özelinde hizmet veriyoruz.
Yani temsilciler farklı kanallardan geliştiriyor.
Mail ile sorununu ileten ya da sesle sorununu ileten müşterilere cevap vermek istediklerinde third party tool'ları kullanmaya devam ediyorlar.
Burada tek tool, tek arayüz gibi bir bakış açısıyla aslında ilk önceliğimiz farklı kanalları da bu tool içerisinde enable'a...
ve onların tek arayüzünden hizmet verebilmesini sağlamak.
Diğer bir noktada daha önceki sorularda farklı segmentlerimizin olduğundan bahsetmiştik.
Bunlardan bir tanesi de International taraf.
Her segmentin farklı ihtiyacı olduğu gibi International'da farklı ihtiyaçları oluyor.
Bunlardan bir tanesi de çeviri ihtiyacı aslında.
Farklı dillerde hizmet almak isteyen müşteriler geliyor.
Mesela yakın zamanda Azerbaycan tarafına doğru bir müşteri açılımı oldu.
Oradan da gelen ihtiyaçlarla işte gelen müşteri...
Kendi dilinde hizmet almak istiyor ve biz bu noktada da farklı dilleri bilen...
temsilciler bulmamız gerekiyor ki onlar istediği dilde hizmet alabilsin.
Bu da çok efficient değil. Burada da aslında biz böyle canlı dil çevirisi sağlayabilen uygulamalarla Connect uygulamasını birleştirip aslında isteyen müşteri hangi dilde sorununu ifade etmek istiyorsa onunla konuşabilsin
istiyoruz. Bir diğer gelecek planlarımızdan bir tanesi de bu.
Son olarak bir de şeyden bahsedebilirim.
Böyle günümüz trendleriyle de paralel olarak aslında NLP tarafına da yatırım yapmak istiyoruz.
İçeride temsilcilerin bazı...
Bunlar da aslında hem süre olarak onların süreçlerini uzatıyor hem de böyle manuel hataya sebep olacak bazı süreçler oluyor.
Ne gibi diye sorarsanız mesela her chatin sonunda temsilciye diyoruz ki bu müşteri niye gelmiş git seç bir yerden.
Orada arayı bulup onu seçmeleri gerekiyor.
Biz burada aslında chatin içeriğini bilerek bir tahminleme yaparak orada bu chat bu sebeple gelmiştir diyebilmek ve tamamen temsilciden bağımsız olarak bu süreci ilerletebilmek ve orada da sebep oluşabilecek hatalar var.
Bu gibi projelerimiz var şu anda öncelikli olarak.
Burada doğal dil işlemi falan, yapay zeka her yere geliyor diyebilir miyiz?
Aynen diyebiliriz. Biz de heyecanlıyız o tarafta neler yapabiliriz diye.
Çok iyi, süper. Arkadaşlar çok teşekkür ettik.
Son sorumuzdu bunlar böyle.
Çok güzel bir sohbet oldu. Buradan Eko ekibine teşekkür ediyoruz.
Biz teşekkür ederiz abi.
Biz de teşekkür ederiz. Sağ olun efendim.
Evet 31. bölümde gördüğünüz gibi Eko ekibiyle beraberdik arkadaşlar.
Herkese çok teşekkürler. Bir sonraki bölümde görüşmek üzere.
Görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.
