Yazılım projesi teslim uyuşmazlıkları: neden çıkar, teknik olarak nasıl incelenir?

Tipik tablo şöyledir. İş sahibi yazılımın teslim edilmediğini, eksik ya da çalışmaz teslim edildiğini söyler ve kalan ödemeyi durdurur. Yüklenici işin şartnameye uygun bittiğini, sistemin aylardır kullanıldığını, istenen yeni özelliklerin kapsam dışı olduğunu söyler ve ödeme bekler. Böyle dosyalarda iki tarafın da kısmen haklı çıkması şaşırtıcı değildir. Teknik incelemenin işi, tartışmayı "yazılım çalışıyor mu" sorusundan çıkarıp "şartnamenin 4.2 maddesi, teslim edilen sürümde, şu koşulda karşılanıyor mu" sorusuna indirmektir.

Uyuşmazlık genellikle nereden çıkar?

Teknik kökler birkaç başlıkta toplanır; bir dosyada çoğu zaman birkaçı birlikte bulunur.

Aynı cümle, iki okuma: belirsiz şartname

Ölçüt içermeyen bir maddeyi her taraf kendi beklentisiyle okur. Sık gördüğümüz örnekler:

Hangi okumanın geçerli olduğu teknik bir soru değildir; sözleşmenin yorumu avukatın ve mahkemenin işidir. Teknik inceleme bu maddeleri ölçülemez diye işaretler, teklifte, toplantı notunda ya da yazışmada maddeyi somutlaştıran bir ifade varsa onu yanına koyar ve gerekirse durumu iki okumaya göre ayrı ayrı gösterir. Belgeler arasında bir öncelik sırası (sözleşme mi, şartname mi, teklif mi) yazılmamışsa bu da not edilir.

Kabul prosedürü yok

Şartname neyin yapılacağını söyleyip teslimin nasıl sınanacağını söylemiyorsa kabul ya hiç yaşanmaz ya da kimsenin fark etmediği bir anda yaşanır. Test ortamı, test verisi, iş sahibinin sonuç bildirme süresi ve hangi önem derecesindeki hatanın kabulü engelleyeceği yazılmamıştır. Sistem bir gün canlıya alınır, kullanıcılar çalışmaya başlar, hatalar dağınık e-postalarla bildirilir. Aylar sonra sorulan "yazılım kabul edildi mi?" sorusunun cevabı hukukidir. Teknik olarak gösterilebilecek olan ise gerçek kullanımın başladığı an ve o anda açık olan hatalardır: ilk gerçek siparişin oluşturulma zamanı, uygulama loglarında test hesapları dışındaki ilk oturumlar, mağaza konsolundaki ilk yayın tarihi, o tarihte iş takip aracında açık duran kayıtlar.

Yazıya geçmeyen değişiklik talepleri

İş sahibi yazılımı gördükçe yeni şeyler ister; bu doğaldır. Sorun, taleplerin toplantıda, telefonda ya da bir mesajlaşma grubunda kalmasıdır. Her biri "küçük bir ekleme" olarak girer ve hiçbirinin süreye ve bedele etkisi yazılmaz. Teslimde iş sahibi bu özellikleri kapsamın parçası sayar, yüklenici ek iş; ikisi de gecikmenin diğerinden kaynaklandığını söyler. İncelemede bu taleplerin izini yazışmalarda, iş takip kayıtlarında ve depo geçmişinde sürer, hangisinin sözleşmeden sonra geldiğini ve kodda ne zaman karşılık bulduğunu tarihiyle gösteririz.

"Teslim" kelimesinin kendisi

Yazılımda teslimin tek bir biçimi yoktur ve taraflar çoğu zaman farklı birini kasteder:

• Kaynak kodun, geçmişiyle birlikte iş sahibinin deposuna aktarılması.
• Çalışan sistemin iş sahibinin sunucusunda ya da bulut hesabında kurulu olması.
• Mobil uygulamanın iş sahibinin geliştirici hesabından mağazada yayımlanması.
• Alan adı, sunucu, e-posta, ödeme kuruluşu ve SMS sağlayıcısı gibi hesapların devri.

Hesaplar yüklenicinin üzerindeyse, uyuşmazlık başladığı gün iş sahibi kendi sistemine erişemeyebilir. Bu teknik incelemeyi de zorlaştırır, çünkü en değerli kayıtlar erişilemeyen hesaplarda kalır.

İş sahibinin payı ve dış hizmetler

Her gecikme yükleniciden kaynaklanmaz. İçeriğin, test verisinin, entegrasyon anahtarlarının ya da karşı sistem erişiminin iş sahibinden geç gelmesi; e-fatura entegratörü, ödeme kuruluşu veya kargo firması gibi üçüncü tarafların API'lerini değiştirmesi de "yazılım çalışmıyor" şikâyetinin arkasından çıkabilir. Bu yüzden kronolojiye yalnızca yüklenicinin değil, iş sahibinin ve dış sağlayıcıların adımlarını da koyarız.

Teknik incelemede neye bakılır?

İnceleme dört kaynağı birbirine bağlar. Yöntemin ayrıntısını yazılım ve kaynak kod incelemesi sayfasında anlattık; burada her kaynağın neden önemli olduğunu ve sınırını özetliyoruz.

1. Şartname eşlemesi. Sözleşme, şartname, teklif ekleri ve yazılı değişiklik taleplerinden numaralı bir gereksinim listesi çıkarılır; her madde teslim edilen sürümde test edilip "karşılandı, kısmen, karşılanmadı, test edilemedi" diye işaretlenir. Ölçütsüz maddeler ayrıca gösterilir, hiçbiri ölçülmüş gibi sunulmaz. İlk iş, "teslim edilen sürüm"ün hangisi olduğunu sabitlemektir: etiket, commit, paketin SHA-256 değeri.
2. Depo geçmişi. Git geçmişi bir özelliğin hangi tarihte, hangi hesaplar adına koda girdiğini ve çalışmanın zamana nasıl yayıldığını gösterir. Sınırı da bellidir: commit'teki yazar adı ve tarihler, commit'i oluşturan bilgisayarda serbestçe ayarlanabilir (GIT_AUTHOR_DATE, GIT_COMMITTER_DATE, git commit --date). Bu yüzden commit tarihleri depo platformunun push kayıtları ve CI/CD çalışma zamanları gibi sunucu tarafı kayıtlarla karşılaştırılır.
3. İş takip kayıtları ve yazışmalar. Jira, GitHub Issues ya da benzeri bir araçtaki kayıt yalnızca son durumu değil değişiklik geçmişini de taşır: hata kim tarafından, hangi tarihte açıldı, kaç kez kapatılıp yeniden açıldı, önem derecesi ne zaman değişti. E-postalar orijinal biçimleriyle (.eml, .msg) alınır; metin içinde iletilmiş (forward) kopyalar çoğu zaman özgün başlık bilgisini taşımaz.
4. Test ortamı. Hata, belgelenmiş ve yalıtılmış bir ortamda yeniden üretilebildiği ölçüde bulgu olur. Kaynağın kod mu, yapılandırma mı, veri mi, dış hizmet mi olduğu ayrılır. Testte çalışıp canlıda çalışmayan bir işlev çoğu zaman ortam farkına işaret eder.

Bu dört kaynak bir kronolojide birleşince tartışmanın çoğu kendiliğinden daralır. Örnek (kurgusal): taraflar "toplu fiyat güncelleme" özelliğinin kapsamda olup olmadığını tartışıyor.

Tablo, özelliğin sözleşmeden sonra istendiğini, yüklenicinin ek süre şartı koyup yine de kodladığını ve canlıya geçişten sonra bildirilen bir hatanın açık kaldığını gösterir. Özelliğin kapsama girip girmediği, ek süre ya da bedel doğurup doğurmadığı ise hukuki değerlendirmedir.

Uyuşmazlık başladığında ilk günlerde ne yapılmalı?

Hukuki adımları avukatınızla planlayın; bildirimlerin biçimi ve zamanı hukuki sonuç doğurabilir. Teknik taraftaki öncelik, bugünkü durumu değiştirmeden kayda geçirmektir. Adımların çoğu iki taraf için de aynıdır:

1. Teslim edilen durumu dondurun. Canlı sistemin ve veri tabanının yedeğini ya da anlık görüntüsünü (snapshot) alın, SHA-256 değerini kaydedin. Yeni bir ekip yazılımı "düzeltmeye" başlamadan önce bunu yapın; sonradan yapılan her değişiklik, teslim anındaki durumun gösterilmesini zorlaştırır.
2. Depoyu geçmişiyle kopyalayın. git clone --mirror bütün dalları ve etiketleri alır; ZIP olarak indirilen kod geçmiş taşımaz. Dışa aktardığınız dosyaların değerini hash hesaplama aracıyla alabilirsiniz; neden gerektiği hash ve delil bütünlüğü yazısında.
3. İş takip kayıtlarını ve platform etkinliğini değişiklik geçmişiyle birlikte dışa aktarın.
4. Yazışmaları orijinal biçimleriyle saklayın. E-postaları .eml olarak, mesajlaşma uygulamalarındaki konuşmaları uygulamanın dışa aktarma işleviyle.
5. Kendi kayıtlarınızı toplayın. Yüklenici için zaman çizelgeleri, demo kayıtları, teslim e-postaları, dağıtım (deployment) logları; iş sahibi için hata bildirimleri, ekran kayıtları, kullanıcı şikâyetleri.
6. Erişimlere dokunmadan önce düşünün. Sunucuyu kapatmak, depoyu silmek, geçmişi force push ile yeniden yazmak ya da karşı tarafın erişimini kesmek, önce sizin lehinize olabilecek kayıtları yok edebilir; hukuki sonuçlarını avukatınız değerlendirir. Yetkiniz olmayan bir hesaba ya da sunucuya girmeyin: bu suç oluşturabilir (TCK m.243) ve böyle elde edilen kayıt delil olarak kullanılamayabilir.

Hukuki çerçeve: avukatın ve mahkemenin alanı

Yazılım geliştirme sözleşmelerine çoğu zaman eser sözleşmesi hükümleri (TBK m.470 vd.) uygulanır; somut sözleşmenin nasıl nitelendirileceği avukatın değerlendirmesidir. Bu hükümler uygulanırsa süreler kısadır: iş sahibi teslimden sonra eseri imkân bulur bulmaz gözden geçirip ayıpları uygun süre içinde bildirmelidir (m.474/1), bunu ihmal ederse eser kabul edilmiş sayılabilir (m.477); ayıp nedeniyle açılacak davalar taşınmaz yapılar dışındaki eserlerde, yüklenicinin ağır kusuru yoksa, teslimden itibaren iki yılda zamanaşımına uğrar (m.478). "Ayıp", "kusur" ve "kabul" hukuki kavramlardır. Teknik rapor bunları kullanmaz, gözlenen durumu kanıtıyla yazar.

Dava açıldığında teknik incelemeyi mahkemenin görevlendirdiği bilirkişi yapar (HMK m.266); Bilirkişilik Daire Başkanlığının alt uzmanlık listesinde "Yazılım" (18.02) ve "Bilişim Proje Yönetimi" (18.10) ayrı alanlardır. TBK m.474/2 de her iki tarafa, giderini karşılayarak eserin bilirkişi tarafından gözden geçirilmesini ve sonucun raporla belirlenmesini isteme imkânı verir; dava öncesinde HMK m.400'deki delil tespiti de bir yoldur. Taraflar ise kendi seçtikleri uzmandan uzman görüşü alıp dosyaya sunabilir (HMK m.293). İkisinin farkını uzman görüşü ile bilirkişi raporu yazısında anlattık. md9 bilirkişi değildir; taraflardan biri için teknik rapor ya da uzman görüşü hazırlar.

Bir sonraki projede uyuşmazlığı küçültmek için

Uyuşmazlığı tamamen önleyen bir şartname yoktur; iyi bir şartname tartışmayı küçük ve ölçülebilir tutar. Teslim uyuşmazlıklarını incelerken eksikliğini en çok gördüğümüz düzenlemeler:

• Belgeler arası öncelik sırası. Sözleşme, şartname, teklif ve toplantı notu çeliştiğinde hangisinin geçerli olacağı baştan yazılsın.
• Numaralı gereksinimler ve kabul senaryoları. Her maddenin karşısında teslimde nasıl sınanacağı. Nasıl yazıldığını proje danışmanlığı ve teknik şartname sayfasında örnekledik.
• Değişiklik talebi kaydı: numara, tarih, isteyen, süreye ve bedele etkisi, iki tarafın onayı.
• Depo baştan iş sahibinin hesabında. Yüklenici bu depoya yazma yetkisiyle çalışırsa teslim tek bir anda değil sürekli gerçekleşir ve geçmişi iki taraf da görür.
• Her teslimde aynı paket. Etiketlenmiş sürüm, paketin SHA-256 değeri, sürüm notu, tarihli kabul tutanağı.
• Alan adı, sunucu, mağaza geliştirici hesabı, ödeme ve SMS sağlayıcıları iş sahibi adına.
• Kaynak kod emaneti. Kod iş sahibine verilmeyecekse, güncel sürümün bağımsız bir yerde saklandığı bir emanet (escrow) düzeni.
• Aşamalı kabul. Büyük tek bir teslim yerine küçük aşamalar ve her aşamada açık hata listesi.
• Yüklenici için: kapsam dışı bir işe yazılı onay almadan başlamamak, demo ve teslim toplantılarını kayda geçirmek, iş sahibinden beklenen içerik ve erişimlerdeki gecikmeleri tarihiyle not etmek.