Yazılım Maliyeti ve Süresi Hakkında Sık Sorulan Sorular

Yazılım maliyeti hakkında sorulan ilk soru neredeyse her zaman aynıdır: "Böyle bir uygulama ne kadara mal olur?" Bu soru tamamen meşrudur, ancak tek bir sayıyla cevaplanamaz — tıpkı "bir ev ne kadara mal olur?" sorusu gibi. Bu yazıda, yazılım projelerinin maliyeti ve süresi hakkında en sık sorulan soruları, hem hizmet alan hem de hizmet veren tarafın işine yarayacak şekilde ele alıyoruz.

Neden net bir fiyat listesi yok?

Çünkü aynı görünen iki ekranın arkasındaki iş, on kat farklı olabilir. "Sipariş listesi" ifadesi, basit bir tabloyu da; rol bazlı görünürlük, çok para birimli tutarlar, iade akışı, muhasebe entegrasyonu ve denetim kaydı içeren bir yapıyı da tarif edebilir. Fiyatı belirleyen şey ekran sayısı değil, ekranların arkasındaki kurallardır.

Bu yüzden ciddi bir teklif, her zaman bir keşif aşamasının ardından gelir. Keşif yapmadan verilen sabit fiyat ya yüksek bir risk primi içerir ya da proje ortasında kapsam tartışmasına dönüşür.

Maliyeti asıl belirleyen faktörler

• Kapsam netliği. Belirsizlik, projelerin en pahalı kalemidir. "Sonra düşünürüz" denen her madde, ilerleyen aşamada birkaç katı maliyetle geri döner. Bu ilişkinin ayrıntıları için yazılım tahminleri yazımıza bakabilirsiniz.
• Entegrasyon sayısı. Her dış sistem bağımsız bir risk kaynağıdır: dokümantasyonu eksik olabilir, test ortamı vermeyebilir, beklenmedik kısıtları olabilir.
• Rol ve yetki karmaşıklığı. Tek tip kullanıcıya hizmet veren bir uygulama ile sekiz farklı rolün farklı verileri gördüğü bir uygulama arasında ciddi fark vardır; tasarım kararlarının etkisi için yetkilendirme modeli yazımıza bakın.
• Veri göçü. Eski sistemdeki verinin taşınması neredeyse her zaman hafife alınır. Gerçek veri her zaman beklenenden dağınıktır ve temizlenmesi ayrı bir iştir.
• Kalite beklentisi. İç kullanıma yönelik bir araçla, binlerce kullanıcıya açık ve kesintisiz çalışması gereken bir sistem arasındaki fark, test ve altyapı maliyetine yansır.

Sabit fiyat mı, zaman bazlı mı?

Her iki modelin de yeri vardır. Sabit fiyat, kapsam gerçekten net olduğunda ve değişme ihtimali düşük olduğunda uygundur; alıcı için öngörülebilirlik sağlar, ancak sağlayıcı riski fiyata yansıtır ve kapsam dışı taleplerde sürtünme yaratır. Zaman bazlı model, kapsamın evrileceği bilinen projelerde daha adildir, ancak alıcının bütçe kontrolünü kaybetmemesi için düzenli teslimat ve şeffaf raporlama gerektirir.

Pratikte en çok işe yarayan yaklaşım, ikisinin birleşimidir: önce sabit fiyatlı kısa bir keşif/analiz aşaması, ardından netleşen kapsam üzerinden fiyatlama.

Proje ne kadar sürer?

Süre, kişi sayısıyla doğrusal olarak kısalmaz. Bir işi iki geliştirici bir ayda yapıyorsa, dört geliştirici iki haftada yapamaz — koordinasyon, kod incelemesi ve entegrasyon maliyeti artar. Ayrıca çoğu projede süreyi belirleyen şey geliştirme değil, bekleme süreleridir: geri bildirim beklemek, dış sistemden erişim beklemek, içerik veya karar beklemek.

Bu yüzden gerçekçi bir takvim, yalnızca geliştirme günlerini değil, karar ve onay adımlarını da içermelidir.

Yayına aldıktan sonra maliyet biter mi?

Hayır ve bu, en sık gözden kaçan kalemdir. Yayın sonrası maliyetler şunları içerir: barındırma ve altyapı, güvenlik güncellemeleri ve sürüm yükseltmeleri, hata düzeltmeleri, küçük iyileştirmeler ve destek. Sürüm güncellemelerini ertelemenin maliyeti için sürüm yükseltme yazımız somut örnekler veriyor. Bakımı bütçelemeyen projeler, birkaç yıl içinde güncellenemez hâle gelir ve yeniden yazım maliyetiyle karşılaşır.

Hazır paket mi, özel yazılım mı?

Kural olarak: süreciniz sektörde standartsa hazır paket neredeyse her zaman daha ucuz ve hızlıdır. Özel yazılım, süreciniz sizi rakiplerinizden ayıran bir şeyse veya hazır çözümlerin dayattığı iş akışı ciddi verim kaybı yaratıyorsa anlamlıdır. Karşılaştırmanın ayrıntıları için ERP seçimi yazımıza bakabilirsiniz.

Teklifleri karşılaştırırken nelere bakmalı?

Sadece toplam rakama bakmak yanıltıcıdır. Sorulması gereken sorular: Kapsama tam olarak neler dahil (test, veri göçü, eğitim, dokümantasyon)? Kaynak kodun sahibi kim olacak? Yayın sonrası destek nasıl fiyatlanıyor? Kapsam değişikliği süreci nasıl işliyor? Teslimat parçalar hâlinde mi yapılacak, yoksa her şey sonda mı görülecek?

Son soru özellikle önemlidir: aşamalı teslimat yapan bir yaklaşım, hem riski düşürür hem de yanlış gidişin erken fark edilmesini sağlar. Projelerin başarısızlık sebepleri için proje başarısızlığı yazımız okunabilir. Süreçlerin genel akışını görmek için ise geliştirme süreci yazımıza bakabilirsiniz. Yazılım geliştirme pratikleri üzerine kapsamlı bir kaynak olarak martinfowler.com önerilebilir.

Sonuç

Yazılım maliyeti sorusunun tek bir cevabı olmamasının sebebi, sorunun eksik olmasıdır: maliyet, kapsamın netliğine, entegrasyonlara, yetki karmaşıklığına, veri göçüne ve kalite beklentisine bağlıdır. Daha faydalı soru şudur: "Bu bütçeyle hangi kapsamı gerçekçi biçimde alabilirim ve ilk çalışan sürümü ne zaman görebilirim?" Bu biçimde sorulan bir soru, hem daha dürüst bir teklif hem de daha az sürprizli bir proje üretir. Bir teklif değerlendirirken de en ayırt edici ölçüt genellikle rakam değil, karşı tarafın kapsam ve belirsizlik hakkında ne kadar açık konuştuğudur.