Teknik sorunların çoğu aslında insan sorunudur
(blog.joeschrag.com)- Büyük ölçekli teknik borcu olan şirketlerde, kopyalanmış kod ve eski framework’ler nedeniyle verimsizlik ortaya çıkar
- Proje ilerlerken yönetimin güvenini kaybetmek ve organizasyon içindeki değişim direnci başlıca engeller olarak öne çıkar
- Teknik borcun temel nedenleri belirsiz gereksinimler, gerçekçi olmayan takvimler, eski teknolojilere bağlılık, yönetimin kısa vadeli tepkileri, kişisel ego gibi insan kaynaklı etkenlerdir
- Proje başarısı için yalnızca teknik çıktı değil, algı yönetimi ve iletişim de kritik önemdedir
- Mühendislerin teknik yetkinliklerinin yanında organizasyon içinde iş birliği yapma ve insan ilişkilerini dengeleme becerilerine de sahip olması gerekir
Teknik borç ve kopya kod sorunu
- Yazarın daha önce çalıştığı bir şirkette, milyonlarca satır kod, birim testlerinin yokluğu ve 10 yıldan eski framework’lerin kullanımı nedeniyle ciddi teknik borç vardı
- Windows’a özel modülleri Linux’ta çalıştırmak için yüz binlerce satır kod kopyala-yapıştır ile taşınmıştı
- Bunun sonucunda iki ayrı kod tabanı oluştu ve özellik ekleme ile hata düzeltme işlemlerinin her biri ayrı ayrı yapılmak zorunda kaldı
- Bu tür bir durum bakımı imkânsız bir yapı doğurur ve zamanla kod tabanları arasındaki fark giderek büyür
İnsan sorunlarının yarattığı teknik borç
- Teknik borç projelerinde yönetimi ikna etmek zordur; sonuçta işlevsel değişim çok az olduğu için görünür çıktı da sınırlıdır
- Proje geciktikçe yönetimin güveni kaybolur
- Sorunun özü teknoloji değil, insanların tutumu ve organizasyon kültürüdür
- Pek çok geliştirici değişime direnç gösterir ve geçmişteki yöntemlere tutunur
- Kod yapısı, onu yazanın karakterini ve değişimi kabul etme düzeyini yansıtır
- Teknik borç; net olmayan gereksinimler, gerçekçi olmayan sözler, eski teknoloji seçimleri, yönetimin projeyi durdurma kararları, kişisel ego gibi nedenlerden doğar
- Değişimden özellikle kaçınan ekiplerin kodunda da bu direnç açıkça görülür
- Birçok geliştirici yıllardır aynı şekilde çalışıyordu; hatta “yeni bir şey öğrenmek istemiyorum” diyenler bile vardı
- Böyle bir ortamda borcun birikme hızı, temizleme hızından yüksek olduğu için, borcu azaltmadan önce yeni borç oluşmasını engellemek öncelik olmalıdır
- Acil servisteki triage (önceliklendirme) benzetmesinde olduğu gibi, önce “kanamayı durdurmak” gerekir
İdeal dünya ile gerçeklik arasındaki fark
- Mühendislik sorunlarını politikadan ya da organizasyon bağlamından bağımsız çözecek ideal ortam neredeyse hiç yoktur
- Çoğu projede teknik olmayan paydaşlar bulunur
- “Biz hallediyoruz, bize güvenin” yaklaşımı işe yaramaz
- Başarı algısını yönetmek, gerçek başarı kadar önemlidir
- Teknik olmayan kişiler, teknik borç temizliğinin gerekliliğini sezgisel olarak anlamadığından, bunu sayısal ve iş değeri üzerinden açıklamak gerekir
- Liderliğin mühendislik geçmişi yoksa, görünür metrikler ve etkiler sunmak gerekir
- Sonuç olarak ekibin üretken görünüyor olması da gerçek üretkenlik kadar önemlidir
Kıdemli mühendisler için gerekli yetkinlikler
- Kıdemli ve üstü roller için departmanlar arası iş birliği ve insan ilişkilerini dengeleme becerisi zorunludur
- Bilgisayar mühendisliği eğitimi, karakter, ego, ilişki yönetimi gibi “insanla çalışma” tarafını öğretmez
- Çok güçlü teknik becerilere sahip mühendisler bile büyük ölçekli ve organizasyonel değişim gerektiren sorunlarda zorlanabilir
- Bireysel üretkenlikleri yüksek olabilir ama organizasyonel etkileri sınırlı kalabilir
Heads up coderrolü önemlidir- Derin teknik yetkinliği korurken aynı zamanda proje risklerini erken fark edip ekibi yönlendirebilen kişidir
- Tek çekirdek gibi tek başına hızlı çalışmak yerine, tüm ekibi verimli biçimde yönlendiren bir rol üstlenir
- Saf teknik odaklı mühendislerden farklı olarak, organizasyonun bağlamını ve risklerini birlikte okuyup buna göre hareket edebilir
Özet
- Teknik sorunların kökeninde her zaman insanlar vardır
- Teknik sorunların çoğu eninde sonunda insan, kültür ve iletişim sorunlarına dayanır
- Teknik borç, kodun değil organizasyonun davranış kalıplarının ve kültürünün ürettiği bir sonuçtur
- Teknik borcu çözmek için önce organizasyonun değişimi kabul etmesi ve liderliğin bunu anlaması gerekir
- Ayrıca, kariyerin ilerleyen aşamalarında yalnızca teknik mükemmeliyetle çözülemeyen daha büyük sorunlar sizi bekler
- Gerçek kıdemli mühendis, teknik yetkinlik ile insanı anlama becerisini birlikte taşıyan dengeli bir liderdir
2 yorum
Hacker News görüşü
Sorunların çoğunun aslında iletişim sorunu olduğunu hissettim
Mühendisler ürün vizyonundan ya da müşteriden kopuk oluyor, ürün ekibi ise mühendislere adeta şirket içi bir taşeron ekip gibi davranıyor
Satış ve CS ekipleri, verdikleri sözlerin ürün yol haritasını nasıl etkilediğini anlamıyor
Sonunda hedefler ve başarı metrikleri birbirinden kayıyor, herkes farklı yöne kürek çekmeye başlıyor
Çözüm “daha iyi insanlar” değil; herkesin aynı hedefe odaklanması ve kendi rolünün bütünün içine nasıl oturduğunu anlaması
Eski teknik borç da aynı şekilde, görmezden gelince ortadan kaybolmuyor. Bu borcun şirkete getirdiği maliyet ve riski sayısallaştırıp diğer hedeflerle dengelemek ve geri ödeme planı yapmak gerekiyor
Kullanıcının hemen yanında olduğun, onunla doğrudan tanışıp arkadaş olduğun, günlük akışını ve bağlamını öğrendiğin oturumlar bunlar
Her 3 haftada bir otomatik planlanıyor ve herhangi bir aksiyon maddesi olmadan yapılıyor. İnsanlar her seferinde şaşırıyor, küçük bug’lar çözülüyor ve bağlantılar kuruluyor
Slack API ile entegre çalışan otomatik bir planlayıcı geliştirip kullanıyorum; en zor kısım takvimleri uydurmak ve katılımı teşvik etmek
Yönetim astlarını dinlemiyor, astlar da dikkat çekebilmek için birbirleriyle yarışıyor
Yakın zamanda bizim departmanda da bir danışman yeni bir platforma geçilmesini önerdi; kimse katılmadı ama yine de durdurulamadı. Sonuçta kimse kimseyi dinlemiyor
“Bunu neden yapıyoruz?” sorusuna genelde “güven bana” tarzı cevaplar geliyor
Bu PM davranışının değişeceğini sanmıyorum. Bu yüzden mühendisler iletişim boşluğunu kapatmak için doğrudan ürün rollerini üstlenmeye başlıyor
Birçok insanın aslında işiyle gurur duymadığını fark ettim
Bazıları için bu sadece maaş
Özellikle daha yaşlı çalışma arkadaşları, sistemlerin çöktüğünü daha önce gördükleri için aynı şeyin tekrar olmasını engellemeye çalışıyor
Her yeni işe geçtiğimde ilk 90 gün içinde net yönergeler koymaya çalışıyorum ama sonuçta işin özü ekip
Bazı ekipler değişime aç, bazıları ise değişimi engelliyor
Lider bilgisizse ya da sadece en hızlı ve en ucuz seçeneği seçiyorsa işler daha da zorlaşıyor
Birleşik Krallık’taki Post Office skandalı gibi, içeride sorunun bilindiği ama önünün kesildiği vakalar aklıma geliyor
Eskiden nüfusun yarısından fazlası kendi işini yapıyordu, bugün bu oran yaklaşık %10
Artık ürettiğimiz şey “bizim” değil, “işverenin”
Daha çok çalışsan da ödüllendirilmiyorsun; aksine üstüne daha fazla iş yükleniyor
Sonunda insanlar birer kaynak gibi görülüyor ve ihtiyaç kalmayınca atılıyor
Kriz anında ilk işten çıkarılan çalışanlar oluyor, CEO ise milyonlarca dolar alıyor
Böyle bir düzende çalışanlardan şirket için fedakârlık beklemek imkânsız
Daha az çalışan daha yüksek maaş alıyor, sen ise maaşının yarısına çalışacak bir yedek yüzünden işini kaybedebiliyorsun
Mülakatlar giderek zorlaşıyor, emeklerin başkaları tarafından sahipleniliyor, enflasyon maaşı eritiyor
Sonunda “gurur neden kayboldu” sorusu bir gizem gibi sunulsa da cevabı aslında çok net
Ama şirketler, çoğu insanın aslında yapmak istediği işi yapamadığını biliyor ve bunun yerine süreçlere ve iş akışlarına odaklanıyor
Birey açısından en iyi senaryo, sevdiğin işi yapıp karşılığında iyi ücret almak
Bir geliştiricinin “yeni şeyler öğrenmek istemiyorum” demesi mutlaka kötü bir şey değil
JavaScript ekosistemindeki her gün değişen framework yorgunluğu ile Go ya da LTS tabanlı teknik istikrar aynı şey değil
İstikrar, ürün çevikliğine de yardımcı olur
Eski bir C++ kod tabanıyla çalışan kıdemli bir mühendistle pazarlık etmek zorunda kalabilirsin ama buna doğrudan teknik borç demek önyargılı olur
Bir kod tabanının teknik borç olup olmadığına, o kod tabanından sorumlu lead IC ve onu yöneten yönetici karar verebilir
Mülakatta insani sorunlardan bahsetmek, elenmenin en iyi yollarından biri
Birçok mülakatçı yalnızca teknik cevapları doğru kabul ediyor, insani içgörüleri görmezden geliyor
Ben tam tersine böyle bir bakış açısını değerli buluyorum ama ekip arkadaşlarımla bunu kabul ettirmek için ayrıca mücadele etmem gerekiyor
Mesaj hacmine bağlı olarak batch processing’in yeterli olabileceğini söyleyince, bunun “queue bilmemek” anlamına geldiğini iddia etti
10 yılı aşkın süredir petabayt ölçekli veri ürünleri üzerinde çalıştığımı anlattım ama onun sistem tasarımı kalıbına uymadığım için elendim
Şimdi de o ekip tüm microservice’leri tek bir API’nin arkasında toplama işi yapıyor
Eğer ekip bu dengeyi anlayamıyorsa, o ekibe katılmamak da sorun değil
Big Tech’te veri mühendisi olarak en zor iki problemim var
Birincisi, Conway’s Law yüzünden her departmanın farklı bir toolchain’i ve veri felsefesi olması
İkincisi, her silo kendi yönteminin tek doğru yol olduğunu savunurken bir yandan da başkalarının verisini istemesi
Standardizasyonun imkânsız olmasının sebebi, her bölüm liderinin kendi yaklaşımının tek çözüm olduğuna inanması
Gerçekte bakınca çoğu yaklaşım hem doğru hem yanlış taraflar barındırıyor
Dışarıdan teknik bir sorun gibi görünüyor ama sonuçta bu da insan sorunu
Upstream sistemlerdeki değişiklikler bildirilmediği için ancak downstream tarafta alarm çalınca haberdar oluyorsun
O kadar çok anlık istek geliyor ki sprintler anlamsızlaşıyor, dokümante edilmemiş bilgi de cabası
Bu deneyimler bana daha alt seviyedeki bilgisayar bilimlerini öğrenmek için motivasyon verdi
Değişimi yönlendirmek için ağ kurmak, insanları bir araya getirmek ve değişimi şeffaf biçimde yaymak gerekiyor
Ama gerçek değişim için director ya da VP seviyesinde üst düzey lider desteği şart
AWS bu tür organizasyonel dönüşüm için rehber yayınladı; AWS Prescriptive Guidance mükemmel bir taslak
Her şey “herkesi tek bir çözümde birleştirelim” diye başlıyor ama kısa süre içinde bölüm bazlı ayrı projelere bölünüyor
Bunu önlemek için güçlü yetkileri olan bir lider gerekiyor
Özellikle kamu tarafında, birimlerin birbirinden hoşlanmaması işleri daha da zorlaştırıyor; özel sektörde ise en azından ortak bir işi koruma hedefi olabiliyor
Jerry Weinberg’in Secrets of Consulting kitabında dediği gibi,
“Yüzeyde teknik bir problem gibi görünse bile, her zaman insan problemidir”
Teknik sorunların kökünde sonuçta insanların tercihleri, iletişimi, yönetimi ve yetkinliği yatıyor
Bir sistem değiştirme projesinde analist olarak çalıştım
Eski sistem işleri basit bir round-robin yöntemiyle dağıtıyordu, yeni sistem ise herkesin iş yükünü dikkate alarak daha adil dağıtım yapıyordu
Ama bazı çalışanlar sistemi meşgul görünecek şekilde manipüle etti ve sonuçta dürüst çalışanlar daha fazla iş yükü aldı
Biz sorunun özünün teknoloji değil, denetim eksikliği olduğunu açıkça anlattık ama yine de teknik bir çözüm dayatıldı
İnsan doğası gereği iş, kendisine ayrılan zamanı dolduracak şekilde genişler; bu tür ters teşvikleri teknik olarak kontrol etmek gerekir
Sistemi ideal insanlar varmış gibi tasarlarsan başarısız olursun
Jerry Weinberg, daha 1971’de yayımlanan The Psychology of Computer Programming’den beri
görünüşte teknik olan problemler için bile “her zaman insan problemidir” ilkesini vurguluyordu
Kitapları bugün bile okunmaya değer
“İşinle gurur duymuyorsun” diye suçlayan tavrı sevmiyorum
Çalışanların çoğu işin sahibi değil, sahibi şirket
Şirket belli bir yönü dayatıyor ve itiraz edersen bunun bedelini ödüyorsan, neden mücadele edesin
Sonuçta biz sadece makinenin dişlileriyiz ve bize böyle davranılıyorsa ona göre davranırız
Yazının sahibindeki benmerkezci tavır rahatsız edici geliyor
Artık oldukça kıdemliyim ve fon sağlayan sponsorlarla, gereksinim sahipleriyle doğrudan çalışıyorum
Onlar “şunu yap, maliyeti ne?” diye soruyor ama ben 30 dakikalık toplantının 18. dakikasında kabaca bir tahmin çıkarmak zorunda kalıyorum
Teknolojiyi bilmiyorlar ama para ve politikanın dilini mükemmel biliyorlar
Bazı sorunları tek bir mesajla çözdüm, bütçe ise 6 milyon dolardı
Başka projeleri ise başka ekipler aldı, 35 milyon dolar harcayıp başarısız oldular
Bütçeyi elinde tutan sponsorların çoğu için öncelik siyaset, hedef ise “bir sonraki makam”
Kariyerlerine bakınca sık sık “bu insanlar o konuma nasıl geldi?” diye düşünüyorsun
Bununla ilgili daha ayrıntılı bilgi edinmek isteyenlere, Peopleware kitabını okumalarını tavsiye ederim!