Yazılım Yaptırmadan Önce Sorulacak 20 Kritik Soru

“Kaynak kod teslim edilir” cümlesi tek başına yeterli değildir. Sözleşmede kodun hangi ortamda (örneğin müşterinin Git deposunda) ve hangi tarihte devredileceği, fikri mülkiyet haklarının müşteriye geçtiği, üçüncü taraf lisansların hangilerinin devredilemediği yazılı olmalıdır. Aksi halde teslim tartışmalı hale gelir ve yazılımı başka bir ekibe taşımanız fiilen imkânsızlaşır.

İkisi de sizin adınıza ve sizin erişebildiğiniz hesaplarda olmalıdır. Domain firmanın e-posta adresiyle açılırsa yenileme, taşıma ve DNS değişikliği için her seferinde firmaya bağımlı kalırsınız; anlaşmazlık halinde markanızın alan adına erişememe riski doğar. Sunucu için de yönetici erişim bilgilerinin sizde bir kopyasının bulunmasını sözleşmeye yazdırın.

Evet, tamamını peşin ödemek teslim güvencenizi zayıflatır. Sağlıklı model düşük peşinat ve ardından teslim edilen aşamalara bağlı ödemelerdir: tasarım onayı, geliştirme aşamaları, kabul testi ve yayın. Her ödeme somut bir çıktıya bağlıysa hem firma düzenli ilerlemeye teşvik olur hem de sorun çıktığında kaybınız o ana kadarki aşamayla sınırlı kalır.

Kapsam net ve yazılıysa sabit fiyat sizi korur; fiyat değişmez, risk firmadadır. Kapsam araştırmayla şekilleniyorsa sabit fiyat ya şişirilir ya da sonradan ek işlerle büyür; bu durumda adam/gün daha dürüsttür. Adam/gün seçerseniz mutlaka tavan bütçe, haftalık harcanan süre raporu ve tavan aşılmadan önce yazılı onay şartı isteyin.

Yeterli değildir. Aşamalara bölünmüş tarihli takvim isteyin: tasarım onayı, geliştirme, entegrasyon, test ve yayın. Ayrıca gecikme yönetimini sorun; gecikmelerin önemli bölümü koddan değil, geç gelen içerik ve onaylardan kaynaklanır. Bu yüzden takvimde sizin sorumluluğunuzdaki maddelerin de tarihli olması, iki tarafı da korur.

Bunu doğrudan sorun. Toplantıya gelen ekip ile kodu yazan ekip farklı olabilir; iş alt yükleniciye ya da yurt dışına devrediliyor olabilir. Alt yüklenici kullanmak tek başına sorun değildir, gizlenmesi sorundur: sorumluluk zinciri uzadıkça hata düzeltme süresi uzar. Atanan geliştiricinin deneyim seviyesini ve eş zamanlı kaç projede çalıştığını da öğrenin.

İyi bir sözleşmede değişiklik yönetimi maddesi bulunur: yeni istek yazılı olarak iletilir, firma süre ve bedel etkisini bildirir, siz onaylamadan iş başlamaz. Bu mekanizma yoksa proje sürekli büyüyerek bütçeyi ve takvimi aşar (scope creep). Küçük düzeltmeler için de kapsam içinde tanımlı bir revizyon hakkı belirlenmesini isteyin.

En sık çıkanlar: sunucu ve alan adı yenileme, SSL, e-posta hizmeti, SMS ve bildirim paketleri, ödeme altyapısı komisyonları, e-fatura veya kargo entegrasyonlarının abonelikleri, ücretli tema ve eklenti lisansları, stok görsel bedelleri, içerik ve çeviri işleri. Teklifte “bu bedele dahil olmayanlar” başlığı isteyin; iyi bir firma bu listeyi zaten kendisi verir. Edge Bilişim tekliflerinde dahil olmayan kalemleri ve yıllık tekrar eden giderleri ayrı bir bölümde listeliyoruz.

Garanti, teslim edilen işin kusurlarının belirli bir süre boyunca ücretsiz giderilmesidir; kapsamı sözleşmedeki işle sınırlıdır. Bakım ise yazılımı güncel ve çalışır tutmayı, yeni istekleri ve sunucu yönetimini kapsayan ayrı bir hizmettir. SLA ise arıza durumunda ilk yanıt ve çözüm için taahhüt edilen süredir; sipariş alan bir sistemde bu süre saat cinsinden tanımlanmalıdır.

Kabul testi, yazılımı gerçek senaryolarla deneyip “tamam” demenizdir. Her ekran için senaryo yazın: kim, hangi adımı izleyerek hangi sonucu görecek. Bu senaryolar baştan yazıldığında teslim tartışmaya dönüşmez. Özel yazılım geliştirme süreçlerimizde kabul kriterlerini kapsam dokümanına madde madde ekliyor, testi müşterinin kendi verisiyle test ortamında yaptırıyor, çıkan bulguları yayından önce kapatıyoruz.

Üç somut soru: veriler hangi ülkedeki sunucuda tutulacak, firma sizin adınıza veri işleyen sıfatıyla yazılı sözleşme imzalayacak mı, panelde kim hangi veriye erişebilecek? Ayrıca form ve üyelik akışlarında aydınlatma metni ile açık rıza kutucuklarının ayrı ayrı kurgulanması, veri saklama sürelerinin tanımlanması ve silme talebinin nasıl karşılanacağı baştan planlanmalıdır.

Şifreler nasıl saklanıyor, yönetici paneline iki adımlı doğrulama var mı, yedek hangi sıklıkla alınıyor ve yedekten geri dönüş test edildi mi, kullanılan kütüphaneler güncelleniyor mu, sunucuya kimler erişebiliyor? Yedeğin varlığı yeterli değildir; geri yükleme denenmemişse yedek yok sayılır. Kritik sistemlerde ayrıca sızma testi yapılıp yapılmayacağını sorun.

Ekran görüntüsüyle yetinmeyin; yayında olan proje bağlantısı isteyin ve bir önceki müşteriyle konuşabilir miyim diye sorun. Eski müşteriye sorulacak en verimli sorular şunlardır: proje takvimde teslim edildi mi, ek fatura çıktı mı, teslimden sonra ulaşabildiniz mi? Bu üç cevap, tanıtım dosyalarındaki tüm bilgiden daha fazlasını anlatır.

Kapsamı küçük ve süresi kısa işlerde freelancer maliyet avantajı sağlar; örneğin tek kişilik bir kişisel portfolyo sitesinde bu tercih makuldür. Ancak tek kişiye bağımlılık, süreklilik ve fatura riski taşır. Resmi tüzel kişilik yasal muhatap, fatura ve ekip sürekliliği sunar. Karar ölçütünüz basit olsun: yazılım durursa işiniz durur mu? Cevap evetse süreklilik güvencesi fiyat farkından değerlidir.

Şunlar uyarı işaretidir: kaynak kodu vermemek, tamamını peşin istemek, sözleşmeyi gereksiz görmek, domaini kendi adına açmak, muğlak teslim süresi, yayında referans gösterememek, fatura kesmemek, kapsamı yazmaktan kaçınmak ve piyasanın çok altında fiyat vermek. Bu maddelerden biri bile çıkıyorsa nedenini yazılı olarak sorun; verilen cevabın netliği firmanın çalışma disiplinini gösterir.