Yazılım Projesi Teklifi: Kapsam Kaymasını Önleyen Teklif Yapısı

Yazılım projesi teklifinde kapsam kaymasını önlemenin yolu, neyin yapılacağını olduğu kadar neyin yapılmayacağını da yazmak ve sonradan gelen her yeni isteği ayrı bir değişiklik talebiyle fiyatlandırmaktır. Bunlara bakım anlaşması ile kaynak kod ve fikri mülkiyet maddeleri de eklendiğinde teklif, projenin ortasında çıkabilecek tartışmaların çoğunu önceden çözer.

Bu yazıda kurgusal Deniz Yazılım'ın bir kargo firmasına hazırladığı kurye takip uygulaması teklifini örnek alıyoruz.

Kapsam kayması neden olur?

Kapsam kayması genellikle kötü niyetten değil, belirsizlikten doğar. Teklifte “Kurye takip uygulaması” yazıyorsa, müşteri bunun içinde bildirimleri, raporları, yönetici panelini ve belki de müşterilerin göreceği bir takip ekranını düşünür. Ajans ise yalnızca kuryenin konumunu gönderdiği bir mobil uygulama ve basit bir harita ekranı fiyatlamıştır.

Her küçük istek “bu da olur herhalde” diye kabul edildiğinde, proje planlanan süreyi aşar ve kâr erir. Çözüm, belirsizliği teklif aşamasında gidermektir.

Kapsam belgesi: ne yapılacak?

Teklifin kalbi kapsam belgesidir. Teknik ayrıntıya boğmadan ama yoruma yer bırakmadan her modülü ve temel özelliklerini yazın. Kullanıcı rolleri üzerinden gitmek, müşterinin de kolayca anlamasını sağlar.

• Kurye mobil uygulaması (Android ve iOS): giriş, günlük teslimat listesi, teslimat durumu güncelleme, teslim fotoğrafı, konum gönderimi
• Operasyon paneli (web): kuryeleri haritada görme, teslimat atama, günlük teslimat raporu
• Yönetici paneli: kullanıcı ekleme ve yetkilendirme, kurye bazında aylık rapor
• Kabul kriteri: Her modül, müşteri tarafından belirlenen test senaryolarıyla doğrulanır ve yazılı onayla teslim alınmış sayılır.

Kabul kriteri maddesi önemlidir. “Bitti mi, bitmedi mi?” sorusunu kişisel yoruma bırakmaz.

Kapsam dışı listesi

Müşterinin aklına gelebilecek ama bu projede olmayan şeyleri açıkça yazın. Bu liste, ileride “bunu da yapacaktınız” tartışmasını baştan bitirir.

• Son müşterinin göreceği gönderi takip ekranı
• Müşterinin mevcut muhasebe ya da depo yazılımıyla veri alışverişi
• Uygulama içi mesajlaşma
• Sunucu ve barındırma ücretleri (müşteri adına açılır, müşteri öder)
• Uygulama mağazası geliştirici hesap ücretleri
• İçerik girişi ve ilk kullanıcı verilerinin aktarılması

Fazlara bölünmüş fiyatlandırma

Büyük bir projeye tek bir sabit fiyat vermek, bütün tahmin riskini ajansa yükler. Projeyi fazlara ve iki haftalık geliştirme dönemlerine (sprint) bölmek, hem ödemeyi ilerlemeye bağlar hem de her aşamada kapsamı gözden geçirme imkânı verir.

Ödemeyi fazlara bağlayın: keşif bedeli işe başlarken, tasarım bedeli tasarım onayında, her sprint bedeli o sprintin demosunda, son kalem teslimde. Böylece hiçbir taraf uzun süre riskte kalmaz. Keşif fazını ayrı satın alınabilir yapmak da iyi bir yoldur: müşteri yalnızca keşfi alırsa, elinde başka bir ajansa da götürebileceği bir kapsam belgesi olur.

Değişiklik talebi ve ek teklif

Proje başladıktan sonra yeni istekler gelecektir; bu normaldir. Önemli olan, bunların nasıl ele alınacağının teklifte yazılı olmasıdır. Örnek madde:

Kapsam belgesinde yer almayan her istek değişiklik talebi olarak değerlendirilir. Talep için 3 iş günü içinde süre ve ücret içeren ek teklif hazırlanır. Ek teklif yazılı olarak onaylanmadan geliştirmeye başlanmaz. Ek işler saatlik 1.500 ₺ + KDV üzerinden fiyatlandırılır.

Örneğin müşteri üçüncü sprintte son müşterilere SMS ile teslimat bildirimi gönderilmesini istedi. Ekip bunun 24 saat süreceğini tahmin ediyor: 24 × 1.500 = 36.000 ₺, KDV ile 43.200 ₺. Ek teklif bu tutarı ve takvime etkisini (bir hafta ek süre) açıkça gösterir. SMS sağlayıcısının ücreti ise müşteriye aittir; bunu da ek teklifte yazın.

Her ek teklifi ana teklifle ilişkilendirin: “TK-2026-0088 numaralı teklife ek 1.” Sürümleri karıştırmamak için teklif revizyon takibi rehberindeki numaralandırma düzenini kullanabilirsiniz.

Bakım anlaşması

Yazılım teslim edildiğinde iş bitmez. İşletim sistemi güncellemeleri, kütüphane güncellemeleri ve küçük hatalar için bir bakım anlaşması önerin. Bu hem müşteriyi korur hem de ajansa düzenli gelir sağlar.

• Kapsam: hata giderme, güvenlik ve uyumluluk güncellemeleri, aylık 8 saate kadar küçük düzenleme
• Müdahale süresi: uygulamayı kullanılamaz hale getiren hatalarda aynı iş günü, diğerlerinde 3 iş günü
• Ücret: aylık 12.000 ₺ + KDV, yıllık peşin ödemede 12 × 12.000 = 144.000 ₺ + KDV
• Kapsam dışı: yeni özellikler (değişiklik talebiyle fiyatlandırılır)

Teslimden sonraki ilk 60 gün için ücretsiz hata giderme süresi tanımlamak da yaygındır. Bu süre içinde bulunan, kapsam belgesine aykırı hatalar ücretsiz düzeltilir.

Fikri mülkiyet ve kaynak kod devri

Sıklıkla atlanan ama sonradan en çok soruna yol açan konudur. Teklifte şu soruları cevaplayın:

• Kaynak kod ne zaman ve nasıl teslim edilir? Örneğin tüm ödemeler tamamlandığında müşterinin kod deposuna aktarılır.
• Projede kullanılan açık kaynak kütüphaneler kendi lisanslarına tabidir; bu lisanslar müşteriye devredilmez, yalnızca koşullarına uyulur.
• Ajansın başka projelerde de kullandığı kendi genel bileşenleri varsa, bunların kullanım hakkı nasıl verilir?
• Ajans projeyi referans olarak gösterebilir mi?

Bu maddeler hukuki sonuç doğurur. Büyük projelerde teklifin yanında ayrı bir sözleşme hazırlayın ve bir avukata kontrol ettirin.

Teklif toplantısında sorulacak sorular

Kapsam belgesini yazabilmek için müşteriden doğru bilgiyi almak gerekir. Keşif görüşmesinde şu soruları sormak, sonradan ortaya çıkacak sürprizleri azaltır:

• Uygulamayı kimler, hangi cihazlarda kullanacak?
• Şu an bu iş nasıl yapılıyor? Hangi dosya, program ya da kağıt kullanılıyor?
• İlk sürümde mutlaka olması gereken üç özellik hangisi? Hangileri sonraya kalabilir?
• Başka bir sistemle veri alışverişi gerekecek mi?
• Projede karar verecek kişi kim, testleri kim yapacak?
• Yayına çıkış için sabit bir tarih var mı?

“Sonraya kalabilir” denen özellikleri kapsam dışı listesine “ikinci faz adayı” olarak yazın. Müşteri unutulmadıklarını görür, siz de ilk sürümün kapsamını korursunuz.

Teklif hazırlarken kontrol listesi

• Kapsam belgesinde her modül ve kabul kriteri var mı?
• Kapsam dışı listesi yazıldı mı?
• Fiyat fazlara bölündü mü, ödemeler aşamalara bağlandı mı?
• Değişiklik talebi süreci ve saatlik ücret belirtildi mi?
• Bakım anlaşması ayrı fiyatla önerildi mi?
• Kaynak kod devri ve lisans maddeleri var mı?
• Geçerlilik süresi yazıldı mı?

Teklifhazır'da fazları ve sprintleri kalem olarak girip toplam ve KDV'yi otomatik hesaplatabilir, ek teklifleri de aynı düzende hazırlayıp PDF olarak indirebilirsiniz. Yazılım ajanslarına özel diğer notlar yazılım ajansları sayfamızda. Tutarları hızlıca kontrol etmek için KDV hesaplama aracı da işinize yarar.

Sık sorulan sorular

Sabit fiyat mı, zaman ve malzeme mi?

Kapsamı net, küçük projelerde sabit fiyat müşteriye güven verir. Kapsamı belirsiz ya da sürekli değişen projelerde sprint bazlı ya da saatlik çalışma riski daha adil paylaştırır.

Keşif fazı için ücret almak doğru mu?

Ayrıntılı analiz ve kapsam belgesi gerçek bir emektir. Ücretlendirip iş alınırsa toplam bedelden düşmek, hem emeğinizi korur hem de müşteriyi ikna eder.

Müşteri değişiklik talebini ücretsiz isterse?

Teklifteki maddeyi hatırlatın. Küçük bir isteği jest olarak yapabilirsiniz ama bunu da yazılı olarak “ücretsiz ek” diye kaydedin; aksi halde emsal olur.

Bakım anlaşması zorunlu mu olmalı?

Zorunlu tutmak yerine önerin ve olmadığı durumda ne olacağını yazın: bakım anlaşması yoksa sonraki talepler saatlik ücretle ve müsaitliğe göre karşılanır.