Yazılım projesi maliyeti nasıl hesaplanır?

"Bu uygulama kaça çıkar?" sorusu, bize gelen ilk sorulardan biri. Sorunun hızlı bir cevabı yok, çünkü aynı cümleyle tarif edilen iki proje arasında birkaç katlık iş farkı olabilir. "Randevu alınan bir mobil uygulama" bir kişi için tek ekranlı bir form, bir başkası için ödeme, bildirim, çoklu şube ve personel takvimi demektir.

Bu yazıda bir yazılım teklifinin arkasındaki hesabı açıyoruz: hangi kalemlerden oluştuğunu, hangi etkenlerin süreyi uzattığını ve teklifleri nasıl karşılaştırabileceğinizi anlatıyoruz. Amacımız, elinizdeki teklifi kalem kalem okuyabilmeniz ve bütçenizi gerçekçi kurabilmeniz.

Yazılım maliyeti hangi kalemlerden oluşur?

Teklifte tek bir toplam rakam görseniz de arkasında birkaç ayrı iş kalemi vardır. Bunları bilmek, eksik kalan kısmı fark etmenizi sağlar.

• Keşif ve analiz: İhtiyaçların toplanması, kullanıcı akışlarının çıkarılması, kapsamın yazıya dökülmesi.
• Arayüz ve deneyim tasarımı: Ekranların taslağı, tasarım sistemi, prototip.
• Geliştirme: Ön yüz, arka uç (sunucu tarafı), veritabanı, yönetim paneli.
• Entegrasyonlar: Ödeme, e-Fatura/e-Arşiv, SMS, harita, muhasebe ya da ERP bağlantıları.
• Test ve kalite güvencesi: Fonksiyon testleri, farklı cihaz ve tarayıcı denemeleri, yük testleri.
• Proje yönetimi: Planlama, toplantılar, raporlama, kabul süreçleri.
• Yayına alma: Sunucu kurulumu, alan adı, mağaza yayını, izleme araçları.
• Bakım ve destek: Yayın sonrası hata düzeltme, güvenlik güncellemeleri, küçük geliştirmeler.

Bu kalemlerin bazıları tek seferliktir, bazıları ise her ay ya da her yıl tekrarlanır. Bütçeyi kurarken ikisini ayrı tutmak gerekir.

Kişi-gün hesabı nasıl yapılır?

Kişi-gün, bir kişinin bir iş gününde yapabileceği iş miktarını ifade eden birim demektir. Yazılım tekliflerinin büyük çoğunluğu, açıkça yazılmasa da bu birim üzerinden hesaplanır.

Temel formül şöyledir:

Toplam maliyet = (Toplam kişi-gün × Günlük oran) × (1 + Risk payı) + Üçüncü taraf giderler

Burada her değişkenin anlamı:

• Toplam kişi-gün: Her iş kalemi için tahmin edilen sürelerin toplamı. Tasarımcı, geliştirici, testçi ve proje yöneticisinin süreleri ayrı ayrı tahmin edilir.
• Günlük oran: Ekibin bir kişi-gün için aldığı ücret. Kıdeme ve role göre değişebilir.
• Risk payı: Belirsizliği karşılamak için eklenen oran. Kapsam ne kadar netse bu pay o kadar küçük tutulabilir.
• Üçüncü taraf giderler: Sunucu, lisanslar, SMS paketleri, harita servisleri, mağaza hesap ücretleri gibi kalemler.

Örnek hesap

Aşağıdaki örnek yalnızca yöntemi göstermek içindir; rakamlar gerçek bir projeye ait değildir.

Bir proje için tasarımda 15, geliştirmede 80, testte 20 ve proje yönetiminde 15 kişi-gün tahmin edildiğini düşünelim. Toplam 130 kişi-gün eder. Günlük oranı O, risk payını R olarak alırsak geliştirme bedeli 130 × O × (1 + R) olur. Buna aylık sunucu ve servis giderleri (S) ile yıllık bakım bedeli ayrıca eklenir.

Bu yöntemin faydası şeffaflıktır. Teklifteki toplamı kalemlere böldüğünüzde, hangi işin neden pahalı olduğunu konuşabilir ve gerekirse kapsamı daraltabilirsiniz.

Maliyeti en çok hangi etkenler artırır?

Aynı ekip, aynı günlük oranla çalışsa bile iki projenin süresi çok farklı çıkabilir. Süreyi uzatan etkenleri bilmek, kapsam konuşmasını kolaylaştırır.

Bu tabloda gözden kaçan genellikle entegrasyonlardır. Bir bankanın sanal POS servisi ya da bir muhasebe programının API'si, belgesi eksikse ya da test ortamı yavaş çalışıyorsa planlanan süreyi kolayca aşabilir.

Sabit fiyat mı, zaman ve malzeme mi?

Yazılım projelerinde iki temel fiyatlama modeli kullanılır. Hangisinin uygun olduğu, kapsamın ne kadar net olduğuna bağlıdır.

Sabit fiyat modelinde kapsam baştan yazılır ve toplam bedel bu kapsama göre belirlenir. Bütçeyi önceden bilmek isteyenler için rahattır. Buna karşılık kapsam dışı her istek ayrı bir değişiklik talebi olarak fiyatlanır ve firma belirsizliği karşılamak için risk payını yüksek tutar.

Zaman ve malzeme modelinde harcanan kişi-gün kadar ödeme yapılır. Kapsamın çalışırken netleşeceği, öncelikleri sık değişen projelerde daha esnektir. Bu modelde düzenli raporlama ve sprint sonu demoları önemlidir; aksi halde bütçe kontrolü zorlaşır.

Pratikte sık kullanılan bir yol, ikisini birleştirmektir: keşif aşaması sabit fiyatla yapılır, ardından netleşen kapsam için ya sabit fiyat ya da aylık ekip modeli seçilir.

Teklifleri nasıl karşılaştırmalı?

Farklı firmalardan gelen teklifleri yalnızca toplam rakama bakarak karşılaştırmak yanıltıcıdır. Düşük görünen teklif, test, proje yönetimi ya da yayın sonrası destek gibi kalemleri içermiyor olabilir.

Karşılaştırma için şu soruları sorun:

• Teklif hangi kapsamı içeriyor, kapsam yazılı mı?
• Kaç kişi-gün öngörülmüş ve hangi rollere dağılmış?
• Test süreci ve kabul kriterleri tanımlanmış mı?
• Kaynak kodun ve tasarım dosyalarının sahipliği kimde olacak?
• Sunucu, lisans ve servis ücretleri dahil mi, ayrı mı?
• Yayın sonrası garanti süresi ve bakım koşulları neler?
• Değişiklik talepleri nasıl fiyatlanacak?

Bu soruları daha ayrıntılı ele aldığımız yazılım firması seçerken sorulacak sorular yazımıza da göz atabilirsiniz.

Bütçeyi düşürmenin sağlıklı yolları nelerdir?

Bütçe sınırlıysa ilk akla gelen günlük oranı düşük bir ekip aramaktır. Oysa çoğu zaman daha etkili yol, ilk sürümün kapsamını daraltmaktır.

• İlk sürümü küçültün: Ürünün asıl değerini gösteren en dar özellik setiyle başlayın. Bu yaklaşımı MVP nedir? Fikirden ilk sürüme yol haritası yazımızda anlattık.
• Hazır servisleri kullanın: Kimlik doğrulama, ödeme, e-posta gönderimi gibi işleri sıfırdan yazmak yerine olgun servislerle çözün.
• Tek platformla başlayın: Kullanıcılarınızın çoğu hangi platformdaysa önce oraya odaklanın.
• Kararları erken verin: Geliştirme ortasında değişen tasarım ya da iş kuralı en pahalı değişikliktir.

Kalite güvencesinden ve testten kısarak bütçe düşürmek ise genellikle tersine döner. Yayın sonrası çıkan hatalar hem kullanıcı kaybettirir hem de geliştirme sırasında düzeltilmesinden daha fazla iş çıkarır.

Yayın sonrası maliyetleri unutmayın

Yazılımın maliyeti yayın günüyle bitmez. Sunucu, alan adı, SSL sertifikası, üçüncü taraf servis abonelikleri, uygulama mağazası hesapları ve yedekleme her ay ya da her yıl tekrarlanan giderlerdir.

Bunlara ek olarak işletim sistemi ve tarayıcı güncellemeleri, kütüphanelerdeki güvenlik açıkları ve kullanıcıdan gelen geri bildirimler düzenli bir bakım işi doğurur. Bu nedenle bütçeyi kurarken geliştirme bedelinin yanında yıllık bir bakım kalemi ayırmak gerekir. Bakım sözleşmesinin içeriğini yazılım bakım ve destek sözleşmesi yazımızda ayrıntılı ele alıyoruz.

Kendi ürünlerimizde de, örneğin Assisto Signage ve AssistoOne gibi yayındaki SaaS ürünlerinde, geliştirme kadar sürekli bakımın da planın bir parçası olduğunu görüyoruz.

Projeniz için kapsamı netleştirmek ve gerçekçi bir bütçe çıkarmak istiyorsanız yazılım danışmanlığı hizmetimiz bu keşif aşamasını kapsıyor. Ön görüşme için iletişim sayfamızdan bize yazabilirsiniz.