Yazılım tekliflerini yalnızca fiyat satırından okumak, sonradan kapsam kayması ve gizli maliyet riskini artırır. Bu rehberde teklifleri kapsam netliği, varsayımlar, risk payı ve teslim kriterleri üzerinden nasıl yan yana değerlendireceğinizi adım adım görebilirsiniz.
Yazılım proje teklifi değerlendirme süreci, çoğu işletmede yanlış yerden başlar: en düşük toplam tutara bakmak. Oysa teklif bir fiyat listesi değil; kapsam, varsayım, risk ve teslim sınırlarının yazılı ifadesidir. Aynı cümleyi farklı firmalar farklı genişlikte yorumlayabilir. Bu rehber, teklifleri yan yana koyup neyin dahil, neyin belirsiz, neyin sonradan bedelli olacağını netleştirmenize yardımcı olur.
Amaç, en ucuz teklifi seçmek değil; iş hedefinizi karşılamaya yetecek kadar net, ölçülebilir ve yönetilebilir bir anlaşma zemini bulmaktır.
Fiyat satırından önce neye bakmalısınız?
Toplam tutar, teklifin yalnızca özet satırıdır. Gerçek fark, o tutarın hangi iş kalemlerini, hangi kalitede ve hangi koşullarda kapsadığında çıkar. İki teklif aynı rakama yakın görünebilir; biri temel ekranları, diğeri entegrasyon, test, eğitim ve yayın sonrası desteği de içerebilir.
Karşılaştırmaya başlamadan önce kendi tarafınızda üç noktayı netleştirin:
- Çözülmesi gereken iş problemi ve başarı ölçütü nedir?
- Hangi süreçler, roller ve veriler sisteme girecek?
- Canlıya geçişte vazgeçilmez olan minimum işlev seti nedir?
Bu çerçeve yoksa teklifleri “ucuz / pahalı” diye ayırmak kolay, “yeterli / yetersiz” diye ayırmak zordur. KepezWeb gibi ekipler de teklifi genelde bu netlik üzerinden şekillendirir; sizin tarafınız da aynı dili konuşmalıdır.
Kapsam netliği nasıl okunur?
İyi bir teklifte kapsam, genel vaatler yerine modül, ekran, kural ve entegrasyon düzeyinde yazılır. “Yönetim paneli yapılır”, “raporlama vardır”, “mobil uyumlu olur” gibi ifadeler tek başına yeterli değildir. Bunlar neyi kapsar, neyi kapsamaz bilinmez.
Kapsam satırlarını şu sorularla okuyun:
- Hangi kullanıcı rolleri ve yetki seviyeleri tanımlı?
- Hangi iş kuralları açıkça yazılmış; hangisi “sonra netleşir”e bırakılmış?
- Entegrasyonlar (muhasebe, kargo, ödeme, e-posta, SMS, ERP/CRM) isim ve yön olarak belirtilmiş mi?
- Veri aktarımı, toplu yükleme, tarihsel kayıt taşıma dahil mi?
- Raporlar hazır şablon mu, yoksa özelleştirilebilir mi?
Kapsam netliği zayıfsa proje başladığında “bunu da kastetmiştik” tartışması büyür. Bu yüzden yazılım projesi rollerini ve karar yetkilerini teklif aşamasında netleştirmek, sonradan yaşanan yetki karmaşasını azaltır.
Dahil / hariç listesi zorunlu sayın
Teklifte “dahil olanlar” kadar “hariç tutulanlar” da değerli bir bölümdür. Hariç listesi yoksa, satıcı ile alıcı zihinde farklı bir ürün hayal eder. Özellikle şu kalemler belirsiz bırakıldığında sürpriz çıkar:
- Tasarım revizyon adedi ve marka kit uygulaması
- Üçüncü taraf lisans, API kotası ve altyapı ücretleri
- İçerik girişi, ürün aktarımı, kullanıcı eğitimi
- Çok dilli yapı, çok şirketli yapı, mobil uygulama
- Performans, güvenlik sertleştirme ve penetrasyon testi
Varsayımlar ve belirsizlikler teklifi nasıl değiştirir?
Varsayımlar, teklifin sessiz risk alanıdır. “Mevcut API belgelenmiş kabul edilmiştir”, “iş kuralları proje başında netleşecektir”, “müşteri içerikleri hazır verecektir” gibi satırlar fiyatı düşük tutabilir; ancak varsayım bozulunca süre ve bütçe bozulur.
Her varsayımı şu matrisle işaretleyin:
- Doğrulanmış: Sizin tarafınızda halihazırda net olan madde
- Koşullu: Belirli bir girdi gelirse geçerli olan madde
- Riskli: Henüz kanıtlanmamış teknik veya operasyonel varsayım
Riskli varsayımlar için teklifte iki seçenek arayın: keşif / analiz aşaması veya koşullu fiyatlandırma. “Her şey proje içinde çözülür” yaklaşımı, belirsizliği yok sayar; yok sayılan belirsizlik ise sonradan kapsam kayması olarak geri döner.
Risk payı, rezerv ve değişiklik yönetimi
Yazılım projelerinde belirsizlik sıfırlanmaz; yönetilir. Bu yüzden teklifte risk payının nasıl ele alındığına bakın. Risk payı bazen ayrı satırda görünür, bazen birim fiyatlara gömülür, bazen de hiç yazılmaz. Hiç yazılmayan risk, “ücretsiz esneklik” anlamına gelmez; genellikle sonradan değişiklik talebi olarak faturalanır.
Değerlendirirken şunları sorun:
- Değişiklik talebi (change request) süreci tanımlı mı?
- Küçük revizyon ile kapsam değişikliği ayrımı yapılmış mı?
- Sprint veya faz bazlı yeniden önceliklendirme mümkün mü?
- Gecikme senaryolarında sorumluluk ve bilgilendirme akışı net mi?
Agile yazılım geliştirme yaklaşımı kullanan ekiplerde teklif, devasa sabit paket yerine fazlı teslim ve düzenli demo üzerine kurulabilir. Bu model, doğru kurgulanırsa belirsizliği parçalara böler; yanlış kurgulanırsa “sürekli açık bütçe” hissi yaratır. Kritik olan, faz çıkış kriterlerinin yazılı olmasıdır.
Teslim kriterleri ve kabul koşulları
Bir teklifin en az okunan, en çok tartışma yaratan bölümü teslim ve kabul kısmıdır. “Proje tamamlanır” ifadesi ölçülebilir değildir. Kabul kriteri; hangi senaryoların geçmesi, hangi ortamda test edileceği ve hangi eksiklerin engelleyici sayılacağı ile tanımlanır.
Güçlü bir teklifte aramanız gerekenler:
- UAT (kullanıcı kabul testi) kapsamı ve örnek senaryo seti
- Hata sınıfları (engelleyici, yüksek, düşük) ve kabul eşiği
- Canlıya alma kontrol listesi ve geri alma planı
- Kaynak kod, erişim bilgisi, dokümantasyon ve devir maddeleri
- Garanti / destek penceresinin neyi kapsadığı ve neyi kapsamadığı
Güvenlik, yedekleme, yetkilendirme ve loglama gibi başlıklar “var” denerek geçiştirilmemelidir. İşletme tarafında kontrol edilebilecek temel maddeler için uygulama güvenliği kontrol listesi yaklaşımı, teklif görüşmelerinde somut soru üretmeye yardımcı olur.
Yazılım proje teklifi değerlendirme: yan yana kontrol listesi
Aşağıdaki tabloyu her teklif için doldurun. Amaç puan vermek değil; belirsiz satırları görünür kılmaktır. Bir satır “belirsiz” ise, imza öncesi yazılı netleştirme isteyin.
| Kontrol alanı | Teklif A | Teklif B | Not / risk |
|---|---|---|---|
| Kapsam maddeleri ölçülebilir mi? | |||
| Hariç tutulanlar listesi var mı? | |||
| Varsayımlar açık yazılmış mı? | |||
| Entegrasyonlar isim ve yönle tanımlı mı? | |||
| Test ve UAT kapsamı net mi? | |||
| Değişiklik talebi süreci tanımlı mı? | |||
| Teslim çıktıları (kod, erişim, doküman) listelenmiş mi? | |||
| Bakım / destek sınırı açık mı? | |||
| Rol ve iletişim modeli belli mi? | |||
| Toplam tutar ile kapsam uyumlu mu? |
Karşılaştırmada en düşük tutar değil, en az “belirsiz” satırı olan ve sizin iş riskinizi yöneten teklif genelde daha sağlıklıdır. Ucuz görünen ama varsayımı bol teklif, proje ortasında pahalıya dönüşebilir.
Ekip, süreç ve iletişim modeli
Teklif yalnızca teknik kapsam değil, çalışma biçimidir. Kim product owner gibi karar verecek, kim haftalık demo yapacak, kim öncelik değişikliğini onaylayacak? Bunlar yazılmadığında proje teknik olarak ilerlese bile karar kuyruğunda yavaşlar.
Süreç tarafında bakılacak pratik işaretler:
- Tek irtibat noktası ve yedek iletişim kanalı
- Düzenli demo / durum raporu sıklığı
- Gereksinim değişikliğinin yazılı onay akışı
- Ortamlar: geliştirme, test, canlı ayrımı
- Bilgi güvenliği ve erişim yönetimi pratiği
Özel yazılım ihtiyacınız netleştiyse, teklifleri okurken yalnızca ajans vaadini değil, geliştirme yaklaşımını da değerlendirin. KepezWeb’in yazılım geliştirme çalışmalarında da olduğu gibi, başarılı sonuç genelde net kapsam + düzenli geri bildirim + ölçülebilir kabul kriteri üçlüsünden çıkar.
Sıkça Sorulan Sorular
En ucuz yazılım teklifi neden riskli olabilir?
Düşük tutar çoğu zaman dar kapsam, belirsiz varsayım veya hariç tutulan kritik kalemler nedeniyle oluşur. Fark, proje ortasında değişiklik talebi olarak geri dönebilir. Önce kapsam ve teslim sınırını, sonra fiyatı okuyun.
Teklifte kapsam kaymasını nasıl önlerim?
Dahil/hariç listesi, varsayımlar, değişiklik talebi süreci ve kabul kriterlerini yazılı hale getirin. “Sonra bakarız” bırakılan her madde potansiyel kapsam kaymasıdır.
Sabit fiyat mı, fazlı model mi daha doğru?
Gereksinimler olgun ve sınırlıysa sabit fiyat daha yönetilebilir olabilir. Belirsizlik yüksekse keşif fazı veya net çıkış kriterli fazlı model daha sağlıklıdır. Modelden bağımsız olarak teslim tanımı net olmalıdır.
Teklif karşılaştırmasında hangi belgeyi istemeliyim?
En azından kapsam özeti, varsayımlar, hariçler, zaman planı yaklaşımı, kabul kriterleri ve destek sınırı içeren yazılı teklif isteyin. Sözlü vaatleri değerlendirme tablosuna almayın.
Tek bir teklifle ilerlemek doğru mu?
Mümkünse en az iki-üç teklifi aynı kontrol listesiyle yan yana okuyun. Amaç pazarlık değil; kapsam dilini ve risk yaklaşımını karşılaştırmaktır.
Yazılım proje teklifi değerlendirme işini disiplinli yürüttüğünüzde, imza anındaki belirsizlik azalır ve proje boyunca konuşulan dil ortaklaşır. Kapsamınızı netleştirip teklifleri yan yana okumak istiyorsanız, ihtiyaç özetinizi teklif al sayfasından iletebilirsiniz. KepezWeb ekibi, yalnızca fiyat satırına değil; kapsam, varsayım ve teslim kriterlerine odaklanarak size uygun bir çerçeve çıkarmanıza yardımcı olur.
