Kapsam belgesi olmadan yazılım fiyatı neden verilmez?

Kapsamı yazılı olmayan bir yazılım projesine verilen sabit fiyat ya müşteriyi ya geliştiriciyi zarara sokuyor; bu yüzden fiyatı analiz bittikten ve kapsam belgesi karşılıklı onaylandıktan sonra veriyoruz. Kapsam belgesi bir formalite değil, projenin neyi kapsadığını ve neyi kapsamadığını iki tarafın da aynı biçimde okuduğunun kanıtı.

Kapsam belgesi ne işe yarıyor

Belgenin asıl işlevi, sonradan çıkacak tartışmaları baştan bitirmek. Yazılım teslim edildiğinde en sık yaşanan anlaşmazlık bir hatadan değil, tarafların aynı cümleden farklı şey anlamasından doğuyor. Müşteri “stok takibi olacak” derken şubeler arası transferi de düşünüyor, geliştirici tek depo anlıyor. İkisi de haklı; eksik olan şey yazı.

İyi bir kapsam belgesi şunları içeriyor: hangi iş akışlarının yazılıma gireceği, her akışta hangi rolün ne yapacağı, hangi ekranların olacağı, hangi dış sistemlerle bağlantı kurulacağı, hangi verinin aktarılacağı ve açıkça kapsam dışı bırakılan konular. Son madde en çok atlanan ve en çok işe yarayan madde.

Bizim belgemizde sabit bir kapsam dışı kalem de var: fatura kesme ve muhasebeleştirme işini üstlenmiyoruz. Geliştirdiğimiz sistem faturanın kesilip kesilmediğini takip eder ve gereken kaydı muhasebe sistemine aktarır; faturayı kesen ve resmî kaydı tutan sistem ayrıdır. Bu bilinçli bir sınır ve baştan yazılı duruyor.

Belgenin ikinci faydası bütçe tarafında. Kapsam yazıldığı anda projenin hangi parçasının pahalı olduğu görünür hale geliyor ve bazı maddeler ilk sürümün dışına alınabiliyor. Her şeyi birinci sürüme sığdırmaya çalışmak yerine çalışan bir çekirdekle başlayıp üzerine eklemek, hem bütçeyi hem riski düşürüyor. Bu kararı ancak yazılı bir liste üzerinde konuşmak mümkün.

Analiz masa başında yapılmıyor

Kapsam belgesini üretmenin tek yolu analiz ve analiz toplantı odasında bitmiyor. İşi gerçekten yapan kişiyle birlikte mevcut akışı adım adım yazıyoruz:

1. Kayıt sisteme nereden giriyor? Telefonla mı, siteden mi, elle mi?
2. Kimin onayından geçiyor ve onay vermeyen kişi ne yapıyor?
3. Hangi noktada bekliyor ve neden bekliyor?
4. Hangi bilgiyi kim arıyor da bulamıyor?
5. Bugün hangi iş Excel tablosunda, mesajlaşma grubunda ya da kâğıt formda yürüyor?

Beşinci soru en verimlisi. Excel tabloları ve mesaj grupları, hazır programın kapatamadığı boşluğun tam olarak nerede olduğunu gösteriyor. O boşluk, yazılacak yazılımın asıl gövdesi oluyor.

Analiz sırasında ortaya çıkan ikinci şey, bazı isteklerin yazılımla değil süreçle çözülmesi gerektiği. Her isteği koda çevirmek yerine hangisinin gerçekten yazılım gerektirdiğini birlikte işaretliyoruz; her işe özel yazılım önermiyoruz.

Sabit fiyat mı, aylık ayrılmış ekip mi

İki çalışma biçimiyle de ilerliyoruz ve seçim kapsamın ne kadar net olduğuna bağlı.

İkisi arasındaki seçimi analizden sonra birlikte yapıyoruz. Kapsamı belirsizken sabit fiyat vermek, ya eksik iş teslim etmek ya da yarı yolda kalan bir proje bırakmak anlamına geldiği için bunu yapmıyoruz.

İki haftalık turlar ve ilerlemenin ölçülmesi

Geliştirme iki haftalık turlar hâlinde yürüyor ve her turun sonunda çalışan bir sürüm görüyorsunuz. Ekranı yayına yakın bir ortamda kendiniz kullanıyor, not düşüyorsunuz; bir sonraki tur o notlarla başlıyor.

Bu düzen iki işi birden yapıyor. Birincisi, yanlış anlaşılmayı erken yakalıyor: bir ekranın beklenenden farklı çalıştığı ikinci haftada anlaşılırsa düzeltmesi küçük bir iş, altıncı ayda anlaşılırsa büyük bir iş. İkincisi, projenin ne kadar ilerlediğini tahmine değil çalışan ekrana bakarak ölçmenizi sağlıyor. Yüzde kaç bitti sorusunun cevabı bir his değil, kullanabildiğiniz ekranların listesi oluyor.

Turların işe yaraması için tek şart var: müşteri tarafında her turun sonunda ekranı deneyip karar verebilecek bir muhatap olması. Geri bildirim gelmediğinde turlar tahmin üzerine yürümeye başlıyor ve düzenin bütün faydası kayboluyor. Bu yüzden kapsam görüşmesinde kimin karar verdiğini de yazıya geçiriyoruz.

Kapsam değişikliği nasıl yönetiliyor

Hiçbir projede kapsam baştan sona aynı kalmıyor ve bu bir sorun değil. Sorun, değişikliğin kayıt altına alınmadan yürümesi. İzlediğimiz yol şu: her yeni istek yazılı olarak listeye giriyor, etkisi (süre ve bağımlılık) not ediliyor, sonra ya mevcut turun dışına alınıyor ya da başka bir maddenin yerine konuyor.

• Küçük değişiklikler aynı turun içinde çözülüyor.
• Yeni bir iş akışı ek kapsam olarak ayrıca değerlendiriliyor.
• Önceliği değişen maddeler listede yer değiştiriyor; aylık ayrılmış ekip modelinde bu bedelsiz oluyor.
• Teknik borç da listeye yazılıyor; yalnızca görünen işlerin takip edildiği projelerde bu kalem birikiyor ve sonra bir anda ödeniyor.

Kısa kontrol listesi

• Kapsam belgesi yazılı ve iki tarafça onaylı mı?
• Kapsam dışı bırakılan konular açıkça yazıldı mı?
• Analiz, işi yapan kişiyle birlikte mi çıkarıldı?
• Çalışma biçimi (sabit fiyat ya da ayrılmış ekip) kapsamın netliğine göre mi seçildi?
• İlerleme çalışan sürümle mi ölçülüyor?
• Yeni istekler yazılı bir listeye mi giriyor?
• Veri aktarımı ve geçiş planı kapsamın içinde mi?

KAV Yazılım projelerinde süreyi ve fiyatı ilk görüşmede değil analiz bittiğinde veriyor; kapsam belgesi ve takvim birlikte çıkıyor.