Yazılım tekliflerini karşılaştırmanın ilk adımı, tekliflerin aynı işi kapsayıp kapsamadığını anlamaktır. Fiyatı daha düşük görünen bir seçenek bazı işleri dışarıda bırakıyor olabilir; daha ayrıntılı bir teklif ise ihtiyacınız olmayan özellikler içeriyor olabilir. Karar verirken bedelle birlikte neyin teslim edileceğini, nasıl kontrol edileceğini ve kullanım sonrasında kimin sorumlu olacağını inceleyin.

Önce ortak bir ihtiyaç listesi hazırlayın

Farklı ekiplere farklı bilgiler verdiğinizde tekliflerin birbirinden uzaklaşması doğaldır. Bu nedenle karşılaştırmadan önce çözülecek iş problemini ve temel beklentileri tek bir belgede toplayın. Hangi kullanıcıların hangi işlemleri yapacağını, mevcut verilerin nerede bulunduğunu ve ilk aşamada hangi işlerin tamamlanması gerektiğini açıklayın.

Bu belge ayrıntılı bir teknik şartname olmak zorunda değildir. Örneğin bir işletmenin gelen talepleri ortak bir yerde takip etmek istediğini düşünelim. Talep oluşturma, sorumlu belirleme, durum değiştirme ve eski kayıtları bulma gibi adımların yazılması, yalnızca “bir takip sistemi istiyoruz” demekten daha açık bir başlangıç sağlar.

Teklif isteyen kişi olarak bütün teknik kararları sizin vermeniz gerekmez. Belirsiz noktaların hangi varsayımlarla ele alındığını sormanız yeterlidir. İhtiyaçları toparlamak için proje başlangıcında sorulacak sorulara da bakabilirsiniz.

Ekran adlarını değil, tamamlanan işleri karşılaştırın

Bir teklifte “raporlama ekranı” yazması, hangi soruların cevaplanacağını tek başına anlatmaz. Raporda hangi bilgiler bulunacak, kimler görebilecek, hangi tarihlere göre süzülebilecek ve sonuç dışarı aktarılabilecek mi? Bu ayrıntılar, aynı başlık altında farklı işler bulunabileceğini gösterir.

Teklifleri yan yana değerlendirirken her temel iş için teslim edilecek sonucu yazın. Belirsiz bir maddeyi kendi yorumunuzla doldurmak yerine açıklama isteyin. Teklifte yer almayan bir özelliğin daha sonra ücretsiz eklenebileceğini varsaymayın; nasıl değerlendirileceğini önceden konuşun.

Kapsam dışında kalan işler de karşılaştırmanın parçasıdır. Bir ekibin açıkça kapsam dışı bıraktığı bir iş, diğer teklifin içinde sessizce varsayılmış olabilir. Bu farkı ortaya çıkarmak, yalnızca daha çok özellik istemekten daha yararlıdır.

Teslim koşulları nasıl anlaşılır?

Teslim, yazılımın bir bağlantı üzerinden açılmasından daha geniş bir konudur. Temel işlerin çalışması, yetkilerin doğru olması, gerekli bilgilerin aktarılması ve kullanıcının işi tamamlayabilmesi gibi koşullar birlikte ele alınabilir.

Kabul ölçütü, işin beklendiği gibi tamamlandığını gösterecek somut koşuldur. Örneğin “kullanımı kolay olacak” ifadesinin yanına, “yetkili kişi bir talebi oluşturabilecek, başka bir sorumluya aktarabilecek ve kapatılan talebi tekrar bulabilecek” gibi bir iş örneği eklenebilir. Bu örnek, neyin kontrol edileceğini görünür kılar.

Teklifte deneme ve düzeltme sürecinin nasıl ele alındığını sorun. Bulunan bir hata ile sonradan istenen yeni bir özellik aynı şey değildir. Aralarındaki ayrımın nasıl yapılacağı ve değişikliklerin bedel ya da takvim üzerindeki etkisinin nasıl bildirileceği açıklanmalıdır.

Mevcut verilerin aktarılması dahil mi?

Yeni yazılımın hazırlanması ile eski kayıtların kullanılabilir biçimde taşınması farklı işler olabilir. Dağınık dosyalar, eksik alanlar veya aynı kaydın birden fazla sürümü varsa aktarım öncesinde düzenleme gerekebilir.

Hangi verilerin taşınacağını, hangi biçimde teslim edileceğini ve doğruluğunun kim tarafından kontrol edileceğini konuşun. Özellikle geçmiş kayıtlar önemliyse küçük bir örnek veri üzerinde deneme yapılmasının kapsamda olup olmadığını sorun.

Varsayımsal işletmemizde bir teklif yalnızca yeni taleplerin kaydedilmesini kapsarken başka bir teklif geçmiş taleplerin de aktarılmasını içerebilir. İki fiyatı bu farkı görmeden karşılaştırmak, gerçekte farklı işleri aynı işmiş gibi değerlendirmek olur.

Kullanım sonrasındaki sorumlulukları yazın

Yazılım kullanıma alındıktan sonra hesap yönetimi, hata bildirimi, güncelleme ve veri dışa aktarma gibi konular gündeme gelebilir. Bunların hangilerinin teklife dahil olduğunu ve hangilerinin ayrı değerlendirileceğini inceleyin.

Bakım ifadesinin ne anlama geldiğini ayrıca sorun. Bir teklif yalnızca belirli hata düzeltmelerini kapsayabilir; başka bir teklif düzenli kontrolleri de tarif edebilir. Destek talebinin nasıl iletileceği, hangi durumların kapsam dışında olduğu ve devam eden giderlerin neler olduğu açık olmalıdır.

Bir başka ekiple devam etmek gerekirse kaynak dosyaların, erişim bilgilerinin ve kullanım açıklamalarının nasıl teslim edileceğini de konuşun. Amaç gelecekte sorun çıkacağını varsaymak değil, sorumlulukları anlaşılır hale getirmektir.

Karar öncesi kısa kontrol listesi

Her teklifi aynı sorularla inceleyin:

  • Aynı kapsam mı? İlk aşamada tamamlanacak işler ve kapsam dışındaki beklentiler açık mı?
  • Sonuç kontrol edilebilir mi? Temel işlerin tamamlandığını gösterecek deneme örnekleri var mı?
  • Veri aktarımı açıklanmış mı? Eski kayıtların hazırlanması, taşınması ve kontrolü kimin sorumluluğunda?
  • Ek işler nasıl ele alınıyor? Yeni taleplerin onay, bedel ve takvim üzerindeki etkisi nasıl değerlendirilecek?
  • Teslim sonrası düzen belli mi? Bakım, destek, erişim ve devam eden giderler anlaşılır mı?

Bu sorulara verilen cevapları kısa bir karşılaştırma tablosuna yazabilirsiniz. Cevabı bilinmeyen hücreleri tahminle doldurmak yerine belirsiz olarak işaretleyin ve açıklama isteyin.

Fiyatı açıklanmış kapsamla birlikte değerlendirin

En düşük fiyatın veya en uzun özellik listesinin her durumda doğru seçim olması gerekmez. Önceliğiniz, ihtiyacınıza uygun kapsamın ve sorumlulukların anlaşılır olmasıdır. Bedelin neden farklılaştığını yorumlamak için yazılım maliyetini etkileyen unsurları inceleyebilirsiniz.

Son karar öncesinde belirsiz maddeleri yazılı olarak netleştirin. Böylece seçiminizi yalnızca bir toplam tutara değil, hangi işin hangi koşullarda tamamlanacağına dayandırabilirsiniz.