Bir yazılım firmasından teklif aldığınızda ilk karşılaşacağınız soru çoğu zaman "ne kadar?" olur. Asıl belirleyici soru ise "nasıl ödeyeceğiz?" sorusudur. Yazılım sözleşme modelleri, bütçenizin ne kadar öngörülebilir olacağını, değişikliklere ne kadar esnek davranabileceğinizi ve riski kimin taşıyacağını belirler.
Bu yazıda sabit fiyat ve adam/saat modellerini, ikisinin arasındaki hibrit yapıları ve her modelin hangi proje türüne uyduğunu ele alıyoruz. Sonunda, sözleşme masasına oturmadan önce kullanabileceğiniz bir kontrol listesi de bulacaksınız.
Yazılım Sözleşme Modelleri Neden Bu Kadar Önemli?
Yazılım, inşaat gibi başlangıçta tüm detayları çizilebilen bir iş değildir. Gereksinimler proje ilerledikçe netleşir, kullanıcı geri bildirimi önceliklerin sırasını değiştirir ve entegre edilecek üçüncü taraf sistemler beklenmedik kısıtlar çıkarır. Sözleşme modeli, bu belirsizliğin maliyetini kimin üstleneceğini önceden yazıya döker.
Yanlış model seçimi iki tipik sonuç doğurur. Belirsiz bir projeyi sabit fiyata bağlarsanız her değişiklik talebi bir pazarlığa dönüşür. Net tanımlı bir projeyi adam/saat ile yürütürseniz bütçe kontrolünü kaybedersiniz. Her iki durumda da asıl kaybeden, ürünün kalitesi ve taraflar arasındaki güven olur.
Modeli seçmeden önce şu üç soruya net cevap vermeniz gerekir:
- Kapsam ne kadar net? Ekranlar, iş kuralları ve entegrasyonlar yazıya dökülmüş mü?
- Bütçe ne kadar esnek? Üst limit kesin mi, yoksa değer üretildikçe genişleyebilir mi?
- Süreçte ne kadar yer alabilirsiniz? Haftalık toplantılara, hızlı karar vermeye ve geri bildirime zaman ayırabilecek bir ürün sahibiniz var mı?
Sabit Fiyat Modeli Nasıl Çalışır?
Sabit fiyat (fixed price) modelinde taraflar önceden belirlenmiş bir kapsam için tek bir bedel üzerinde anlaşır. Ödeme genellikle aşamalara bölünür: sözleşme imzası, tasarım onayı, test sürümü teslimi ve canlıya çıkış gibi. Kapsam dışında kalan her iş, değişiklik talebi olarak ayrıca fiyatlandırılır.
Sabit fiyatın avantajları
- Bütçe öngörülebilirliği: Finans ve yönetim onayı almak kolaylaşır.
- Net teslimat beklentisi: Ne zaman, neyin teslim edileceği sözleşmede yazılıdır.
- Düşük yönetim yükü: Saat takibi ve haftalık efor raporlarıyla uğraşmazsınız.
- Karşılaştırma kolaylığı: Aynı şartnameye gelen teklifleri yan yana koymak mümkündür.
Sabit fiyatın gizli riskleri
Sabit fiyat, riski tamamen müşteriden alıp yazılım firmasına aktarıyormuş gibi görünür. Gerçekte risk, sözleşmeye farklı bir biçimde yansır. Firma belirsizlikleri fiyata "risk payı" olarak ekler. Projenin ortasında kapsam tartışması çıkarsa da tarafların motivasyonu çatışır: müşteri her şeyin kapsamda olduğunu savunur, firma ise kapsamı dar yorumlamaya çalışır.
Bir diğer risk, "sözleşmeye uygun ama işe yaramayan" teslimattır. Kapsam eksik tanımlandıysa ürün sözleşmedeki maddeleri karşılasa bile gerçek ihtiyacı çözmeyebilir. Bu yüzden sabit fiyat, ancak detaylı bir şartname ile birlikte sağlıklı çalışır. Şartnameyi nasıl hazırlayacağınızı teknik şartname hazırlama rehberimizde adım adım anlattık.
Adam/Saat (Time & Material) Modeli
Adam/saat modelinde ödeme, harcanan efor üzerinden yapılır. Her rol (geliştirici, tasarımcı, test uzmanı, proje yöneticisi) için belirlenen saatlik veya günlük birim oran, gerçekleşen çalışma süresiyle çarpılır ve genellikle aylık faturalanır. Kapsam sabit bir listeden çok, öncelik sırasına göre ilerleyen bir iş listesidir (backlog).
Bu modelin gücü esnekliktir. Sprint sonunda gördüğünüz çıktıya göre yönü değiştirebilir, önemsiz çıkan bir özelliği bırakıp kaynağı daha değerli bir işe kaydırabilirsiniz. Değişiklik talebi için pazarlık yapmanız gerekmez, çünkü değişiklik sürecin doğal bir parçasıdır.
Zayıf yönü ise bütçenin açık uçlu olmasıdır. Kontrol mekanizması kurulmazsa maliyet, plandan sessizce uzaklaşabilir. Ayrıca saat bazlı ücretlendirmede verimlilik artışının faydası müşteriye kendiliğinden yansımaz. Yapay zekâ destekli kodlama araçları gibi iş akışını hızlandıran yöntemler yaygınlaştıkça, "kaç saat harcandı" sorusu tek başına yeterli bir ölçüt olmaktan çıkıyor. Saat verisinin yanında her sprintte üretilen çalışan yazılımı da ölçmelisiniz.
Adam/saat modelini güvenle yürütmek için şu kontrolleri sözleşmeye ekleyin:
- Aylık veya sprint bazlı tavan bütçe: Aşılması için yazılı onay gerekir.
- Şeffaf efor raporu: Kim, hangi görevde, kaç saat çalıştı sorusu görev bazında izlenebilir.
- Düzenli demo: Her sprint sonunda çalışan sürüm gösterilir.
- Çıkış hakkı: Makul bir bildirim süresiyle sözleşmeyi sonlandırabilir ve kodu devralabilirsiniz.
Sabit Fiyat ve Adam/Saat Karşılaştırması
| Kriter | Sabit Fiyat | Adam/Saat | Hibrit (Aşamalı) |
|---|---|---|---|
| Bütçe öngörülebilirliği | Yüksek | Düşük–orta (tavanla artar) | Orta–yüksek |
| Kapsam esnekliği | Düşük | Yüksek | Orta |
| Başlangıçta gereken netlik | Çok yüksek | Düşük | Orta |
| Riski taşıyan taraf | Ağırlıklı olarak firma (fiyata yansır) | Ağırlıklı olarak müşteri | Paylaşımlı |
| Müşteri katılım ihtiyacı | Orta | Yüksek | Yüksek |
| Uygun proje tipi | Net tanımlı, sınırlı projeler | Keşif ağırlıklı, uzun soluklu ürünler | Kapsamı kısmen belirsiz kurumsal projeler |
Hibrit ve Alternatif Yazılım Sözleşme Modelleri
Pratikte en sağlıklı sonuçlar çoğu zaman iki uç modelin arasında, kapsamın netlik düzeyine göre kurgulanan yapılardan gelir. En sık kullanılan seçenekler şunlardır:
- Keşif aşaması + sabit fiyat: İlk 2–4 hafta analiz, prototip ve teknik mimari için küçük bir adam/saat veya sabit paket olarak yürütülür. Çıkan net kapsam için gelişim aşaması sabit fiyatla sözleşmelenir.
- Tavanlı adam/saat (not-to-exceed): Saat bazlı çalışılır ancak toplam bütçe için üst limit konur. Limite yaklaşıldığında taraflar kapsamı yeniden değerlendirir.
- Aşamalı (milestone) sabit fiyat: Proje fazlara bölünür, her faz ayrı fiyatlandırılır. Bir sonraki faz, önceki fazın çıktısına göre netleşir.
- Adanmış ekip / aylık kapasite: Belirli sayıda uzman, aylık sabit bedelle ürününüz için çalışır. Sürekli geliştirilen ürünlerde ve SaaS platformlarında yaygındır.
- Bakım ve destek (SLA) sözleşmesi: Canlıya çıkışın ardından hata düzeltme, güvenlik güncellemesi ve küçük iyileştirmeler için ayrı bir aylık paket tanımlanır.
Belirsizliği azaltmanın bir başka yolu, ilk aşamada yalnızca çekirdek özellikleri hayata geçirmektir. MVP yaklaşımı, hem bütçe riskini küçültür hem de sonraki fazları gerçek kullanıcı verisine göre fiyatlandırmanıza imkân tanır.
Hangi Proje İçin Hangi Model? Üç Gerçekçi Senaryo
Senaryo 1: Mevcut bir sürecin dijitale taşınması
Bir üretim firması, Excel üzerinden yürüttüğü sipariş takibini web tabanlı bir panele taşımak istiyor. Ekranlar, roller ve raporlar mevcut sürece bakılarak tanımlanabiliyor. Bu durumda sabit fiyat uygundur, çünkü kapsam büyük ölçüde bilinir. Yine de ilk haftalarda yapılacak kısa bir analiz çalışması, fiyatın gerçekçi olmasını sağlar.
Senaryo 2: Yeni bir dijital ürün fikri
Bir girişimci, abonelik tabanlı bir SaaS ürünü planlıyor. Hangi özelliğin kullanıcıya değer katacağı henüz belli değil. Burada kapsamı baştan sabitlemek, yanlış özelliklere bütçe harcamak anlamına gelir. Tavanlı adam/saat veya adanmış ekip modeli, ürünün öğrenerek ilerlemesine izin verir.
Senaryo 3: Eski sistemin modernizasyonu
Kurumsal bir firma, on yıllık bir sistemi parça parça yenilemek istiyor. Eski sistemin gizli iş kuralları ancak kodun içine girildiğinde ortaya çıkar. Keşif aşaması + aşamalı sabit fiyat yapısı hem yönetim onayı için bütçe görünürlüğü sağlar hem de sürprizlere alan bırakır.
Sözleşme İmzalamadan Önce Kontrol Listesi
Model ne olursa olsun, aşağıdaki maddeler sözleşmede açıkça yer almalıdır:
- Kapsam tanımı: Dahil olan ve özellikle dahil olmayan işler, ekran ve entegrasyon listesiyle birlikte yazılı.
- Kabul kriterleri: "Tamamlandı" ifadesinin ölçülebilir karşılığı (hangi senaryolar çalışmalı, hangi testler geçmeli).
- Değişiklik yönetimi: Değişiklik talebinin nasıl iletileceği, nasıl fiyatlanacağı ve kim tarafından onaylanacağı.
- Ödeme planı: Ödemelerin takvime değil, doğrulanabilir teslimatlara bağlanması.
- Fikri mülkiyet ve kaynak kod: Kodun, tasarım dosyalarının ve dokümantasyonun mülkiyeti ile teslim biçimi.
- Garanti ve bakım: Canlıya çıkış sonrası hata düzeltme süresi ve sonrasındaki destek koşulları.
- Gizlilik ve veri güvenliği: KVKK kapsamındaki veriler için sorumluluklar ve erişim yetkileri.
- Fesih ve devir koşulları: Sözleşme sona erdiğinde projenin sorunsuz devredilmesini sağlayan hükümler.
Kapsam kayması, hangi model seçilirse seçilsin bütçeyi ve takvimi en çok sarsan etkendir. Önleme yöntemleri için kapsam kayması rehberimize göz atabilirsiniz.
Doğru Modeli Seçmek İçin 5 Adım
- Belirsizliği ölçün: Gereksinimlerin yüzde kaçını ekran ve iş kuralı düzeyinde anlatabildiğinizi dürüstçe değerlendirin.
- Bütçe esnekliğinizi belirleyin: Kesin bir üst limitiniz varsa tavanlı veya aşamalı bir yapı tercih edin.
- Keşif aşamasını planlayın: Kısa bir analiz çalışması, ister sabit ister saat bazlı olsun, teklifin güvenilirliğini ciddi biçimde artırır.
- Teklifleri aynı zemine getirin: Farklı modellerdeki teklifleri kıyaslarken kapsam, varsayım ve hariç tutulan işleri tabloya dökün. Bu konuda yazılım teklifi karşılaştırma rehberimiz yardımcı olur.
- Yönetişimi tanımlayın: Kimin karar vereceğini, toplantıların ne sıklıkla yapılacağını ve raporlamanın nasıl işleyeceğini sözleşme ekine yazın.
Sık Sorulan Sorular
Sabit fiyat her zaman daha ucuz mudur?
Hayır. Sabit fiyat bütçeyi öngörülebilir kılar ama otomatik olarak düşürmez. Firma belirsizlik riskini fiyata yansıtabilir, kapsam dışı kalan işler de sonradan ek maliyet doğurur. Toplam sahip olma maliyetini, değişiklik talepleri dahil değerlendirmek gerekir.
Adam/saat modelinde bütçe kontrolden çıkar mı?
Kontrol mekanizması kurulmazsa çıkabilir. Tavan bütçe, görev bazlı efor raporu, sprint sonu demo ve yazılı onay şartı gibi önlemlerle model güvenle yönetilebilir. Önemli olan şeffaflık ve düzenli ölçümdür.
Proje ortasında model değiştirilebilir mi?
Evet, taraflar mutabık kalırsa mümkündür. Örneğin keşif sonrası kapsam netleşince saat bazlı çalışmadan sabit fiyatlı faza geçilebilir. Bunu sözleşmede baştan öngörmek, ileride zaman ve pazarlık kaybını önler.
Kaynak kodun mülkiyeti hangi modelde kime ait olur?
Mülkiyet, seçilen fiyatlama modeline değil sözleşme maddelerine bağlıdır. Özel geliştirilen yazılımda kodun, tasarımın ve dokümantasyonun hangi koşulda müşteriye devredileceği açıkça yazılmalıdır. Bu hükmü hukuk danışmanınızla birlikte gözden geçirmenizi öneririz.
Küçük bütçeli projeler için hangi model uygundur?
Kapsamı net ve sınırlı projelerde sabit fiyat genellikle en pratik seçenektir. Kapsam belirsizse önce küçük bir keşif paketi ve MVP ile başlamak, bütçeyi korurken hatalı yatırım riskini azaltır.
Sonuç: Doğru Yazılım Sözleşme Modeli Kapsamınıza Bağlı
Yazılım sözleşme modellerinde evrensel bir "en iyi" yoktur. Kapsamı net olan projelerde sabit fiyat, keşif ve öğrenme ağırlıklı ürünlerde adam/saat ya da adanmış ekip, ikisinin arasında kalan kurumsal projelerde ise aşamalı hibrit yapılar daha sağlıklı sonuç verir. Model ne olursa olsun kabul kriterleri, değişiklik yönetimi ve şeffaf raporlama sözleşmenin vazgeçilmez parçalarıdır.
CodeStup olarak her projeyi, kapsamın netliği ve bütçe beklentisine göre en uygun çalışma modeliyle ele alıyoruz. Elinizdeki fikri ya da şartnameyi paylaşın, birlikte hangi modelin size daha uygun olduğunu değerlendirelim. Projeniz için ücretsiz ön görüşme ve teklif almak üzere bizimle iletişime geçin.
