Transkript
Hello herkese hoş geldiniz.
Bu haftaki podcastımız 20 mi oldu?
Ben şu an kontrol ettim.
19 Trendyol Hızlı Market Yemek OMS bölümümüzmüş.
Şu an evet gerçekten de inanılmaz bir durum.
20. bölümdeyiz. Hakikaten ve bunu ilk seferde ilk defa mı şey yaptık?
Hep böyle kaçtı 19 mu bilmem ne mi kalıyorduk?
Evet. Mükemmel bir 20.
bölüm konuğumuz. 20.
bölüme yakışır bir şekilde farklı bir ekip bu sefer.
Hep kendi ekiplerinden gidiyorduk.
Bu sefer mobil taraftan IOS ekibinin Checkout tarafından Selin ve Beyza ile birlikteyiz.
Hoş geldiniz Selin ve Beyza.
Hoş bulduk. Nasılsınız?
İyiyiz. Teşekkür ederiz.
Siz nasılsınız? Biz de iyiyiz.
O zaman şey yapalım hemen.
Bir böyle bize çalıştığınız domenini anlatın.
Mesela ben şey merak ediyorum.
iOS ekibinin checkout tarafından dedik sizin için.
Mesela nerede çalışıyorsunuz?
Domeninizde kaçer tane ekip var?
Bunlar nasıl yerleşiyor?
Biraz bunlardan bahsedebilirsiniz.
Olur tabii. Selamlar yeniden.
Ben Leyza. Aslında biz iOS tarafında yaklaşık 35 developer tek bir codebase ile çalışıyoruz.
Ama içeride yaklaşık olarak 7 tane ekibe...
kanala ayrı ayrı bölünüyoruz.
Selim ve benim bulunduğum kısım Checkout olarak geçiyor.
Checkout tarafında da aslında küçük küçük içeride market, yemek, işte Dolap Light, International olarak farklı farklı arkadaşlarımız görev alıyor.
Biz ana Checkout tarafında çalışıyoruz.
Peki burada neler bulunuyor?
Aslında ödeme ekranları, kullanıcının login olduktan sonra görebildiği ekranlar, işte basket ekranı gibi ekranları geliştirmelerini biz yapıyoruz.
Ya aslında siz çalışmazsanız tren diyor sipariş alamaz diyebilir miyiz?
Gerçi çok yüksek girdim.
Buradan şeye geleceğim aslında.
Selin Beyza siz kimsiniz?
Bize biraz kendinizden bahsedir misiniz?
Doğru tabii güzel bir soru bu.
O zaman ben devam edeyim.
Ben Beyza İnce.
Yaklaşık bir senedir tren yoldayım.
Çekahat hekimle çalışıyorum. Başlangıcım 3 aylık bir süreçte yemek tarafındaydım.
iOS ekibinde. Sonrasında Checkout'un bu bahsettiğim ödeme ekranlarının olduğu kısma geri geldim diyebiliriz.
Ondan önce de yaklaşık bir senelik bir iOS Developer geçmişim vardı.
Daha öncesi de Frontend Developer olarak çalışıyordum aslında.
Şu anda da buradayım. Ben de Selin.
Ben de bir yıldır buradayım.
iOS Checkout ekibindeyim.
Ben ayrı bir takıda değilim.
Hep iOS Checkout'taydım.
Ondan önce de yaklaşık benim de bir 3-4 yıl deneyimim var bu konuyla ilgili.
Teşekkürler. Peki biraz böyle hangi domen ve takımlarla yakın çalışıyorsunuz onlardan da bahsedebilir misiniz?
Bildiğim kadarıyla böyle şeyle daha çok yakın yani Zeus ekibi var işte mobil tarafın BFF olan.
Onunla baya yakın çalıştığınızı biliyorum ama onun dışında çalıştığınız ekipler kimler mesela?
Özellikle Checkout sizin ekip.
Ondan dolayı merak ettim birazcık.
Evet aslında çok doğru söyledin Barış.
Biz en çok herhalde Zeus'la çalışıyoruz BFF'imiz.
Ama yani genel iOS ekibinden bahsedecek olursam Apollo ve Atlas da var yine aynı BFF'ler.
Atlas Miel tarafının, Apollo ise Dolaplay tarafının BFF'i.
Biz Checkout olarak başka hangi ekiplerle çalışıyoruz?
Yani tabii ki tahmin edebileceğiniz gibi Payment tarafıyla, Wallet, User ekipleri, Social bir sürü ekiple çalışıyoruz.
Hatta herhalde günün sonunda herkese tek tek böyle bir interaksiyonumuz oluyordur.
BFF dediniz ya ben biraz onu sormak istiyorum.
BFF tam olarak ne yapıyor?
Aslında Atlas ekibi, Zeus ekibi, Apollo ekibi dediniz ama neye yarıyor?
Siz neden bu BFF'leri kullanıyorsunuz?
Şöyle aslında deep backend dediğimiz taraftan bize gelen, client'a gelen isteklerin işte bize gelecek şekilde bizim isteğimiz doğrultusunda çevrilmesine yarıyor.
Bizim isteğimiz doğrultusunda bu şekilde geliyor.
Biz de onları kullanıyoruz. Böylece deep backend'de birden çok servise gitmiyoruz.
İşte beklediğimiz şekilde client nasıl istiyorsa o şekilde dönebiliyor.
Böyle bir yapımız oluyor.
EFF'lerden bahsettikten sonra o zaman biraz da şu anki bulunduğunuz ekibin yapısından bahseder misiniz?
Backend developer var mı?
Hiç bilmiyorum ama varsa kaç tane var?
İşte kaç tane mobil developer var?
QA'ler, product team, kaç kişisiniz toplam?
Onur tabii burada ben söze gireyim.
İçeride 34 tane iOS developer bulunuyor şu anda arkadaşımız.
Bunlar da aslında iki ana şey...
gruba ayrılıyor, disco ve check-out olarak.
Bunun yanında 8 tane QA arkadaşımız var, yine kanal bazlı bölünen ve 8 tane de product manager'ımız var.
Her biri farklı kanallara baktığı için aslında sayımız fazla duruyor ama gün sonunda tam olarak yetiyor gibiyiz.
Ya ben şeyi soracağım, 34 developer sabah toplantısında aynı anda girmiyor değil mi?
Yok, hayır. Kanal bazlı yürüttüğümüz süreçler aslında ayrılıyor.
Mesela check-out tarafında sadece Benim bulunduğum kısma bakan yaklaşık 5 ya da 6 tane developer var.
Bizim daily'lerimiz diğer ekiplerin daily'lerinden farklı oluyor.
Sadece haklılık yaptığımız weekly'ler ya da bazen yaptığımız retro'larda ortak buluşuyoruz.
Onun dışında planlarımız birbirinden bağımsız.
Süper, süper. Peki hala remote dönemindeyiz.
Hatta omikronla beraber COVID'in böyle arttığı bir dönemdeyiz tekrar.
Ama yeni kişiler trend dola başlamaya devam ediyor.
Siz bu yeni gelen kişileri nasıl onboard ediyorsunuz?
Böyle yeni gelen kişiler yazdığı konuyu ne zaman sistemde görebiliyor?
Aslında onboarding sürecimiz tren yolunun genel kürtülüğüyle de uyuşarak tabii ki de bir body atama süreciyle başlıyor.
Ben kendi deneyimimden örnek, yani benim de bir yıl oldu.
Bir yıl önce işte...
BanaBody'm daha başlamadan önce yazmıştı direkt.
Tanıttı kendini.
Nasıl ilerleyeceğimizden bahsetti.
Biz de bu şekilde aslında bu body atamadığını bu şekilde yapıyoruz.
Daha sonrasında en önemli kısım ekip.
Çok söylediğimiz gibi çok 34 developer falan gibi bir büyük ekip olduğumuz için.
Herkeste de tek tek kaynaşmanın önemli olduğunu düşündüğümüz için tanışmaca toplantıları yapıyoruz aslında.
Böyle birebir vakit geçirmek şeklinde.
Maalesef Zoom'dan oluyor şimdi ama.
Onun dışında Bu canlıya kod çıkma durumunda şöyle biz aslında başlangıç itibariyle peer programming ile ilerliyoruz.
Böylelikle hem koda hakimiyetini yeni gelen arkadaşımızla geliştirmeye çalışıyoruz hem de destek oluyoruz birlikte.
İletişimimiz de böylece güçlenmiş oluyor.
Bu canlıya çıkma konusunu da yani çok uzun bir süreç olmuyor.
Zaten bizim belli süreçlerle canlıya çıktığımız için herhalde geldikten sonraki ilk...
pakette bir kodu oluyordur.
Peyreni hallediğimiz için çabuk bir adaptasyon sağlıyoruz aslında.
Teşekkürler. Peki bu bence kritik bir soru.
Sizin de bir yılına yaklaşmış.
Peki bu bir yıl içinde sizin veya bir başkasının aslında karşılaşmış olabileceği bir şey.
bence. Ekipteki herkes bütün gelen işlerle %100 eşleşiyor mu?
Yani mesela her işe karşı aynı motivasyonda olmayabilirsiniz ve yapmak istemediğiniz bir işle karşılaştığınızda nasıl aksiyon alıyorsunuz?
Biz aslında bu %100 eşleşmeni sağlamaya çalışıyoruz.
Domenin bilgisini herkese.
Bunları nasıl sağlıyoruz?
Daha önce örnek verecek olursam, mesela Bullet'la ilgilenmiş bir arkadaşımız, Bullet'a daha önce hiç girmemiş bir arkadaşımızla Payr olarak ilerliyor.
İş alma süreçlerinde de bu taskı sen al, bu taskı ben al şeklinde ilerlemiyoruz.
Herkes zaten istediğini alıp ilerliyor ama böyle büyük ve domain bilgisini yayması gereken tasklarda planlamalarımızı genelde bu dediğim şekilde Payr halinde ilerletmeye çalışıyoruz.
Ben de şey tanımıyorum.
Mesela şu ana kadar konuştuğumuz ekipler ya backend ağırlıklı ya da frontend ağırlıklı ekiplerdi.
O yüzden bir feature çıkacakları zaman onu bir şekilde feature breaklerle bir şekilde dipto çıkıp daha sonra onları açarak anında müşteri yansıtabiliyor olmalıydı.
Ama bildiğim kadarıyla iOS ve Android tarafında biraz agile kısmı biraz daha şey yani istediğin zaman direkt.
Bir paket çıkamıyorsun işte bir onaydan geçiyor vesaire falan.
Belli bir süreç var. Bu sürece bir şekilde uymak gerekiyor.
Ve bu da biraz sanki ecail olmamızı etkiliyor mu acaba?
Sizdeki durum nedir? Mesela sizlerin ecail informasyonunuz nedir?
Süreçleri nedir? Biraz anlatabilir misiniz?
Aslında bizim de yani paket çıkmak için belli bir süreçimiz var.
Hatta şu an bir süredir belirli zamanlarla paket çıkıyoruz.
Tarihlerimiz belli şeklinde.
Bu sürece de yine en küçük parçayı oluşturup yine eylem şeklinde ilerliyoruz.
O pakete girecek şeyleri ayarlayıp ilerletiyoruz.
Anlık bir aksiyon alma genelde konfik dediğimiz şeylerle ya da bir hata durumunda backend ekiplerinden destekle oluyor.
Ve bunları kabul edebilecek şekilde çıkmaya çalışıyoruz zaten.
Ben şeyi soracağım ekstra.
Bazen böyle yeni bir feature çıkıyor trend yolda.
Diyoruz ki mesela order parent ID'yi yok edeceğiz.
Ama eski uygulamalar var.
Eski uygulamaları desteklememiz gerekiyor.
O yüzden order parent ID'yi yok etmek çok zor olabiliyor.
Bu tarz durumlarda nasıl yaklaşıyorsunuz?
Hangi verilere bakıyorsunuz? Burada ben cevap vereyim.
Aslında bizim eski client'larımızın etkilenmemesi için genellikle optional olarak period'ları dengelemeye çalışıyoruz.
Ve Zeus'dan gelen data da...
Belirlediğimiz bir yıldan hemen kaldırılması şeklinde değil de yandan yeni bir value eklenmesi olarak devam ediyoruz.
Yoksa diğer türlü ilerlediğimizde eski clientlerde işte crash hatalar oluşmaya başlıyor.
O yüzden genelde şey kontrol ediyoruz.
Bunu kapattığımızda eski clientlerde bir sorun olacak mı?
Olacaksa kaldırmayalım.
Eski clientlerdeki kullanım azaldığında ve işte yeni çıktığımız sürümlerden sonra tekrar Zeus'la görüşüp kaldırmaya o şekilde karar veriyoruz.
Peki ortalama ne kadar sürüyor bu kaldırma?
Yani bir şeyi yok etmek istedik tren yolunda, bir alanı yok etmek istedik.
Ne kadar sürer? Ya bu aslında o versiyonun kullanım miktarı ile alakalı.
Atılan isteklerde Zeus ya da diğer backend servisleri ne kadar istek geldiğini biliyor versiyonlama sayesinde.
Hani orada işte hiç istek gelmediğini anladığımız durumda tekrar konuşmamız gerekiyor ama hani bu bahsedilen sürece biz çok fazla yapmıyoruz.
Onun yerine eskiyi kaldırmak değil, yeniyi eklemeyi daha çok tercih ediyoruz.
Yaptığım birçok işle mesela eskiyi genelde kaldırmadım.
Hep yeni üzerine ekleme şeklinde ilerledik.
Peki şimdi dediğiniz işlere çıkıyoruz.
İşlere çıktıktan sonra ne gibi monitoringler yapıyorsunuz?
Veya ne gibi alert mekanizmalarınız var?
Mobil tarafta kritik olan şeyler neler aslında?
Veya bir bug oluştuğunda production'da ve gerçekten çok büyük user'ları etkilediğinde bunlardan nasıl haberdar oluyorsunuz?
Aslında şöyle, client olduğumuz için bizim en çok karşımıza çıkabilecek, yani bizim kontrol edebileceğimiz crash fix ya da bug fix olabiliyor.
Crash fix'i de aslında biz paketimizi kontrollü bir adaptasyonla açtığımız için daha %1 sürecindeyken kontrollerini yapıyoruz.
Bu yüzden zaten açıyoruz. Crash var mı?
Kullanıcılığı etkileyen eventler gönderiyoruz.
Crashlytics'ten bunu takip ediyoruz.
Böyle bir durum varsa paketi durduruyoruz yayılımını.
Hotfix çıkıyoruz. Eğer bunu daha geç fark edersek yine bir hotfix çıkmamız gerekiyor.
Yani client tarafı olduğumuz için bir anlık müdahale bu kadar yapabiliyoruz.
Aniden çiğit çıkma konusunda.
Onun dışında bir nivrelikten takip ediyoruz.
Ondan sonra response time'ları, error rate'leri kontrol ediyoruz.
Ve gerekli ekiplere bunun işte böyle olduğunu haber veriyoruz.
Ve buna göre bir düzenlemeler yapılıyor.
Mobil tarafı biraz yabancı olduğum için bu soru mantıksız gelebilir ama bildiğim kadarıyla iOS'da yeni bir süreç çıkmak istediğimizde bir kurula bunu yolluyoruz.
Onlar kontrol ediyor, sonra onay veriyor.
Bu da uzun süren bir süreç diye duymuştum.
Bu cidden böyle mi? Evet yani şöyle aslında bizim bir arsa sürecimiz oluyor, test ediliyor.
Daha sonra evet dediğin gibi biz App Store'a göndermek için Apple'a review'e gönderiyoruz.
Onların kabulünden yani e-proof verdikten sonra onlar yayılıma başlatabiliyoruz biz.
O süre ne kadar sürüyor ortalama?
Aslında önceleri bu süre biraz uzundu ama şu an çok uzun sürmüyor.
Bir iki gün, bazen bir iki saat.
Yani işte Amerika'da oldukları için denk gelirse daha hızlı olabiliyor.
O yüzden şu anda yeni bir app'te olmadığımız için, var olan bir app'e güncelleme çıktığımız için aslında daha hızlı e-proof alabiliyoruz.
Önce de bahsettim böyle işte bir sorun olduğu zaman işte etkiler falan işte petçiler çıkıyor vesaire falan dedim.
Yani Trendyol mod uygulamasını da hani böyle milyonlarca aslında kişi kullanıyor baktığın zaman ve çok hızlı şekilde de çıkılan versiyonlar download edilip işte yükleniyordu diye düşünüyorum.
Yani bu şekilde aslında kod kalitesini ya da işte bu süreçlerdeki kaliteyi korumak için neler yapıyorsunuz?
Mesela işte kod review, işte TDD pair ya da işte...
Unit test ya da integration test gibi şeylerde neler yapıyorsunuz?
Biraz o tarafı anlatabilir misiniz?
Tabii. Aslında biz iki kod review süreçlerini biz hep harekete tutmaya çalışıyoruz.
Bu yüzden de herhangi bir arkadaşımız yeni bir pull request açtığında yaptığı iş için genelde ona minimum 6 tane reviewer atıyoruz.
Ve bu arkadaşların en az 5 tanesinin onaylamasını bekliyoruz.
Burada da reviewer arkadaşlar aslında orada yapılan her değişikliği, her klastaki değişikliği tek tek inceliyorlar.
ve sorunlu ya da işte daha iyi performans verecek hale geldiklerini düşündüğünde oraya bir yorum giriyorlar.
Eğer kesinlikle oranın değişmesini istiyorsak orada bir test kaçıyoruz ve developer arkadaşın orada düzeltme yapmasını bekliyoruz.
Beş tane pro almadan aslında köye geçmesini de engelliyoruz.
Bu sayede hem review süreçlerimiz daha stabil ilerliyor hem de içeride yazdığımız kod basedeki değişiklikler çok fazla stabiliteyi bozmuyor.
Bunun yanında test driving development uygulamıyoruz.
Onun yerine aslında işte istenilen lojiyi uygulayıp sonrasında unit test yazmaya çalışıyoruz oradaki her lojik için.
Unit testler açılan bir yerlerde must.
Eğer yazılmazsa orada developer arkadaşı uyarıyoruz ve işte geliştirme yapmasını bekliyoruz unit testler için.
Bunun yanında yakın zamanlarda özellikle UI tarafında mona kontrol yerine otomasyon tarafına ağırlık verebilmek için işte çeşitli çalışmalar yaptık.
Bunlardan şu an en...
ithal etmeye çalıştığımız kısım snapshot testler.
Yakın zamanda zaten onun için bir sunum yapmıştık.
Snapshot testlerle de amacımız özellikle QA arkadaşlarının üzerindeki yükü almak.
Çünkü release planlı zamanlarda çok fazla ekran ve case olduğu için monel test süreçlerinde bir şeyin gözden kaçma ihtimali çok fazla.
Snapshot testlerle de aslında ekranların her release zamanı beklediğimiz şekilde çalıştığından emin olmaya çalışıyoruz.
Genel olarak test süreçlerimize ağırlık vermek üzerine kurulu geçiyor şu anki zamanımız.
Ben bununla alakalı bir soru sormak istiyorum.
Mesela bir versiyon çıktınız ama o versiyonla bir sorun olduğunu düşünüyorsunuz ve az önce dedik ya versiyonu geri çekebiliyoruz.
O durumda mesela ben indirmiş olduğum zaman ne oluyor?
Ben o versiyonu açamıyor muyum?
iOS'u engelliyor mu? Burada şöyle bir durum var, eğer senin cihazına inmeyse ona yapabileceğimiz bir şey yok.
Ama mesela %1 ile açtığımız için kullanıcılara, kanal %99'un ona erişmesini engelliyoruz.
O süreçte de aslında Apple'dan bir destek alıyoruz.
Diyelim ki orada bir sorun var ve işte hotfix çıktık.
Sonra Apple'a bunun için bir mesaj atıyoruz.
Eski versiyonun bir kreşe sebep olduğunu, o yüzden de hızlı bir şekilde...
Hepimizin review'dan geçip canlıya çıkması konusunda onlara bir mail atıyoruz.
O mailde sağ olsunlar çok hızlı dönüyorlar çoğunlukla.
O yüzden oradaki kreşi kısa zamanda çözüme kavuşturmuş oluyoruz.
Takım olarak en büyük challenge'ınız nedir?
Şu an özellikle teknik kısımda 34 tane developer arkadaş tek bir codebase'e geliştirme yaptığı için ve uygulama proje çok büyük olduğu için bu yurt tayinlerimiz biraz yüksek.
Bunun için de içeride platform adı verilen bir ekibimiz var.
Onlar özellikle modüler kısımda çok fazla geliştirme yapmaya çalışıyorlar ve bu yurt sürelerini düşürmek için böyle yeni çalışmaları var.
Yakın zamanda da burada güzel sonuçları alacağımızı düşünüyoruz.
Genel olarak çalıştığımız yerler...
Ne kadar güzel yerler oluyor olsa da bir şekilde bizim de kişisel olarak merak ettiğimiz konular olabiliyor ve bunları da her zaman şirketteki kullandığımız teknolojiler karşılayamayabiliyor.
Bu tür durumlarda mesela hiç kişisel bir konuyu araştırayım ya da şöyle bir yeni bir şey çıkmış da bu projede uygulayabilir miyiz gibi dediğimiz şeylerde kişisel gelişme olmak
sağlayacak zamanlarınız oluyor mu?
Kendinizi bu tür zamandan yaratabiliyor musunuz?
Tabii bu kısımda da ekip olarak bizim fazla bir isteğimiz var.
Özellikle cuma sabahları böyle kişisel gelişim için kendimize zaman yaratmaya çalışıyoruz.
Ve Slack tarafında da IAS Massey adını verdiğimiz bir kanalımız var.
Ekipteki arkadaşlar herhangi bir şekilde işinize yarayacağını düşündüğü bir tool'u, kütüphaneyi direkt orada paylaşabiliyorlar.
Ya da herhangi yeni bilgiyi, işte kullandığımız yazılım dilindeki bir gelişmeyi de orada paylaşabiliyorlar.
Diyelim ki yeni bir kütüphane gördük ve hoşumuza gitti.
Gerçekten işe yarayacağını düşünüyoruz.
Sonrasında bunu tartışıyoruz.
Hani ne şekilde projeye entegre edebiliriz diye.
Eğer güzel çıktı alacağına inanıyorsak aslında içeride de onu kullanmaya çalışıyoruz.
Ayrıca her hafta salı günlerinde bir tek meetingimiz oluyor IOS ekibi olarak.
Orada da bu alacağımız kararları hani ne yapabiliriz şeklinde konuşmalarımız oluyor.
Bu arada siz hangi dili yazıyorsunuz?
Çok basit bir soruyla geldim ama.
Doğru bir soru. Şu an Swift diliyle yazıyoruz.
Projenin başlangıcı Objective C'ymiş.
Biz gelmeden önce Swift tarafına taşımışlar.
O yüzden çok mutluyuz. Aynen.
Süper. Günce olan teknoloji Swift bildiğim kadarıyla.
Peki hani böyle gelişim için kullandığımız en güzel tool'lardan bir tanesi Retro.
Böyle son Retro'dan çıkan güzel bir maddeniz var mıdır?
Yani böyle iyileştirdiğiniz bir şeyle alakalı olabilir.
Kanlı bir Retro aksiyonu olabilir.
Yakın zamanda Checkout Ekim'de yaptığımız Retro'lardan çıkardığımız güzel bir aksiyon var.
Bizim tarafta işler bazen AB'li ya da konflik eklemeli şeklinde ilerliyor.
Ve bu eklediğimiz konflik key'lerini aslında QA arkadaşlar tek tek takip ediyordu.
Restorada konuşurken bunun gözden kaçma durumunu fark ettik.
Ve bunu engellemek için de aslında otomasyon tarafında bir geliştirme yaptık.
Diyelim ki bir iş için konflik ekledik panellerimize.
Eklediğimiz konflikleri icra testlerinde bildiğimiz standart bir comment şekline girmeye çalışıyoruz.
Sonrasında işte köy arkadaşlarımız Slack'taki botlarımıza bir tane küçük bir şey giriyorlar, kod giriyorlar.
O kod sayesinde de onlara aslında hangi işlerde hangi konflik keylerini tanımladığımızı dönen bir mesaj geliyor.
Peki anladığım kadarıyla önce kullanıcıların %1'ini açıyoruz yine versiyonu dediniz.
Tahminimce bir problem olduğu zaman zaten çok fazla kullanıcı etkilenmiyordur ama en son canlı sistemde çok büyük bir problem yaşadığınızda yani canlıyı patlattığınızda kaba tabiriyle aksiyon olarak ne
yaptınız? Yani canlıda çıkan bir problemden aslında öğrendiğiniz en önemli şey neydi?
Şöyle örnek verebilirim sanırım.
Yani bazen backend tarafında az önce de aslında bahsettik.
Null beklemediğimiz değerlerin null gelmesi durumu yani bizim bunu optional yapmıyor oluşumuz.
Crash'e ya da ekranda beklenmeyen bir hata oluştu basması sebep olabiliyor.
Ama tabii ki bunun aksiyonu çok hızlı bir şekilde alınabiliyor.
Backend de hızlı bir şekilde düzeltebiliyor.
Ama biz de bundan şunu öğrenebiliyoruz.
Bunun dönmeme ihtimalini de düşünelim.
yazarken ekleyelim şeklinde bir öğretisi bize geri dönüşü olmuş oluyor.
Peki böyle sınırcı ekip yönlerinde bulunmak gereken en önemli bir soft skill nedir?
Özellikle remote çalıştığımız bu süreçte biz iletişim olduğunu düşünüyoruz.
Çünkü özellikle Zoom konuşmalarında yaptığımız, peyir olduğumuz işlerde bildiğimiz know-how'ları karşı tarafa...
iyi bir şekilde aktarabilmek ve karşı tarafında bunu boşluklar detaylarında eksik kalmayacak şekilde anlayabilmesi için iletişim kısmında açık ve net olmaya çalışıyoruz.
Bu sayede de aslında yaptığımız işlerden hem keyif alıyoruz hem de ekip içindeki uyumu arttırabiliyoruz.
Çok güzel bir şeyden bahsettiniz.
İletişim gerçekten mutlu.
Yani normalde olduğundan böyle iki kat, üç kat daha önemli hala gelmeye başladı.
Çünkü iletişim kurabileceğimiz zamanlar da azaldı.
Bunun bir yan noktası olarak aslında iletişim arttırmanın yollarına odaklanmaya çalışıyoruz tüm trendi olarak.
Siz de ekip lideri dışındaki kişiler birbirleriyle sık sık birebir yapıyor mu?
Yani bu one to one adı altında olmuyor.
Söylediğim gibi aslında...
Çok pair yapıyoruz. Yani gün içinde ben kaç tane insanla görüşüyorum, pair yapıyorum.
Ben sayamıyorum herhalde.
O yüzden de hem sohbet edip hem birlikte kod yazıp kafa patlatmak ona bizim mantıvanımız o oluyor gibi oluyor.
O yüzden o iletişim hiç kopmuyor aramızda açıkçası.
Peki birbirimize feedback verirken böyle rahat mısınız?
Çünkü feedback vermek bazen çok zor olabiliyor.
Yani rahatız. Şu ana kadar ben böyle bir rahatsız olduğumuz bir şeyle karşılaşmadım açıkçası.
Çünkü bu konuda birbirimize güvenimiz tam bir alınma ya da iyi bir şey geldiğinde şımarma gibi bir şeyimiz olmuyor.
O yüzden rahatça birbirimize konuşabiliyoruz.
Zaten iletişimin sonucu oluyor bu.
Peki en son neye feedback verdin?
En son aslında bu değerlendirme yaptığımız süreçte böyle feedback bodylerime ben feedback vermiştim mesela.
Orada hem iyi feedbackler hem de yapıcı feedbackler kısmında böyle alınmadan ve gerçekten rahatça söyleyebileceğimi düşündüğüm şeyleri yazdım.
Burada da galiba mesela Selin'e bir feedback vermiştim.
İletişim konusunda birebir de çok iyi olduğunu söylemiştim.
Ama daha kalabalık gruplarda biraz daha sessiz kalmayı tercih ediyordu.
Hani bu konuda açık açık onunla içimden geçeni anlatabilmiştim.
Çok güzel ya gerçekten herkeste iyi ve kötü yani hem geliştiği noktaları hem de gelişme alanlarını birbirine çok dürüst bir şekilde söyleyebiliyor olmak bence bir ekipteki en
büyük şanslardan bir tanesi.
Sizin de böyle olduğunuz için çok mutlu oldum açıkçası.
Anladığım kadarıyla tabii bunlardan sonra ekipte aslında birbirinizi önemsiyorsunuz da.
Bu sebeple bir sorun var.
Bir işte ekip arkadaşınızın gerçekten motivasyonunun düştüğünü gördünüz.
Böyle bir durumda nasıl bir çözüm uygularsınız veya uyguladınız?
Genelde şekilde ilerliyor.
Özellikle kullandığım bir metot yok ama işte yine iletişim konusuna geliyor olay.
Payroll'urken ya da herhangi bir kanalda bir arkadaşımın demoralize olduğunu hissediyorsam aslında direkt ona yazıyorum.
Ya da boşluğunda benimle vantofan atmasında işte Zoom kolunda buluşmamızı istediğimi söylüyorum.
Öyle günlük bir muhabbet yapıyoruz aramızda ve onun enerjisini artırmaya çalışıyorum ben genel olarak.
Sonrasında da aslında arkadaşımın daha iyi bir duruma geldiğini düşünüyorum.
Aslında yani hiç düşürmemeye çalışıyoruz birbirimiz ama transiyon temel o medyası o.
O yüzden sürekli yüksek tutmaya çalışıyoruz.
Ama tabii ki düştüğü durumlarda Beyza'nın dediği gibi birbirimize gaz vererek ilerleyerek geliştirirsen kendimizi yükseltiririz.
Aynen. Peki bu tarz durumlarda birbirimize şarkı söylüyor musunuz?
Bizde şarkıdan çok özlü sözler var aslında.
Birbirimize hayatın anlamlarını açıklayan sözlerle yükselmeye çalışıyoruz.
Hatta şu an mesela söyleyebileceğimiz birkaç tane sözümüz de var.
Tabii ki. Lütfen.
O zaman ilk ben söyleyeyim.
Benim çok sevdiğim, sevgili Android'deki ekip lideri Ertuğrul Taras'tan bir söz var.
Aklıma o geldi. Sözün bittiği yerde umut vardır, umudun olduğu yerde de hayat.
Alkış. Alkış gerekiyor bu defa.
Başka var mı böyle sözler? Tabii ki de.
Olmaz mı? O zaman bir sonraki sözümüz de Cenk Işık'tan gelsin.
Birbirimize sarılmazsak nasıl çıkacak bu karanlıklar aydınlığa?
Değil mi? Çok iyi.
O zaman üç taneye tamamlayalım bence.
Bir özlü söz daha rica edelim.
O zaman sonuncusu da yine benden gelsin.
Cenk Işık'tan bir özlü söz söylemek isterim.
Bazen en yukarı zıplamak için çömelik bıçak almak lazım.
Olamaz gerçekten ya.
Bizimki bu başta herhangi kimse yok.
Gerçekten. Şu anda kanlı mallıyı bayağı.
Ama şu an... Önüne dön çalışacağım ve bundan sonra her güne göre bir özlü söz yollayacağım.
Kesinlikle. Toplantıları böyle kapamak istiyorum bundan sonra.
Özlü sözlerle, azı sözlerle ilgili.
Peki arkadaşlar, güldük, eğlendik ama bir şarkı da rica ediyoruz sizden.
Evet, şimdi bu güzel seferi duyduk.
O bir dur dedi de, hiç söyleyip bulaştırmayalım sizi.
Siz söylersiniz ya, ben sizden o şeyi aldım, o da aldım.
Biz o kadar çok söz seçtik. Vallahi ben söyleyemem, utanırım.
Hep beraber söyleyeceksek tabii ki katılırız.
Aynen, aynen. Sizden seçtik ederiz.
Yeni yıl şarkısı da mı olmaz?
Yeni yıl, yeni yıl, yeni yıl falan gibi.
Tabii hep beraber söyleyelim.
Hep beraber. İstemeyiz değil mi Selim?
Tabii. Tamam.
Çok kringli olacak şu an.
Biz yeni yıl kutlu olsun diyelim daha çabuk.
Yeni yılımız kutlu olsun diyelim.
Aşk olsun ya. Bir gerçekten şöyle coşkulu.
Yeni yıl yeni yıl diye bir girmediniz ya.
Geliyor. Geliyor.
Ben hissediyorum. Beyza söyleyecek ya.
Ben söylerim.
Ne olacak? Şurada izini seven insanlarız.
O zaman ben mi gireyim? Yeni yıl, yeni yıl, yeni yıl, yeni yıl, bizlere kutlu olsun.
Yeni yıl, yeni yıl, yeni yıl, yeni yıl, bizlere kutlu olsun.
Çok güzel, mükemmel.
Çok teşekkürler arkadaşlar ya.
Belki de hepimiz çok değil yani.
Çok teşekkür ediyoruz. Biz teşekkür ederiz.
Beyza, çok teşekkür ederiz katıldığınız için programımıza.
Çok keyifli bir program oldu. Galiba yılı böyle kapatıyoruz değil mi?
Şu an ayın 30'u çünkü. Aslında 2022'nin ilk podcastı bu.
Hayırlı olsun. Bu podcastı kaydettiğimizden...
Çok teşekkürler. Çok keyifliydi.
Çok teşekkürler.
Çok teşekkürler.
Bir sonraki podcastta görüşmek üzere.
Hoşçakalın. Hoşçakalın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.