Yazılım projesi maliyeti nasıl hesaplanır? Bu soruya "ne kadar sürer, kaç kişi çalışır?" cevabı verilmeden sağlıklı bir rakam söylemek mümkün değildir. Yazılım bir raf ürünü değil; maliyeti kapsamın büyüklüğü, ekibin yapısı, teknik riskler ve seçilen fiyatlandırma modeli belirler. Bu yazıda maliyetin nasıl oluştuğunu, sabit fiyat ile time and material (zaman ve malzeme) modelleri arasındaki farkı ve bütçe planlarken sıkça unutulan kalemleri ele alıyoruz.
Yazılım maliyetinin temel formülü
Hangi fiyatlandırma modeli kullanılırsa kullanılsın, maliyetin temelinde aynı basit formül yatar:
Toplam maliyet = Tahmini efor (adam/gün) × Ekip günlük ücreti + Harici giderler + Risk payı
- Efor: Tasarım, geliştirme, test, proje yönetimi ve yayın için gereken toplam iş günü.
- Günlük ücret: Ekibin kıdemine ve rollerine göre değişir. Kıdemli bir mimar ile yeni başlayan bir geliştiricinin ücreti aynı değildir.
- Harici giderler: Sunucu, üçüncü parti servisler, lisanslar, mağaza hesapları.
- Risk payı: Belirsizlik yüksekse tahmine eklenen tampon.
Örneğin tamamen varsayımsal bir hesapla, 60 adam/günlük bir iş ve belirli bir günlük ücret üzerinden gelen rakama, sunucu giderleri ve yüzde 15 gibi bir risk payı eklenir. Gerçek rakamlar ekip, şehir ve döviz kuruna göre ciddi farklılık gösterir; bu yüzden internette gördüğünüz "ortalama fiyatlara" temkinli yaklaşın.
Maliyeti belirleyen başlıca etkenler
- Kapsam ve özellik sayısı: Her ekran, her iş kuralı ve her rol efor ekler.
- Platformlar: Sadece web mi, iOS ve Android de mi? Native mi, çapraz platform mu?
- Entegrasyonlar: Ödeme sistemleri, ERP, muhasebe, harita, SMS ve e-fatura entegrasyonları genellikle tahminlerin en riskli kısmıdır.
- Tasarım: Hazır bileşen kütüphanesi ile tamamen özgün bir tasarım dili arasında belirgin fark vardır.
- Güvenlik ve mevzuat: KVKK, finansal veriler veya sağlık verileri ek önlemler gerektirir.
- Ölçek ve performans: Aynı anda binlerce kullanıcıya hizmet verecek bir sistemin mimarisi farklı kurgulanır.
- Takvim baskısı: Süreyi kısaltmak için ekibi büyütmek, verimliliği doğrusal şekilde artırmaz.
Sabit fiyat vs time and material: hangisi, ne zaman?
Yazılım projesi maliyeti belirlenirken en sık kullanılan iki model sabit fiyat (fixed price) ve time and material (T&M) modelleridir. Aralarındaki fark, riskin kim tarafından taşındığıdır.
Sabit fiyat modeli
Kapsam baştan detaylı şekilde tanımlanır ve toplam bedel üzerinde anlaşılır. Bütçe öngörülebilirdir; ancak firma belirsizliğe karşı teklifine risk payı ekler ve kapsamdaki her değişiklik ayrı bir değişiklik talebi olarak fiyatlandırılır.
Time and material modeli
Ekibin harcadığı gerçek zaman üzerinden, genellikle aylık olarak faturalandırılır. Kapsam proje ilerledikçe şekillenebilir, öncelikler değiştirilebilir. Esneklik yüksektir, ancak toplam bütçeyi yönetmek için düzenli raporlama ve disiplinli önceliklendirme gerekir.
| Kriter | Sabit fiyat | Time and material |
|---|---|---|
| Bütçe öngörülebilirliği | Yüksek | Orta, sınır belirlenerek yönetilir |
| Kapsam esnekliği | Düşük, değişiklikler ek ücretli | Yüksek |
| Riskin sahibi | Ağırlıklı olarak yazılım firması | Paylaşımlı, ağırlıklı müşteri |
| Başlangıç hazırlığı | Detaylı analiz gerekir | Hızlı başlanabilir |
| Uygun olduğu projeler | Kapsamı net, küçük ve orta ölçekli işler | Gelişen ürünler, MVP sonrası büyüme, uzun soluklu işler |
Pratikte iki modelin karışımı da sık kullanılır: keşif ve analiz aşaması sabit fiyatla yapılır, geliştirme ise T&M ya da sabit fiyatlı küçük fazlarla ilerler. Uzun soluklu ihtiyaçlar için ise aylık bedelli bir outsource yazılım ekibi modeli daha öngörülebilir olabilir.
Hangi modeli seçerseniz seçin, sözleşmede kapsam değişikliklerinin nasıl ele alınacağının yazılı olması gerekir. Sabit fiyatta bu bir değişiklik talebi süreci, T&M modelinde ise bütçe tavanı ve düzenli raporlama anlamına gelir. Hangi modelde olursa olsun, düzenli demolar ve açık bir iş takip panosu, bütçenin nereye harcandığını görmenizi sağlar ve sürpriz faturaların önüne geçer.
Tahmin nasıl yapılır? Keşif aşaması ve iş kırılımı
Güvenilir bir maliyet tahmininin arkasında genellikle bir iş kırılım yapısı (work breakdown structure) bulunur. Proje önce modüllere, modüller ekranlara ve işlevlere, işlevler de tahmin edilebilir küçük görevlere bölünür. Her görev için tasarım, geliştirme ve test eforu ayrı ayrı düşünülür. Parçalar küçüldükçe tahmin de gerçekçileşir.
Belirsizliğin yüksek olduğu kalemler için tek bir rakam yerine aralık vermek daha dürüst bir yaklaşımdır. Örneğin daha önce belgelerini görmediğiniz bir ERP sistemiyle entegrasyon, "iyimser, beklenen, kötümser" şeklinde üç senaryo ile tahmin edilebilir. Bu aralık, teklifteki risk payının da gerekçesini oluşturur.
Kapsamın büyük kısmı henüz netleşmediyse, kısa ve ücretli bir keşif aşaması en mantıklı başlangıçtır. Bu aşamada kullanıcı akışları çıkarılır, kaba ekran taslakları hazırlanır, teknik riskler araştırılır ve sonunda çok daha güvenilir bir tahmin ortaya çıkar. Keşif çıktıları size ait olduğu için, isterseniz bu belgelerle farklı firmalardan da teklif alabilirsiniz.
Bütçede sıkça unutulan kalemler
- Bakım ve destek: İşletim sistemi ve kütüphane güncellemeleri, güvenlik yamaları.
- Altyapı giderleri: Sunucu, veritabanı, depolama ve CDN gibi aylık kalemler.
- Üçüncü parti servisler: Harita, SMS, e-posta, ödeme altyapısı ve yapay zekâ API kullanım ücretleri.
- Mağaza hesapları: Apple Developer Program yıllık üyeliği ve Google Play geliştirici hesabı.
- İçerik ve veri hazırlığı: Ürün görselleri, metinler, eski sistemden veri aktarımı.
- İç ekibinizin zamanı: Toplantılar, testler ve kabul süreçleri için ayırdığınız mesai.
Bu kalemlerin bir kısmı küçük görünse de yıllık toplamları göz ardı edilemeyecek seviyelere ulaşabilir. Özellikle yapay zekâ ve harita gibi kullanım bazlı ücretlendirilen servislerde, kullanıcı sayısı arttıkça maliyetin nasıl değişeceğini baştan modellemek iyi bir alışkanlıktır.
Daha doğru bir teklif almak için ne yapmalısınız?
- İş hedefini ve temel kullanıcı akışlarını yazılı hale getirin.
- Özellikleri "olmazsa olmaz" ve "sonra da olur" diye ikiye ayırın.
- Gerekli entegrasyonları ve mevcut sistemlerinizi listeleyin.
- Bütçe aralığınızı paylaşmaktan çekinmeyin; firma kapsamı buna göre önerebilir.
- Teklifte varsayımların ve hariç tutulan kalemlerin açıkça yazmasını isteyin.
Kapsamı belirsiz projelerde ücretli bir keşif aşaması, hem sizin hem firmanın daha gerçekçi bir tahmin yapmasını sağlar. Web ve mobil projelerde nasıl kapsam çıkardığımızı web yazılım geliştirme ve mobil uygulama geliştirme sayfalarımızda bulabilirsiniz.
BernSoftware olarak teklif hazırlarken kapsamı, varsayımları ve riskleri kalem kalem paylaşıyoruz. Projeniz için şeffaf bir maliyet tahmini almak isterseniz bizimle iletişime geçin.
Sıkça sorulan sorular
Basit bir mobil uygulamanın maliyeti ne kadardır?
Tek bir rakam vermek yanıltıcı olur. Birkaç ekrandan oluşan, entegrasyonu az bir uygulama ile ödeme, kullanıcı rolleri ve yönetim paneli içeren bir uygulama arasında kat kat fark olabilir. En sağlıklı yol, temel özellik listenizle birkaç firmadan kalem kalem teklif almaktır.
Sabit fiyatlı projede kapsam değişirse ne olur?
Genellikle değişiklik talebi (change request) süreci işler. Firma yeni isteğin süre ve maliyet etkisini hesaplar, siz onayladıktan sonra iş planına eklenir. Bu sürecin nasıl işleyeceğinin sözleşmede baştan tanımlanması önemlidir.
Time and material modelinde bütçeyi nasıl kontrol ederim?
Aylık ya da sprint bazlı bir bütçe tavanı belirleyin, harcanan saatlerin düzenli raporlanmasını isteyin ve her sprint başında öncelikleri gözden geçirin. Böylece esneklikten vazgeçmeden harcamayı görünür tutarsınız.
Yazılım projesinde bakım maliyeti ayrıca mı hesaplanır?
Çoğu zaman evet. Geliştirme bedeli ilk sürümü kapsar; yayın sonrası güncellemeler, güvenlik yamaları ve küçük iyileştirmeler genellikle aylık ya da yıllık bir bakım anlaşmasıyla ayrıca fiyatlandırılır.
Böyle bir proje mi planlıyorsun?
10 adımda planla