- Mühendislerin günlük işi ve kariyer rotası, maaşlarının satış/pazarlama, araştırma-geliştirme veya bakım bütçesinden hangisinden çıktığına büyük ölçüde bağlıdır
- Satış/pazarlama bütçesindeki mühendislik, paraya daha yakındır ve performansı ölçmek kolaydır; ancak stack ranking ve iç rekabet kültürüne yol açabilir
- Araştırma-geliştirme bütçesi, ürün organizasyonu altında en çok mühendisi istihdam eder ve kısa vadeli deneylerden çok çeyrek dönem ve sonrası için uzun vadeli değer ile varlık birikimini önemser
- Bakım bütçesi, maliyet optimizasyonu hedefi olarak görülür; sysadmin, eski sistemlerin işletimi, bazı platform mühendisliği işleri ve iç araç çalışmaları bu kapsama girebilir
- Kendi işinizin hangi bütçeye ait olduğunu bilmek, growth işlerinin sık değişimini, araştırma-geliştirmenin uzun vadeli yatırımlarını ve bakımın düşük önceliğini kariyer kararlarınıza yansıtmanıza yardımcı olabilir
Üç bütçe mühendislik işlerini ayırır
- Yazılım mühendisliği maaşları büyük ölçüde üç bütçeden birinden gelir
- satış/pazarlama
- araştırma-geliştirme
- bakım
- Bütçenin niteliği, mühendisin günlük çalışma biçimini ve kariyer yönünü etkiler
- Bu ayrım, kariyer vizyonu veya konumlanma üzerine düşünürken faydalı olabilir
Satış/pazarlama bütçesi: ölçülebilir ve anlık sonuçlar
- Growth organizasyonuna bağlı mühendislikte sonuçları nicel olarak ölçmek kolaydır
- Hangi işin hangi metriği yükselteceği görece daha nettir
- Bu kategoriye growth engineer, sales engineer, devrel gibi roller girer
- mevcut ürünün daha iyi satılmasını sağlarlar
- insanların özelliklerden haberdar olmasına yardımcı olurlar
- alıcıların aracı iş akışlarına benimsemesini desteklerler
- Şirketin beklentisi anında etki yaratmaktır
- Avantajı, yatırım getirisini anlamanın kolay olması ve işin doğrudan gelire bağlanmasıdır
- Ölçüm kolay olduğu için insanlar arası kıyaslama da kolaylaşır
- çalışanlar arasında stack ranking oluşabilir
- birlikte problem çözme kültüründen çok iç rekabet kültürü güçlenebilir
- Çalışma ritmi genellikle kısa vadelidir
- bir sonraki deney
- bir sonraki müşteri
- bir sonraki pazarlama trendinin peşinden gitmek gibi
- Şirket, bu bütçeye koyduğu paranın ürettiği çarpana göre değer biçer ve optimizasyon arayışı içinde döner kapı etkisi ortaya çıkabilir
Araştırma-geliştirme bütçesi: zaman içinde biriken varlıklar
- Araştırma-geliştirme, yani Ar-Ge, en fazla mühendisin çalıştığı alandır
- genellikle ürün organizasyonunun altındadır
- daha büyük şirketlerde gerçek bir araştırma organizasyonu veya bilim organizasyonu bulunabilir
- Bu kategoriye product engineer, researcher, architect gibi roller dahildir
- şirketin sattığı şeyi üretirler
- ya da iyi çalışırsa şirketin satabileceği şeyleri araştırırlar
- Şirketin beklentisi, zaman içinde büyüme sağlamaktır
- Ortam görece daha sakindir
- mevcut kullanıcıları koruyacak özelliklerle yeni kullanıcı çekecek özellikler arasında denge kurulur
- kayıt olduktan sonra gerçek kullanıma geçişi artıran özellikler yapılarak growth tarafına kayılabilir
- yeni ürün hatları araştırılarak araştırma tarafına da kayılabilir
- Gerçek bir araştırma departmanı olan şirketlerde, yıllarca ürüne dönüşmeyebilecek fikirlerle uğraşan kişiler de vardır
- Araştırma-geliştirme aslında iki farklı bütçenin tek bir kategoriye toplanmış halidir
- geliştirme ile araştırma farklıdır
- ama ortak noktaları uzun vadeli sonuçlara odaklanmalarıdır
- İlgilenilen en kısa zaman dilimi çeyrek dönemdir
- Mühendislerin işi, önümüzdeki yıllarda değer üretmeye devam edecek varlıklar olacak şekilde tasarlanır
- daha kısa deneyler ise bu yolun basamaklarıdır
- Sonuçları ölçmek zordur, ancak şirket bu işi bir yatırım olarak görür
- varsayım, ürün iyileştikçe satışın ve elde tutmanın da iyileşeceğidir
Bakım bütçesi: azaltılmak istenen maliyet
- Bakım genellikle geliştirme işlerinin içine dağılmış durumdadır
- Bu bütçenin istediği şey maliyet optimizasyonudur
- sysadmin, eski sistemleri ayakta tutan kişiler ve bazen platform engineer bu kategoriye girer
- Şirket bu işi saf maliyet olarak görür ve en aza indirmeye çalışır
- Birçok şirkette bakım rolleri ürün geliştirme içine yayılmıştır
- önemli görülmeyen işlerdir
- ama biri yeterince rahatsız olunca sonunda ele alınırlar
- Şirketler, NFR yani işlevsel olmayan gereksinimler için mühendislere zaman vermeyi özel bir ayrıcalık gibi sunabilir
- her sprintte can sıkıcı işleri çözmek için 2 gün verilmesi buna örnektir
- İç araç geliştirme de bu kategoriye girebilir
- şirketin işlemesini sağlayan yönetici panelleri vardır
- ama çoğu zaman yeterli öncelik almazlar
Bütçedeki konumun kariyer kararlarına verdiği sinyal
- Bir işin hangi bütçeye ait olduğu, mühendisin günlük deneyimini belirler
- Growth işleri ölçülebilirdir ve sık değişir
- Araştırma işleri daha sakindir ama sonuçları daha belirsizdir
- Geliştirme işleri değerli görülür ve zamanla birikir
- Bakım işleri ise her an kesilebilecek bir alan gibi ele alınır
1 yorum
Hacker News yorumları
Maaşınızın hangi bütçe kaleminden çıktığını bilmenin yanında, kurumun yazılım geliştirmeyi nasıl değerlendirdiğini de bilmek kariyerinizi ciddi biçimde etkiler
Şirket, geliştirme zamanı satan bir danışmanlık şirketiyse müşteri ilişkileri becerisi ve makul yazılımı hızlıca üretme becerisi değer görür; yazılım ürünü satan bir ürün şirketiyse yazılımı geliştirme ve işletme becerisi değer görür
Yazılımın kısmen yer aldığı ya da yazılımla mümkün hâle gelen başka bir işse, bütçe içinde teslim etme becerisi değer görür; ama sahnenin yıldızı olmak zordur
İlginç biçimde bu ayrım, yazarın sözünü ettiği üç kategoriyle iyi örtüşüyor: danışmanlık satış/pazarlamaya, ürün araştırma-geliştirmeye, geri kalanlar da bakıma karşılık geliyor
Bir yazılım startup'ında kıdemli mühendisken yıldız muamelesi, hisse opsiyonları ve beklenebilecek türden bir ofis kültürü vardı; bir IT danışmanlık şirketinde kıdemli danışmanken ise daha çok iyi PowerPoint hazırlayan bir satış elemanı gibi olmam gerekiyordu
Faturalandırılabilir saatleri maksimize etmem gerekiyordu; projeyi hızlı bitirmek ya da minimum kodla bitirmek olmuyordu
Şu anda nerede olduğumu kabaca tahmin edebilirsiniz
Bu, kutulu ürün olarak satın alabileceğiniz bir şey değil; genelde birçok sistemin ağır biçimde özelleştirilip zorla birbirine bağlanmış hâlidir ve çoğu zaman baştan birlikte çalışmak üzere tasarlanmamıştır
Her şirketin yöntemi de farklıdır
Bu işi seviyorum ve birden çok departmanı kesen bütün sistemi düşünmekte iyiyim
Sorunların içinden geçebilmek için iç politika bilgisi de gerekir; benim değerim de tam olarak orada ortaya çıkar
Programcı olarak da fena değilim, ama programlamayı kariyer edinmiş birinin uzmanlığına erişemem
Diğer iki durumda minimize edilmesi ya da ortadan kaldırılması gereken bir maliyet olursunuz
Yalnızca şirketin temel ürününü üretiyorsanız gelir getiren bir varlık olursunuz
Ben de bu hatayı yaptım; bir toplantıya çağrılıp “Nasıl gidiyor?” sorusunu duyduktan hemen sonra “Ayrıntılara girmeyin” dendi
3 numarada çalışmak, sıkıcı ve unutulan çözümler üretmek demektir; teknik olarak geçerli olsa bile politik açıdan intihar sayılabilecek çözümler üretebilirsiniz
Örneğin bir donanım üreticisinde çalışırsanız, yıldız olmak bir yana saygı görmek bile zordur
Yazılım çalışanları maliyet olarak, mümkünse ödenmek istenmeyen bir maliyet olarak görülür
Zamanında ve bütçenin altında teslim etseniz bile dikkat çekmezsiniz; aksine gözden tamamen kaybolursunuz
Modern teknoloji kültüründe bakımın her zaman listenin en altında olduğu, bütçesinin kesildiği ve doğru dürüst bütçe alamadığı söylenmesini anlamakta zorlanıyorum
20 yıl boyunca çeşitli şirketlerde bu sözü duydum ama neredeyse hiç katılmadım
Şirket pazara sunacağı yeni özellikler ister, ama aynı zamanda hizmetin düzgün çalışmasını da ister
İşten çıkarmalar veya işe alım dondurmaları sırasında bile SRE niteliğindeki organizasyonların araştırma-geliştirme ekiplerine göre daha iyi dayandığını gördüm
Ancak bir şirkette kültür, sürekli yeni şeyler yapıp mevcut olanı sürdürmeyi ödüllendirmemeye dönüştü; bunun sonucunda iç araçların sürekli taşınması, bitmeyen emeklilik süreçleri ve yarım kalmış migrasyonlar yaşandı
Bir ürünü yapan kişiler terfi edip bir sonraki portföy işine geçince, yeni ve parlak olan şey de kısa sürede sahipsiz kaldı ve yeni bir ekip yine onun yerine geçecek bir şey yaptı
6 yıl içinde bir iç araç dört kez yeni bir iç araçla değiştirildi ve kullanıcılar dört araca dağılmış halde kaldı
Buna basit bir yürütme başarısızlığı da denebilir, ama işletmenin bakımı değerli görmediğini söyleyen kültür çok zararlıdır ve kendi kendini yok etmeye götürür
Diyelim ki bir geliştirici her yeni özellik eklediğinde 1.000 dolarlık disk alanı kullanıyor ve 10.000 dolarlık yeni gelir yaratıyor
Sistem yöneticisi büyük bir dosya sunucusu satın alıyor; yeni bir sunucunun 500.000 dolar olduğunu varsayalım
Bürokratik bir organizasyonda sistem yöneticisi disk alanı maliyetini geliştiriciye kurum içi faturalandırır ve yeni dosya sunucusu gerektiğinde para zaten hazırdır
İyi yönetilen ve daha az bürokratik bir organizasyonda yönetim, 500.000 dolarlık faturanın 5 milyon dolar getirecek projeyi mümkün kıldığını anlar ve bunu memnuniyetle öder
Kötü yönetilen bir organizasyonda ise yönetim 500.000 doların pahalı olduğu ve belirli bir projeye bağlı olmadığı gerekçesiyle tepki gösterir; sistem yöneticisi de bir sonraki 1.000 dolarlık disk alanına ihtiyaç duyan kişiye 500.000 dolar ödemesini söyler, o kişi de reddeder
Sonunda sistem yöneticisi talepleri reddeder ve geliştiricileri log saklama süresini 7 günden 3 güne indirmeye ikna etmeye başlar; bir bakmışsınız yönetim sistem yöneticisi hakkında kötü geri bildirimler duymaya başlamıştır
Anlattığınız ortam, aksine işletmenin bakımı değerli görmediği bir gerçeklik gibi görünüyor
“Bakım en altta” sözü, böyle olması gerektiğine dair bir reçeteden çok fiilen olan biteni tarif eden bir ifade
Yazar bunun neden böyle olduğunu ya da başka bir yaklaşımın iş açısından daha iyi olup olmadığını analiz etmiyor; ama düzgün çalışan ve yüksek kaliteli şeylere değer veriyorsanız doğal olarak farklı bir sonuç istersiniz
Yine de çok az şirket böyle davranıyorsa, bunun çıkarların hizalanmasıyla ilgili bir nedeni olma ihtimali yüksek
Çünkü müşteriye bakım satamazsınız; satabildiğiniz şey yalnızca özelliklerdir
Geliştirici açısından da bakım kaçınmak istenen bir iştir
Özgeçmişe bakımı parlak bir madde olarak koymak zordur; herkes başarıları, yayımlanan projeleri ve modern teknolojileri görmek ister
Hizmeti müşterinin talep ettiği seviyede çalışır halde tutmak herkes için yüksek önceliklidir
Hiçbir şirket, arızalar yüzünden müşteriler ayrılacak kadar SRE’yi azaltmak istemez
Ama SRE, geleneksel bir şirketteki operasyonlara, yani hizmet sunmak için kaçınılmaz olan işlevlere daha yakındır; mümkün olduğunca ertelenen bakımdan farklıdır
Bu açıdan bakım; teknik borcun azaltılması, iç araçların iyileştirilmesi, deney tekrar sürelerinin kısaltılması gibi şeylerdir ve bu işler çoğu zaman ürün etkisine kıyasla olduğundan az değer görür
Yazı ikincisini ele alıyor ve 3. kategoriye gitmenin kariyer intiharı olduğunu söylüyor
‘Terfi ya da kapı dışarı’ tipinde biri değilseniz 3. kategoride zaman geçirmeyi de düşünebilirsiniz
Elbette yazılım kullanıldığı anda eskidiği için, kendini 2. kategoride sanan kişiler de aslında zamanlarının çoğunu 3. kategoride geçirip yalnızca çok küçük bir kısmını 2. kategoriye harcıyor olabilir
Yine de bütçe yılda bir kez, en fazla birkaç kez tahsis edildiğinden, o anda 2. kategori olarak sınıflandırılan bir yerdeyseniz hâlâ daha iyi bir konumdasınız
“Satış/pazarlama” ve “araştırma-geliştirme” şirketlerin yıllık raporlarında görebileceğiniz sınıflandırmalardır, ama bakım bu şekilde görünmez
Şirketlerin finansal tablolarını okumanız iyi olur
“Satışların maliyeti” ya da COGS, “genel yönetim giderleri”, birleşme ve satın almalar gibi tek seferlik gider kalemleri görürsünüz; her kalemin farklı dinamikleri vardır ve şirketten şirkete de farklı işler
İçinde bulunduğunuz sektörün iş yapısını anlamak da önemlidir
Bu başlıkta bile bazı şirketlerin yazılım mühendisliğine “değer vermediği” sonucuna sıkça varılıyor; oysa brüt kâr marjı %70 olan bir sosyal medya şirketiyle %15–20 seviyesindeki otomotiv veya havacılık şirketlerini karşılaştırmak saflık olur
Bir sektörün daha fazla mühendis alabilmesi, daha fazla ödeme yapabilmesi, daha çok promosyon ürünü ve yan hak sağlayabilmesi doğaldır
Aynı şirket içinde bile bazı ürün grupları ve işlevler uzun vadeli yatırım alırken, bazı ürün grupları diğerlerinden daha yüksek marja sahiptir
Bütçeye bağlı olarak bir yazılım ürününe harcanabilecek para büyük ölçüde değişir
Mühendisler kendi işlerini düşünürken şirketin finansallarına da bakmalı
Şirket bir hayır kurumu ya da kilise değil; nakit akışı, gelir, uzun vadeli strateji ve ürün geliştirme maliyetlerini dengelemek zorunda olan bir işletmedir
Bu yazı da iyi, ama patio11’in yazısı da bunu maliyet merkezi ve kâr merkezi ayrımıyla iyi açıklıyor
Neden bir kâr merkezine yakın durmak gerektiğini ikna edici biçimde anlatıyor; okumadıysanız başka birçok iyi içerik de var
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
2 numaralı kuralım ise o kâr merkezi içinde sürdürülebilir kârlılıkla güvenilir biçimde bağlantılı bir rol üstlenmektir
Doğrudan para kazandırıyor olmam şart değil, ama çalışmayı bırakırsam paraya doğrudan etkisi olacağı açık olmalı
Biraz farklı bir konu ama Swizec’in birkaç yıl önce yazdığı Serverless Handbook’u çok faydalı bulmuştum ve uzun süredir onun düşünceli, içgörülü e-posta bültenini keyifle okuyorum
O, “yaparak öğrenme / herkese açık şekilde öğrenme” kampında sağlam bir yerde duruyor ve öğrenme sürecini paylaşma işini çok iyi yapıyor
Takip etmenizi veya abone olmanızı güçlü şekilde öneririm
Tarihsel olarak yazılım mühendisliği IT fonksiyonunun bir parçasıydı; IT de muhasebeden doğmuştu
Makineler yapmadan önce “computer” kelimenin tam anlamıyla birinin iş unvanıydı
Bugün bile birçok işletmede muhasebe hâlâ yazılımın ana itici gücü ve bütçenin kaynağıdır
Aslında dört bütçe kategorisi var
1 numara araştırma-geliştirmedir; genelde özel vergi işlemleri ve vergi kredileri uygulanır
2 numara satış/pazarlamadır; satış öncesi mühendisleri ve bazen uygulama işlerini kapsar
3 numara bakımdır; hataları düzelten ve genelde özel vergi işlemleri ya da kredilere tabi olmayan, araştırma-geliştirme dışı kod işleri yapan geliştiricilerdir
4 numara hosting hizmetleri, PaaS ve SaaS’taki operasyondur; genelde yazılım mühendisi maaşlarının bir kısmını içerir
Paranın hangi bütçeden çıktığını ve hangi işi yaptığınızı bilmenin vergi etkilerini anlamak çok önemlidir; ölçek büyüdükçe bu çok daha karmaşık hâle gelir
Kâr merkezi ve maliyet merkezi modelinin daha iyi olduğunu düşünüyorum
İdeal olarak tüm departmanlar hem gelirden hem maliyetten sorumlu olmalı
Ölçemiyorsanız bu KPI sorunudur
KPI’lar maliyet odaklı belirlenip yanlış hizalanabilir; ama bu, departmanın kendisini maliyet merkezi yapmaz
Ancak araştırma-geliştirme ayrımının eklenmesini beğendim
Bakım odaklı ekipler de bakım maliyetini düşürmek için araştırma-geliştirme yapmalı; tıpkı iyi bir satış ekibinin satış kârını artırmak için araştırma-geliştirme yapması gibi
Farklı içgörüler sağlar ve birbirini tamamlayabilir
Çalıştığım şirketlerin hiçbirinde growth engineering maaşları pazarlama bütçesinden çıkmıyordu
“Bakım bütçesi” diye ayrı bir şey de yoktu; hepsi basitçe araştırma-geliştirme/mühendislikti
Ekibe veya role göre beklentiler çok farklı olabilir, ama bu bir bütçe meselesi değil, şirketin hedefleri nasıl takip ettiğine bağlıdır
Ya şu anda para kazanıyorsunuz, ya uzun vadeli değer yaratıyorsunuz ya da mevcut üründe yavaş yavaş batıyorsunuz; üçünden biri