Egoyu dışlayan mühendislik: dersler ve içgörüler
Giriş
- Teknoloji sektöründe ego ve dar alanlılık (parochialism), ekip çalışmasını engelleyen başlıca unsurlar olarak işliyor
- Mühendislik ekiplerini daha verimli ve daha işbirlikçi hale getirmenin yollarını düşünürken edinilen içgörüleri paylaşıyor
Sorumluluk dağıtımının ikilemi
- Yalnızca iki çalışan olsa bile iş dağılımı zorunludur
- Ancak dağıtım biçimi hem anlık hem de uzun vadeli etkiler yaratabilir
- Pek çok şirket bu meseleyi derinlemesine düşünmez
Bilgisayar biliminin gerçekliği
- Pek çok bilgisayar bilimci, matematiksel soyutlamayla ilgili bir alana adım attığını sonradan fark eder
- Bu ilk şok nedeniyle çoğu kişi, kariyerinin büyük bölümünde öğrendiklerini bilgisayar dışındaki alanlara uygulamaktan kaçınan bir tutum sergiler
- Çalışma ortamı da teknik yaklaşımlar kadar derin düşünülse iyileşme ihtimali vardır
Organizasyonlardaki aksaklıklar ve deneyimler
- Başarılı şirketler bile organizasyonel hastalıklardan kaçınmakta zorlanır ve buradan öğrenilecek şeyler vardır
- Kariyerinin ilk dönemini geçirdiği bir startup örneği:
- Şirket henüz küçük ve erken aşamada olmasına rağmen aşırı bürokratik bir yapı benimsemişti
- Web isteklerini hızlandıracağı yönündeki hatalı teoriyle bir "Python middleware" katmanı eklendi
- Sonuçta daha fazla ağ atlaması oluştu ve performans düştü
- Tek bir özelliği yayına almak için birden fazla rol arasında karmaşık işbirliği gerekiyordu
- Veritabanı çalışanı DDL yazıyor ve stored procedure geliştiriyordu
- Python geliştiricisi verimsiz middleware üzerinde çalışıyordu
- PHP geliştiricisi frontend kodu yazıyordu
- Bu işbölümü yapısı nedeniyle iki yıl boyunca hiç yeni özellik yayımlanamadı
- Sonuç
- Verimsiz yapı ve iş akışlarının sonucu olarak tüm çalışanlar işten çıkarıldı
- Ben hariç. Şikayet ettiğim için hayatta kaldım
Büyük ölçekli şirketlerde rol ayrışması sorunu
- Arka plan: 1.000'den fazla çalışanı olan bir B2B ürün şirketinde çalışma deneyimi
- Başlangıçta rollerin net biçimde ayrıldığı işlevsel ekipler (Feature Teams) ve ortak hizmet ekipleri (operasyon, DBA vb.) yapısı vardı
- İlk bakışta sıradan bir yapı gibi görünüyordu
- Zaman geçtikçe roller aşırı derecede bölündü ve verimsizlik arttı
- Yayınları yönetmek için "Release Manager" adlı yeni bir rol eklendi
- Bu rol eklemenin nedeni net değildi ve organizasyon yapısı giderek daha karmaşık hale geldi
- Sorun örnekleri:
- Frontend mühendisleri yalnızca frontend, backend mühendisleri yalnızca backend işleriyle sınırlandı
- Bu ayrım idare edilebilirdi, ancak tüm güvenlik işlerinin güvenlik ekibine bırakılması ciddi sorunlara yol açtı
- Sonuç: Roller görevlerle özdeşleştirildiğinde organizasyonel verimlilik zarar gördü
- Ekipler arası işbirliği eksikliği ve iş tekrarları ortaya çıktı
Dağınık ürün portföyü ve denetim yapısının yokluğu
- Ağırlıklı olarak native istemci uygulamaları geliştiren bir şirkette çalıştı
- İlk dönemde başarılı bir amiral gemisi istemci uygulaması vardı, ancak 2020'lerde dağınık ve tutarsız projeler paralel biçimde yürütülmeye başladı
- Ürün portföyü yönetimindeki sorunlar
- Tüm ürünleri kapsayan denetim yapısı zayıftı
- Teknoloji yığını veya karar alma süreçlerinde ürünler arasında hiçbir koordinasyon yoktu
- Her ürün ekibi bağımsız biçimde CEO'ya rapor veriyordu ve CEO koordinasyon çabası göstermiyordu
- Ortak operasyon fonksiyonu kurma girişimi
- Operasyon grubu mimari karar süreçlerine dahil olmadığı için zorluklar yaşandı
- Operasyon ekibi, geçmişte geliştirme ekiplerinin kullandığı yüzlerce servisi yönetmekle meşgul olduğundan önemli kararlara katılacak zamanı bulamıyordu
- Bu durum, organizasyonel verimsizliğin tipik bir örneği sayılabilir
[Organizasyon sorun kalıplarını genelleştirmek]
Kalıp 1: Rol ve görevlerin karıştırılması
- Yeni işler için yeni iş tanımları oluşturma eğilimi vardır
- Örneğin yapay zeka ile ilgili işleri mevcut mühendisler yapabilecek olsa da yeni bir yapay zeka mühendisi rolü açılır
- Bu, organizasyon içinde çatışma yaratır ve mevcut ekip üyelerinin motivasyonunu zayıflatabilir
- Bu tür aşırı rol ayrımları gereksiz bürokrasiye yol açar
Kalıp 2: DevOps devriminin eksik dağılımı
- Pek çok şirket "DevOps'u uyguladığını" söyler, ancak gerçekte işbölümü ve çatışmalar sürer
- Operasyon ekibi ile geliştirme ekibi ya da SRE ile geliştirme ekibi arasındaki net sınırlar işbirliğini engeller
- DevOps'un asıl amacı işbirliği ve empati yoluyla sınırları kaldırmaktır, ancak pratikte buna nadiren ulaşılır
Kalıp 3: Katı işbölümünün sınırları
- İşleri bölmek ve uzmanlaştırmak liderlere doğal görünebilir
- Örneğin yapay zeka işleri yapay zeka uzmanlarına, operasyon işleri operasyon sorumlularına bırakılır
- Ancak bu yapı darboğazlar üretir
- Eklenen mühendisler hızı artırmak için yeni işler üretmeye çalışır, fakat bunun sonucunda analiz için bekleme süreleri doğrusal olmayan biçimde artar
- Veri bilimciler veya analiz kaynakları sınırına ulaştığında tüm süreç yavaşlar
Kalıp 4: Hatalı organizasyon yapısı ek iş üretir
- Organizasyon sınırları belirsizse ya da yanlış çizilmişse gereksiz iş yükü artar
- Örneğin güvenlik ekibi tüm güvenlik sorunlarını üstlenir ve bir güvenlik bilet kuyruğu oluşur
- Geliştirme ekipleri güvenliği dikkate almadan ilerler, bunun sonucunda güvenlik işi daha da artar
- Bu kısa vadede göz ardı edilebilir, ancak uzun vadede ciddi sorunlara dönüşür
Kalıp 5: İnsanın kronik önyargıları
- Kişi kendi rolünü abartma, başkalarının rolünü küçümseme eğilimindedir
- Bazıları sunucu işlerinin "teknik olmadığını" yanlış biçimde düşünür
- Tersine, ürün işlerini daha az teknik görenler de yaygındır
- Bu tavırlar ekipler arası güveni zayıflatır ve işbirliğini engeller
- "Parlak ama dayatmacı kişi" sistem düzeyinde gerçek bir değer üretmez
- Liderler ve organizasyonlar bu tavrı sık sık "zeki" ya da "değerli" diye yanlış değerlendirir
[Dar alanlılık ve ego]
- Dar alanlılık (Parochialism) ve ego, organizasyon içindeki başlıca verimsizlik nedenleridir
- Dar alanlılık: Başkasının alanına girmemeye çalışma ya da merak eksikliği
- Ego: Yapılan işle ilgili gurur bazen olumlu etki yaratabilir, ancak alan koruma veya başkalarının yeteneğini küçümseme gibi olumsuz etkiler de doğurabilir
- Bu içgüdüsel davranışlar empati eksikliğine yol açar ve işbirliğini zorlaştırır
Daha iyi bir örnek: başarılı mühendislik ekipleri deneyimi
- Geçmişte bir startup'ta yatay biçimde ayrılmış "fiefdom" yapısı sadeleştirildi ve daha küçük ekiplere dönüştürüldü
- DevOps'u ciddiyetle benimseyen liderler engelleri kaldırdı ve işbirliğini teşvik etti
- Yaklaşık iki yıllık bir "yaratıcı yıkım" süreci boyunca tüm ekip üyeleri çeşitli işlere dahil oldu
- Sonuçta altyapı istikrarı ve yazılım yayımlama kapasitesi yeniden kazanıldı
- Organizasyon yeniden yapılandıktan sonra mühendislik ekibi zaman ve özerklik kazandı
- Bunun üzerine ekibin ilave kapasitesinin nasıl kullanılacağı tartışıldı
Öneri 1: Büyük ölçekli refactoring (Proposition 1: Boil the Ocean)
- Ekipler bazen boş kapasiteyi sevmedikleri alanları baştan aşağı refactor etmek için kullanır
- Ancak bu yöntem daha önce denenmişti ve pek sevilmemişti
Öneri 2: "Gösteriş" faaliyetleri (Proposition 2: Dress Like Big Dorks)
- Ekibin boş zamanını ekip kültürünü öne çıkaran ürünler hazırlamak gibi işlerde kullanma girişimleri oldu
- Ancak bu ana strateji olarak uygun değildi
- Belirleyici olay: tasarımcının build hatası
- Gece yarısı bir tasarımcı build'i bozdu ve ekip bunu düzeltmek zorunda kaldı
- İlk tepki olarak tasarımcılarla kod yazarların rollerini daha net ayırma görüşü ortaya atıldı
- Ancak ekipten biri cesur bir kararla deployment anahtarını doğrudan tasarımcıya verdi
- Sonuç:
- Tasarımcı kod işlerine katıldı ve işbirliği seviyesi arttı
- Ekip monitoring, test suite vb. kurarak güvenli bir çalışma ortamı oluşturdu
- İş verimliliği ve üretkenlik büyük ölçüde iyileşti
Öneri 3: Diğer herkesin güçlenmesini sağlamak (Proposition 3: Empower Everybody Else)
- Ekibin boş kapasitesini diğer ekipleri desteklemek ve güçlendirmek için kullanma stratejisi benimsendi
- Hem teknik hem teknik olmayan ekipler için uygulandı
- Organizasyon genelinde işbirliğini teşvik etti ve etkili uygulamaya dönüştü
Uygulama iradesi
- Tasarımcı örneğinden sonra farklı gruplarla çalışırken benzer başarılar yaşandı
- Ekibin serbest zamanı ve organizasyonel yetkisi kullanılarak her ekibin etkili biçimde işbirliği yapması desteklendi
- Başarılı uygulamanın temelinde şirket genelinde işbirliği ve empati vardı
[Başarılı uygulamanın hissi]
- Uzman vs. sahip
- Ekiplerde alan uzmanları vardı, ancak belirli görevlerin veya alanların "sahibi" yoktu
- Güvenlik örneği: Güvenlik ekibi tüm sorunları çözmek yerine, tüm ekip güvenlikten sorumlu oldu ve güvenlik ekibi diğer ekip üyelerinin yetkinliğini artırma rolünü üstlendi
- Bu model başka alanlarda da uygulanmalıydı, ancak çoğu ekip bunu başaramadı
- Başarısız örnekler
- Frontend ve backend mühendislerinin katı biçimde ayrılması
- İşbirliği eksikliği nedeniyle GraphQL gibi gereksiz karmaşıklıkların ortaya çıkması
- Belirli rollerde uzmanlara ihtiyaç vardır, ancak unvanları "frontend" ve "backend" diye bölmek verimsizdir
- Temel ilke:
- "Alan uzmanları olsun, sahipleri değil"
- Uzmanların, kendi işleri dışında diğer ekip üyelerine yardım edecek zamanı olmasına özellikle alan açmak
Proaktif işbirliğini teşvik etmek
- Boş zaman sağlamak
- Genel ekip çalışmasını korumak için ekip üyelerine nefes alanı bırakılır
- Doğal işbirliğinin kendiliğinden ortaya çıkmasını beklemek yerine, sisteme bilinçli olarak canlılık katılır
- Psikolojik güvenlik ve iç grubun genişletilmesi
- İnsanlar, ait oldukları grupta psikolojik güvenlik hissederken deneme yapar ya da yeni şeyler öğrenir
- Ekip üyelerinin "iç grubunu" genişletmek için zaman ve kaynak yatırımı yapılır
- Bootcamp: Başka ekiplerde zorunlu çalışma ile işbirliği fırsatı sunulur
- Hackathon: Benzer etkiyi yaratan etkinlikler olarak kullanılır
Bilinçli ekip değerleri
- Ekibin felsefesini ve ilkelerini tanımlamak
- Kod inceleme, bootcamp, hackathon gibi çeşitli faaliyetlerin daha yüksek amacını açıkça tanımlamak
- Elitizmin zehir olduğu ilan edilir
- Herkesin "yapılması gereken işi bizzat yapması" kültürü oluşturulur
- Karşılıklı güven ve iyileştirme beklentisi
- Başkasının yaptığı işi ele alırken onu her zaman daha iyi durumda bırakma yönünde güçlü bir beklenti oluşturulur
- Bu kültür, ekip üyelerini isteyerek işbirliği yapmaya yönlendirir
Son düşünceler
- Teknoloji sektörünün sorunu: elitizm ve dayatmacı liderlik
- Alçakgönüllülükten yoksun dayatmacı liderler ekip işbirliğini baltalar ve gereksiz acımasızlığı teşvik eder
- Teknoloji sektörü bu tür liderleri çoğu zaman faydalı sanır, ancak bu parazit bir olgudur ve zararlıdır
- Başkalarına saygılı davranmanın radikal bir şey olmaması gerekir, ama pratikte durum böyle değildir
- İşbirliği daha iyi sonuçlar getirir
- İşbirliği sonuçları iyileştirir; dayatmacı liderlerin olmadığı bir çalışma hayatı daha iyidir
- Dar alanlılık ve egoyu ortadan kaldırmak için çaba gerekir
- Yetkilendirmenin önemi
- Ekip üyelerini merakla işbirliği yapmaya teşvik etmek için liderlerin izni ve desteği gerekir
- Örneğin deployment işinin SRE yerine doğrudan geliştiriciler tarafından yapılmasına geçilmesi
- Başlangıçta geliştiricilerin hata yapacağı endişesi vardı, ancak çoğu geliştirici sorunları kendi başına çözdü ve uygulama başarılı oldu
- Ürün mühendisleri sorunları kendilerinin çözmek istemesiyle öne çıktı
- Sisteme boşluk (slack) bırakmak
- Bootcamp ya da hackathon gibi programlar sürekli bağlılık gerektirir
- Sistemde boşluk yoksa bu programlar kolayca ortadan kaybolur
- Bilgisayarları %100 kullanımda çalıştırmayız, ama kendimizi çoğu zaman öyle çalıştırmaya eğilimliyiz
- Değerler ve ödüllerin önemi
- Liderler işbirliğini ve merakı ödüllendirmeli, bunu ekip kültürüne yerleştirmelidir
- CEO'lar çoğu zaman olumlu programları (bootcamp, hackathon) kaldırmaya çalışır, ama olumsuz programları (zorunlu kod inceleme) kaldırmak için aynı çabayı göstermez
- "Acı"nın sonuç getirdiği yönündeki yanlış inanç terk edilmelidir
- Acı, sonuçların uygun bir vekil göstergesi değildir; işbirliği ve güven daha iyi performans getirir
7 yorum
> Ekip üyelerini merak duygusuyla iş birliği yapmaya teşvik etmek için liderin izni ve desteği gerekir
Mutlaka kendi alanları olmasa bile, ekip üyelerinin birbirlerinin alanlarına karşı merak duymalarını teşvik etmenin önemli olduğunu düşünüyorum!
Gerçeklik...!
Her gün ilerleme diye dırdır eden sözde Agile startup’larda mümkün olmayan bir yapı gibi görünüyor..
Tüm uygulama ekiplerinin işe ilk girdiklerindeki ilgiyi sürdürebilmesi gerekiyor ama bu açıdan destek genelde ya hiç olmuyor ya da yetersiz kalıyor.
Söylenenlerin hepsi uzun uzun bakınca doğru..
Ama gerçekler.................. hıçkıra hıçkıra
Gerçekten çok iyi bir yazı gibi görünüyor!
Güzel bir yazı.
Hacker News görüşü
Yazılım geliştirmede programcının egosunu geri plana itmenin önemli olduğu yönünde bir görüş var. Ekip çalışması sayesinde yazılım ürününü ekibin ortak başarısı olarak görmek daha sağlıklı.
Geliştirme kariyerinden çıkarılan ders olarak, gereksiz süreçler eklememek, her rolde ürün sahipliği beklemek, tepkisel kararlardan kaçınmak ve ekipler arası iş birliğini teşvik etmek gerektiği söyleniyor.
En iyi ekipler, tüm stack'i sahiplenen pizza ekipleri ve gerektiğinde tavsiye veren uzmanlardan oluşur.
Spor metaforları teknoloji alanında pek sevilmese de, spor takımlarının dinamiklerinin iyi iş ekiplerine benzediği yönünde bir görüş var.
Bir organizasyonun başarısı, her üyenin grubun ihtiyaçlarını karşılamak için özverili davranmasına bağlıdır.
Bilinçli biçimde ekip değerleri belirlemenin önemi vurgulanıyor.
Growth bölümünde çalışırken, başlangıçta yöneticinin tüm commit'leri inceleyip merge ettiği, ancak daha sonra kişinin doğrudan production'a deploy etme yetkisine sahip olduğunu fark ettiği anlatılıyor.
Domain uzmanları, domain sahiplerinden daha çok tercih ediliyor ve aşırı açık uzmanlaşma sorun yaratabiliyor.