Maliyeti belirleyen işin kendisidir
Yazılım bütçesine ekran sayısıyla başlamak yanıltıcıdır. Asıl soru, kullanıcının hangi işi baştan sona tamamlayacağı ve bu sırada hangi istisnalarla karşılaşacağıdır. Yetkiler, mevcut kayıtların taşınması, dış sistemlerle bağlantılar, hata sonrası toparlanma ve yayına hazır olduğumuzu gösterecek kontroller de bu işin parçasıdır. Bu yüzden beş ekranlı iki ürünün gerektirdiği emek birbirinden çok farklı olabilir.
Bir tedarikçi portalı üzerinden hesaplayalım
Yalnızca hesap yöntemini göstermek için kurguladığımız bir tedarikçi portalını düşünelim. Keşif ve tasarım için 8, ana iş akışı için 15, entegrasyon için 6, doğrulama için 5 ve yayına hazırlık için 3 kişi-gün ayıralım. Toplam 37 kişi-gün eder. Bunlar bir teklif veya piyasa ölçütü değil, örnek varsayımlardır. Mutabık kalınan günlük ücretle çarpıldığında işçilik tahmini elde edilir. Barındırma ve sürekli destek bu hesaba ayrıca eklenir; kişi-gün toplamı da işlerin paralel yürütülebilmesine bağlı olarak takvim süresinden farklıdır.
Tahmini gözden geçirilebilir bir kapsam tablosuna dönüştürün
Her iş kalemi için beklenen sonucu, dayandığı varsayımı, sorumlu kişiyi ve kabul sırasında gösterilecek kanıtı yazın. Tedarikçi portalında yalnızca “entegrasyon” yazması karşılaştırma yapmaya yetmez. Bunun yerine, onaylanan siparişin tedarikçiye bir kez iletileceğini, dış sistemden bir referans alınacağını ve aktarım başarısız olduğunda siparişin takip edilebilir kalacağını belirtin. Tedarikçinin test hesabını sunup sunmadığı ve bu erişimi kimin sağlayacağı da aynı tabloda yer alsın. Böylece düşük görünen bir teklifin, başka birinin hesaba katılmamış emeğine dayanıp dayanmadığını anlayabilirsiniz. Teklifleri aynı sorumluluklar üzerinden karşılaştırın.
İstisnaların kapsamda olup olmadığını birlikte inceleyin
Sorunsuz bir siparişin yanında zor bir örneği de adım adım ele alın: ürünlerden biri satıştan kalkıyor, onaydan sonra teslimat adresi değişiyor ve tedarikçi geç yanıtlıyor. Bu durumların hangileri mevcut tahmine dahil? Hangisi bir varsayımı geçersiz kılıyor? İyi bir kapsam görüşmesi, teklifin tamamını yeniden açmak yerine etkilenen iş kalemini netleştirir. Yeterli bilgi yoksa küçük bir inceleme çalışması ve onun sonucunda verilecek karar üzerinde anlaşın. Belirsizlik payını yeni özellik ekleme bütçesiyle karıştırmayın: biri üzerinde anlaşılan işin belirsizliğini karşılar, diğeri yeni bir kapsam kararı gerektirir.
Yayına çıkış ve işletme maliyetlerini ayrı değerlendirin
İlk sürümden sonra da yedeklerin kontrol edilmesi, güncellemelerin uygulanması, başarısız aktarımların araştırılması ve operasyon sorularının yanıtlanması gerekir. Bu sorumlulukların işletmede mi, stüdyoda mı, başka bir sağlayıcıda mı olacağını ve aralarındaki devirleri açıklayın. Bir destek talebinin hangi noktada ayrıca onaylanacak geliştirme işine dönüştüğünü baştan konuşun. Tahmini kabul etmeden önce bir kabul testi örneğini, kapsam dışındaki işleri, dış servis ücretlerini, hesapların sahipliğini ve kullanılmayan belirsizlik payının nasıl ele alınacağını kontrol edin. Amaç bütün gelecek faturaları tahmin etmek değil; sonradan alınacak kararları iki tarafın da anlayabildiği bir anlaşmaya dayandırmaktır.
Belirsizliğe uygun bir teklif modeli seçin
Belirsizliğin gerçek olduğu yerde tek rakam yerine gerekçeli bir aralık isteyin. Belgeleri ve test erişimi bulunan bir API için daha dar bir entegrasyon tahmini yapılabilir; içeriği henüz bilinmeyen bir dışa aktarım için aynı güven beklenemez. Küçük bir ücretli keşif çalışması bu belirsizliği azaltabilir. Sabit kapsamlı bir teklif ise kabul örnekleri ve bağımlılıklar netleştiğinde daha anlamlıdır. Hangi fiyatlandırma modeli seçilirse seçilsin sorumlulukların tanımlanması gerekir.
Görünmeyen işleri hesabın dışında bırakmayın
Veri temizliğini geliştirme işinin içine saklamayın; doğrulamayı da “zaman kalırsa yapılacak” bir iş olarak görmeyin. Tahminin neleri dışarıda bıraktığını ve hangi müşteri kararlarının hesabı değiştireceğini yazın. Bir belirsizlik payı ayrılıyorsa bunu açıklamasız bir yüzdeyle değil, henüz sağlanmamış erişim gibi somut risklerle ilişkilendirin.
İlk görüşmeye hangi yanıtlarla gelmeli?
Örnek veriyi kim sağlayacak, erişim kurallarını kim onaylayacak ve bir işlem hangi durumda tamamlanmış sayılacak? Özel yazılım görüşmesine bu soruların yanıtlarıyla gelmek bütçe konuşmasını somutlaştırır. Kullanışlı bir tahmin yalnızca bir toplam vermez; varsayımlarını ve hangi yeni bilginin bu hesabı değiştireceğini de açıklar.