Sabit fiyat ancak sabit kapsamla işe yarar
Sabit fiyatlı web projeleri hep aynı nedenle kötü bir üne sahip: fiyat sabitlenmiş, kapsam sabitlenmemiştir. Belirsiz gereksinimler sonradan varsayımlarla doldurulur ve anlaşmazlık işin ortasında, çözmenin en pahalı olduğu anda ortaya çıkar. O noktada veri modeli oturmuş, migration’lar yazılmıştır; herkesin istediği değişiklik de her katmana dokunur. Bu anlaşmazlıkların çoğu teklifteki tek bir belirsiz satırdan çıkar.
Tek bir belirsiz satırın bedeli
Teklifteki tek bir satır haftalarca işi gizleyebilir. “Ürün konfigüratörü” bunun en açık örneği. aux-garagen.de’deki konfigüratörde 41 seçenek var ve emeğin çoğu bunlar arasındaki ilişkilerde. Seçenekler başka seçeneklere bağlıdır, bazı kombinasyonlar birbirini dışlar. Bazıları fiziksel olarak mümkündür ama satılmamalıdır; bu yüzden müşteri fiyat görmeden önce bir şeyin onları reddetmesi gerekir. Fiyat kuralları zamanla değişir; bu yüzden saklanan bir teklif fiyatlandığı kuralları da tutar, yoksa yeniden üretilemez. Para birimi ve KDV baştan kararlaştırılır.
Sunucu taraflı dönüşüm takibi de aynı özeni ister. Kapsam belgelerimizde takip satırı her olayı, nereden gönderildiğini, sunucu olayının tarayıcı olayıyla nasıl eşleştiğini ve ziyaretçi izin vermezse ne olacağını yazar. Bu liste olmadan takibin bitip bitmediğini anlamanın üzerinde anlaşılmış bir yolu yoktur.
Belgeye ne giriyor
Kapsamı geliştirme başlamadan yazıyor ve müşteriyle yazılı olarak kararlaştırıyoruz: sayfalar, işlevler, entegrasyonlar, revizyon turu sayısı ve açıkça kapsam dışında kalanlar. Belge bir teknik şartname gibi okunur. Her işlev satırı belgeye girmeden önce aynı sorulara cevap verir:
Onu ne tetikliyor ve beklenen sonuç ne
Girdiyi kim sağlıyor: metin, görsel, ürün verisi, fiyat listeleri, API kimlik bilgileri
Hata durumunda ne oluyor: geçersiz bir kombinasyon, reddedilen bir rıza, erişilemeyen bir üçüncü taraf servisi
Sonucun teslimde nasıl doğrulanacağı, iki tarafın da gözleyebileceği ölçütlerle
O satırın açıkça neyi içermediği
Bazı satırlar idaridir ve onlar da aynı belgeye girer. Ödeme %50 peşin, %50 teslimde, 14 gün vadelidir; bu düzen ancak “teslim”in ne olduğu belgede yazılıysa işler.
Değişiklik talepleri ve revizyon turları
Sabit kapsamın bir bedeli var ve bu bedel müşteriye olduğu kadar bize de çıkıyor. İşin ortasında biri daha iyi bir fikir buluyor ve çoğu zaman fikir gerçekten daha iyi. Onu sessizce üstlenmek yerine bir değişiklik talebi olarak yazıyoruz. Sessizce üstlenmek o an daha dostça görünür ve sabit fiyatlı işlerin bozulmasının nedeni de budur: takvim, kimse karar vermeden kayar ve bu ancak sonda, konuşacak zaman kalmadığında görünür.
Aynı ayrım revizyonlar için de geçerli. Revizyon turu, iki tarafın zaten yapmayı kabul ettiği bir şeyi düzeltir; belgenin dışındaki her şey, e-postada adı ne olursa olsun, bir değişiklik talebidir. En çok tartışılan çizgi budur; bu yüzden teslim baskısı başlamadan belgede yer almalıdır. Standart bir site yaklaşık bir hafta sürer ve bu süre işin ortasında yeniden tanımlamaya yer bırakmaz.
Belgenin çözemedikleri
Belgenin çözemediği ilk şey içeriktir. Sayfa yapısını alan alan yazabiliriz ama metin ve fotoğraflar gelmeden iş ilerlemez. İşe yarayan, müşteriden neye ihtiyacımız olduğunu belgede, bağımlılık zamanında görünecek kadar erken yazmaktır. İkinci boşluk üçüncü taraf sistemlerdir: ödeme sağlayıcıları ve reklam platformları davranışlarını haber vermeden değiştirir; bu yüzden her entegrasyon belgede adıyla yer alır.
Üçüncü durum, ne istediğini henüz bilmeyen bir müşteridir. Teknik şartname erken karar almaya zorlar ve bu kararların bazıları erken kalır. Bu durumda daha küçük bir ilk iş öneriyoruz: doğru tarif edilebilecek kadar dar bir kapsam, gerisi sonraki tura.
Kapsam belgesi doğru olduğunda son fatura teklifle aynı çıkar; yalnız yazılı kararlaştırılan değişiklikler eklenir.
Bu tür işleri nasıl kapsamlayıp fiyatladığımız hizmetler sayfasında.
