Firmalar için yazılımcıları elinde tutma rehberi
Yazılımcı bulamama probleminin konuşulmayan tarafı: Çalışan Deneyimi
Teknoloji alanında küresel bir yetenek eksikliği ile karşı karşıyayız. Bu sadece yazılımcı olarak değil veri bilimcisi, veri analisti, siber güvenlik uzmanı ve ürün yöneticisi olarak da kendisini gösteriyor. Geçtiğimiz haftalarda farklı sektörlerden konuştuğum birçok kişinin bu eksikliği fırsata çevirmek için kariyer değişikliği yaparak teknoloji rollerine dönüş yaptığını duydum. Örneğin, firmasında muhasebe bölümündeki birisinin kendi alanındaki ürünlerde çalışmak üzere ürün yöneticisi olduğunu görsel tasarım alanında çalışan bir başka kişinin de frontend developer olduğunu duydum. Eminim etrafınızda bu şekilde kariyer değişikliği yapan birçok kişi vardır.
Problem
Bu küresel sorunun sonucunda teknoloji alanında tecrübeli kişiler için teklif edilen maaşlar da dramatik miktarda artmaya başladı. Özellikle pandemi zamanında gerçekleşmeyen yatırımlar 2021-2022 yılında çılgın büyüme hedeflerine dönüştü. Bu da Avrupa ve ABD için aşağıdaki sonuçları doğurdu;
Çılgın büyüme hedefleri sonucunda birçok firma büyük bütçelerle büyüme hedeflerini daha agresif bir şekilde gerçekleştirmeye başladı.
Bunu yaparken yetenek havuzundan piyasanın üstünde maaş ve imkânlarla hızlı bir şekilde yetenek işe almaya başladı.
Bunun karşısında kendi içinde maaş politikasını düzenlemekte zayıf kalan firmaların çalışanları, bu firmaların %30’a varan yüksek tekliflerine karşı gelemediği için iş değiştirmeye başladı.
Maaş artışlarını yeni yatırım turlarıyla ya da kendi içinde yönetebilen firmalar kaybettikleri çalışanların yerine yeni çalışanları bünyelerine katabildi.
Bu durum sebebiyle en çok sürdürülebilir bir iş modeli olmayan girişimler sorun yaşamaya başladı.
İşte bu noktada işin ucunun Türkiye’ye gelmeye başladığını düşünüyorum. Özellikle Türkiye’deki döviz kurunun yüksek olması ve kendi firmanı kurup döviz ile gelir elde etmenin avantajlı olmasından dolayı birçok Avrupalı firma Türkiye gibi ülkelerin havuzlarını da kullanmanın avantajını yaşıyor. Bu durum tabi ki Türkiye’de TL ile kazanç sağlayan çoğu firma için zor bir rekabet koşulu oluşturuyor. Ancak uzun vadeli çalışan memnuniyetinin de önemini bence daha da arttırıyor.
Biliyorum bu sefer uzun bir giriş oldu ama anlatacaklarımın önemini biraz daha vurgulamam gerektiğini hissettim. Özellikle kurumsal büyük firmaların bu konuya kafa yorup güzel ofis kurarak ya da sürekli hediye göndererek çözüm ürettiklerini sanmaları bunun önemini vurgulamam konusunda beni daha da tetikliyor diyebilirim.
Çalışan memnuniyetini birçok farklı noktadan değerlendirmekte fayda var. Ancak ben bugün biraz daha derinlemesine inerek iş yapış biçimlerinin etkisinden bahsedeceğim. Özellikle odaklanmak istediğim konu da planlama ve iş yetiştirme pratikleri. Bunu da farklı bir kitap önerisinde bulunarak başlatacağım. Gelecek haftalarda da bu konunun farklı boyutlarını ele almaya çalışacağım.
Gelelim bu haftanın kitabı olan “The Progress Principle” kitabına. Kitabın yazarları Teresa Amabile ve Steven Kramer yıllarca inceledikleri firmalardan çıkardıkları sonuçları bu kitapta paylaşıyor. Kitapta yazarlar sayısız farklı inceleme ve olay örneği ile size “Inner Work Life” diye bir kavramdan bahsediyor. Benim tecrübeme göre bu olgu iyi bir çalışan deneyimi tasarlamak ve çalışanları mutlu ederek daha uzun süre firmalarda kalmalarını sağlamak için en önemli kavramlardan bir tanesi.
Nedir bu “Inner Work Life”?
Bir çalışanın bir iş günü içinde algıladığı, hissettiği ve motive olduğu olayların tamamı diyebiliriz. Bu sadece diğer çalışanlarla olan ilişkisini değil, aynı zamanda çalışanın firmadaki iş süreçleriyle kurduğu ilişkiyi de kapsıyor. Yani çalışan başarmak istediğini ne kadar az zorlukla ve ne kadar hızlı bir şekilde başarabiliyor.
İşte bu iş hayatı aslında kişinin olumlu ya da olumsuz gelişen birçok haberi ne şekilde algıladığını da ciddi bir şekilde etkiliyor. Yaptıkları araştırmalarda, iç süreçlerinde az bürokrasi olan ve çalışanlara en az direnç göstererek iş yapabilmelerini sağlayabilen firmaların toplu işten çıkartma olayları gibi çok olumsuz gelişmeleri bile daha kolay atlattıklarını görmüşler. Peki o zaman bunu yazılımcılar için daha iyi bir hale nasıl getirebiliriz?
Yazılımcıların bir günü
Kendi çalıştığım firmalardan örnek verecek olursam, yazılımcı gün içinde birkaç toplantıya giriyor, ekibiyle buluşuyor, bol bol kod yazıyor, tıkandığı noktalarda birilerine ulaşarak destek alıyor ve belki de izin almak, kariyer gelişimi konusunda düşünmek gibi tam olarak iş ile ilgili olmayan ama alakalı insan kaynakları dertleriyle uğraşıyor.
İşte bir yönetici ya da lider olarak bu deneyimin ne kadar rahat olduğu, sizin çalışanlarınızın sizinle daha uzun süre kalmasına kritik bir seviyede etkisi oluyor.
Gelin şimdi birkaç tane örnek soruyla konuyu tartışalım, siz de belki bu ve sizin aklınıza gelen sorularla hızlı bir sağlık kontrolü yapabilirsiniz. Ama kuralımız şu, bu sorulara cevap verirken varsayım yapmayın. Bilmiyorsanız bunu ekibinize sorarak öğrenin. Çoğu zaman bildiğimizi sandığımız şeyler aslında varsayımlarımızdan başka bir şey olmayabiliyor.
Ekibiniz yaptığınız toplantıları değerli buluyor mu? Yoksa zaman kaybı olarak mı görüyorlar? Mesela her sabah stand-up meeting yapmak gerçekten gerekli mi yoksa sadece öyle alışıldığı için mi yapıyorsunuz?
Ekibiniz bir proje geliştirirken ne kadar çok bariyerle karşılaşıyor? Başka takımlara ya da karar vericilere bağımlılıkları üretkenliklerini nasıl etkiliyor? Bunu nasıl çözebilirsiniz?
Ekibiniz bir konuda sorun yaşadığında başka bir ekibi boş boş oturup beklemeleri gerekiyor mu? Yoksa bu konuyu bir öğrenme fırsatına çevirip yeni bir şeyler öğrenebiliyorlar mı?
Bir projede farklı bir sorunla karşılaştığınızda buna refleksiniz ne oluyor? Pragmatik mi davranıyorsunuz yoksa idealist mi?
Ekibiniz kararları kendileri verip kendi kaderlerini kontrol edebiliyorlar mı? Yoksa siz onlara bitirilmesi gereken zamanı ve çözümü veriyorsunuz da onlar sadece kod mu yazıyorlar?
Yazılımcılarınız akıllarındaki bir fikri hayata geçirirken ne kadar çok dirençle karşılaşıyorlar? Birileri “şimdi odağımız bu değil” diyerek kesip atıyor mu? Yoksa bundan bir şey öğrenip hızlı aksiyona geçiyor musunuz?
Firmanız çalışanlarının kendi eğitimlerini bir bütçe ile seçmelerine izin veriyor mu? Yoksa firmada işten çok uzak birileri sürekli ekipleri zorla eğitimlere mi sokuyor?
İzin almak ve tatil planlamak ne kadar zor ya da kolay?
Yazılımcılarınız doğru araçlara gerçekten sahip mi? Birileri bunları düzenli olarak kontrol edebiliyor mu?
Bilişim güvenliği adı altında baskıcı kurallar var mı? Yoksa bilişim güvenliği ekibi yazılımcıların üretkenliğini en az etkileyerek mi önlemlerini yerine getiriyorlar?
Hata yapıldığında ekiplere öğrenme fırsatı sunuluyor mu? Yoksa parmakla gösterip “iş yetiştiremedi” ya da “çuvalladı” mı deniliyor?
Bu sorular ve örnekler eminim firmadan firmaya göre değişiklik gösterecektir. Ama buradaki önemli olan şey; çalışanların iş hayatının birinci sınıf bir ilgi görüp görmemesi.
Elinizde veri yoksa iyileştiremezsiniz.
Eğer orta ya da büyük ölçekli bir firmadaysanız, insan kaynakları ekibi çoktan bir firmayla anlaşmış ya da bir SaaS ürünü alarak belli aralıklarla anketler göndererek çalışan bağlılığını ölçüyordur. Ancak asıl sorun buradan sonra başlıyor. Bu anketlerin sonuçlarını nasıl değerlendirip aksiyon alıyorsunuz? Bu aksiyonları aldığınızı ne şekilde ekibinize geri yansıtıyorsunuz?
Eğer bunların sonucunda bir şeyler değiştiğini görebiliyorsanız harika! Doğrusu 8 yıldır çalıştığım neredeyse tüm firmalarda bu tarz anketler uygulandığını gördüm. Ancak şu anda çalıştığım firma dışında hiç bir zaman ciddiye alındığına tanık olmadım. Bu yüzden kendi ekiplerim için spotify modeli bir takım sağlığı ölçme formunu kendi açımdan daha faydalı buldum. Bu tarz yöntemlerle topladığınız veriler, sizin yapacağınız retrospektif toplantılarını ya da toplantılarda söyleyeceklerinizi hatta söylemeyeceklerinizi kritik boyutlarda etkileyecektir. Dolayısıyla ekiplerinizin sorunlarını açık bir şekilde dinlemeli, bunun için doğru veri kaynaklarını kullanarak veri üretmeniz gerekmektedir.
Eğer bir takımın yöneticisi ya da lideriyseniz, ekibin başarısızlığı sizin başarısızlığınızdır. Bu yüzden takımın motivasyonunu ayakta tutmak da sizin en önemli göreviniz. Şimdi kısa birkaç tane gördüğüm en önemli motivasyon yıkıcı konuya değinip yazıyı kapatacağım.
Ekip ritüelleri
Çoğu zaman Scrum ya da kanban uygulayacağız diye çevik yöntemlerin suyunun çıkarıldığına tanık oluyorum. İtiraf edelim, yöneticiler her şeyin kontrol altında olduğundan emin olmak için toplanmak isterken, yazılımcılar otonomiden dem vururlar. Bunu asgari müşterekte buluşturmak çok önemli.
Mesela, her pazartesi sabahı en fazla 30 dakika süren bir haftalık hedef toplantısı, cuma akşamüstü de 30 dakikalık kısa bir retro yaparak hedeflerin durumunu tartışmak ekiplere otonomiyi, yöneticilere de kontrolü verecektir. Hatta ekibin dinamiklerine göre pazartesi toplantısı bile gereksiz olabilir. Mesela eğer bir Jira tahtasına bakarak süreci anlayabiliyorsanız ve ekip de böyle çalışmaktan memnunsa her sabah toplantı yapmaya gerçekten gerek var mı? Çoğu zaman kontrolü ekibe vermenin, onları sorumlu haline getireceğini ve böylece işlerin sizden bağımsız yürümeye başlayacağını unutmayın. Ama bu, ekiple ilgilenmeyin demek de değil tabii ki!
Proje yönetimi
Kitaba geri dönecek olursak, yazarlar hızlı ve küçük başarılar kazanan firmaların motivasyonlarının yüksek olduğu gözlemlemiş. Yani ekiplerin her gün, her hafta, her ay bir şeyler başarması ve projelerin küçük adımlar halinde ilerlemesi ekibin ve bireylerin motivasyonuna etki ediyor. Bunu sağlamak nispeten kolay olabilir. Ancak çoğu zaman planlama yaparken belirsizlik konisini unutmayın. Her ne kadar çoğu zaman işin en kolay yerini yapmamız ilk adımda projede hızlı bir ilerleme sunsa da bu ancak kısa vadeli olacaktır. Bu yüzden projelere en zor kısımlardan ve risklerini elemekten başlamak daha sürdürülebilir bir proje planı verecektir. Bu konuyla ilgili olarak daha önce yayınladığım bir yazıya göz gezdirebilirsiniz.
Yazılımcı deneyimi
En son ne zaman ekibinizden bir yazılımcı ile pairing yaptınız? Hadi bunu yapmadıysanız da ne zaman geliştirme süreciyle ilgili sorunlarını dinleyip bunu çözmek için çaba harcadınız? Mesela fikir aşamasından canlıya kuruluma kadar geçen süreyi ölçmeniz size çok güzel bir metrik sunacaktır.
Çoğu büyük ölçekli ürün firmalarında bu konuya kafa yoran ekiplerin oluşmasının faydasını çok gördüm. Özellikle ekiplerin zaman harcayıp ürün için değer üretemediği konularda onları destekleyen “Developer Experience” ya da “Developer Productivity” gibi ekiplere yatırım yapılmasının geri dönüşü uzun vadede çok fazla oldu.
Ancak yazılımcı deneyimi dediğimde sadece codebase değil, aynı zamanda bilgisayarlarının performansı, ekstra ekranları, kullandıkları klavyeler hatta ve hatta bilgisayarlarına zorla kurulan yazılımların etkileri bile denkleme dahil olmalı. Ekibinize alacağınız güzel bir klavyenin ya da ekranın maliyeti size katbekat geri dönecektir.
Yazılımcı deneyimiyle ilgili bir çok firmanın kaçırdığı konulardan biri de yazılımcılar arasında popüler olan yazılım geliştirme ürünlerini kullanmamaları. Bunu yaparken de iyi bir sebep sunmamaları. Bir çok firmanın, özellikle kurumsal firma kültüründen gelenlerin çalıştığı firmaların, “aman kodlarım çalınacak” korkusu ile yazılımcılarına hiç bir dayanağı olmayan bariyerler sunduğunu görüyorum.
Örneğin doğru düzgün bir arayüzü olmayan git sunucularını kendi veri merkezlerinde çalıştıranlar mı istersiniz, yoksa yazılımcılarını uzak masaüstü ile uzak bir terminale bağlamak isteyenler mi.
Şunu unutmamak lazım, bu tarz “farklı” pratiklerin çok iyi bir nedeni yoksa ve yazılımcılarınıza bunu güzelce anlatamıyorsanız ilk olarak en iyi yazılımcılarınızı kaybedeceksiniz. Çünkü ekibinizdeki en iyi yazılımcılar hızlıca başka bir yerde iş bulabilecek ve hızlıca firmanızı terk edecektir.
Çoğu zaman güzel ve havalı bir ofisten çok, çalışanların işlerini hızlı ve sorunsuz yapabileceği firma kültürü çok daha önemli. Bunu gerçekleştirmek için ekiplerinizi karar verici noktalara getirmek yani onları yetkilendirmek firmanızın kaderini değiştirecektir. Ekiplerin yetkilendirilmesi ile ilgili bir yazıyı geçtiğimiz haftalarda paylaşmıştım. Eğer kaçırdıysanız göz atmanızı öneririm!