Web ve Yazılım Projesi Başlatmadan Önce Sık Sorulan Sorular

Bir yazılım projesi başlatmadan önce sorulan doğru sorular, projenin en ucuz sigortasıdır. Aşağıdaki sorular, hem yazılım hizmeti alan kurumların hem de teklif hazırlayan ekiplerin en sık karşılaştığı belirsizlikleri kapsıyor. Cevapların sözleşme aşamasında yazılı hâle gelmesi, projenin ilerleyen aylarındaki tartışmaların büyük kısmını ortadan kaldırır.

Kapsam ve süreç

Proje ne kadar sürer, neden net süre verilmiyor?

Yazılım tahmini, gereksinimlerin netliğiyle doğru orantılıdır. Gereksinimler tek cümleyle tarif edilmişse verilen süre bir tahmin değil temennidir. Sağlıklı yaklaşım, aralık vermek ("6-9 hafta") ve ilk teslimden sonra tahmini güncellemektir. Konunun ayrıntısı için tahminler neden şaşar yazımıza bakabilirsiniz.

Sonradan değişiklik isteyebilir miyim?

Evet ve bu normaldir; proje ilerledikçe herkes ihtiyacı daha iyi anlar. Kritik olan, değişikliğin bedelinin konuşulmasıdır: eklenen her istek ya takvimi uzatır ya da başka bir maddenin yerini alır. Bu süreci sağlıklı yürütmenin yolları için kapsam kayması yazımızı öneririz.

Sabit fiyat mı, saatlik mi daha iyi?

Sabit fiyat, kapsamı gerçekten net olan işlerde güven verir; kapsam belirsizse tedarikçi riski fiyata ekler ve değişikliğe direnir. Pratikte en dengeli model, bütçenin sabit kapsamın önceliklendirilmiş olmasıdır: liste yukarıdan aşağı ilerler, bütçe bittiğinde en önemli işler tamamlanmış olur.

Sahiplik ve teknik kararlar

Kaynak kodu kime ait olacak?

Bu, en sık atlanan ve en pahalı sorudur. Sözleşmede açıkça yazmıyorsa, ilişki bittiğinde ciddi bir anlaşmazlık doğar. Standart beklenti, ödeme tamamlandığında kodun müşteriye ait olmasıdır; tedarikçinin kendi genel kütüphaneleri ise genellikle lisanslı olarak kullandırılır. Önemli olan bu ayrımın yazılı olmasıdır.

Hangi teknoloji seçilmeli?

Müşteri açısından doğru soru "hangi teknoloji en iyi" değil, "bu teknolojiyi bilen başka geliştirici bulabilir miyim"dir. Niş bir seçim, tedarikçi değişikliğini zorlaştırır. Teknoloji ve çerçeve seçiminin nasıl değerlendirileceği için framework seçimi yazımıza bakabilirsiniz.

Hazır bir ürün mü, özel yazılım mı?

Genel geçer bir cevap yoktur; ölçüt, süreçlerinizin ne kadar özgün olduğudur. Standart bir ihtiyaç için özel yazılım geliştirmek çoğu zaman pahalı bir tercihtir. Karşılaştırmalı bir bakış için ERP seçimi yazımız yararlı olabilir.

Teslim sonrası

Teslimden sonra ne oluyor?

Yazılım, teslim edildiği gün bitmez. Kütüphane güncellemeleri, güvenlik yamaları ve ortam değişiklikleri süreklidir. Bakımsız bırakılan bir sistem birkaç yıl içinde güncellenemez hâle gelir; erteleme maliyetini sürüm yükseltmesini ertelemek yazımızda ele aldık. Sözleşmede bakım kapsamının (yanıt süresi, dahil olan saat, kapsam dışı işler) tanımlı olması gerekir.

Hata çıkarsa ücret ödeyecek miyim?

Teslim edilen kapsamın çalışmaması bir hatadır ve garanti kapsamında düzeltilir. Yeni bir ihtiyaç veya değişen bir kural ise geliştirmedir ve ücretlendirilir. Bu ayrımın sözleşmede tanımlı olması, en sık yaşanan gerilimi baştan çözer.

Barındırma ve alan adı kimin hesabında olmalı?

Mümkünse müşterinin kendi hesabında. Alan adı ve sunucu tedarikçinin hesabındaysa, ilişki bittiğinde teknik bir devir sorunu değil bir erişim sorunu yaşanır. Tedarikçiye yetkili erişim vermek, sahipliği devretmekten farklıdır.

Veri, güvenlik ve devir

Verilerim güvende mi, kimler erişebiliyor?

Sorulacak somut sorular şunlardır: yedekler ne sıklıkla alınıyor ve geri dönüş denendi mi, üretim verisine kimler erişebiliyor, kişisel veriler nasıl korunuyor? Yedeklerin varlığı tek başına yeterli değildir; denenmemiş yedek, kâğıt üstünde güvenliktir — ilgili yazımızda bunu ayrıntılandırıyoruz.

Anlaşma biterse ne olacak?

Devir planı sözleşmede bulunmalıdır: kaynak kodun teslimi, sunucu erişimlerinin devri, üçüncü parti hesapların aktarımı ve kurulum belgeleri. En iyi devir, kurulumun tek komutla yapılabildiği ve belgelerin depoda durduğu projelerde yaşanır — bu, tek komutla kurulum yazımızda anlattığımız disiplinin ticari karşılığıdır.

Küçük bir işletme için nereden başlamalı?

Her şeyi kapsayan büyük bir sistem yerine, en çok zaman kaybettiren tek bir süreçle başlamak neredeyse her zaman daha iyi sonuç verir. Küçük ve çalışan bir çözüm, hem gerçek ihtiyacı ortaya çıkarır hem de bütçeyi korur. Kaynak seçimi ve genel değerlendirme için MDN Web Docs gibi tarafsız teknik kaynaklar da yol gösterebilir.

Sonuç

Bir yazılım projesinde sonradan yaşanan anlaşmazlıkların büyük kısmı, teknik değil tanım eksikliğinden doğar: kaynak kodun kime ait olduğu, kapsam dışının ne olduğu, bakımın nasıl fiyatlandığı, erişimlerin kimde durduğu ve devrin nasıl yapılacağı. Bu beş başlık sözleşmede yazılıysa proje boyunca çıkacak soruların çoğu zaten cevaplanmıştır. Bir sonraki teklifi almadan önce bu listeyi açın ve her maddenin karşılığını yazılı olarak isteyin — sorulmayan tek soru, genellikle en pahalıya mal olandır.