Yazılım mühendisliği maaşları üç bütçeden birinden ödenir

Üç bütçe

• Yazılım mühendisliği maaşları üç bütçeden birinden çıkar.
• Maaşın ödendiği bütçe, günlük işi ve kariyer rotasını etkiler.
• Bu üç bütçe satış/pazarlama, araştırma ve geliştirme ile bakım bütçesidir.

Satış/pazarlama bütçesi

• Büyüme organizasyonunun parçası olduğunuzda sonuçlar kolayca nicelleştirilebilir ve ölçülebilir olur.
• Büyüme mühendisi, satış mühendisi, developer relations çalışanları gibi roller buna girer; mevcut ürünleri satmak, özellikleri duyurmak ve araç benimsenmesini sağlamakla ilgilenirler.
• Bu bütçe anında etki ister.
• Ölçülebilir etki, ROI'nin her zaman bilinmesini sağlar ve doğrudan gelir üretir.
• Ölçüm kolay olduğunda karşılaştırma da kolaylaşır; bu da içeride rekabetçi bir kültüre yol açabilir.
• İş kısa vadeye odaklıdır; bir sonraki deneyin, müşterinin ya da pazarlama trendinin peşinden gider.
• Şirket yatırım getirisini en üst düzeye çıkarmaya çalıştığı için çalışan sirkülasyonu yüksek olabilir.

Araştırma ve geliştirme

• Araştırma ve geliştirme (Ar-Ge) en fazla mühendisi istihdam eder.
• Ürün organizasyonunun altında çalışır; büyük şirketlerde gerçek araştırma ve bilim organizasyonları bulunur.
• Ürün mühendisleri, araştırmacılar ve mimarlar gibi roller buna girer; şirketin sattığı ya da satabileceği ürünleri inşa eder veya keşfederler.
• Bu bütçe zaman içinde büyüme ister.
• Ortam daha sakindir ve bakım ile yeni kullanıcı kazandıracak özellikler arasında denge arar.
• Düzgün bir araştırma bölümüne sahip şirketlerde, yıllar sonra ürüne dönüşecek fikirler üzerinde çalışan insanlar bulunur.
• Geliştirme ile araştırma farklıdır, ancak ortak noktaları uzun vadeli sonuçlara odaklanmalarıdır.
• En kısa ilgi süresi çeyrektir ve yapılan işin bir varlığa dönüşerek yıllarca değer üretmesi gerekir.

Bakım

• Bakım çoğunlukla geliştirme içinde erir.
• Bu bütçe maliyet optimizasyonu ister.
• Sistem yöneticileri, eski sistemleri ayakta tutan kişiler ve bazen platform mühendisleri buna girer.
• Şirket bu işi saf bir maliyet olarak görür ve en aza indirmek ister.
• Birçok şirkette bu iş ürün geliştirme içine entegre edilmiştir ve değer üretmeyen iş olarak görülür.
• Şirketler bu bütçeden o kadar hoşlanmaz ki, mühendislere NFR çalışmasına (işlevsel olmayan gereksinimler) zaman ayırmayı özel bir ayrıcalık gibi sunarlar.
• İç araçların geliştirilmesi de bu kategoriye girebilir; şirketi çalıştıran ama öncelik verilmeyen yönetim panelleri buna örnektir.

Bunun neden önemli olduğu

• Çalıştığınız bütçeye göre günlük işiniz değişir.
• Büyüme ölçülebilirdir ve oynaktır.
• Araştırma sakindir ve belirsizdir.
• Geliştirme değerlidir ve zaman içinde inşa edilir.
• Bakım her zaman küçültme hedefidir.

GN⁺ görüşü

• Bu yazı, yazılım mühendislerinin kariyerlerini planlamasına ve yaptıkları işin şirket içinde nasıl algılandığını anlamasına yardımcı olur.
• Her bütçenin özelliklerini anlayarak mühendisler, işlerinin uzun vadeli değer üretip üretmediğini ya da kısa vadeli sonuçlara mı odaklandığını değerlendirebilir.
• Bu içgörü, mühendislerin rollerini daha net anlaması ve kariyer hedeflerine ulaşmak için gerekli stratejik kararları vermesi açısından faydalıdır.

[GN⁺]

Hacker News görüşü

• Yazılım geliştirmeye ilişkin kurumsal değer anlayışını kavramak önemlidir; bu, kariyer üzerinde büyük etki yaratır.

  • Danışmanlık şirketlerinde müşteri ilişkileri ve temel yazılım geliştirme becerileri önemsenir.
  • Ürün şirketlerinde yazılımı inşa etme ve işletme becerisi önemlidir.
  • Yazılımın ikincil rol oynadığı diğer şirketlerde bütçe içinde teslim etme becerisi önemlidir ve öne çıkmak zordur.

• Bakım çalışmalarının sürekli bütçe kesintilerinin hedefi olması ve düşük değer görmesi şeklindeki modern teknoloji kültürünü anlamak zor.

  • Yeni özellik geliştirmek önemlidir, ancak özelliklerin düzgün çalışması da önemlidir.
  • Bir şirkette, bakım yerine sürekli yeni şeyler inşa etmeye odaklı bir kültür vardı; bu da iç araçların durmadan değiştirilmesine yol açıyordu.
  • Bakıma önem vermemek işletme için zararlıdır ve kendi kendini yıkıcıdır.

• Yazılım mühendisliğini "değersiz" olarak görmek, sektörün iş yapısını anlamamaktır.

  • Diğer sektörlerle karşılaştırıldığında bütçeler ve kâr marjları farklıdır; bu yüzden mühendisleri işe alma ve ücretlendirme biçimleri de değişir.
  • Şirket içindeki diğer ürün hatları ve fonksiyonlara göre uzun vadeli yatırımlar farklılaşır; bu da yazılım ürünlerine ayrılan bütçeyi etkiler.

• Bir şirketin yıllık raporunda "Satış ve Pazarlama" ile "Araştırma ve Geliştirme" sık görülür, ama "Bakım" nadiren anılır.

  • Bir şirketin finansal tablolarını okumak, farklı gider kalemlerini ve bunların farklı dinamiklerini anlamaya yardımcı olabilir.

• patio11'in blogu, maliyet merkezi ile kâr merkezi ayrımı yapıyor ve kâr merkezinin parçası olmanın önemli olduğunu savunuyor.

  • Söz konusu blog başka birçok faydalı bilgi de sunuyor.

• Bütçeleri ayıran dört kategori vardır:

  1. Araştırma ve Geliştirme: Özel vergi avantajları ve vergi indirimleri uygulanır.
  2. Satış/Pazarlama: Sales engineer ve implementasyon bu kapsama girebilir.
  3. Bakım: Hata düzeltmeleri ve özel vergi avantajı kapsamına girmeyen kod işleri yapan geliştiriciler.
  4. Hosting service/PaaS/SaaS tarafında operasyonlar, belirli düzeyde yazılım mühendisi maaşını içerir.
  • Hangi işin hangi bütçeden karşılandığını anlamak, vergi açısından önemlidir.

• Swizec, "Serverless Handbook" adlı faydalı bir kitap yazdı ve uzun süredir yararlı bir e-posta bülteni hazırlıyor.

  • "Yaparak öğrenme / açıkta öğrenme" yaklaşımını destekliyor ve öğrendiklerini paylaşma konusunda çok başarılı.

• Bütçeleri "bucket" olarak tanımlamak mecazi görünebilir, ancak yazıda kelimenin gerçek anlamına yakın kullanılıyor.

  • Bakım rolleri ürün geliştirme içinde yer alır ve her sprintte bakıma ayrılan zaman sınırlıdır.
  • Growth ve developer relations mühendisleri genellikle ürün organizasyonuna bağlıdır.

• Tarihsel olarak yazılım mühendisliği, IT fonksiyonunun bir parçasıydı; bunun kökeni muhasebeye dayanır.

  • Günümüzde de birçok işletmede yazılımın arkasındaki ana itici güç hâlâ muhasebedir.

• Deneyime göre growth engineering maaşları hiç pazarlama bütçesinden gelmedi ve ayrıca bir "bakım" bütçesi diye bir şey de yok.

  • Her şey R&D/mühendislik bütçesine dahildir; beklentiler takım/role göre değişse de bu bir bütçe meselesi değildir.