Yazılım ekiplerinin ekonomisi: Mühendislik organizasyonlarının çoğu neden finansal olarak ‘gözleri bağlı’ çalışıyor

• Mühendislik organizasyonlarının çoğu, ekip bazında maliyet ve değer yaratımını sayısal olarak kavramadan faaliyet gösteriyor ve bu da finansal verimsizliğe yol açıyor
• 8 kişilik bir ekibin yıllık maliyeti yaklaşık €1,04 milyon (aylık €87 bin, günlük €4.000) ve bu nedenle özellik geliştirme ya da iyileştirmelerdeki her gecikme kararının net bir parasal etkisi bulunuyor
• İç platform ekipleri ile müşteri odaklı ürün ekiplerinin ikisi de başabaş noktası ve 3–5 kat değer yaratma eşiğini hesaplayabilir; ancak bunu gerçekten takip eden organizasyon sayısı az
• Son 20 yıldaki düşük faizli ve büyüme odaklı kültür, finansal disiplini zayıflattı ve büyük organizasyonlarla karmaşık kod tabanlarını varlık değil yükümlülüğe dönüştürdü
• LLM’lerin ortaya çıkışıyla bu yapısal verimsizlik görünür hale geliyor; ekip bazında maliyet, değer ve kârlılığı nicel olarak ölçen organizasyonlar uzun vadeli rekabet avantajı elde edecek

---

Yazılım ekiplerinin ekonomisi: Mühendislik organizasyonlarının çoğu neden finansal olarak ‘gözleri bağlı’ çalışıyor

• Yazılım geliştirme maliyet yapısını ve ekip bazında ekonomik gerekçeyi sayılarla inceliyor; çoğu organizasyon ise bu verilerin farkında olmadan faaliyet gösteriyor
• 8 kişilik bir ekip için yıllık yaklaşık €1,04 milyon (aylık €87 bin) harcama gerekiyor; bu da günlük yaklaşık €4.000 maliyet anlamına geliyor
• İç platform ekipleri ve müşteri odaklı ürün ekipleri, başabaş noktasını (break-even) geçmek için ne kadar değer yaratmaları gerektiğini hesaplayabilir; ancak bunu takip eden organizasyon neredeyse yok
• Son 20 yıldaki düşük faiz ortamı ve büyüme odaklı kültür, finansal disiplini zayıflattı ve büyük mühendislik organizasyonları ile karmaşık kod tabanlarının birer ‘varlık’ olduğu yanılgısını yarattı
• LLM’lerin (büyük dil modelleri) ortaya çıkışıyla bu yapısal verimsizlik açığa çıkıyor; her ekibin maliyetini ve yarattığı değeri net biçimde ölçen organizasyonlar rekabet avantajı elde edecek

Gerçek ekip maliyet yapısı

• Batı Avrupa’da bir yazılım mühendisi için kişi başı yıllık toplam maliyet €120.000–€150.000, ortalama olarak €130.000 seviyesinde
  • Buna maaş, sosyal güvenlik giderleri, emeklilik, ekipman, yönetim giderleri ve ofis alanı dahil
• 8 kişilik bir ekibin yıllık toplam maliyeti €1.040.000, aylık €86.667, günlük €4.000
• Mühendislerin ve yöneticilerin çoğu bile bu rakamları bilmiyor; önceliklendirme sürecine maliyet farkındalığı yansımıyor
• Özellik geliştirme, iyileştirme gecikmeleri, platformun yeniden inşası gibi tüm kararların açık bir parasal maliyeti var
  • Örnek: 3 hafta boyunca kullanıcıların %2’sine yönelik bir özellik geliştirmek yaklaşık €60.000’luk bir karar

İç platform ekipleri için başabaş hesabı

• 8 kişilik bir platform ekibinin 100 mühendise destek verdiğini varsayalım
  • Aylık maliyet €87.000; bunu dengelemek için aynı miktarda değer yaratılması gerekir
• Mühendis başına aylık maliyet €10.800 (saat başına €65)
  • 100 kişi için ayda 1.340 saat tasarruf sağlanırsa (kişi başı haftada 3 saat), başabaş noktasına ulaşılır
• Sadece zaman tasarrufu değil, arızaların azalması gibi etkilerle doğrudan gelir koruması da mümkün
• Buna rağmen ekiplerin çoğu bu rakamları ölçmüyor ya da karar alma sürecine katmıyor
• Gerçekçi finansal sağlamlık ölçütü 3–5 kat değer yaratımıdır (aylık €260 bin–€430 bin)
  • Sistem bakım/değişim maliyetleri ve başarısızlık oranı (%50–70) hesaba katılmalı
  • Sadece ‘başabaş’ değil, sürdürülebilir kârlılık gerekli

Müşteri odaklı ürün ekiplerinde de aynı mantık

• Müşteri odaklı 8 kişilik bir ekibin de aylık €87.000 maliyet yapısı var
  • Kullanıcı başına aylık gelir €50 ise, başabaş noktası 1.740 kullanıcı değerine, 3–5 kat eşiği ise 5.000–8.700 kullanıcı değerine karşılık gelir
• En doğrudan kaldıraç churn (müşteri kaybı) oranındaki iyileşmedir
  • Örnek: 50 bin kullanıcı içinde aylık %2 kayıp (1.000 kişi, €50.000 zarar) → neden ortadan kaldırılırsa başabaşın büyük kısmı karşılanır
• Activation (aktivasyon) oranındaki iyileşme de önemlidir
  • Aylık 10 bin yeni kullanıcıdan yalnızca %30’u aktive oluyorsa, bunun 5 puan artması 500 ek dönüşüm ve €25.000 ek gelir demektir
• Conversion (dönüşüm) oranındaki artış da aynı etkiyi yaratır
  • 20 bin denemede %4’ten %4,5’e çıkılması 100 ek ücretli kullanıcı ve €5.000 ek gelir sağlar
• Birden fazla metriktteki küçük iyileşmeler birikerek büyük finansal etki yaratabilir; ancak ekiplerin çoğu bu metriklerle finansal sonuçlar arasındaki bağı ölçmüyor

Neden finansal ölçüm yapılmıyor?

• Pek çok ekip yalnızca velocity, bilet sayısı, özellik sayısı, NPS, CSAT gibi aktivite ve duygu metriklerini takip ediyor
  • Bunlar finansal metriklerin yerine geçmez; tamamen farklı bir kategoridir
• Aktivite metrikleri iyileşse bile finansal performans kötüleşebilir
  • Özellik sayısının artması → yanlış özellikler geliştiriliyor olabilir
  • Etkileşimin yükselmesi → gelire katkı sağlayan gerçek kullanıcılar azalıyor olabilir
• Bu metrikler, ölçülmesi, raporlanması ve başarı hikâyesine dönüştürülmesi kolay olduğu için tercih ediliyor
  • Finansal metrikler rahatsız edici gerçekleri ortaya çıkarabilir
• Organizasyonların çoğu şeffaf finansal ölçüm kültürünü bilerek inşa etmiyor

Son 20 yılın arka planı

• 2002–2011: Faizler düşüktü, ancak yatırımcıların riskten kaçınması nedeniyle finansal disiplin korunuyordu
• 2011–2022: Sıfır faiz, risk iştahının geri dönüşü ve SaaS büyüme mantığı birleşti
  • 11 yıl boyunca şirketler, personel artışı, düşük verimlilik ve yanlış önceliklere rağmen büyüme oranları sayesinde affedildi
• Bu dönemde yetişen liderlik kuşağı, finansal sonuç talep edilmeyen bir ortamda büyüdü
  • Bu yüzden 2022 sonrasında sermaye maliyeti artsa da davranışlar otomatik olarak uyum sağlamıyor

‘Varlık’ sanılan mühendislik organizasyonlarının yükümlülüğü

• Büyük kod tabanları ve mühendislik organizasyonları geleneksel olarak varlık (asset) olarak görülüyordu
  • Birikmiş iş mantığı, teknik temel, organizasyonel yetkinlikler vb.
• Gerçekte ise bunlar, bakım yükü, koordinasyon maliyeti ve karar alma gecikmelerinin biriktiği bir yükümlülük (liability) yapısıdır
  • Karmaşıklık arttıkça üretkenlik düşer, maliyetler yükselir, gelir durağanlaşır
• Geçmişte düşük faiz ortamı bu yükümlülüğü gizledi

• LLM’lerin açığa çıkardığı gerçek

  • Geliştirici Nathan Cavaglione, LLM ajanlarını kullanarak 14 günde Slack’in temel işlevlerinin %95’ini kopyaladı
  • Slack, binlerce mühendisin 10 yılı aşkın süredir geliştirdiği ve milyarlarca euroluk yatırım alan bir ürün
  • Nathan ise organizasyonel karmaşıklık, mevcut mimari ve koordinasyon maliyetleri olmadan benzer bir ürünü kısa sürede tamamladı
  • Bu durum, büyük organizasyonların ölçeği, karmaşıklığı ve birikmiş kodunun rekabet avantajı olduğu varsayımının artık geçerli olmadığını gösteriyor
  • LLM ile üretilen kodun bakım yapılabilirliği konusunda sorunlar var; ancak ajan-ajana ortamda insan bakımına kıyasla maliyet ve hız açısından üstünlük söz konusu

Bundan sonra öne çıkacak organizasyonların koşulları

• Rekabet gücünün özü teknoloji değil, analiz yeteneği
  • Her ekibin maliyetini, yarattığı değeri ve kârlılık eşiklerini net olarak bilen organizasyonlar yapısal avantaja sahip olacak
• Bu organizasyonlar şunları yapabilir
  • Build vs Buy kararlarını gerçek ekonomik temele göre vermek
  • Kârlılık eşiğinin altındaki ekipleri belirlemek
  • Gecikmenin yol açtığı değer kaybını nicel olarak hesaplayıp öncelikleri yeniden düzenlemek
• Organizasyonların çoğunda bugün ölçüm altyapısı, veri akışları ve alışkanlıklar yok
  • Bunu kurmak rahatsız edici olabilir ama zorunludur
  • Ekiplerin, finansal bağlantısı olmayan işlere tüm çeyreği harcadığını ortaya çıkarabilir
• Geçmişte düşük faiz ve büyüme odaklı mantık bunu tolere ediyordu; ancak yapay zeka ile geliştirme maliyetlerinin sert biçimde düştüğü ve yatırımcıların finansal sonuç talep ettiği bir ortamda bu sürdürülebilir değil
• Ekip bazında ekonomiyi açıkça sorgulama ve ölçme alışkanlığına sahip organizasyonlar, zaman geçtikçe bileşik getiri benzeri bir rekabet avantajı biriktirecek

[GN⁺]

Hacker News yorumları

• Bu yazının özündeki nokta, zor olanın programlamanın kendisi değil, neyin programlanması gerektiğini bulmak olduğu. Gerçekte çoğu zaman problem alanını, önce yanlış şeyi yapıp sonra değiştirerek birkaç kez keşfediyoruz. Programlama çoğu zaman nihai çıktıdan çok, problem tanımını netleştirmek için bir araç olmaya daha yakın.

  • Bunun her zaman doğru olduğunu düşünmüyorum. Bazı projelerde ne yapılması gerektiği nettir ama mühendislik zorluğu başlı başına aşırı yüksektir. Sadece framework’leri birleştirmek söz konusuysa kolay olabilir, ama karmaşık sistemlerle uğraşılan ortamlarda programlamanın kendisi gerçekten zordur.
  • Pek çok yazılım aslında değer üretmiyor, hatta değeri azaltıyor. Basit bir talebin devasa bir sisteme dönüştüğünü sık sık gördüm. Ama Google gibi altyapıya akıllıca yatırım yaparsanız rekabet avantajı da elde edebilirsiniz.
  • Bu kavram mühendislik dışındaki alanlarda da var. İnternetteki “yanlış cevabı yazarsan doğru cevabı daha hızlı alırsın” sözü gibi, yanlış denemeler bazen daha iyi içgörü sağlayabiliyor. Ama bu yaklaşım çoğu zaman verimsiz görünüyor ya da insanın “yanlış şeyler söyleyen kişi” sanılmasına yol açıyor.
  • Programlama en zor şey olmayabilir ama yine de kolay bir iş olmadığını unutmamak gerekir.
  • Yeni başlayan geliştiriciler için doğru olabilir ama deneyimli mühendisler zaten verimli şekilde nasıl üretileceğini bilir. Pek çok geliştirici kendi projesinin özel olduğunu sanıyor, ama aslında çoğu durumda hâlihazırda kanıtlanmış tasarımları kopyalamak yeterli oluyor.

• Yazıda dendiği gibi, kod hızlı üretildiğinde yönetimin zorlaşacağı kaygısı yerinde; ama insanlar bakım yapmayacaksa bunun daha az önemli olduğu iddia ediliyor. Ama bence aynı mantık “agile koç LLM” için de geçerli. LLM zaten içgörülerin çoğunu çok daha ucuza sunabiliyor. Sonunda insanlar havuz kenarında dinlenebilir belki.

  • AGI işimi devralırsa ben yine de doğrulama ve sorumluluk kısmını üstlenirim. Yönetim katmanı ortadan kalkarsa belki daha huzurlu bile olur.
  • Bu aralar LLM hakkındaki yazıların çoğu sanki LLM tarafından yazılmış gibi geliyor. Satılan eğitim materyalleri bile tek satırlık bir prompt ile değiştirilebilir gibi.
  • Artık öğrenmenin maliyetinin neredeyse sıfır olduğu, eğitmenin ise sadece öğrenmeyi zorlayan kişi rolüne indiği bir dönemdeyiz.

• “Dağınık bir kod tabanına birkaç ajan atarsan çözülür” iddiasına katılmıyorum. Gerçekte dışarıdan kusursuz görünen ama içeride straforla yapılmış bina gibi yapısal olarak hatalı çok kod var. Böyle kodlar zamanla genişletilemez hale geliyor ve sonunda tuğla gibi katılaşıyor.

  • Yeterli mimari tasarım ve guardrail’ler varsa ajanlar da iyi çalışabilir. Yoksa insanların dikkatli gözetimi şart.
  • Ajanlar fazla “zekice kod” yazarsa debugging işini kimin yapacağı sorunu ortaya çıkıyor.
  • “Sanat yük taşır” ifadesi gerçekten çok etkileyiciydi.
  • Yönetimin AI’ın her şeyi çözeceğine inanması tehlikeli bir yanılgı. Sadece hesaplama gücüyle çözülecek bir şey değil.
  • Böyle sorunlar ortaya çıkıyorsa test sisteminin kendisinde bir şeyler eksik değil mi?

• Ben de AI tarafından yapılmış iki projenin tamamen başarısız olduğu deneyimi yaşadım. Daha fazla ajan eklemek de ilerleme sağlamadı ve ortaya çıkan sonuçların çoğu yanlış yöndeydi.

  • Benim de benzer bir deneyimim oldu. 40 bin satırdan fazla kod sildim. AI’ın ürettiği kod neredeyse her zaman yanlış soyutlamalar kullanıyor.
  • Bu biraz Mythical Machine Month gibi bir durum. İnsan yerine makine sayısını artırmak da üretkenliği yükseltmiyor.
  • AI ile uğraşırken insanlardaki dikkat hatalarına benzer örüntüler sık sık görüyorum. Sonuçta mesele bağlam ve odak.
  • Kodun sahipliği hâlâ insanda. AI üretmiş diye bu sorumluluk ortadan kalkmıyor.
  • AI’ın teknik borca saplanması da insandan farklı değil. Ama en azından yeniden yazımı kolaylaştıran bir araç olma potansiyeli var.

• “Yazılım geliştirme sermaye yoğun bir faaliyettir” görüşüne katılıyorum, ama bağlam sektörden sektöre değişiyor. Elektrik şirketleri ya da üreticiler için fiziksel altyapının bakım maliyeti, IT’den çok daha büyük. Yine de SaaS sözleşmeleri çoğaldıkça, LLM geliştiricileri istihdam etmenin daha ekonomik olup olmadığını sorgulayan şirketler artıyor.

  • Ulaşım idareleri gibi kamu kurumlarında bile SaaS harcamalarının aşırı olduğuna dair bir farkındalık oluşuyor. Sonunda yönetim bunu gördüğünde gereksiz sözleşmeler büyük ölçüde temizlenecek.
  • Ama SaaS tamamen ortadan kalkmayacak. Çünkü sorumluluk zincirini ve hukuki riski taşıyabilecek bir yapıya ihtiyaç var.
  • İlaç fabrikalarının sadece inşaat maliyeti bile milyarlarca dolar. Böyle sektörlerde yazılım maliyeti önemsiz kalıyor.

• Yazıyı ilgiyle okuyordum ama Slack klonu örneğinde güvenimi kaybettim. Bu, gerçek Slack’in ölçeğini, güvenilirliğini ve işlevselliğini hiç anlamayan bir iddia.

  • Slack öyle basitçe kopyalanabilecek bir ürün değil. Sayısız deneme-yanılma ve ürün sezgisi birikiminin sonucu.
  • “%95 kopya” ifadesini görünce güven orada bitti zaten.
  • Üniversite öğrencileri de Twitter klonu yapabiliyor, ama gerçek rakip kod değil pazar ve ekosistem.
  • Ben de 2 haftada bir Slack klonu yapabilirim, ama sadece yasal saklama özelliğini düzgün uygulamak bile aylar sürer. Kurumsal ürünlerde böyle yüzlerce ayrıntı zorunludur. Basit kopyalama rekabet etmek değildir.
  • Slack’i yapmak, sadece kod yazmak değil, ne yapılacağını keşfetme süreciydi.

• Sayılar ve grafikler fırlatıp duran yazılar bana tartışmayı kazanmak isteyen birinin yazısı gibi geliyor. Rory Sutherland’ın dediği gibi, “Finance People” kesinlik ve öngörülebilirliğe takıntılı. Ama dünya o kadar basit değil.

  • Hassas hesaplar, yan etki olarak problemi parçalara ayırmaya yardımcı olur. Ama sonunda pazarı fetheden şey problemin derinlemesine anlaşılması ve vizyondur.
  • Onun matematiği gerçeklikle uyuşmuyor. Ürünün başarısı öngörülemez ve yatırımın kendisi bir kumar.
  • Gerçek her zaman bir yerlerde ortadadır. Sayılarla sezgi arasında denge gerekir.
  • Doğru ölçüm araçları ve metriklere sahip ekipler uzun vadede daha iyi sonuç üretir.
  • Yine de en azından bir özelliğin gelire nasıl etki edeceğine dair bir hipotez kurmak gerekir ki sürdürülebilir bir iş yapılabilsin.

• Yazının ayrıntılarından çok, maliyet karşılığı değer üzerine düşünmeyen mühendislik kültürüne katılıyorum. Toplantılarda ya da olay müdahalesi süreçlerinde maliyet-etki dengesi gözetilmeden aşırı önlemler alındığı çok oluyor. Teknik borçta da durum aynı; maliyeti bilmeden sorumlu kararlar verilemez.

  • Toplantılardan daha büyük israf, yanlış projeler veya özelliklerdir. Bakım ve karmaşıklığı sonsuza kadar sürüklerler.

• “Platform ekibi, sağladığı zaman tasarrufuyla değerini kanıtlamalı” şeklindeki basit hesap yanlış. Platform ekibi sadece zaman kazandırmaz; iş riskini azaltır ve temel kaliteyi garanti eder.

  • Platform ekibinin varlık nedeni tekrarlanan çabayı merkezileştirmek ve güvenlikle operasyonun ayrımını korumaktır. Bu sadece ekonomik mantık değil, organizasyonun gerekli altyapısı meselesidir.

• Sonuçta önemli olan, ekibin ürünü gerçekten önemseyip önemsemediği. Kısa vadeli kariyerden çok ürünün kendisini önemseyen ekipler, metriklerin ve yönetim tekniklerinin ötesinde gerçek sonuçlar üretir. Ama bazı projeler daha en baştan insanın bağ kuramayacağı bir yapıda olduğu için üretkenliğin sınırı nettir.