Başka hiç bir yerde bulamayacağınız deneyim ve bilgiyi paylaşmak üzere Crossover‘ın yazılım geliştirme alanındaki başarısının arkasındaki isimle, Mircea Strugaru ile yaptığım bir röportajı paylaşmak istedim. Bu röportajda nasıl tam zamanlı uzaktan çalışmayı dünyanın çeşitli yerlerinden binlerce profesyonel için mümkün kıldıklarını ve yazılım mühendisliği alanında nam salmış performansı nasıl elde ettiklerini irdelemek istedim.
Bize biraz kendinden ve geçmişinden bahseder misin?
Kodlamaya 12 yaşında başladım, babam o zamanlar Timisoara’da bir Romanya Üniversitesinde Bilgisayar Bilimleri departmanının başındaydı. Bana bilgisayar virüsünü o bulaştırdı. O günden bu yana teknolojiyle iç içeyim.
2000 yılında ilk işime başladım. Yazılım geliştirici olarak başlasamda ilk gün işverenimden bana yazılım takımlarını yönetme fırsatı vermesini istedim. Yazılım geliştirme şirketi olarak bir deneme sürecindeydik. Bu deneme sürecinde Alman bir grubun şemsiyesi altındaydık ve değerlendiriliyorduk. Bu Alman yazılım geliştirme grubuna dış kaynak olarak hizmet veriyorduk. Birkaç yıl içinde bu grubun tüm işlerini almayı başardık ve tüm eforu kendi çatımız altında toplamıştık. O zamanlar 3-4 farklı bölgede yazılım geliştiren bu grup ürettiğimiz verim sayesinde tüm bütçesini bizim çatımız altına toplamaya ikna olmuştu. Bu esasen yazılım geliştirmenin yanında yönetim alanında ilk büyük başarımdı diyebilirim.
3 Yılımı o şirkette geçirdikten sonra 10 yıl kurumsal alanda farklı seviyelerde yazılım geliştirme süreçlerinin yönetiminde çalıştım. Çalıştığım şirket Alcatel Lucent idi. Uğraşmak zorunda olduğum bürokrasiden bıktım ve kariyerimin bir sonraki adımı için yeni bir şeye ihtiyacım olduğunu hissediyordum. Yeniden yaratıcı ve üretken olmalıydım fakat nereden başlayacağımla ilgili bir fikrim yoktu. Yakın zamanda kendi hikayesini Rusça konuşan topluluklarla paylaşan Slava gibi bende Seattle, Dublin gibi şehirlere taşınıp Microsoft ve Google gibi devlerle çalışmak istemedim. Evde, Romanya’da kalmak istiyordum.
Ve sonra Andy Tryba ile tanıştım, 3 ay sonra VP of Engineering pozisyonunda Crossover’da çalışıyordum, buluştuk ve bana inşa etmek istediği şeyi, vizyonunu anlattı. Mantığı hemen anlamıştım ve Andy Montgomery gibi bazı anahtar oyuncularla tanışıp konuştuktan sonra herşey aklımda oturdu. Karar vermek için ihtiyacım olan herşeye sahiptim, kurulan bu yapının bir parçası olmam gerektiğini anladım ve katılmaya karar verdim.
Crossover’da ve çatı şirketi ESW Capital’de tam olarak ne yaptığını bize anlatır mısın?
Birkaç şeyi paralel olarak yürütmem gerekiyor aslında, bunların ilki Andy Tryba’nın şirketlerinde yazılım mühendisliğini yürütmek. Bildiğin gibi şu an Crossover, EngineYard ve DNN i yönetiyor . Bunun yanında yılın geri kalanında onlarca farklı şirket satın alması planlıyor. Yakın zamanda milyar dolarlık bir fon kurdu ve adını da Think3 koydu. Bu fonla dünyanın heryerinden SaaS şirketlerini satın almayı ve daha kârlı hale getirmeyi planlıyor. Bu satın alma ile küresel ölçekte startup kurucularına yeni denemeler yapma fırsatı vermeyi hedefliyor.
Sorumluluklarımın ilk bölümü bunlar, bir diğer bölümü ise merkezi yazılım mühendisliği grubunda bakım süreçlerini yürütmek. 130 Kadar mühendisimiz tüm grup için yazılım ürünlerine bakım hizmeti veriyor. Tüm şirketler ve tüm ürünler burada bakım hizmeti alıyor. Kurduğumuz yazılım mühendisliği fabrikasının özeti böyle. Geniş takımlar kuruyor ve onları Worksmart fabrikaları olarak yönetiyoruz.
Sorumluluklarımın üçüncü ve son bölümü ise farklı şirket ve ürünlere etki ediyor. Bazı uçtan uca süreçler geliştiriyor ve bunları uyguluyorum, bunlar neler? Hızlıca anlatayım; defect çözümlemeleri, yayına giden yol haritaları, teknik arıza anında uygulanacak planlar vs. tüm bunlar farklı ürünler üzerinde çalışan tek ve sabit bir plan geliştirmeye dayalı. Worksmart Pro dediğimiz yönetim konsepti takım seviyesinde bu süreçlerin uygulanabilirliğini ve kalitesini yönetebilmemizi sağlıyor. Bu üçü şimdilik Crossover’da VP of Engineering olarak aldığım sorumluluklar.
Yeni bir yazılım şirketi satınalmasından sonra tam olarak ne yapıyorsunuz? Takımları ve şirketleri nasıl dönüştürüyorsunuz?
Tabi, öncelikle finansal hesaplamalar aşaması var tabi fakat yazılım mühendisliği perspektifinden bakarak yaptığımız ilk şey bir durum tespiti bunu muhakkak satınalma öncesinde yapıyoruz. Bu durum tespit sürecinde geliştirilen yazılım ürününün kalitesini anlamaya odaklanıyoruz, ne kadar iyi tasarlanmış? Hangi teknolojiler kullanılmış? Standart modelimizle ne kadar uyumlu? Evet, standart bir yazılım ürünü geliştirme modelimiz var. Satınalma tamamlandıktan sonra ise Import dediğimiz süreci başlatıyoruz. Bu Import sürecinde satın alınan şirketin daha önce geliştirdiği ürünü alıp yeniden yapılandırıyoruz ve standart modelimize uyumlu hale getiriyoruz.
Bu ne anlama geliyor? Grubumuzun içinde CI/CD süreçlerinin standart bir modeli var, continuous integration ve continuous deployment her zaman aynı teknolojilerle ve standartlarımız çerçevesinde yapılıyor olmalı. Sonrasında ürünün yayına alım süreçlerini inceliyoruz. Daha önce kullandıklar model her neyse o modelden Docker’a geçiş yapıyoruz. Yani tüm ürünlerimiz hem geliştirme hem yayın ortamında Docker container’lerinde çalışıyor ve son olarak kullandıkları veritabanı teknolojisi her ne olursa olsun o teknolojiden Amazon Aurora’ya geçiş yapıyoruz.
Ürünlerimizi yalnızca cloud ortamında çalıştırıyoruz. Yerel sunucu ortamında çalışan ürünümüz yok. Hangi veri merkezinde veya cloud sunucusunda çalışırsa çalışsın ürünü öncelikle Amazon’a taşıyoruz, yani ürettikleri tüm ürün ve veriyi alıp Amazon’a taşıyoruz ve dockerize ederek CI/CD süreçlerimize uyumlu hale getiriyoruz. Bazı durumlarda ise satın alınan ürünün teknolojisini değiştiriyor ve kısmen veya tamamen yeniden yazıyoruz. Merkezi olarak tercih ettiğimiz Java ve .NET gibi bazı teknolojiler var, ürünü bu dillerde yeniden yazıp uyumlu gale getiriyoruz.
Ön yüz bölümü için bir UI fabrikası kurduk ve bu fabrikada Angular kullanıyoruz. Arka yüz içinse .NET veya Java kullanıyoruz çoğunlukla.
Yazılım mühendisliği takımlarını dönüştürürken ölçümlediğiniz anahtar metrikleriniz neler?
Yeni bir şirketi veya ürünü satın aldığımızda ilk olarak mevcut insan kaynağı içerisinde yetenekli üyeleri ekipte tutmaya çalışıyoruz, sonrasında ise dünyanın 1% lik sınanmış kabiliyetlerinden oluşan Crossover insan kaynağını ekibe eklemeye başlıyoruz, bu sayede genel kalite ortalamasını arttırıyoruz. Biliyorsun Crossover’da hedefimiz yetenekleri sınayarak en iyi 1% lik dilimi işe almak, rakamlara baktığımızda bunda da epey başarılıyız aslında.
En iyi ihtimalle, aldığımız şirketlerin içerisinde yazılım mühendisliği anlamında test ekibi ve geliştirme ekibi olarak ikiye ayrılan bir yapı gözlemliyoruz. Yani bir grup yazılım geliştirirken diğer grup test ve kaliteyle uğraşıyor. Elde olan tüm yapı çoğunlukla bu oluyor nitelik olarak baktığımız zaman. Biz işi bundan çok öteye taşıyoruz. Öncelikle yazılım için yeni özellikler geliştiren ekibi (Feature) bakım yapan ekipten (Maintenance), performans iyileştirmesi yapan ekipten (Faster) ve arayüzde geliştirmeler yaparak kullanıcı deneyimini iyileştirmeye çalışan ekipten (Easier) ayırıyoruz.
Nihai olarak 4 farklı yazılım fabrikası kurmuş oluyoruz, Feature, Faster, Easier ve Maintenance olarak adlandırıyoruz bunları. Yeni bir şirketi aldığımızda ise yüksek performansla çalışan eski takım üyelerini yeni kaynağımızla birlikte çalışacakları bir eş çalışma modeline alıyoruz (pair work program). Bu sayede ekip içerisindeki deneyim ve ürün bilgisinin tüm gruba yayılmasını sağlıyoruz.
Çapraz eğitim faktörü dediğimiz (cross-training factor) bir yapı var, şu anlama geliyor; her birey 3-5 arasında değişen farklı üründe çalışarak deneyim geliştirmeye çalışıyor. Elbette bu aynı anda olmuyor farklı zaman dilimlerinde bunu yaparak tüm ürünlerde deneyim kazanmalarını sağlıyoruz.
Sonrasında ise bu ekiplerin tamamının ölçümü giriyor hayatımıza, tüm bu ekipler tek bir metrikle ölçülüyor ve tek bir süreçle yönetiliyor. Hayal edin, bakım ekibinin sorumlu olduğu 80 farklı ürün var, ekip içerisinde dünyanın çeşitli yerlerinden 130 mühendis var ve tüm bu bireyler ürün fark etmeksizin aynı süreçle, aynı kalite hedefiyle, aynı SLAler ile yönetiliyor.
Bu tekileşmiş yönetim biçimiyle tüm ürünlerde çalışan mühendislerimizi sayısı ne olursa olsun sağlıklı bir biçimde ölçebiliyoruz ve bu bize süreçlerimizde neyi iyileştirmemiz gerektiği, kimin aslında çok iyi sonuç ürettiğiyle ilgili net bir bilgi sağlıyor. Bu, büyük çapta yarattığımız ekonominin temeli, üretkenliği arttırırken rekabeti canlı tutuyor ve yüzlerce mühendis arasından kimin daha verimli olduğunu saptıyoruz.
Tüm bu süreç şu iki temel kolon üzerinde yaşıyor:
Yazılım Mühendisliğinde Üretkenlik
-
Birim maliyeti
Ekibin KPI’ı olan ve mutlaka tek bir metrik’le yönettiğimiz iş biriminin maliyeti. Bu her zaman baktığımız bir veri ve bu veriyi bireysel olarak, ürün başına, takım başına, ve birim başına ölçüyoruz. İş birimi mutlaka ürüne veya müşteriye değer katan bir şey olmak zorunda ve birim değeri her takım için farklı. Birimler soyut değil mutlaka ölçülebilir iş değeri ürettiğinden emin olduğumuz şeyler. Story point’ler gibi soyut değerleri kesinlikle kullanmıyoruz. Bakım ekibi için bu çözülen sorun sayısı iken yeni özellikler geliştiren ekip için bu müşterinin gerçekten kullanacağı ve ihtiyacı olan bir özellik, performans ekibi için ise yüzdesel olarak üründe gerçekleşen hız artışı.
-
İş döngüsü süresi
İş döngüsü süresi dediğimizde bahsettiğimiz şey tam olarak iş birimi üzerinde çalışmaya başlandığı andan tamamlandığı ana kadar geçen süre. İş döngüsü süresini sürekli olarak kısaltmak için kendimizle yarışıyoruz. Bir örnek vermem gerekirse 2017’nin son çeyreğinde bakım ekibi için sorun çözme süresi 30 gündü. Yani yazılımdaki tek bir sorunu çözmek ortalama 30 günümüzü alıyordu. Kendimizle yarışarak bu süreyi 6 güne kadar düşürmeyi başardık. İki çeyreklik sürede 5 kat performans artışı sağladığımızı söyleyebilirim. Şunu da eklemeliyim ki bunu daha da kısaltmak için hala çalışıyoruz.
Yazılım Mühendisliğinde Kalite
-
Kalite hedefinde sapma yüzdesi
Burada tam olarak şunu yapıyoruz; takımlar arasında iş geçişlerinde bir kalite hedefi koyuyoruz. İşlerin takımlar arasında belirli bir kalite hedefiyle transfer olmasını sağlamanız işin süresini kısaltmak için çok önemli. Objektif ve anlaşılır bir kalite hedefiniz olması gerekiyor. Ve bu süreci olabildiğince otomatize ediyoruz, buna insan kaynağı harcamak istemiyoruz. Kalite hedefini ortaya koyduğumuzda ekipler arasındaki tüm iş geçişleri ya kalite hedefimizin üzerinde ya da altında kalıyor. Bir işlem kalite hedefinin altında kaldığında bunu kaydediyoruz. Tüm işlemlerin sayısını alıp 10% luk bir kalite hedefi sapması elde ettiğimizde hedefimiz en iyiye ulaşmak olduğundan bu işlemi reddediyor ve yok sayıyoruz. Yani mühendis bu konuyu yeniden çalışmak zorunda. Kalite hedefinde %100 ü yakalamak, sapma oranında ise %0’ı yakalamak için çalışıyoruz.
-
SLAs (service-level agreements)
Sonrasında elbette birde böyle bir ayrım var elimizde, her takımın kendi fonksiyonunu gerçekleştirebilmek için ihtiyacı olan zamanı belirliyoruz. Bunun için SLA adında bir başka değeri ortaya koyuyoruz. Mühendislerimiz bir iş üzerinde çalışmaya başladığında ilerleme kaydetmek için ne kadar zamana ihtiyaçları oluyor bunu belirliyoruz. Bunun için de aynı yaklaşımı ortaya koyuyoruz, örneğin QA, QA süreçleri için belirlediğimiz SLA 24 saat. Eğer QA takımı bugün 13:00’da bir iş alırsa bunu ertesi gün 13:00’a kadar istediğimiz kalite seviyesinde teslim etmek zorunda. Eğer tamamlayamadılarsa elbette bu görev üzerinde çalışmaya devam ediyorlar fakat SLA’leri bozulmuş olacak ve biz bunu bileceğiz. Eğer 100 iş devralıp bunun 50 tanesini 24 saat içerisinde teslim edebiliyorlarsa hata oranları %50 olacak. Bu saydığımız bir başka değer. Bu değeri ürettiğimiz işin yüksek kalitede üretilmesini sağlamakta kullanıyoruz. Bu tamamen iş aşamalarından hangisinde ne kadar zaman harcandığıyla ilgili. Arzu edilenden daha fazla zaman haranıyorsa sürecimiz yeterince iyi değil demektir. Eğer iyileştirdiğin iş birimi diğer takım tarafından reddediliyorsa burada da işin kalitesinin istediğimiz seviyede olmadığı sonucunu sayma fırsatımız oluyor. Bunu bir kalite verisi olarak sayıyoruz.
Bir örnek vermem gerekirse kalite hedefinde sapma olarak karşımıza çıkan Gerileme (Regression) durumu var. Eğer bir iş birimi tamamlandı olarak geçiyor ve canlıya alınıyor ve sonrasında hata ürettiği saptanıp mühendislik ekibine geri gönderiliyorsa bu bizim kalite hedefimizde sapma verisi olarak karşımıza çıkıyor. Eğer mühendis geliştirdiği bölümü QA ekibine gönderiyor ve QA ekibi bunu reddediyorsa biz bunu normal karşılamıyoruz. Bunu kabul edemeyiz, biz mühendisin yaptığı işlerde %100’lük bir başarı oranına ulaşması ve hatasız iş üretmesi için bu veriyi sürekli olarak sayıyoruz. Bu sayede QA ekibinin işi kolaylaşıyor ve süreç hızlanıyor, eğer başarı oranı %100 değilse derin analizler yaparak asıl sebebe ulaşıyoruz, bazen ürünün yeteri kadar unit test’e sahip olmadığını görüyoruz bazende evrensel mühendis problemi olan “bende çalışıyor ama sende çalışmıyor” durumu ile karşılaşıyoruz. Senaryo her ne olursa olsun süreçlerimizi iyileştirmek için bu veriye dikkat ediyoruz. Eğer hata oranı %0 ise işini doğru yaptığını varsayıyoruz. Biz bunu Formula 1’de yarışan arabaların aerodinamikleri gibi görüyoruz. Arabamızı daha hızlı hale getirmek için SLA sürelerini kısaltıyoruz. Bir sonraki çeyrek için hedefimiz örneğin QA süreçlerini 24 saatten nasıl 1 saate düşürebiliriz. Evet bu QA süreçlerinde hata oranımızı %50’ye çıkarabilir, ama iyi tarafından bakın, başarı oranımızı önümüzdeki çeyrekte çok çalışarak %100’e yeniden çıkarabiliriz. Her halukarda bu arabamızı bir önceki çeyreğe göre daha hızlı yapar. Eğer üretilen işlerin geri dönme (regression) oranları artmaya başladığında aşırı hız yaptığımızı anlıyoruz. Bu sayede o kadar hıza henüz hazır olmadığımızı görüyoruz. Bu senaryoda SLA’lerimizin süresini uzatır (ki genelde bunu hiç yapmayız) veya eksik olanın ne olduğunu araştırırız. Test örneğin otomasyonuna mı ihtiyacımız var? 24 saate karşı 1 saat hedefinde kalmak için neye ihtiyacımız var?
Bu bizim üzerinde çok kafa yorduğumuz fakat diğer şirketlerin çoğunlukla gözardı ettiği bir şey. Diğer şirketler çoğunlukla “işini hızlı yap fakat birşeyleri bozma” derler. Bizse “olabildiğince hızlı git, birşeylerin ters gittiğini görürsen yavaşlama fakat bunu düzelt” deriz. Formula 1’de yarışıyorsanız sürücüye “arabayı çarpma” demek aptallıktır, bu zaten aşikar. Yapmanız gereken sürücüye olabildiğince hızlı gitmesini söylemek ve bunu mümkün kılmak için aracının bakım süresini kısatlmak, tekerlerinin yolu daha iyi tutmasını sağlamak, motorunun daha verimli çalışmasını sağlamak olmalı. Burada konu kaza yapmamak değil, bu zaten belli. Mühendislerimizin hata yapmama sorumluluğu yok fakat hataya sebep olan problemleri ortadan kaldırma sorumluluğu var. Farkımızın bu olduğunu düşünüyorum. İşin derinine inip bunu çözmekle mükellefler. Yani “hata çıkmasın diye” hızdan ödün verme şansları yok.
-
NPS (net promoter score)
Elbette NPS verisini de sayıyoruz, günün sonunda bizde iç veya dış müşterilerimize dönüp işimizle ilgili ne düşündüklerini soruyoruz.
İşimizi iyi yapıp yapmadığımızı bize bildirmelerini istiyoruz. Bu veriyi son kontrol verisi olarak ele alıp doğru yönde ilerlediğimizden emin oluyoruz.
Geçmiş başarılarınızla ilgili bize biraz dolar verisi sağlaman mümkün mü?
Elbette, bazı yüzdesel veriler de sağlayabilirim, burada uyum konusunda biraz bilgi vermek isterim. Uyum verisi performansımıza katkı sağlayan temel bir veri. Uyum verisi mühendislerimizin iş yaparkenki davranışlarını yönetme ve işe kalite ve performans kazandırmada çok önemli. İş içerisindeki bu davranışları ekip içinde yönetmeye başladığınızda esasen iki şeyi yapma imkanınız oluyor, hemde çok hızlı bir şekilde. Bazı deneyler yaparak farklı davranışları ve ürettikleri sonuçları ölçümleyebiliyorsunuz. Küçük bir ekipte yaptığınız deneyin ürettiği sonuçlardan memnun olduğunuzda bunu bir günde yüzlerce kişiye uygulama fırsatınız oluyor.
Diyelimki bir uyum programı yönetiyorsunuz ve yaptığınız deneylerden elde ettiğiniz bir veri üzerine tüm mühendisler için 2 yeni uyum kriteri eklemek istediniz, ekip daha önce bu davranışı göstermediğinden ilk aşamada uyum oranlarının düştüğünü göreceksiniz, burada ekibin uyum sağlamasını ve iyileşmesini bekliyorsunuz. Nihai hedef herkesin %100 uyumlu olması. Günün sonunda deneyle elde ettiğiniz başarının tüm şirket sathına yayılmasını sağlayabiliyorsunuz. Herkes o şekilde davranıyor iş süreçleri içerisinde. Bu sayede uzun uzun doküman yazmanız gerekmiyor, yönergeler hazırlamanız ve insanların bu dokümanları okuduğunuz varsaymanız gerekmiyor. Bu sayede tüm çalışanlara tek tek eğilip kontrol etmeniz gerekmiyor, yalnızca tek tablo üzerinde uyum skorlarını inceliyorsunuz ve bu uyum skoru otomatik olarak oluşturuluyor. Yani herşeyin temelinde davranışları yönetmek yatıyor. Davranışı doğru yönde yönetip bunun performansa yansımasını görüyorsunuz ve günün sonunda ürettiğiniz iş biriminin arttığını görüyorsunuz.
Nadiren sapan ve kural olarak benimsediğimiz her çeyrekte %25 iyileştirme hedefimiz var. Bizim için bu taşa yazılı birşey. Yani bir yönetici olarak davranış yönetiyorsanız ekibinizin o çeyrekte %25 performans kazanması bekleniyor. Bu da ekibinizin %25 daha üretken olduğu anlamına geliyor. Bunu bir yıl yapmayı sürdürdüğünüzde 12 ay içerisinde iki kat daha verimli bir ekip halin geliyorsunuz.
Bir örnek vermem gerekirse, zaman etüdlerimiz (time-motion studies) oluşan her bir yazılım hatasını yeniden üretmek için 1 güne ihtiyaç duyduğumuzu gösteriyordu. Bu arızaların oluşmasını önlemek adına kalite hedefi koyarak bir günün %90’ını kurtarma şansımız oldu. Grup içindeki 130 mühendisle çarptığınızda elde ettiğimiz işgücü tasarrufun değeri milyon dolarlar seviyesinde.
Bir başka örnek, bir çeyrekte 5000 kadar yazılımsal arıza giderme kapasitemiz vardı. Verimlilik tarafından bakınca şunu yapmamız gerekti; her bir iş biriminin detaylarına inerek maliyet yaratan faktörleri tespit edip ortadan kaldırarak veya otomatize ederek bir iş biriminin maliyetini %25 düşürük ve bunu aralıksız 4 çeyek üst üste yapabiliriz. İlk çeyrekte yazılımsal arızaların giderilmesi iş birimini 1000$’dan 316$’a kadar indirebildik. Yalnızca bu yaklaşımla yılda 13.6 Milyon dolar tasarruf edebiliriz ve bu her bu seviyede devam eder çünkü artık davranışlar değişmiştir.
Sana altyapı tarafı ile ilgili bir başka iyileştirme hikayesi anlatayım, insanlar önceden sanallaştırılmamış sunucuları “çıplak metal” olarak adlandırırdı, veri merkezlerinde bulunan sunucuları kastediyorlardı. Sana ironik gelebilir fakat biz yalnızca bulut kullanımını artık “çıplak bulut” olarak adlandırıyoruz. Yani hala pek çok insan uygulamasını bulut sistemlere taşıdığında en iyi ve en son tekolojiyi kullandığını düşünür, AWS’ye taşındık, artık cloud’dayız, elastiklikten faylanıyoruz vs diye düşünürler. Bu gelinebilecek son noktaymış gibi, bizim için durum farklı. Herşeyi buluta taşımak bizim ölçeğimizde bir yapı için bile ölçülebilir, öngülebilir ve yapılabilir birşeydi ve bunu zaten kısa sürede yaptık. Şimdi ise bundan daha fazlasını yapabiliyoruz. Ürünlerimizi dockerize ediyoruz ve çok geniş docker host’larına yüklüyoruz, bu docker host’larının içerisinde binlerce container tek bir sanallaştırılmış sunucu içerisinde çalışıyor. Yani bulut içinde bulut diyebileceğin bir yapımız var. Paranın satın alabileceği en geniş AWS sunucu kaynaklarını satın aldık. Ve bu EC2 kaynakların içerisinde ürünlerimizi basit AMI image’lar olarak yüklemek yerine (çünkü bunu yalnızca bir EC2 instance içerisinde yapabilirsin) çok geniş bir EC2 instance alıp içerisinde docker host ediyoruz. Bu docker host içerisinde ise 1000 kadar container çalıştırıyoruz. Bu contianer’ler 30-40 kadar ürünü host ediyor olabilir. Bunu yaparak ciddi bir ekonomi oluşturuyor ve tasarruf ediyoruz. Binlerce AWS sunucu kaynağı kullanmak yerine 20’den az devasa AWS sunucu kaynağında bu işi hallediyoruz.
Düşün ki bir kargo gemin var ve içerisine binlerce konteyner yükleyebiliyorsun, aynı işi birer ikişer konteyner taşıyan binlerce küçük gemiyle de yapabilirsin fakat taşıdığın kilogramın birim maliyeti çok yükselir. Burada bizim yaklaşımımız bu.
Bu yöntemle operasyonel maliyetleri %95’den fazla kısma garantimiz var. Yani düşün, bir SaaS şirketin var ve biz bunu satın alıyoruz, sen yılda 1 milyon dolar harcarken biz aynı işi yılda 50 bin dolarla hallederiz.
Her seviyeden yazılım mühendisleri ve startup’lar için tavsiyelerin var mı?
Bizim yaptıklarımızın büyük ölçekte ne kadar iyi çalıştığı aşikar, yüzlerce mühendisin bakım, yeni özellik geliştirme, performans iyileştirme vs gibi farklı gruplarda çalıştığı bir yapımız var. Fakat yaptıklarımız kesinlikle daha küçük ölçekli şirketlerde ve startuplarda da uygulanabilir şeyler. Bence insanlar çoğu zaman basitliğe odaklanmayı unutuyorlar. Dolayısıyla aşırı mühendislik yapıyorlar ve ihtiyaçları olmayan kompleks yapılar kuruyorlar. Bu konuda bir yazılım design pattern’i bile var, adı Yagni. Yazılım alanında guru diyebileceğimiz Martin Fowler gibi adamlar kompleks tasarımın yalnızca ihtiyaç olduğunda eklenmesi gerektiğini savunuyorlar, kesinlikle daha önce değil, biz bunu çok ciddiye alıyoruz. Yazılım mühendisliğinde basitliği korumak, canlıya alma süreçlerinde basitliği korumak, takım yapısında basitliği korumak, performans metriklerinde basitliği korumak, özet olarak her alanda basitliği korumak çok çok önemli. Bu belkide verebileceğim en önemli tavsiye olurdu. Elde ettiğiniz basitlik size sorunları daha hızlı tespit etme fırsatı sunacak, daha hızlı karar verme fırsatı sunacak ve nereye daha çok dikkat etmeniz gerektiğini net bir şekilde gösterecektir.
Kompleks yapıları yalnızca 10 kat performans artışı elde edebileceğiniz bir senaryoda ekleyin. Ders bir, basitliği koruyun.
Her seviyeden tüm takımlar için verebileceğim ikinci tavsiye ise ölçümleme. Yaptığımız herşeyin doğru ölçülmesi başarımızın temel taşıdır. Worksmart Pro kullandığımızı biliyorsun, bunu kendimizi ölçmek için yapıyoruz, kaç saat çalıştığımızı, ne kadar focus olabildiğimizi, ne yoğunlukta çalışabildiğimizi, tam olarak hangi aktiviteler üzerinde ne kadar çalıştığımızı ölçüyoruz. Bazı startup sahibi arkadaşlarımın Worksmart Pro benzeri araçlar kullanarak kendilerini ölçümlediğini görüyorum. İlk farkettileri şey Facebook ve benzeri araçlarda geçirdikleri devasa verimsiz zaman. Ve zamanlarını verimsiz kullanıyorlar çünkü süreçleri yeterince otomatize edilmemiş durumda. Bu da onları gerçekten iş değeri yaratan başlıklara odaklanmak yerine rastgele farklı işlere bölünüp verimsizleşmeye itiyor. Dolayısıyla ölçümleme, herşeyin tek ve basit bir performans metriği ile ölçülmesi, verimliliğin ölçülmesi, kalitenin ölçülmesi, hızın ölçülmesi heryerde uygulanabilecek basit fakat etkili bir yöntem.
Üçüncü tavsiyem ise otomasyon. Yaptığınız işlerin büyük bir bölümünü otomatize ederek ciddi zaman tasarrufları sağlayabilirsiniz. Bazı şeyler bellidir, tek tıkla canlıya alma süreci mümkün bunu yapmalısınız, canlıya alma süreçlerinizi otomatize edebilirsiniz, geliştirme ortamı yaratma işini otomatize edebilirsiniz, testlerinizi otomatize edebilirsiniz, yayındaki ürünün gözlem ve takip işini otomatize edebilirsiniz, oluşan hatalarda sistemin kendini toparlaması süreçlerini otomatize edebilirsiniz.
Otomasyon sizi bölünüp yapmak zorunda olduğunuz bireysel işlerden kurtarır ve çok önemlidir.
Focus hakkında konuşurken, bununla mühendisin farklı bir konuya geçerek üzerinde çalıştığı asıl konuyu kurban etmesinin önüne geçebilirsiniz. İşi koruyup focus’u sabit tutmak asıl mesele. Birkaç butona tıklayıp yapmanız gereken bir işi basit bir script yazarak otomatize edebilirsiniz. Yıla baktığınızda bu size devasa zaman tasarrufları kazandırır.
Her teknolojiden yazılım mühendisleri için kendilerini geliştirmeri ve küresel bir oyuncu olmaları yönünde tavsiyen var m?
Esasen yeni meydan okumalara maruz kalmak işin temelinde yatıyor. Yeni teknoloji kullanan projelerde çalışmaya kendilerini zorlamaları gerekiyor. Yöneticilerin ve mühendislerin farketmeden yaptığı bazı şeyler var, konfora ulaşıp orada kalmayı tercih ediyorlar, konfor alanı geliştiriyorlar, ürünü bozma korkusu ile çok fazla hata ve problemle yüzleşmekten çekiniyorlar. Inovasyon yaratmak istemiyor, ilerleme ve iyileştirme yapmaktan uzak kalıyorlar.
Pek çok aday üretkenlik iyileştirmesi, teknoloji yenileme, basitlik getirme gibi konularda sorular sorduğumuzda “lazım değildi” veya “benden istenmedi” diye cevap veriyor. Açık söylüyorum, böylesine, sizi zorlamayan bir organizasyonda çalışıyorsanız çok yüksek ihtimalle her geçen gün yavaş yavaş daha az rekabetçi bir mühendis haline geleceksiniz küresel alanda.
Konfor Alanını Terket
Peki bununla nasıl savaşılır? Bir startup’a katılabilirler, sıfırdan bir ürünü yazmaya başlayabilirler, eski dandik bir modülü yeni teknolojiyle gerekirse kendi kişisel zamanlarından ödün vererek yeniden yazmaya çalışabilirler. Ve eğer eski kafalı bir şirket içerisinde çalışıyorlarsa bunun sırf yapılabilir olduğunu yönetime göstermek için yapmalılar. Yeterince iyi olmayanı kabullenmeyi reddetmek zorundalar. Konfor alanında oturmak küresel rekabetçilikten uzaklaşmanın en kesin ve kısa yolu. Düşünsünler, Elon Musk ve ona direkt olarak bağlı yöneticiler geçtiğimiz birkaç yılın kaç gününü konfor alanlarında geçirmişlerdir? Başlamak için tek tarih bugün, daha geç değil.
Öyle umuyorum ki bu röportajı okuyan arkadaşlar bizim organizasyonumuzda kimlerin kendine yer bulabileceği ve gerçek kabiliyete ne kadar ihtiyacımız olduğu ile ilgili net bir bilgi edinmişlerdir. Eğer bize katılmak isterlerse tüm açık pozisyonlarımızı şurada bulabilirler.
— Mülakatın Sonu —
Teşekkür ederim Mircea, dünyanın çeşitli yerlerinden mühendis, yönetici ve girişimcilerin sözlerinde ilham bulacağından şüphem yok.