Yazılım şartnamesi nasıl hazırlanır: teklifleri karşılaştırılabilir kılan altı başlık
Üç firmadan birbirini tutmayan üç teklif geliyorsa sorun firmalarda değil, şartnamededir. Şartname teknik bir belge değil, karar belgesidir — ne yazılmalı, ne yazılmamalı.
Aynı ihtiyacı üç firmaya anlatıp birbirini tutmayan üç teklif aldıysanız, ilk suçlanacak yer firmalar değil. Üçü de farklı bir şey anlamıştır — çünkü anlatılan şey her seferinde biraz değişmiştir.
Şartnamenin işi budur: firmaların aynı şeyi fiyatlamasını sağlamak. Teknik bir belge değildir, karar belgesidir. Yazması da yazılımcının değil, işi bilenin işidir.
Neyi yazmalı, neyi yazmamalı
Yazın: ne olacağı, kimin kullanacağı, hangi koşulda “bitti” sayılacağı.
Yazmayın: nasıl yapılacağı. Veritabanı seçimi, çatı, mimari — bunlar firmanın uzmanlık alanıdır ve şartnamede belirtilirse iki şey olur: daha iyi bir çözüm önerebilecek firmanın elini bağlarsınız, sonuç kötü çıkarsa sorumluluk da size geçer.
Tek istisna: mevcut sisteminizle uyumluluk zorunluluğu varsa onu yazın. “PostgreSQL kullanın” değil, “verimiz şu an PostgreSQL’de ve taşınmayacak” cümlesi doğru olandır.
Altı başlık
1 · İş amacı ve başarı ölçütü. Bu yazılım hangi sorunu çözüyor ve çözdüğünü nasıl anlayacaksınız? “Sipariş girişindeki telefon trafiğini yarıya indirmek” cümlesi, “modern bir sipariş sistemi” cümlesinden yüz kat kullanışlıdır.
2 · Kullanıcı rolleri. Kim girecek, kim ne görecek, kim neyi değiştirebilecek. Yetki matrisi sonradan eklenen bir özellik değildir; baştan yazılmazsa veri modelini bozar.
3 · Kritik akışlar. Hepsini değil — en çok kullanılan üç-beş tanesini adım adım yazın. “Müşteri sipariş verir” yetmez: hangi ekrandan başlar, hangi durumda ne olur, stok yoksa ne görür.
4 · Entegrasyonlar ve kimin sorumlu olduğu. Hangi sistemle konuşacak, o sistemin dokümantasyonu var mı, erişimi kim alacak. Bir entegrasyonun tarafı siz değilseniz — banka, e-fatura sağlayıcısı, kargo firması — başvuru süresini de şartnameye yazın. Takvimin en sık kayan yeri burasıdır.
5 · Veri. Mevcut veriniz var mı, aktarılacak mı, hangi formatta? Beş yıllık Excel arşivini taşımak başlı başına bir projedir ve unutulursa faturası sonradan gelir.
6 · Kabul kriterleri. Hangi koşulda onaylayacaksınız. Ölçülebilir yazın: “hızlı açılsın” değil, “ürün listesi 3G bağlantıda 3 saniyede açılsın”. Ölçülemeyen kriter, teslimde tartışma demektir.
Kapsam dışını da yazın
Şartnamenin en çok atlanan bölümü budur ve en çok para kurtaranıdır.
“Mobil uygulama bu projede yok”, “çok dillilik ikinci fazda”, “muhasebe entegrasyonu kapsam dışı”. Bu cümleler yazılmazsa her biri projenin ortasında “ama bu da olacaktı” tartışmasına dönüşür — bütçe aşımlarının tek en büyük sebebi budur.
Şartnameyi kim yazar
İdeal olan sizin yazmanızdır; kimse işinizi sizden iyi bilmez. Ama teknik karşılığını kuramıyorsanız bu normaldir ve çözümü şudur: keşif ayrı ve küçük bir iş olarak satın alınır.
Keşfin çıktısı yazılı kapsam belgesidir ve o belge sizindir — başka firmalardan teklif almak için de kullanabilirsiniz. Bunu kabul etmeyen firma, size belge değil bağımlılık satıyordur. Teklif görüşmesinde sorulacak ilk soru zaten budur.
Şartname, sürecin yalnızca bir adımıdır; ihtiyaç tanımından devre kadar tamamını yazılım yaptırmak yazısında sıraladık.
Şartname hazırsa sıradaki adım sözleşmedir: yazılım sözleşmesinde nelere dikkat edilmeli.
Kapsamı birlikte çıkarmak ve elinizde başka firmalara da gösterebileceğiniz bir belge kalmasını isterseniz görüşme planlayalım. Fiyatın bu belgeye nasıl bağlandığını fiyatlandırma yazısında anlattık.
