Aynı ihtiyaç için alınan iki özel yazılım teklifi arasında büyük fiyat ve süre farkı olabilir. Bunun nedeni her zaman ajansların fiyat politikası değildir; tarafların aynı cümleden farklı kapsam anlamasıdır. “Stok takip sistemi” bir firma için basit giriş-çıkış ekranı, başka bir firma için barkod, lot, depo transferi, yetki ve muhasebe entegrasyonu demek olabilir.
Teklifi sağlıklı değerlendirmek için önce ihtiyacı ekran isimleriyle değil, gerçek kullanım senaryolarıyla anlatın. Ardından her teklifin aşağıdaki başlıklara verdiği cevabı aynı tabloda karşılaştırın.
Kapsam: Yazılım hangi işi, hangi sınırda yapacak?
Modül listesi tek başına yeterli değildir. Kullanıcı rolleri, iş adımları, onaylar, bildirimler, raporlar ve istisnalar açıklanmalıdır. Örneğin “sipariş modülü” için siparişi kimin açtığı, kimin onayladığı, hangi durumda değiştirilebildiği ve iptal kaydının nasıl tutulduğu yazılmalıdır.
Kapsam dışı maddelerin de listelenmesi faydalıdır. Mobil uygulama, veri girişi, eski veri aktarımı, donanım, lisans veya üçüncü taraf servis bedelleri dahil değilse sonradan sürpriz oluşmaz.
Fonksiyonel olmayan gereksinimleri gözden kaçırmayın
Yazılımın ne yaptığı kadar nasıl çalıştığı da önemlidir. Eş zamanlı kullanıcı, beklenen veri hacmi, yedekleme, erişim logları, rol bazlı yetki, performans ve desteklenen cihazlar teklifin teknik bölümünde yer almalıdır. Hassas veya ticari veri işleniyorsa güvenlik ve saklama sorumlulukları ayrıca netleştirilmelidir.
Entegrasyonlar için isim değil senaryo isteyin
“Muhasebe entegrasyonu dahil” ifadesi belirsizdir. Hangi sistemin hangi sürümüyle, hangi verinin, hangi yönde ve ne sıklıkta aktarılacağı yazılmalıdır. Karşı sistemin API erişimi, lisansı veya teknik sınırları proje başlamadan doğrulanmalıdır.
- Bağlantı kesilirse veri kuyruğa alınacak mı?
- Hatalı kayıt kim tarafından görülecek?
- Aynı kayıt iki sistemde değişirse hangisi geçerli olacak?
- Test ortamı ve örnek veri sağlanabiliyor mu?
Takvim: Tek tarih yerine kilometre taşları
Analiz, prototip, geliştirme, entegrasyon, kullanıcı kabul testi, veri aktarımı ve canlı geçiş ayrı adımlar olarak planlanmalıdır. Her adımda müşterinin teslim etmesi gereken veri veya onaylar yazılırsa gecikmenin kaynağı anlaşılır.
Çok kısa süre vaadi kadar ucu açık takvim de risklidir. Belirsizlik yüksekse önce ücretli analiz veya prototip aşaması yapılabilir; ana geliştirme kapsamı bu çıktıya göre kesinleşir.
Maliyet modelini ve değişiklik kuralını anlayın
Sabit fiyat, zaman ve malzeme ya da aşama bazlı modelin her birinin uygun olduğu proje tipi farklıdır. Sabit kapsam netse sabit fiyat öngörülebilirlik sağlar. Keşif ve iterasyon yoğunsa aşama bazlı model daha gerçekçi olabilir. Yeni talebin nasıl analiz edileceği, fiyatlanacağı ve takvime ekleneceği sözleşmede yer almalıdır.
Test ve kabul kriterleri
“Sistem çalışıyor” yerine test edilebilir kabul maddeleri kullanın. Örneğin yetkisiz rolün maliyet alanını görememesi, onaylanan siparişin değiştirilememesi veya entegrasyon hatasının yöneticiye bildirilmesi gibi senaryolar yazılabilir. Hata öncelikleri ve düzeltme süreci de tanımlanmalıdır.
Kaynak kod, veri ve yayın sonrası destek
- Kaynak kod ve veritabanının sahipliği kimde?
- Kullanılan üçüncü taraf lisanslar hangileri?
- Hosting hesabına ve yedeklere kim erişiyor?
- Garanti kapsamı ile yeni geliştirme nasıl ayrılıyor?
- Kritik hata için bildirim ve müdahale kanalı nedir?
- Dokümantasyon ve kullanıcı eğitimi teslim ediliyor mu?
Karşılaştırma için puanlama tablosu oluşturun
Her teklife kapsam netliği, sektör ve süreç anlayışı, teknik yaklaşım, güvenlik, test, takvim, iletişim ve toplam sahip olma maliyeti başlıklarında puan verin. En düşük ilk bedel, bakımı zor veya veriyi kilitleyen bir yapıda uzun vadede avantaj olmayabilir.
ARTISIVAR ile özel yazılım projesi planlarken önce kullanım senaryolarını ve riskli entegrasyonları netleştiriyoruz. Karşılaştırılabilir bir kapsam oluşturmak için proje talebinizi iletebilirsiniz.
Sık sorulan sorular
Teklif almadan önce ayrıntılı teknik doküman hazır olmalı mı?
Her zaman değil. Sorunu, kullanıcıları ve mevcut süreci anlatan bir ön doküman yeterli başlangıç olabilir. Teknik kapsam analiz aşamasında birlikte geliştirilebilir.
Bakım bedeli neden ayrı değerlendirilir?
Sunucu, izleme, yedek, güvenlik güncellemesi, destek ve yeni geliştirme farklı emek kalemleridir. Hangi hizmetin periyodik bedele dahil olduğu açıkça yazılmalıdır.
İhtiyacınıza uygun hizmet kapsamını ve yol haritasını birlikte hazırlayalım.
Teklif Al