Yazılım projelerinde bütçeyi aşan şey çoğu zaman kötü kod ya da yavaş ekip değildir; kimsenin açıkça karar vermediği küçük eklemelerdir. "Şu ekrana bir filtre de olsa" ya da "bildirim de gelse iyi olur" cümleleri tek başına masum görünür, ama toplamda proje başka bir projeye dönüşür. Buna kapsam kayması diyoruz ve ona karşı en etkili savunma, teklif aşamasında kuruluyor.
Kayma neden olur
Deneyimlerimize göre nedenler genellikle üç başlıkta toplanıyor: gereksinimin iki tarafta farklı anlaşılması, proje ilerledikçe gerçekten yeni bir ihtiyacın doğması ve değişikliğin maliyetinin görünmemesi. İlki teklif aşamasında çözülebilir, ikincisi yönetilebilir, üçüncüsü ise süreç kurularak şeffaflaştırılabilir. Sorun, bu üçünün karışıp "anlaşmazlık" olarak yaşanması.
Teklifte neyi netleştirmeli
İyi bir teklif fiyattan önce sınırı çizer. Bizim her tekliften önce müşteriyle cevapladığımız sorular şunlar:
- Hangi kullanıcı rolleri var ve her biri neyi yapabiliyor?
- Hangi ekranlar ve akışlar kapsamda, hangileri açıkça kapsam dışı?
- Hangi dış sistemlerle entegrasyon var (ödeme, ERP, SMS, harita) ve bunların testi için kim erişim sağlayacak?
- Hangi platformlar destekleniyor: iOS, Android, web, hangi minimum sürümlerden itibaren?
- "Bitti" ne demek: kabul kriterleri kim tarafından, nasıl onaylanacak?
"Kapsam dışı" listesi en az kapsam listesi kadar değerlidir. Yazılmayan şey, çoğu zaman karşı tarafın zihninde dahildir.
Belirsizliği fiyatlamak
Her şeyi baştan bilmek mümkün değil, bunu kabul etmek gerekiyor. Belirsiz kalan kalemleri saklamak yerine ayrı gösteriyoruz: sabit fiyatlı çekirdek kapsam, ayrıca keşif gerektiren kalemler için ayrı bir analiz çalışması. Örneğin bir üçüncü taraf API'sinin dokümantasyonu yetersizse, o entegrasyonu teklifin içinde sabit fiyatla vermek yerine önce kısa bir teknik doğrulama çalışması öneriyoruz. Böylece iki taraf da tahmine değil, veriye dayanarak karar veriyor.
Değişiklik yönetimi: kural önceden konuşulmalı
Proje başladıktan sonra yeni istek gelmesi doğal ve sağlıklı. Önemli olan bunun bir yolu olması. Sözleşmede ya da proje planında şu adımlar yer almalı:
- Her yeni istek yazılı olarak kaydedilir; sözlü "bir şey daha" talepleri kayda alınmadan işe başlanmaz.
- İstek için süre ve maliyet etkisi, onaydan önce müşteriye gösterilir.
- Müşteri üç yol arasından seçer: ek bütçeyle ekle, kapsamdan eşdeğer bir kalemi çıkar ya da sonraki sürüme bırak.
Bu yapı kimseyi engellemiyor; sadece her değişikliğin bir bedeli olduğunu görünür yapıyor. Müşteri açısından da avantajlı, çünkü fatura sürpriz olmaktan çıkıyor.
Süreç boyunca erken uyarı
Kapsam kayması çoğu zaman bir günde değil, haftalar içinde birikiyor. Kısa aralıklı demolar ve her sprint sonunda kapsam listesiyle karşılaştırma, kaymayı küçükken yakalamanın en ucuz yolu. Ekran görüntüsü yerine çalışan bir sürümü müşteriyle birlikte denemek, "ben bunu böyle düşünmemiştim" cümlesinin kodlama bittikten sonra değil, ilk haftalarda gelmesini sağlıyor.
Müşteri tarafında tek bir karar vericinin belirlenmesi de aynı derecede önemli. Farklı departmanlardan gelen çelişkili istekler, ekibi sürekli yön değiştirmeye zorluyor. Tek bir kişi önceliği belirlerse hem takvim hem bütçe korunuyor.
Kapsam konuşmalarında sık yaşanan bir başka sorun, aynı kelimenin farklı şeyleri anlatması. "Admin paneli" bir tarafta üç ekranlık basit bir yönetim alanı, diğer tarafta raporlama, yetkilendirme ve dışa aktarma içeren tam bir ürün olabilir. Bu yüzden teklif aşamasında ekran listesini ve her ekranın ne yaptığını birkaç cümleyle yazmak, belirsiz kalan kavramı somutlaştırıyor. Tel kafes ya da basit bir akış şeması, sayfalarca metinden daha hızlı ortak anlayış sağlıyor. Anlaşılan her kavramı teklife ve proje notlarına yazmak, ay sonra dönüp bakılacak ortak bir referans bırakıyor. Böylece tartışma kişisel yorumlara değil, yazılı kayda dayanıyor.
Bir yazılım projesi planlıyorsanız ve teklifi sağlam bir kapsam üzerine kurmak istiyorsanız, iletişim sayfamızdan bize yazın. 2010'dan bu yana 500'ün üzerinde projede gördüğümüz net bir gerçek var: iyi yazılmış bir kapsam, projenin ilk ve en ucuz kalite kontrolüdür.