Yazılım geliştirme sözleşmesinde nelere dikkat edilmeli

Yazılım sözleşmesi kapsamı, teslim ölçütlerini, ödemeyi ve kaynak kod sahipliğini yazıya döker. Kapsam, değişiklik yönetimi, garanti, KVKK, fesih ve devir maddeleri.

Kapsam, ödeme, teslim ve mülkiyet başlıklarına bölünmüş, aralarında onay işaretleri olan bir sözleşme sayfası şeması

Yazılım geliştirme sözleşmesi, neyin yapılacağını, nasıl teslim edileceğini, ne kadar ödeneceğini ve ortaya çıkan yazılımın kime ait olduğunu yazıya döken belgedir. İyi bir sözleşme anlaşmazlığı çözmez; anlaşmazlık çıkmasını engeller.

Yazılım projelerindeki sorunların çoğu kötü niyetten değil, belirsizlikten doğar: “bu kapsamda mıydı”, “bitti sayılır mı”, “kaynak kod kimde” gibi sorular. Bu yazı sözleşmede hangi başlıkların açık yazılması gerektiğini sıralıyor. Hukuki bir görüş değildir; nihai metni mutlaka bir hukukçuyla gözden geçirin.

Sözleşmede kapsam nasıl yazılmalı?

Kapsam, sözleşmenin en önemli maddesidir. “Kurumsal web sitesi yapılacaktır” gibi genel bir cümle yetmez. Şunlar yazılı olmalı:

  • Yapılacak sayfa, modül ve özelliklerin listesi.
  • Yapılmayacak şeyler (örneğin içerik yazımı, üçüncü taraf lisansları, ek diller).
  • Kullanılacak entegrasyonlar ve bunların sorumluluğu.
  • Desteklenecek cihaz ve tarayıcılar.

Kapsamı yazılı bir şartnameye dayandırmak en sağlam yoldur; bunun için yazılım şartnamesi nasıl hazırlanır yazısına bakın.

Kabul kriterleri neden gerekli?

“Proje tamamlandı” ifadesi, ölçütü yoksa tartışma konusudur. Her teslim için ölçülebilir kabul koşulları yazın:

  • Hangi senaryolar test edilecek?
  • Kabul testini kim, ne kadar sürede yapacak?
  • Hata bulunursa düzeltme için tanınan süre nedir?
  • Süre içinde itiraz gelmezse teslimin kabul edilmiş sayılıp sayılmayacağı.

Değişiklik yönetimi nasıl işlemeli?

Yazılım projesinde istek değişir; sorun değişikliğin kayıtsız olmasıdır. Sözleşmede şu mekanizma bulunmalı:

  1. Değişiklik yazılı talep edilir.
  2. Etkisi (süre, bütçe, kapsam) yazılı olarak bildirilir.
  3. İki taraf onaylamadan iş başlamaz.

Bu mekanizma olmadan bütçe aşımı kaçınılmazdır; ayrıntısı yazılım projesi bütçe aşımı yazısında.

Ödeme takvimi nasıl kurulmalı?

YaklaşımAvantajDikkat
Aşamaya bağlı ödemeHer ödeme somut bir teslime bağlanırAşamaların net tanımlanması gerekir
Takvime bağlı ödemeTahmin edilebilirTeslimle bağı zayıflayabilir
Süreye ve emeğe dayalı ödemeDeğişken kapsama uygunTavan ve raporlama şart

Genel mantık: ödemeyi, doğrulayabileceğiniz teslimlere bağlayın. Tutarlar ve vade sözleşmenin ticari kısmında yazılır; bu yazıda rakam vermiyoruz. Fiyat mantığı için yazılım geliştirme fiyatları yazısına bakabilirsiniz.

Kaynak kod ve fikri mülkiyet kimde olmalı?

Bu madde en çok atlanan ama en pahalıya patlayan maddedir. Açıkça yazılmalı:

  • Kaynak kodun teslim edilip edilmeyeceği ve hangi aşamada (ödemeyle birlikte mi) teslim edileceği.
  • Yazılımın mülkiyetinin ya da kullanım hakkının kime ait olduğu; hakkın süresiz mi, sınırlı mı olduğu.
  • Üçüncü taraf ve açık kaynak bileşenlerin lisansları.
  • Alan adı, sunucu, mağaza hesapları ve diğer hesapların müşteri adına açılması.
  • Yüklenicinin benzer işlerde yeniden kullanabileceği genel bileşenlerin sınırı.

Bizim önerimiz, kaynak kod ve hesap sahipliğinin sözleşmede açıkça yazılmasıdır. Aksi halde yüklenici değiştirmek istediğinizde elinizde bir şey kalmayabilir; bu durumu yazılım projesi devralma yazısında anlattık.

Garanti ve bakım nasıl düzenlenmeli?

  • Garanti süresi: Teslimden sonra ortaya çıkan hataların ücretsiz düzeltileceği dönem. Biz teslim sonrası 30 gün hata garantisi veriyoruz.
  • Garanti kapsamı: Hata ile yeni istek ayrımı. Hata, kabul kriterine uymayan davranıştır; yeni özellik değildir.
  • Bakım: Güvenlik güncellemesi, yedekleme, izleme ve küçük geliştirmelerin garanti sonrası nasıl yürüyeceği; ayrı bir sözleşme ya da ek olabilir.
  • Müdahale süresi: Kritik hatada ne kadar sürede dönüş yapılacağı.

Gizlilik ve KVKK nelere dikkat ister?

Yazılım projesinde yüklenici çoğu zaman sizin verilerinize, bazen müşterilerinizin kişisel verilerine erişir. Sözleşmede şunlar yer almalı:

  • Gizlilik yükümlülüğü ve süresi.
  • Kişisel veriye erişim varsa, tarafların KVKK kapsamındaki rolleri (veri sorumlusu, veri işleyen) ve veri işleme şartları.
  • Verinin nerede tutulduğu, kimlerin eriştiği ve proje bitince verinin ne olacağı.
  • Güvenlik ihlalinde bildirim süreci.

Bu başlıkta yükümlülüklerin ayrıntısı mevzuata ve veri türüne bağlıdır; hukukçunuzla teyit edin.

Fesih ve devir maddeleri neden önemli?

İyi niyetle başlayan işler de bitebilir. Önceden şunu yazın:

  • Hangi koşullarda hangi taraf sözleşmeyi feshedebilir ve ihbar süresi nedir.
  • Fesihte o ana kadar yapılan işin bedeli ve teslimi nasıl ele alınır.
  • Kaynak kod, dokümantasyon ve erişimlerin devir süreci: kim, ne zaman, hangi formatta teslim eder.
  • Devir sırasında yüklenicinin makul bir yardım yükümlülüğü.

Fesih maddesi kötü senaryo içindir ama en iyi o sırada işe yarar.

Sık sorulan sorular

Sözleşme olmadan yazılım projesi yapılır mı? Teknik olarak evet, ama kapsam, ödeme ve mülkiyet belirsiz kalır. Küçük projede bile kısa bir sözleşme ve yazılı kapsam şarttır.

Kaynak kodu istersem fazladan ücret mi öderim? Bu ticari bir pazarlıktır. Önemli olan konunun sözleşmede baştan yazılı olmasıdır; sonradan pazarlık etmek zayıf konumdur.

Sabit fiyat mı, süreye dayalı mı daha güvenli? Kapsamı net projelerde sabit fiyat öngörülebilirdir. Kapsamın değişeceği işlerde iki haftalık döngülerle ilerlemek ve her döngüde kapsamı yeniden onaylamak daha dengelidir.

Sözleşmeyi kim hazırlamalı? Taslağı yüklenici de hazırlayabilir; sizin için önemli olan, metni kendi hukukçunuzla gözden geçirmenizdir.

Garanti süresi bittikten sonra ne olur? Bakım düzeni ayrıca konuşulur. Hesaplar ve kaynak kod sizdeyse bakımı başka bir ekibe de verebilirsiniz.

Boygantech’te sözleşme öncesinde kapsamı ve teslim planını yazılı çıkarıyoruz. Projeniz için ilk görüşmeyi planlamak üzere iletişim formunu doldurun ya da info@boygantech.com adresine yazın.

İlgili yazılar

Bir fikriniz mi var, yoksa duran bir ürün mü?

Kısa bir görüşmede kapsamı netleştirelim. İlk konuşmada teknik yaklaşımı ve tahmini bütçe aralığını konuşuruz.

Bize yazın