Yazılım ekibi maliyeti, kişi başı maaşların toplamı değil; her rolün kıdemine göre tam yüklü maliyeti ile projede çalışacağı adam/ay miktarının çarpımı ve buna eklenen yönetim, araç ve risk paylarıdır. Doğru hesap için önce kapsam rollere, roller kıdemlere, kıdemler de zamana çevrilir; ardından iç kadro ile dış kaynak aynı formülle karşılaştırılır. Bu rehberde belirli bir maaş veya fiyat vermiyoruz; çünkü ücretler şehir, teknoloji, kıdem, piyasa koşulları ve döviz kuru gibi etkenlere göre hızla değişir ve genelleştirilmiş rakamlar yanıltıcı olur. Bunun yerine, kendi rakamlarınızı yerleştirebileceğiniz bir yöntem, kontrol edilmesi gereken maliyet kalemleri ve örnek tablo yapıları sunuyoruz. Tablolardaki [köşeli parantez] içindeki ifadeler, sizin kendi verilerinizle dolduracağınız yer tutuculardır.

Neden “kişi başı maaş” yeterli değildir?
Bir geliştiricinin şirkete maliyeti, bordrodaki brüt ücretin oldukça üzerindedir. İşveren primleri, yan haklar, ekipman, lisanslar, ofis, eğitim, işe alım masrafları ve yönetim zamanı eklendiğinde ortaya tam yüklü maliyet (fully loaded cost) çıkar. Üstelik bu maliyet, kişinin yılın tamamında verimli çalıştığı varsayımıyla hesaplanırsa yine eksik kalır: izinler, resmi tatiller, eğitimler, toplantılar ve işe alıştırma dönemi verimli kapasiteyi azaltır.
Dış kaynak tekliflerini kendi kadronuzla karşılaştırırken yapılan en yaygın hata, tedarikçinin adam/ay fiyatını iç kadronun brüt maaşıyla kıyaslamaktır. Doğru karşılaştırma, iki tarafın da tam yüklü ve verimli kapasite üzerinden hesaplanmasıyla yapılır. Bu karşılaştırmanın genel çerçevesi için outsourcing mi, işe alım mı rehberimize de bakabilirsiniz.
Temel kavramlar
| Kavram | Tanım | Hesapta nasıl kullanılır? |
|---|---|---|
| Adam/ay | Bir kişinin bir ay boyunca tam zamanlı çalışması | Efor ve bütçenin ortak birimi |
| Adam/gün, adam/saat | Daha küçük efor birimleri | Kısa işler ve saatlik fiyatlamada kullanılır |
| Verimli kapasite | Toplantı, izin, tatil, destek işleri düşüldükten sonra üretime ayrılan zaman | Efor tahminini takvim süresine çevirirken kullanılır |
| Tam yüklü maliyet | Brüt ücret + işveren yükleri + yan haklar + ekipman + diğer giderler | İç kadronun gerçek maliyeti |
| Kullanım oranı (utilization) | Ödenen zamanın ne kadarının projeye harcandığı | Boşta kalma maliyetini görünür kılar |
| Risk payı (buffer) | Tahmin belirsizliğine karşı eklenen ek efor | Kapsam belirsizliği arttıkça yükselir |
Adım 1: Kapsamı rollere çevirin
Maliyet hesabı “kaç geliştirici?” sorusuyla değil, “hangi işler yapılacak?” sorusuyla başlar. Örneğin bir mobil uygulama ve onu besleyen bir yönetim paneli için mobil, backend, frontend, test ve tasarım işleri ayrı ayrı listelenir. Ardından her iş grubu bir role eşlenir.
| Rol | Ne zaman gerekir? | Maliyete etkisi |
|---|---|---|
| Ürün sahibi / analist | Gereksinimler sık değişiyorsa, paydaş sayısı fazlaysa | Genellikle kısmi zamanlı; eksikliği yeniden iş maliyeti doğurur |
| Takım lideri / teknik lider | İkiden fazla geliştirici varsa, mimari kararlar kritikse | Doğrudan maliyeti yüksek, dolaylı tasarrufu büyüktür |
| Backend geliştirici | API, iş kuralları, entegrasyonlar | Çoğu projede ana efor kalemi |
| Frontend / mobil geliştirici | Web arayüzü, iOS, Android veya çapraz platform | Platform sayısı eforu doğrudan etkiler |
| Test / QA uzmanı | Canlıya çıkışın sık ve hatasız olması gerekiyorsa | Eksikliği hataların canlıda bulunmasına yol açar |
| UI/UX tasarımcı | Kullanıcı deneyimi ürünün başarısını belirliyorsa | Proje başında yoğun, sonra kısmi |
| DevOps / bulut uzmanı | CI/CD, altyapı otomasyonu, ölçeklenme gerekiyorsa | Kısmi zamanlı veya paylaşımlı olabilir |
Rol listesini hızlıca oluşturmak ve farklı kompozisyonları denemek için ekip oluşturucu aracımızı kullanabilirsiniz.
Adım 2: Kıdem karışımını belirleyin
Aynı rol, farklı kıdem seviyelerinde çok farklı maliyet ve verimlilik anlamına gelir. Junior geliştiricilerden oluşan bir ekip kâğıt üzerinde ucuz görünür, ancak mimari hatalar, uzun kod inceleme döngüleri ve yeniden yazımlar toplam maliyeti artırabilir. Tersine, kıdemlilerden oluşan bir ekip rutin işlerde gereğinden pahalıdır.
| Kıdem | Tipik sorumluluk | Planlamada dikkat |
|---|---|---|
| Junior | Tanımlı, küçük görevler; gözetimle çalışır | Mentorluk zamanı kıdemlilerin kapasitesinden düşülmelidir |
| Mid | Bağımsız olarak özellik geliştirir | Ekibin üretim gücünün çoğunu oluşturur |
| Senior | Karmaşık işler, kod inceleme, teknik kararlar | Kritik yollarda darboğazı önler |
| Lead / mimar | Mimari, standartlar, ekip koordinasyonu | Üretim kapasitesinin bir kısmı yönetime gider |
Adım 3: Eforu adam/aya çevirin
Efor tahmini için iş kalemleri (epic, özellik veya kullanıcı hikayesi) her rol için ayrı tahmin edilir. Tahminler genellikle adam/gün cinsinden yapılır, sonra adam/aya çevrilir. Burada iki düzeltme kritik önemdedir: verimli kapasite ve risk payı.
- Toplam efor (adam/ay) = Rol bazında tahmin edilen iş günleri toplamı ÷ [bir aydaki verimli iş günü sayısı]
- Riskli efor = Toplam efor × (1 + [risk payı oranı])
- Takvim süresi (ay) = Riskli efor ÷ (o roldeki kişi sayısı)
- Rol maliyeti = Riskli efor × [o rol ve kıdem için aylık birim maliyet]
Risk payı, kapsamın netliğine göre belirlenir: detaylı analizi yapılmış bir kapsamda düşük, keşif aşamasındaki bir üründe daha yüksek tutulur. Risk payının sıfır olduğu bir plan, gerçekçi değil iyimser bir plandır.
Adım 4: İç kadronun tam yüklü maliyetini çıkarın
Kendi kadronuzla karşılaştırma yapacaksanız, aşağıdaki kalemlerin her biri için şirketinizin gerçek verilerini kullanın. Bu kalemlerin bir kısmı muhasebe kayıtlarında, bir kısmı (ör. yönetim zamanı, boşta kalma) ise tahmin olarak yer alır.
| Maliyet kalemi | Açıklama | Değer |
|---|---|---|
| Brüt ücret | Rol ve kıdem bazında | [brüt ücret] |
| İşveren yükleri | Sosyal güvenlik işveren payı ve ilgili yasal yükler | [işveren yükü] |
| Yan haklar | Yemek, ulaşım, sağlık sigortası, prim ve benzerleri | [yan haklar] |
| Ekipman ve lisanslar | Bilgisayar, yazılım lisansları, geliştirme araçları, bulut test ortamları | [ekipman + lisans] |
| Ofis ve altyapı payı | Ofis alanı, internet, ortak giderler | [ofis payı] |
| İşe alım maliyeti | İlan, aday arama, mülakat süresi, varsa işe alım danışmanlığı bedeli; çalışma süresine yayılır | [işe alım ÷ beklenen çalışma ayı] |
| Eğitim ve oryantasyon | İşe alıştırma döneminde düşük verimlilik dahil | [eğitim] |
| Yönetim zamanı | Yöneticinin bu kişiye ayırdığı süre | [yönetim payı] |
| Boşta kalma ve ayrılma riski | Proje arası boşluklar, ayrılan kişinin yerine yeni kişi bulma süresi | [risk payı] |
Aylık tam yüklü maliyet = Bu kalemlerin aylık toplamı. Verimli adam/ay maliyeti ise bu toplamın, kişinin aylık verimli kapasite oranına bölünmesiyle bulunur.
Adım 5: Dış kaynak teklifini aynı formülle okuyun
Dış kaynak tekliflerinde adam/ay fiyatı genellikle ücret, işveren yükleri, ekipman, işe alım, yedekleme ve tedarikçinin hizmet bedelini içerir. Teklifi karşılaştırırken neyin dahil olup neyin olmadığını netleştirin:
- Takım liderliği veya proje yönetimi ayrı mı fiyatlanıyor?
- Test, DevOps ve tasarım gibi destek roller dahil mi?
- Yerinde çalışma, seyahat ve mesai dışı destek nasıl ücretlendiriliyor?
- İzin ve tatil günlerinde yedek kişi sağlanıyor mu, yoksa o günler faturadan mı düşülüyor?
- Oryantasyon dönemi faturalanıyor mu?
- Fiyat hangi para biriminde ve hangi güncelleme koşuluyla belirleniyor?
Rol ve kıdem bazında iç kadro ile dış kaynak karşılaştırmasının nasıl kurgulandığını geliştirici kiralama maliyet karşılaştırması bölümümüzde görebilirsiniz.
Örnek ekip maliyet tablosu (yer tutucularla)
Temsili senaryodur. Aşağıdaki yapı, bir mobil uygulama ve yönetim paneli projesi için 6 aylık bir ekip planının nasıl tablolaştırılacağını gösterir. Birim maliyetler bilinçli olarak yer tutucu bırakılmıştır; kendi iç maliyetlerinizi veya aldığınız teklifleri yerleştirmeniz gerekir.
| Rol | Kıdem | Kişi | Süre (ay) | Doluluk | Adam/ay | Aylık birim maliyet | Toplam |
|---|---|---|---|---|---|---|---|
| Teknik lider | Lead | 1 | 6 | %50 | 3 | [B1] | 3 × [B1] |
| Backend geliştirici | Senior | 1 | 6 | %100 | 6 | [B2] | 6 × [B2] |
| Backend geliştirici | Mid | 1 | 5 | %100 | 5 | [B3] | 5 × [B3] |
| Mobil geliştirici | Mid | 2 | 5 | %100 | 10 | [B4] | 10 × [B4] |
| Test / QA uzmanı | Mid | 1 | 5 | %100 | 5 | [B5] | 5 × [B5] |
| UI/UX tasarımcı | Mid | 1 | 6 | %40 | 2,4 | [B6] | 2,4 × [B6] |
| DevOps uzmanı | Senior | 1 | 6 | %25 | 1,5 | [B7] | 1,5 × [B7] |
| Ara toplam | 32,9 | Σ satırlar | |||||
| Risk payı | [%R] | Ara toplam × [%R] | |||||
| Araç, lisans, bulut test ortamı | [araç bütçesi] | ||||||
| Genel toplam | Ara toplam + risk + araç |
Tablodaki doluluk oranları da örnektir: teknik liderin zamanının yarısını bu projeye ayırdığı, tasarımcının proje başında yoğun sonra kısmi çalıştığı, DevOps uzmanının ise paylaşımlı olduğu varsayılmıştır. Kendi planınızda bu oranları ekip yapınıza göre güncelleyin.
Fiyatlama modelleri ve ekip maliyetine etkisi
| Model | Nasıl hesaplanır? | Avantaj | Risk |
|---|---|---|---|
| Adam/ay | Kişi sayısı × ay × [aylık birim fiyat] | Basit, öngörülebilir, esnek | Verimlilik riski müşteride |
| Saatlik | Gerçekleşen saat × [saatlik fiyat] | Değişken işlerde adil | Bütçe tavanı yoksa sapma |
| Sabit fiyat | Kapsam × tahmin × tedarikçi risk payı | Bütçe kesinliği | Değişiklikler ek bedel; risk payı fiyata gömülü |
| Sonuç bazlı | Taban bedel + ölçülebilir sonuca bağlı pay | Hedef uyumu | Sonucun ölçümü ve tanımı zor olabilir |

Maliyeti artıran ve azaltan faktörler
| Faktör | Maliyeti artırır | Maliyeti azaltır |
|---|---|---|
| Kapsam netliği | Belirsiz gereksinimler, sık değişiklik | Detaylı analiz, önceliklendirilmiş backlog |
| Teknoloji | Nadir teknolojiler, çok sayıda platform | Yaygın, olgun teknolojiler; çapraz platform uygun ise |
| Entegrasyonlar | Dokümantasyonu zayıf üçüncü taraf sistemler | Standart API’ler, hazır bağlayıcılar |
| Kalite ve güvenlik gereksinimleri | Regülasyon, sızma testi, yüksek erişilebilirlik | İhtiyaca uygun, abartılmamış gereksinimler |
| Ekip sürekliliği | Sık kişi değişimi, bilgi kaybı | Uzun süreli, istikrarlı ekip |
| Karar hızı | Geç onaylar, bekleyen ekip | Yetkili ve erişilebilir ürün sahibi |
Sık yapılan hesaplama hataları
- Takvim süresini eforla karıştırmak: 12 adam/aylık iş, 12 kişiyle bir ayda bitmez; iletişim ve bağımlılıklar nedeniyle kişi eklemek süreyi doğrusal kısaltmaz.
- Test ve proje yönetimini unutmak: geliştirici eforunu hesaplamak bütçeyi sistematik olarak düşük gösterir.
- Risk payı koymamak: Her tahmin belirsizlik içerir; bunu görünür kılmak bütçe güvenilirliğini artırır.
- Canlı sonrası maliyeti atlamak: Bakım, izleme, hata düzeltme ve küçük geliştirmeler için ayrı bir kapasite planlanmalıdır.
- İç kadroyu brüt maaşla, dış kaynağı tam fiyatla kıyaslamak: Karşılaştırma ancak iki taraf da tam yüklü maliyetle hesaplandığında anlamlıdır.
Proje türüne göre ekip kompozisyonu
Ekip kompozisyonu proje türüne göre değişir. Aşağıdaki tablo kişi sayısı değil, hangi rollerin genellikle ağırlıklı, hangilerinin kısmi zamanlı olduğunu gösterir; kendi planınızda bu yapıyı başlangıç noktası olarak kullanabilirsiniz.
| Proje türü | Ağırlıklı roller | Genellikle kısmi zamanlı roller |
|---|---|---|
| Mobil uygulama + yönetim paneli | Mobil, backend, test | Tasarım, DevOps, teknik lider |
| Kurumsal entegrasyon (ERP, CRM, ödeme) | Backend, analist | Test, DevOps |
| SaaS ürün geliştirme | Backend, frontend, test | Ürün sahibi, tasarım, DevOps |
| Sistemin bakımı ve modernizasyonu | Backend veya ilgili teknoloji uzmanı | Test, mimar |
| Veri ve raporlama projesi | Veri mühendisi, analist | Backend, DevOps |
Bütçeyi proje boyunca nasıl takip edersiniz?
Maliyet hesabı bir kez yapılıp kenara konacak bir belge değildir. Proje ilerledikçe gerçekleşen efor, plana göre düzenli olarak karşılaştırılmalı ve sapmaların nedeni erken tespit edilmelidir. Aşağıdaki göstergeler bu takibi kolaylaştırır.
| Gösterge | Ne gösterir? | Ne sıklıkla? |
|---|---|---|
| Planlanan / gerçekleşen adam/ay | Efor sapması | Aylık |
| Tamamlanan kapsam oranı | Harcanan eforun karşılığında ne üretildiği | Sprint sonunda |
| Kapsam değişikliği hacmi | Sapmanın kapsamdan mı tahminden mi kaynaklandığı | Aylık |
| Kullanım oranı | Ödenen kapasitenin ne kadarının projeye gittiği | Aylık |
| Kalan risk payı | Belirsizliğe karşı ne kadar tampon kaldığı | Aylık |
Ekip büyüdükçe koordinasyon maliyeti de artar. Birden fazla ekibin aynı ürün üzerinde çalıştığı yapılarda iletişim, entegrasyon ve ortak platform işleri planlanmalıdır; bu konudaki yaklaşımımızı büyük ölçekli yazılım ekibi sayfamızda anlattık.
Ekip maliyeti hesaplama kontrol listesi
- ☐ Kapsam iş kalemlerine ayrıldı ve her kalem bir role eşlendi
- ☐ Her rol için kıdem seviyesi ve doluluk oranı belirlendi
- ☐ Efor, verimli kapasite dikkate alınarak adam/aya çevrildi
- ☐ Kapsam netliğine uygun bir risk payı eklendi
- ☐ İç kadro için tüm tam yüklü maliyet kalemleri hesaplandı
- ☐ Dış kaynak teklifinde dahil olan ve olmayan kalemler netleştirildi
- ☐ Araç, lisans ve test ortamı bütçesi eklendi
- ☐ Canlı sonrası bakım ve destek kapasitesi planlandı
- ☐ Bütçe takibi için göstergeler ve gözden geçirme sıklığı belirlendi
Sık sorulan sorular
Yazılım ekibi maliyeti nasıl hesaplanır?
Kapsam önce rollere, roller kıdem seviyelerine ayrılır. Her rol için gereken efor adam/ay olarak tahmin edilir, risk payı eklenir ve rolün aylık tam yüklü birim maliyetiyle çarpılır. Araç, lisans ve yönetim giderleri eklenerek toplam bulunur.
Adam/ay nedir?
Adam/ay, bir kişinin bir ay boyunca tam zamanlı çalışmasını ifade eden efor birimidir. Hem iş miktarını hem de bütçeyi ortak bir birimle ifade etmeyi sağlar; ancak takvim süresiyle aynı şey değildir.
Tam yüklü maliyet neleri kapsar?
Brüt ücretin yanında işveren yükleri, yan haklar, ekipman ve lisanslar, ofis payı, işe alım ve eğitim maliyetleri, yönetim zamanı ve boşta kalma ile ayrılma risklerini kapsar.
Neden bu rehberde maaş veya fiyat rakamı yok?
Ücretler şehir, teknoloji, kıdem, piyasa koşulları ve kur gibi etkenlere göre hızla değişir. Genelleştirilmiş rakamlar yanıltıcı olacağından, kendi verilerinizi yerleştirebileceğiniz bir yöntem ve tablo yapısı sunuyoruz.
Risk payı ne kadar olmalı?
Tek bir doğru oran yoktur. Kapsamı detaylı analiz edilmiş projelerde daha düşük, keşif aşamasındaki ürünlerde daha yüksek bir pay kullanılır. Önemli olan risk payının görünür ve gerekçeli olmasıdır.
Kişi sayısını artırmak projeyi orantılı olarak hızlandırır mı?
Hayır. Kişi sayısı arttıkça iletişim ve koordinasyon yükü de artar; bağımlı işler paralel yürütülemez. Belirli bir noktadan sonra kişi eklemek süreyi kısaltmak yerine uzatabilir.
İç kadro ile dış kaynak nasıl adil karşılaştırılır?
İki taraf da tam yüklü maliyet ve verimli kapasite üzerinden hesaplanmalıdır. Dış kaynak teklifinde nelerin dahil olduğu (yedekleme, liderlik, test, ekipman) netleştirilmeli, iç kadroda ise işe alım, boşta kalma ve ayrılma riskleri hesaba katılmalıdır.
Test ve proje yönetimi maliyete dahil edilmeli mi?
Evet. Geliştirici eforunu hesaplamak bütçeyi sistematik olarak düşük gösterir. Test, proje yönetimi, tasarım ve DevOps gibi destek roller, doluluk oranlarıyla birlikte plana eklenmelidir.
Canlıya çıktıktan sonra ekip maliyeti nasıl planlanır?
Canlı sonrası dönem için bakım, izleme, hata düzeltme ve küçük geliştirmeleri kapsayan daha küçük bir çekirdek ekip veya kısmi doluluklu roller planlanır. Bu kapasite, ilk geliştirme bütçesinden ayrı ele alınmalıdır.
Ekip planınızı birlikte çıkaralım
Kapsamınızı rol, kıdem ve adam/ay bazında bir ekip planına dönüştürmek ve farklı modellerin toplam maliyetini karşılaştırmak için bize ulaşabilirsiniz. Model farkları için staff augmentation rehberimize göz atabilir; 360 Soft ekibine +90 850 335 10 87, info@360-soft.com veya iletişim sayfamız üzerinden ulaşabilirsiniz.