Özel Yazılım Maliyeti Neye Göre Belirlenir?

Özel yazılım fiyatları, ekran sayısından çok, yazılımın ne kadar kural, veri ve bağlantı içerdiğine göre belirlenir. Aynı görünen iki uygulamadan biri birkaç haftada, diğeri aylar içinde tamamlanabilir. Bu yazıda bir fiyat listesi vermiyoruz, çünkü kapsamı bilinmeyen bir yazılım için verilen rakam yanıltıcı olur. Bunun yerine teklifleri doğru okumanızı sağlayacak etkenleri anlatıyoruz.

Özel yazılım fiyatını belirleyen 8 etken

1. Kapsam: özellik sayısı ve derinliği

En büyük etken budur. "Müşteri kaydı" tek satırlık bir özellik gibi görünür. Ama müşterinin birden fazla adresi, yetkilisi, cihazı ve geçmiş kaydı olacaksa; arama, filtreleme ve dışa aktarma da isteniyorsa, aynı özellik birkaç katına çıkar. Teklif istemeden önce her özelliği "kim, neyi, hangi adımlarla yapıyor?" sorusuyla yazıya dökmek, en çok tasarruf sağlayan adımdır.

2. İş kuralları ve istisnalar

Yazılımdaki asıl emek, kuralların ve istisnaların kodlanmasıdır. "Teklif 10 günde onaylanmazsa hatırlatma gitsin", "belirli müşteri grubuna farklı fiyat uygulansın", "üretime geçen sipariş artık değiştirilemesin" gibi kurallar ekranda görünmez; ama her biri geliştirme ve test ister. Kullanıcının gördüğü ekranla arkadaki kurallar arasındaki farkı Frontend ve Backend Nedir? yazımızda anlattık.

3. Entegrasyonlar

Yazılımın başka sistemlerle konuşması gerekiyorsa (muhasebe programı, e-fatura, SMS, WhatsApp, ödeme, kargo, makine verisi), her bağlantı ayrı bir iş kalemidir. Maliyeti etkileyen şeyler:

• Karşı sistemin belgelenmiş bir API'si olup olmadığı,
• Test ortamı sunup sunmadığı,
• Hata durumlarında (bağlantı kopması, eksik veri) ne olacağının tasarlanması.

İyi belgelenmiş bir API ile çalışmak, belgesi olmayan eski bir sistemle veri alışverişinden genellikle çok daha öngörülebilirdir.

4. Kullanıcı rolleri ve yetkiler

Tek tip kullanıcı olan bir yazılım ile "yönetici, satış, saha personeli, muhasebe, müşteri" gibi farklı rollerin farklı ekranlar ve izinler gördüğü bir yazılım aynı değildir. Her rol; görünüm, yetki kontrolü ve test senaryosu ekler.

5. Platformlar

Yalnız web tarayıcısından çalışan bir panel mi, yoksa ayrıca iOS ve Android uygulaması da mı gerekiyor? Her platform tasarım, geliştirme, test ve yayın sürecini etkiler. Mobil uygulama gerekiyorsa, tek kod tabanıyla iki platforma çıkan yaklaşımlar bütçeyi etkileyen bir seçenektir; ama her proje için doğru seçim olmayabilir.

6. Tasarım düzeyi

Hazır bir arayüz kitiyle kurulan yönetim ekranları ile müşteriye açık, markaya özel tasarlanmış ekranlar arasında ciddi emek farkı vardır. İç kullanım ekranlarında sadelik ve hız; müşteriye açık ekranlarda ise marka ve kullanıcı deneyimi öne çıkar.

7. Mevcut veriyi taşıma

Excel dosyalarında, eski bir programda ya da birden fazla kaynakta duran verinin yeni sisteme taşınması çoğu zaman tahmin edilenden uzun sürer. Verinin temizlenmesi, eşleştirilmesi ve doğrulanması ayrı bir iştir.

8. Güvenlik, yedekleme ve yasal gereksinimler

Kişisel veri işleyen bir yazılımda erişim kayıtları, yetkilendirme, şifreleme ve yedekleme gibi önlemler baştan tasarlanmalıdır. Sektörünüze özgü yasal gereksinimler varsa (ör. e-belge, kayıt saklama süreleri), bunlar da kapsama dahil edilmelidir.

Teslimden sonraki maliyetler

Yazılımın maliyetini yalnız geliştirme bedeli olarak düşünmek, en sık yapılan bütçe hatasıdır. Teslimden sonra şu giderler devam eder:

• Barındırma: Sunucu, veritabanı, yedekleme alanı, alan adı ve SSL. Uygulamanın kullanıcı ve veri miktarı arttıkça bu gider de değişir. Barındırma seçeneklerini Hosting Nedir? yazımızda anlattık.
• Bakım: Kullanılan dil, framework ve kütüphanelerin güncellenmesi, güvenlik yamaları, hata düzeltmeleri. Bakım yapılmayan yazılımda risk zamanla birikir; web sitesi tarafındaki karşılığını Web Sitesi Bakımı Neden Gerekli? yazımızda bulabilirsiniz.
• Geliştirme: İşiniz değiştikçe yeni özellik ihtiyacı doğar. Yaşayan bir yazılım, hiç değişmeyen bir yazılımdan daha olağandır.
• Üçüncü taraf ücretleri: SMS paketleri, mesajlaşma servisleri, harita ya da ödeme hizmetleri gibi kullanım başına ücretlendirilen servisler.

Bakımın ertelenmesinin bir de görünmeyen maliyeti vardır. Yazılım dünyasında buna teknik borç denir: Martin Fowler'ın anlatımıyla, kodun iç kalitesindeki sorunlar her yeni özelliği biraz daha uzun ve pahalı hale getirir; tıpkı bir borcun faizi gibi.

Bir teklifte bu kalemlerin nasıl ele alındığını sorun. "Teslim sonrası destek ne kadar sürüyor, sonrasında nasıl ilerliyor?" sorusunun cevabı yazılı olmalıdır.

MVP yaklaşımı: küçük başlayın, gerçek veriyle büyüyün

MVP (Minimum Viable Product, en küçük işe yarar ürün), Eric Ries'in 2009'da yaygınlaştırdığı Lean Startup kavramıdır. Agile Alliance'ın açıklamasına göre MVP, ürünün kullanıcılar hakkında en az emekle doğrulanmış öğrenme sağlayan sürümüdür. Önemli bir uyarı da vardır: MVP yalnız "en az özellik" demek değildir; gerçek kullanımda doğru sonuç verecek kadar işe yarar olmalıdır.

Özel yazılımda MVP yaklaşımı şöyle uygulanabilir:

1. Tek bir ana sorunu seçin. Örneğin "servis kayıtları kâğıtta kayboluyor."
2. O sorunu çözen en kısa akışı tanımlayın. Kayıt aç, ata, kapat, raporla.
3. İlk sürümü bu akışla sınırlayın. Entegrasyonları ve "olsa iyi olur" özelliklerini ikinci aşamaya bırakın.
4. Gerçek kullanıcılarla kullanın. Ekibin neyi kullandığını, neyi atladığını gözlemleyin.
5. Bir sonraki aşamayı veriye göre planlayın.

Bu yaklaşımın bütçeye etkisi şudur: Kullanılmayacak özelliklere baştan para harcamazsınız ve bütçenin büyük kısmını, gerçekten ihtiyaç olduğu kanıtlanmış işlere ayırırsınız.

İki teklifi nasıl karşılaştırırsınız?

Fiyatı farklı iki teklif çoğu zaman aynı işi anlatmıyordur. Karşılaştırmadan önce şunlara bakın:

• Kapsam listesi: Her teklifte hangi özellikler, hangi roller, hangi entegrasyonlar var?
• Varsayımlar: "Veri taşıma dahil değildir", "tasarım hazır şablonla yapılır" gibi notlar fiyatı ciddi biçimde değiştirir.
• Test ve teslim: Test süreci, kabul kriterleri ve canlıya alma kimin sorumluluğunda?
• Sahiplik: Kaynak kod, sunucu ve veriler kimin kontrolünde olacak? Bu konuyu Özel Yazılım Nedir? yazımızda ayrıntılı ele aldık.
• Teslim sonrası: Bakım, hata düzeltme ve yeni geliştirmeler nasıl ücretlendiriliyor?

Bütçenizi baştan belirtmek de işe yarar. Bu, ekibin size o bütçeyle mümkün olan en işe yarar kapsamı önermesini sağlar.

Bizim deneyimimiz

Özel yazılım projelerinde (CRM, panel, SaaS ve API işleri) fiyatı ekran sayısına göre değil, iş akışının ayrıntısına göre çalışıyoruz. Projelerimizde teklif öncesinde mevcut süreci adım adım yazıya döküyor, ilk sürüme girecek kısmı ve sonraki aşamaları ayrı ayrı listeliyoruz. Böylece hem siz bütçenin nereye gittiğini görüyorsunuz hem de proje sırasında "bu da dahil miydi?" tartışması azalıyor. Çalışma biçimlerimizi Çalışma Modelleri sayfamızda anlattık.

Sık sorulan sorular

Sonuç

Özel yazılım maliyetini belirleyen şey, ekranda gördükleriniz değil; o ekranların arkasındaki kurallar, bağlantılar ve sorumluluklardır. Kapsamı yazıya dökmek, MVP ile başlamak ve teslim sonrası giderleri baştan konuşmak, bütçenizi kontrol altında tutmanın en sağlam yoludur. İhtiyacınızı birlikte netleştirmek isterseniz Yazılım ve Dijital Çözümler sayfamıza göz atabilir ya da bizimle iletişime geçebilirsiniz.