4 maddede Developer Experience (DX) nasıl olmalı?
Developer Experience (Türkçeye yazılımcı deneyimi diye çevirebiliriz sanıyorum) zaman geçtikçe ama ne yazık ki geç farkına vardığım, bir yazılımcının huzurlu bir şekilde işini güzel ve eksiksiz yapmasını sağlayan, sabah bilgisayarı açtığında mutlu mutlu gününü geçirmesinin en önemli göstergesi. İyi bir Developer Experience sağlamak, bir teknoloji şirketinin en önemli misyonu olmalı.
Maaş, çalışılan domain, yan hak, kullanılan teknolojiler, prim v.b. gibi dış etkenler yerine, aslında daha uzun süre kişileri mutlu edecek ve aynı şirkette mutlu bir şekilde kalmalarını sağlayacak maddeleri aşağıdaki 4 maddede toplamaya çalıştım. 2021 ve sonrası için kendime koyduğum en önemli hedef, beraber çalıştığım her ekip için bu maddeleri sağlamaya çalışmak olacak. Maddeler şöyle :
1. Gün İçi süreçler
2. Backlog + Data
3. Eğlence
4. Kişisel Gelişim
Tek tek detaylandırmak gerekirse;
1. Gün içi süreçler
1.1 Omuzdaki Yük
Bir yazılımcının çalışırken omzundaki yükün çok az olması ve bu yükün sadece business ve domain özelinde olması gerekiyor. Team Topologies’de de geçtiği üzere, bir takımın üzerinde 3 tip yük varsa, ki bunlar intrinsic (skills), extraneous (süreç), and germane (domain) olarak belirleniyor, bir takım sadece içinde olduğu domain’le ilgili konulara odaklanmalı. Bir yazılımcının üzerindeki dış yükler (extraneous load ) minimum olmalı. Bu dış yükler, deployment nasıl oluyordu, CD süreci nasıl işliyordu, hata olursa nasıl geri alınıyordu gibi konular çok basit ve net olmalı.
1.2 CD Süreçleri
Ben her iş görüşmesinde, adaylara kendi şirketlerindeki CD süreçlerini anlatmasını ya da nasıl bir süreç olsa süper olurdu tasarlamasını rica ediyorum, çünkü bu konu cidden o şirketi ya da kişiyi tanımlayan en karakteristik özelliklerden biri oluyor. Bir şirket kültürünü en iyi gözlemleyebileceğimiz yer, o şirketin CD süreçleri ve o şirketin bu konuya yaklaşımlarıdır bence. Trendyol’da bu konuda iyi olduğumuzu düşünüyorum ama iyileştirebileceğimiz daha çok şey var. Ekip olarak takip ettiğimiz 4 Key Metrics aslında bunun bir göstergesi. Bu konuda uzun uzun tartışabiliriz ama yazıyı çok da uzatmamak için, bu konuyu başka bir yazıya saklayalım.
1.3 En iyi araç gereç
Hep söyleniyor ama tekrar hatırlatmakta fayda var, en doğru ve olabiliyorsa en iyi araçlar bir yazılımcının elinin altında olmalı. Mouse, klavye, laptop, monitor, ide v.b. ne gerekiyorsa en iyisi olmalı. Gün içinde kullanılan her bir toolda ‘ucuza kaçma’ aslında, her bir developer’in daha verimsiz olma ihtimalini arttırıyor.
1.4 No Meeting Zone
Herhangi bir günde, bir developer olabildiğince üretken olabilmeli, toplantılar ile dikkati dağılmadan, işine konsantre olabilmeli. Bunun için her toplantının en fazla 30 dk olmasını sağlamak, ‘no meeting zone’ zamanlar belirlemek önemli olabilir.
1.5 Hazır bir Infra & Platform
Yazılımcıların daha verimli olması için, herhangi bir konudaki bilgiye daha rahat ulaşması için, şirket içi süreç ve araçları geliştiren platform ekiplerinin olması da çok iyi oluyor. Ortak sorunların ortak çözümlerini geliştiren bu ekipler, yazılımcıların üzerlerindeki ‘extraneous’ yükü azaltıyor, domain ekipleri sorumlu oldukları işlere daha konsantre olabiliyorlar. İşe başladığınızda önünüze hazır gelen ( isterseniz pair olup daha da iyileştirebileceğiniz, geri bildirimlerinizle, commitlerinizle, katkılarınızla daha da iyi olan ) cache, scale, xdcr, monitoring, güvenlik, ci-cd v.b. nin hazır olduğunu bir düşünsenize. Trendyol’da teknoloji ekibi olarak 700+ kişiye çıktığımız bu zamanlarda, platform ekibimiz son 1 yıldır bize bu konuda çok fazla katkı sağladı.
1.6 Alarm ve Monitoring
Bir yazılımcı mevcut işlerini yaparken, arka planda sistemin her zaman doğru şekilde çalıştığını bilmeli. Sistemde bir sıkıntı olduğunda anında haberdar olabilmeli, bunları monitor edebilmeli. Developer’ın çalıştığı platform’un alarm ve monitoring icin sistemlerinin hazır olması, hem mevcut hem de yeni yapılan geliştirmelerin otomatik olarak kontrol ediliyor olması lazım. Uçtan uca sistemi görebileceğimiz bir APM olması, hem business metric’leri hem de sistemin işleyişini görebileceği, business data’larını takip edebileceği dashboard’lar olması, buradaki anomalilerin bir alarm ile yazılım ekibine ulaşabilmesi çok önemli. Trendyol’da Slack uzerinden takip ettiğimiz bir metrik, satıcıların gönderdiği fiyat ve stok işlemlerinin suistimal edilip edilmediği mesela.
2. Backlog + Business
Her türlü teknik ‘challenge’a bayılan developer’ların aslında yapılan her iş özelinde business’a yakin olması, detayları bilmesi, işe başlarken neden sorusuna cevap alabilmesi, iş bittiğinde de sonuçları ne oldu konusunda her an erişebildiği bir bilgi paylaşımı çok önemli. Yapılan her işin çıktısını data bazlı görebilmek, yazılımcıların teknik altyapı, büyüme ve değişim planları yaparken daha yakın tahminler yapabilmesine olanak sağlarken, iç motivasyonu da çok arttırıyor. Su an Trendyol’da 30 Milyon aktif ürünümüz varsa, 2021 sonunda ne kadar olacağını tahmin ederken, bu bilgi üzerinden hesaplamaları yapabiliyoruz mesela. Bunların yanına günlük gelen istek sayılarını da koyup, nereye kadar nasıl scale edebileceğimizi planlıyoruz. Aktif 20 Milyon müşteri ve günde ortalama 1,1 Milyon paketi kullanıcılara ulaştırırken, bu business rakamlarını yazılım ekipleri ile paylaşmak, onları da şirketin bir parçası olduklarını ve yaptıkları işin önemini hissetmelerini sağlıyor.
Business Backlog’u, yani şirketin o ekipten beklediklerini her ay başında ekibe sunmak, hem o aylık hem de önümüzdeki 3 ve 6 aylık tahmini proje ve iş planlarını ekibe periyodik olarak anlatmak, developer’ların da kendini domain içinde daha çok hissetmesini sağlıyor. Bir şey yapıyoruz ama neden bilmiyorum duygusundan çıkartıp, bu işi X nedeniyle yapıyoruz, çıktısı da Y olacak denebilmesi çok önemli. Aylık ve haftalık backlog oluşurken, hem teknik, hem belki legal hem de iş birimlerinden gelen işlerin önceliklendirmesinde ekibin tümünün açık şekilde haberdar olması, yorum yapması ve dinlemesi çok önemli oluyor. Yapılan işlerin A/B testleri ile yapılması, hem çıktıların ölçülmesi hem de daha sonra kontrol edilip iyileştirmesi adına çok güzel bir pratik. Yapılan işi gün sonunda müşterilerimiz için yapıyoruz ve onların ne kadar kullandığı ( ya da kullanmadığı ) aslında o işin başarısını tanımlıyor.
3. Eğlence
Çalışırken beni en çok motive eden şey sanırım eğlenmek. Beraber eğlenen ekiplerin daha başarılı olduğunu onlarca kez gördüm. Tam tersine, ortak bir eğlencesi olmayan ekiplerin de aynı şekilde mutsuz olduğuna ve birçok kez tanık oldum. Bir iş yaparken eğer eğleniyorsan, çalışıyor gibi değil de, aslında bir hikayenin, masalın hatta en önemlisi de çok önemli bir hedefin parçası olduğunu hissediyorsun. Yan yana oturduğun, ( pandemi sürecinde zoom’da yan yana pencerelerde olduğun 😔 ) aynı hedefe doğru koştuğun, production’da sıkıntı olduğunda omuz omuza verip sorunu çözdüğün o anlarda yanında olan ekip arkadaşların ile eğlenebilmek; ekip için ve o ekibi oluşturan her bir birey için en önemli şeylerden biri. Bir yazılımcı için de, eğlenmek, mutluluğu artıran, içsel motivasyon sağlayan kritik konulardan.
Hayatımda en mutlu ve belki de verimli çalıştığım dönemlerden biri Dolap’ın ilk 1 yılıydı. En sevdiğim zamanlar da 08:30–09:00 arası sabah kahvesi boşu ve 12–2 arası geyikleriydi. Birbirimize takılır, eğlenir, boş boş sağı solu izlerdik. Yürüyüş yapar, dondurma yer, kafa dağıtırdık. Ama çalışırken de bir makine gibi durmadan, bölünmeden akar giderdik. Trendyol’da da benzer bir beraber çalışma ve eğlenme ortamı var, o yüzden çok huzurluyum burada. Gün sonunda ekiptekiler iş arkadaşımdan önce, arkadaşlarım gibi hissediyorum.
Pandemi olmadığı bir dünyada, ayda iki üç ofis dışı buluşmalar, sabah beraber kahvaltı yapmak, öğle yemeklerini ortak yemek, ayın belli günleri beraber POC’ler yapmak, ortak bir github projesinde çalışmak v.b. çok önemli. Bunlara katılmayan ekip arkadaşlarını gerekirse zorla dahil etmek lazım. Pandemi sürecinde de hayatımıza giren among us, garticphone gibi oyunlar, bu mutluluğu arttırıyor. Şirketlerin, şirket dışı aktivitelere de imkan sağlaması çok önemli.
Ekip bazlı NPS ölçmek, 1–1'lerde mutluluk puanını sormak (ben hemen hemen hepsinde 10 üzerinden mutluluğuna kaç puan verirsin ama cevap olarak 7 veremezsin şeklinde bu bilgiyi öğrenmeye çalışıyorum) bu konularda uygulanabilecek pratikler arasında.
4. Kişisel gelişim
Sürekli gelişim, bir yazılımcı olarak dikkat etmemiz gereken en önemli şey. Her ayın sonunda, kendimize bu ay geliştim mi diye sormamız lazım mesela. Her gün dünden daha iyiye gitmeye çalışmalı ve bunun sonuncunda da 1 günde değil belki ama 1 ay, 6 ay belki 1 yıl sonunda çıktıları çok büyük oranda görebiliyor olabilmeliyiz. Kaizen ve Compound Interest olarak iki maddeyi buraya ekledim, isteyenler daha detaylı bakabilirler.
Şirketlerin kişisel gelişim için şirkette çalışan herkese; udemy, safaribooks vb. gibi platformlarda hesaplar açabilmesi için destek sağlaması, eğitim / konferans bütçelerinin olması ( Trendyol’da bu dediklerim mevcut 🙂) önemli. Tabii ki herkes bu nimetleri kullanmıyor ama kendini geliştirmek isteyenler için çok yardımcı oluyor.
Kişisel gelişimin göstergesi ve devamlılığı için bir hobi projesi olması, aynı domain’de olmaması gerektiğini düşünüyorum, github’da aktif olması DX’i iyileştirecektir, şirketin aktif bir github hesabi da aslında bu konuda developer’lara bir ateşleyici güç olacaktır.
Kişisel gelişim konusunda liderlerin ve şirketlerin yapabileceği şeyler; Internal meetup’lar düzenlenmesi, brown bag session’lar yapılması,meetup’lara katılım konusunda ekip arkadaşlarının motive edilmesi, Meetup’lara hem konuşmacı hem de dinleyici olarak katılmayı hedefler arasına koymak, medium ve OSS’e katkı gibi konuları da bu kişisel hedeflere eklemek olabilir.
Bitirirken, Developer Experience, bir yazılımcının mutlu, huzurlu bir şekilde hem kendini, hem de çalıştığı ekibi ve şirketi büyüttüğü bir ortam sağlaması; şirketlerin ve liderlerin en önem vermesi gereken konu. Diğer her şey ikinci planda kalıyor.
Not1: bu yazıyı yazdığım günlerde, Nick Tune’un da yazısını gördüm, ona da göz atılması süper olur.
Not2: Bu yazıda ekipteki diğer rolleri unuttuğum düşünülmesin, DevInTest, PO, UI/UX, DevOps v.b. de benzer deneyimi yaşamalı, benzer süreç o roller için de kesinlikle olmalı.
