Yazılım Teklifi Nasıl Okunur? Teklifleri Karşılaştırırken Sormanız Gereken Sorular

Özel bir yazılım için birkaç firmadan teklif aldınız. Biri iki sayfa, diğeri yirmi sayfa. Biri tek bir toplam rakam veriyor, diğeri işi parçalara bölmüş. Sonunda çoğu kişi en düşük rakama ya da en güven veren görüşmeye bakarak karar verir. Oysa yazılım tekliflerinde asıl fark rakamda değil, rakamın neyi kapsadığındadır. Bu yazıda bir yazılım teklifini bölüm bölüm nasıl okuyacağınızı ve teklifleri karşılaştırırken hangi soruları soracağınızı anlatıyoruz.

Kapsamda neyin yapılacağı ve neyin yapılmayacağı yazıyor mu?

Teklifin en önemli bölümü kapsamdır. 'Müşteri yönetim sistemi' gibi tek satırlık bir tanım, iki firma için bambaşka işler anlamına gelebilir. İyi bir teklif, sistemin hangi ekranlardan ve özelliklerden oluşacağını, hangi kullanıcı rollerinin olacağını ve hangi programlarla bağlantı kurulacağını tek tek yazar. Daha da değerlisi, kapsam dışında kalanları da açıkça belirtir. 'Mobil uygulama bu teklife dahil değildir' gibi tek bir cümle, ileride yaşanabilecek bir anlaşmazlığı baştan önler. Kapsamda kullanılan kelimelere de dikkat edin. 'Raporlama' bir teklifte birkaç hazır tablo, başka bir teklifte istediğiniz kırılımda rapor alabileceğiniz bir ekran anlamına gelebilir. Belirsiz kalan her kelimeyi bir örnekle netleştirmesini isteyin.

Proje bittiğinde elinize tam olarak ne geçecek?

Bir yazılım projesinin sonunda yalnızca çalışan bir sistem değil, onu sürdürmenizi sağlayacak parçalar da teslim edilmelidir. Teklifte şu başlıkların her biri için bir cümle arayın:

• Çalışan sistemin kendisi ve hangi sunucuda, kimin hesabında yayınlanacağı.
• Kaynak kod ya da kaynak koda erişim koşulları.
• Teknik belgeler: sistemin nasıl kurulduğu, veritabanı yapısı ve bağlantıların nasıl çalıştığı.
• Kullanım kılavuzu ve ekip eğitimi.
• Eski verilerin yeni sisteme taşınması, eğer kapsamdaysa.
• Alan adı, sunucu ve dış servis hesaplarının kimin adına açılacağı.

Bu maddelerin teklifte yer alması, firmanın iş bittikten sonra sizi bağımsız bırakmayı da düşündüğünü gösterir. Belgesiz teslim edilen bir sistem, onu yazan ekip dışında kimsenin kolayca dokunamadığı kapalı bir kutuya dönüşür.

Tek bir teslim tarihi neden yetmez?

'Üç ayda teslim' gibi tek bir tarih, ilerlemeyi takip etmenize izin vermez. Daha sağlıklı bir teklif işi aşamalara böler: keşif, ekran taslakları, geliştirme, test ve yayın. Her aşamanın sonunda neyi göreceğiniz ve neyi onaylayacağınız yazılıdır. Bu yapıda bir gecikme son haftada değil, ilk aşamada fark edilir. Sürenin sizin tarafınıza bağlı kısımlarını da kontrol edin. Ekran onayları, içerik ya da veri teslimi geciktiğinde takvimin nasıl kayacağı teklifte belirtilmiş olmalıdır. Sürenin hangi varsayımlara dayandığını da sorun: kaç kullanıcı rolü, kaç bağlantı ve ne kadar veri hesaba katıldı? Varsayım değiştiğinde sürenin de değişmesi doğaldır; önemli olan bunun baştan bilinmesidir.

Ödeme planı ilerlemeye bağlı mı?

Ödeme planı, iki tarafın riskini dengeleyen bölümdür. Ödemelerin aşamalara bağlandığı bir yapıda her ödeme, gördüğünüz ve onayladığınız bir ilerlemeye karşılık gelir. Teklifte hangi ödemenin hangi aşamaya bağlı olduğuna, kapsam değişikliklerinin nasıl ücretlendirileceğine ve ek iş taleplerinin nasıl onaylanacağına bakın. Proje sırasında fikir değiştirmek normaldir; önemli olan, değişikliğin süreye ve maliyete etkisinin yazılı olarak konuşulmasıdır. Planı okurken yalnızca geliştirme bedeline değil, yayından sonra düzenli ödenecek kalemlere de bakın: sunucu, alan adı, dış servis abonelikleri ve bakım. Bu kalemlerin kimin adına ve kimin hesabından ödeneceği de yazılı olmalıdır.

Yayından sonra bakım ve destek nasıl işleyecek?

Yazılım yayına girdiği gün bitmez. Hatalar çıkar, kullandığınız dış servisler değişir, güvenlik güncellemeleri gerekir, ekibiniz de yeni istekler getirir. Teklifte yayından sonraki dönem için şunları arayın: belirli bir süre ücretsiz hata düzeltme var mı, bakım hizmeti ayrıca sunuluyor mu ve neleri kapsıyor, bir sorun bildirdiğinizde ne kadar sürede dönüş yapılıyor, yeni özellik talepleri nasıl ücretlendiriliyor. Hata düzeltme ile yeni özellik geliştirme arasındaki farkın açıkça yazılması, ileride çıkabilecek tartışmaları önler. Destek taleplerinin hangi kanaldan ve hangi saatlerde iletileceği de teklifte yer almalıdır.

Kaynak kod ve sahiplik neden en kritik madde?

Kaynak kod, yazılımın geliştiricilerin okuyup değiştirebildiği asıl halidir. Kodun kimde olacağı ve üzerindeki kullanım haklarının nasıl paylaşılacağı, uzun vadede en kritik maddedir. Bu konuda tek bir doğru model yoktur. Bazı projelerde tüm haklar müşteriye devredilir, bazılarında ise yazılım firmasının hazır altyapısı lisansla kullanılır. Önemli olan, seçilen modelin teklifte ve sözleşmede açıkça yazmasıdır. Hangi model seçilirse seçilsin, verilerinizin size ait olduğu ve istediğiniz an okunabilir bir biçimde teslim edileceği de yazılı olmalıdır. Kendinize şu soruyu sorun: yarın bu firmayla çalışmayı bırakırsam sistemi başka bir ekiple devam ettirebilir miyim?

Teklifleri karşılaştırırken hangi soruları sormalısınız?

• Kapsamdaki özellikler bizim günlük senaryolarımızı karşılıyor mu, kapsam dışında ne kaldı?
• Hangi aşamada neyi göreceğiz ve neyi onaylayacağız?
• Teklifteki süre hangi varsayımlara dayanıyor, bizden ne zaman ne bekleniyor?
• Kapsam değişirse bu nasıl fiyatlanıyor ve nasıl onaylanıyor?
• Yayından sonra hata düzeltme, bakım ve yeni geliştirme birbirinden nasıl ayrılıyor?
• Kaynak kod, belgeler ve sunucu hesapları kimde olacak?
• Daha önce benzer bir iş yaptınız mı, canlıda çalışan bir örneği görebilir miyiz?

Rakamları karşılaştırmadan önce bu soruların cevaplarını yan yana koyun. Çoğu zaman düşük görünen teklifin kapsamının dar, yüksek görünen teklifin ise sonradan ek iş çıkarmayacak kadar ayrıntılı olduğu ortaya çıkar. Teklifi hazırlayan ekibin size ne kadar soru sorduğuna da dikkat edin; işinizi anlamadan verilen bir teklif, ne kadar ayrıntılı görünürse görünsün tahmine dayanır. Adorb'da her projeye ücretsiz bir keşif görüşmesiyle başlıyor, kapsamı ve iş yükünü netleştirdikten sonra teklif hazırlıyoruz; çalışma modelini ve sahiplik koşullarını da baştan birlikte belirliyoruz.