Elmalı Tech / Özel yazılım
Özel yazılım maliyetini hangi kararlar belirler?
Özel yazılım bütçesi, geliştirilecek ekranlarla birlikte o ekranların arkasındaki iş kurallarına ve teslim sorumluluklarına bağlıdır. Aynı başlığı taşıyan iki teklif; entegrasyon, veri aktarımı, kullanıcı kabulü veya bakım açısından farklı işler içerebilir. Sağlıklı karşılaştırma için önce neyin teslim edileceğini ve hangi kalemlerin bütçeye dahil olduğunu netleştirin.
Bir bakışta
İlk görüşmeden önce netleştirin.
- İlk sürümü çalışan bir iş akışı ve kabul koşullarıyla tanımlayın.
- Geliştirme bedeliyle birlikte kurulum, entegrasyon ve işletim kalemlerini görün.
- Teklifleri aynı varsayımlar, kapsam dışı işler ve değişiklik yöntemiyle karşılaştırın.
1. Kapsamı özellik listesinden iş akışına çevirin
“Müşteri ekranı, sipariş ekranı ve raporlar” bir başlangıç listesidir. Müşteri kaydını kim açacak, sipariş hangi onaylardan geçecek, hangi istisnalarda işlem duracak ve rapordaki değer hangi kayıttan üretilecek? Bu kurallar geliştirme ve doğrulama işini belirler.
Örnek senaryo: Bir sipariş portalında yalnızca sipariş oluşturma istenmesi ile çok aşamalı onay, parçalı teslimat, iptal ve iade takibi istenmesi farklı kapsamlardır. Ekran sayısı benzer görünse bile iş akışları farklıdır. Teklifte bu ayrıntıları ve ilk sürümde hangilerinin bulunacağını yazılı hâle getirin.
2. Kullanıcı rolleri ve kanalları belirleyin
İç ekip, müşteri, bayi ve yönetici aynı bilgiyi farklı yetkilerle kullanabilir. Rol ve erişim kuralları; ekran davranışını, veri görünürlüğünü ve test senaryolarını etkiler. Kurum ya da şube bazında ayrım gerekiyorsa bunu başlangıç kapsamına ekleyin.
Web, mobil tarayıcı ve mağazalarda dağıtılacak mobil uygulama ihtiyaçlarını ayrı değerlendirin. Çevrimdışı kullanım, bildirim, cihaz özellikleri veya farklı dil seçenekleri ek çalışma gerektirebilir. Kullanıcıların gerçekten ihtiyaç duyduğu kanalı ilk teslim için seçin; gelecekteki seçenekleri yol haritasında belirtin.
3. Entegrasyon ve veri aktarımını ayrı kalemler olarak görün
ERP, CRM, ödeme veya lojistik sistemiyle bağlantı kurulacaksa ürün, sürüm, erişim yöntemi ve test imkânlarını inceleyin. Mevcut sistemin hazır bir bağlantısı bulunması, sizin iş kurallarınızı doğrudan karşılayacağı anlamına gelmez. Alan eşleştirme, hata yönetimi ve karşı sistemde yapılacak işler teklif kapsamına yazılmalı.
Eski verinin yeni ürüne taşınması da ayrı bir iştir. Hangi kayıtlar aktarılacak, mükerrer veya eksik bilgiler nasıl temizlenecek ve aktarımın doğruluğunu kim kabul edecek? Veri hazırlığı müşteri tarafında yapılacaksa bu bağımlılığı ve gecikme durumunda planın nasıl değişeceğini belirtin.
4. Test, güvenlik ve teslim koşullarını netleştirin
Kritik işlemlerin doğrulanması, rol bazlı erişim kontrolleri ve gerekli performans koşulları geliştirme kapsamıyla birlikte düşünülmelidir. Pilot kullanıcı kabulü, hata giderme ve canlıya geçiş desteğinin teklife dahil olup olmadığını sorun. Başlangıçta tanımlanmayan bir kabul koşulu sonradan ek iş yaratabilir.
Kod, dokümantasyon, kurulum bilgileri ve kullanılan üçüncü taraf hizmetlerin yönetimi için teslim koşullarını inceleyin. Kaynak koda erişim, kullanım hakları, garanti kapsamı ve destek sorumlulukları sözleşmede açık olmalı. İhtiyacınız olan güvenlik ve işletim koşullarını karşılaştırma dosyanızda aynı biçimde belirtin.
5. Yayın sonrası toplam sahip olma maliyetini hesaplayın
İlk geliştirme bedeline ek olarak barındırma, lisans, kullanım bazlı servisler, izleme, yedekleme ve bakım kalemlerini değerlendirin. Bunların hangisinin proje bedeline dahil olduğunu, hangisinin doğrudan sizin hesabınızdan ödeneceğini ve kullanım büyüdüğünde neye göre değişeceğini öğrenin.
Karşılaştırma için aynı kullanıcı, işlem ve veri hacmi varsayımlarını kullanın. Her kalemi tek seferlik veya tekrarlayan gider olarak ayırın ve ortak bir dönem üzerinden inceleyin. Tahmini gelir ya da tasarrufları gerçekleşmiş sonuç gibi bütçeye yazmak yerine varsayım olarak görünür tutun.
6. İlk sürüm ve değişiklik yöntemiyle bütçeyi yönetin
İlk sürüm için bir kullanıcının baştan sona tamamlayabildiği kritik akışı seçin. Başarı ölçütünü, gerekli rollerini ve zorunlu entegrasyonlarını belirleyin. Henüz doğrulanmamış rapor veya otomasyon taleplerini sonraki aşamaya bırakmak değerlendirilebilir; temel erişim ve veri güvenliği ihtiyaçları ise ilk kapsamın parçası olmalı.
Sabit kapsamlı veya zaman bazlı çalışmanın nasıl yönetileceğini de konuşun. Varsayımlar, kapsam dışı işler, ödeme aşamaları ve değişikliklerin onay yöntemi görünür olmalı. Yeni bir ihtiyaç geldiğinde etkisinin süre ve bütçe açısından nasıl hesaplanacağı belli olduğunda teklif karşılaştırması daha anlamlı olur.
Teklif karşılaştırması için sorulacak sorular
- İlk teslimde hangi iş akışları, roller, kanallar ve kabul koşulları bulunuyor?
- Keşif, tasarım, entegrasyon, veri hazırlığı, test ve canlıya geçiş işlerini kim yapıyor?
- Hangi lisans ve kullanım giderleri dahil; hangileri ayrıca ödeniyor?
- Kod, dokümantasyon, kullanım hakları ve şirket hesaplarına erişim nasıl teslim ediliyor?
- Hata giderme, bakım ve yeni geliştirme birbirinden nasıl ayrılıyor?
- Kapsam değişiklikleri nasıl fiyatlandırılıyor ve kim tarafından onaylanıyor?
- Teklif hangi varsayımlara dayanıyor; müşteri tarafındaki hazırlık gecikirse plan nasıl güncelleniyor?
Kaynak ve ek okuma
Buluta geçiş bağlamındaki bu kaynak, altyapı ve işletim maliyetlerinin ortak varsayımlarla değerlendirilmesine ek okuma sağlar. Özel yazılım geliştirme fiyatlarını belirleyen bir liste değildir.