Özel Yazılım Teklifi Nasıl Karşılaştırılır?

1. Ekran listesi yerine iş akışı tanımlayın

Önce yazılımın çözmesini istediğiniz problemi bir paragrafta anlatın. Kim hangi işlemi yapıyor, bilgi nereden geliyor, hangi aşamada zaman veya hata maliyeti oluşuyor? “Sipariş ekranı istiyoruz” yerine “satış temsilcisi tekliften sipariş oluşturacak, depo stok uygunluğunu görecek ve yetkili kişi onaylayacak” tanımı daha fazla belirsizliği ortaya çıkarır.

Ardından normal senaryonun dışına çıkın. Müşteri son anda ürünü değiştirirse ne olacak? Stok aynı anda başka siparişe ayrılırsa kim uyarılacak? Bir onay reddedilirse kayıt hangi duruma dönecek? Bu sorulara verilen cevapları bütün adaylarla aynı kapsam belgesinde paylaşın. Böylece her firma farklı bir varsayımı fiyatlandırmamış olur.

2. Her önemli maddeye kabul ölçütü ekleyin

Örnek bir gereksinim “teklifler PDF olarak indirilebilecek” olabilir. Daha denetlenebilir tanım ise “onaylanan teklifte ürün, adet, fiyat, toplam ve teklif numarası yer alacak; yetkisiz kullanıcı başka müşterinin teklifini açamayacak” şeklindedir. Bu bir örnek senaryodur; belirli bir müşteriye teslim edilmiş proje iddiası değildir.

“Sınırsız revizyon” gibi kapsamı belirsiz ifadeler yerine değişiklik isteğinin nasıl değerlendirileceğini sorun. Yeni ihtiyaç, hata düzeltmesi ve tasarım tercihi aynı başlık altında toplanmamalıdır. Kabul ölçütleri, hem işletme hem geliştirici için ortak bir kontrol zemini oluşturur.

3. Entegrasyonun başarısız olduğu günü düşünün

Ödeme, stok, kargo veya muhasebe bağlantısı için yalnızca sağlayıcı adını görmek yeterli değildir. Verinin yönünü, aktarım sıklığını, kimlik eşleştirmesini ve hatalı kayıtların nasıl izleneceğini yazılı isteyin. Aynı mesaj tekrar geldiğinde aynı siparişin ikinci kez oluşmaması gibi durumları test planına dahil edin.

Ayrıca üçüncü taraf hizmete ait abonelik, kullanım sınırı ve erişim yetkisinin kimin sorumluluğunda olacağını sorun. Bir sağlayıcı API’sini değiştirdiğinde güncellemenin bakım kapsamında olup olmayacağını netleştirin. Belirsiz bir “entegrasyon yapılır” maddesi yerine örnek veri ve hata senaryosuyla ilerleyin.

4. Güvenliği doğrulanabilir maddelerle konuşun

“Sistem güvenlidir” beyanı yerine rol bazlı erişim, oturum yönetimi, kayıtların korunması ve hassas işlemlerin kontrolü için hangi testlerin yapılacağını sorun. OWASP ASVS, uygulama güvenliğini doğrulamak için gereksinim çerçevesi sunar. Projeye uygun maddeler teknik ekip tarafından seçilmeli ve test kapsamına dönüştürülmelidir.

Yedekleme için de aynı yaklaşımı kullanın. Yedek alındığını söylemek ile o yedekten çalışan sistemi geri kurabilmek farklı kontrollerdir. Geri yükleme denemesinin nerede yapılacağını, sorumlusunu ve sonucunun nasıl kaydedileceğini belirleyin. Bu kontrol listesi hukuki sözleşme veya güvenlik sertifikası yerine geçmez.

5. Tek seferlik ücretin dışındaki giderleri ayırın

Teklifleri başlangıç geliştirmesi, barındırma, üçüncü taraf servisler, destek, bakım ve olası geçiş giderleri olarak yan yana koyun. Burada sabit piyasa fiyatı vermek yerine hangi maliyetin neye bağlı olduğunu sormak daha değerlidir. Kullanıcı sayısı, veri hacmi veya işlem adedi arttığında hangi kalemin değişeceğini öğrenin.

Kaynak kodunun, depo erişiminin, kurulum bilgisinin ve operasyon hesaplarının nasıl devredileceğini de değerlendirin. Sadece çalışan bir ekran değil, ileride bakım yapılabilir bir teslimat isteyin. Dokümantasyonun kapsamını ve ekip eğitiminin kimlere verileceğini yazılı netleştirin.

6. Son kararı küçük bir doğrulamayla destekleyin

Kritik iş akışını gösteren bir prototip veya sınırlı kapsamlı ilk teslimat isteyebilirsiniz. Bunu ücretsiz iş talebine çevirmek yerine kapsamı, çıktısı ve değerlendirme ölçütü belirli bir aşama olarak planlayın. Birbirine yakın tekliflerde, hangi firmanın belirsizlikleri açıkça gösterdiğini ve riskleri anlaşılır anlattığını ayrıca değerlendirin.

Sık sorulan sorular

En ucuz teklifi elemek gerekir mi?

Hayır. Önce kapsamın ve sorumlulukların aynı olup olmadığını görün. Daha düşük bedel, daha dar teslimat veya farklı bakım modeli anlamına gelebilir.

Teklif almadan önce teknik şartname şart mı?

Ayrıntı seviyesi projeye göre değişir. En azından ana iş akışları, kullanıcı rolleri, bağlantılar ve kabul ölçütleri yazılı olmalıdır.

Hazırlama notu: Bu rehber, bağlantı verilen resmî dokümantasyon ve örnek çalışma senaryoları kullanılarak yapay zekâ desteğiyle hazırlanmıştır. Örnekler gerçek müşteri sonuçları değildir. Uygulamadan önce kullanılan altyapının güncel dokümantasyonunu ve projenize özel gereksinimleri kontrol edin.