Özel yazılım maliyeti ekran sayısından ibaret değildir. Çözülecek iş akışları, kullanıcı rolleri, entegrasyonlar, veri aktarımı, güvenlik, test kapsamı, yayın ortamı ve destek modeli birlikte fiyatı oluşturur. Sağlıklı teklif için önce ilk sürümün sınırları ve kabul ölçütleri yazılı hale getirilmelidir.
Başlangıçta kontrol edilmesi gerekenler
İlk sürümde çözülecek iş problemi ve kapsam dışı kalacak maddeler
Modüller, kullanıcı rolleri, yetkiler ve kritik istisna akışları
Mevcut sistem bağlantıları ile aktarılacak verinin niteliği
Test, yayın, eğitim, dokümantasyon ve destek teslimleri
Kaynak kod, veri, alan adı ve yönetici hesaplarının sahipliği
Özel yazılıma neden ihtiyaç anlaşılmadan tek fiyat verilemez?
“Stok programı”, “müşteri portalı” veya “fabrika uygulaması” aynı isim altında çok farklı kapsamlar taşıyabilir. Bir projede yalnızca temel kayıt ve listeleme yeterliyken başka bir projede çoklu şirket, onay zinciri, mobil uygulama, barkod, muhasebe bağlantısı ve ayrıntılı yetkilendirme gerekebilir. İsim aynı kalsa da üretilecek iş ve risk aynı değildir.
İlk görüşmede kesin rakam söylemek yerine kapsam varsayımlarını görünür kılmak daha sağlıklıdır. Teklif; hangi kullanıcıların hangi işlemi yapacağını, verinin nereden geleceğini, hangi istisnaların ele alınacağını ve tamamlanmış sayılmak için hangi senaryoların çalışacağını açıklamalıdır.
Maliyeti en çok etkileyen kapsam kararları
Geliştirme süresini yalnızca ekran sayısı belirlemez. Basit görünen bir ekran, farklı rollere göre değişen alanlar, onay kuralları veya harici sistemden gelen veriler nedeniyle önemli iş mantığı içerebilir. Bu yüzden maliyet değerlendirmesi teknik özellik listesiyle iş senaryosunu birlikte ele almalıdır.
- Modüller ve iş akışları: kayıt, onay, planlama, raporlama ve istisnalar
- Kullanıcılar ve yetkiler: şirket, şube, ekip, müşteri veya bayi sınırları
- Platformlar: responsive web, mobil uygulama, çevrimdışı kullanım veya cihaz özellikleri
- Entegrasyonlar: ERP, muhasebe, ödeme, kargo, e-posta, SMS ve üçüncü taraf API’ler
- Veri aktarımı: kaynakların kalitesi, temizleme, eşleştirme ve doğrulama
- Kalite beklentisi: güvenlik, performans, erişilebilirlik, test ve kayıt tutma
- Yayın ve devamlılık: barındırma, izleme, yedekleme, eğitim, bakım ve destek
Teklif istemeden önce bir sayfalık kapsam özeti hazırlayın
Uzun bir teknik şartnameyle başlamak zorunda değilsiniz. Karşılaştırılabilir teklif alabilmek için işletmenin bugünkü işleyişini ve hedeflediği ilk sonucu anlatan kısa bir proje özeti yeterli bir başlangıçtır. Bu belge çözümü peşinen dikte etmez; teklif veren ekibin aynı problemi değerlendirmesini sağlar.
- Bugün süreç nasıl ilerliyor ve en çok nerede zaman veya bilgi kaybı oluşuyor?
- Sistemi kimler, hangi cihazlardan ve hangi sıklıkta kullanacak?
- İlk sürümde mutlaka çalışması gereken üç ila beş senaryo nedir?
- Hangi mevcut programlar ve veri dosyaları korunacak veya bağlanacak?
- Yasal, güvenlik veya kurum içi onay gereksinimleri var mı?
- Yayın için hedeflenen dönem ve kurum tarafındaki karar sorumlusu kim?
İlk sürüm ile sonraki fazları ayırın
Bütün ihtiyaçları ilk yayına eklemek bütçeyi ve teslim riskini büyütebilir. İlk sürüm, ana iş problemini gerçek kullanıcıyla çözen en küçük anlamlı kapsam olmalıdır. “En küçük” ifadesi kalitesiz veya eksik anlamına gelmez; kritik uçtan uca senaryoların çalıştığı, güvenli ve genişletilebilir bir temel anlamına gelir.
Sonraki fazlar ilk sürümde elde edilen kullanım verisi ve geri bildirimle önceliklendirilir. Böylece hiç kullanılmayacak raporlar veya süreçle uyuşmayan özellikler için erken yatırım yapılmaz. Teklifte ilk sürüm, opsiyonel modüller ve gelecekteki entegrasyonlar ayrı başlıklarda gösterilmelidir.
İki yazılım teklifini aynı kapsam üzerinden karşılaştırın
Toplam bedelleri yan yana koymak yeterli değildir. Bir teklif analiz, tasarım, veri aktarımı, test ve yayın desteğini içerirken diğeri yalnızca geliştirmeyi içeriyor olabilir. Teslimlerin ve varsayımların satır satır karşılaştırılması, sonradan çıkabilecek ek maliyetleri görünür kılar.
- Kapsama dahil modüller ve açıkça kapsam dışı bırakılan maddeler
- Tasarım, responsive kullanım ve erişilebilirlik çalışmasının sınırları
- Entegrasyon başına veri yönü, hata yönetimi ve üçüncü taraf ücretleri
- Test türleri, kabul senaryoları ve hata düzeltme dönemi
- Yayın ortamı, alan adı, sertifika, izleme ve yedekleme sorumlulukları
- Eğitim, dokümantasyon, bakım ve destek için süre ve kanal
- Değişiklik taleplerinin nasıl fiyatlandırılacağı ve onaylanacağı
Kod, veri ve hesap sahipliğini sözleşmede görünür kılın
Proje tamamlandığında verinin hangi formatta dışa alınabileceği, alan adı ve barındırma hesabının kimde olduğu, yönetici erişimlerinin nasıl teslim edileceği net olmalıdır. Kaynak kod teslimi veya kullanım hakkı da seçilen ticari modele göre sözleşmede açıkça tanımlanmalıdır; varsayıma bırakılmamalıdır.
Güvenlik konusunda yalnızca “SSL var” ifadesi yeterli değildir. Rol bazlı erişim, yönetici hesaplarının korunması, özel dosyaların sunumu, yedekleme, hata kayıtları ve bağımlılık güncellemeleri projenin riskine göre değerlendirilmelidir. Mutlak güvenlik vaadi yerine sorumluluklar ve bakım yaklaşımı açıklanmalıdır.
Karar vermeden önce son kontrol
İyi teklif yalnızca neyin yapılacağını değil, projenin nasıl yönetileceğini de açıklar. İletişim sorumluları, ara onaylar, teslim ortamları, kabul süresi ve değişiklik yöntemi anlaşılır olmalıdır. Anlamadığınız teknik ifadelerin iş sonucuna nasıl bağlandığını sorun.
- Teklif gerçek iş problemini ve kullanıcıları doğru tarif ediyor mu?
- İlk sürümün sınırı ve tamamlanma ölçütü açık mı?
- Süre tahmini hangi varsayımlara ve kurum tarafındaki onaylara bağlı?
- Veri aktarımı ve entegrasyonlarda sorumluluklar ayrılmış mı?
- Yayın sonrası hata, bakım ve yeni geliştirme süreçleri tanımlı mı?
- Veri ve temel hesaplara erişim kurumunuzun kontrolünde mi?
Sık sorulan sorular
Özel yazılıma neden tek fiyat verilemez?
Aynı proje adı farklı modül, rol, entegrasyon, veri aktarımı ve kalite gereksinimleri içerebilir. Sağlıklı fiyat, ilk sürümün sınırları ve kabul senaryoları anlaşıldıktan sonra oluşur.
Özel yazılım maliyetini en çok ne etkiler?
İş akışlarının karmaşıklığı, kullanıcı yetkileri, mobil veya çevrimdışı kullanım, entegrasyonlar, veri aktarımı, test kapsamı ve yayın sonrası destek başlıca etkenlerdir.
Analiz, tasarım ve test teklife dahil midir?
Her sağlayıcıda aynı değildir. Teklifte analiz çıktısı, tasarım kapsamı, test türleri ve kabul desteği ayrı teslimler olarak belirtilmelidir.
Hazır yazılım hangi durumda yeterlidir?
Süreçleriniz standartsa, ürün gerekli rapor ve rolleri karşılıyorsa, veri dışa aktarımı mümkünse ve entegrasyon sınırları kabul edilebiliyorsa hazır ürün daha hızlı bir çözüm olabilir.
Teklifleri karşılaştırırken nelere bakılmalıdır?
Toplam fiyatın yanında kapsam, varsayımlar, kapsam dışı maddeler, veri aktarımı, entegrasyon, test, yayın, sahiplik ve destek koşulları aynı tablo üzerinde karşılaştırılmalıdır.
Kaynak kod ve verilerin mülkiyeti kimde olur?
Bu durum projenin lisans ve ticari modeline göre değişir. Kullanım hakkı, kaynak kod teslimi, veri sahipliği ve dışa aktarma koşulları sözleşmede açıkça yazılmalıdır.