Yazılım Geliştirme Hakkında Sık Sorulan Sorular
16.07.2026 · 3 dk okuma · 1 okunma
Yazılım projelerine başlarken en çok tekrarlanan sorular, aslında birkaç başlıkta toplanır. Bu yazıda sık sorulan soruların dolambaçsız cevaplarını, hem işletme hem geliştirici tarafından bakarak topladık.

Süre ve maliyet
"Bu iş ne kadar sürer?"
Süreyi belirleyen şey, yazılacak kod miktarından çok verilecek karar sayısıdır. Ekranı, kuralları ve istisnaları net tanımlanmış bir modül hızlı ilerler. "Nasıl olsa yaparız" denilen belirsiz alanlar ise süreyi ikiye katlar.
Kaba bir çerçeve vermek gerekirse: tek amaçlı bir araç günler, orta ölçekli bir modül 3-6 hafta, çok rollü kurumsal bir sistem 2-4 ay sürer. Bu aralıklar analiz tamamlandıktan sonra daralır.
"Neden analiz için ayrı ücret alınıyor?"
Çünkü analiz, işin kendisidir. Süreçlerin çıkarılması, kuralların yazılması ve istisnaların belirlenmesi, projenin en değerli çıktısıdır. Analiz yapılmadan verilen fiyat bir tahmindir ve tahminler genellikle iki taraf için de kötü sonuçlanır.
"Hazır bir çözüm daha ucuz olmaz mı?"
Süreçleriniz standartsa evet, çoğu zaman daha ucuzdur. Ancak hazır çözüm, sizin çalışma biçiminizi kendi mantığına uydurmanızı bekler. Farklılaştığınız ve rekabet avantajı sağladığınız süreçlerde ise özel geliştirme uzun vadede daha ekonomiktir.
Süreç ve iş birliği
"Proje sırasında ne kadar zaman ayırmam gerekir?"
Beklenenden fazlasını. Kabul kriterlerinin onaylanması, ara gösterimlerin izlenmesi ve test edilmesi müşteri tarafının işidir. Bu zaman ayrılmadığında proje ya gecikir ya da yanlış yönde ilerler.
"Neden her istek hemen yapılamıyor?"
Küçük görünen bir istek, sistemin başka yerlerini etkileyebilir. Yeni bir alan eklemek; formu, listeyi, raporu, dışa aktarmayı ve yetki kurallarını ilgilendirir. Bu yüzden istekler sıraya alınır ve etkileri değerlendirilir.
"Test etmek bizim işimiz mi?"
Teknik testler geliştiricinin sorumluluğundadır; ancak iş kurallarının doğruluğunu yalnızca işi bilen kişi doğrulayabilir. Kıdem hesabının doğru olup olmadığını, o hesabı bilen kişi kontrol etmelidir.
Teknoloji ve devir
"Hangi teknoloji kullanılmalı?"
Karar üç ölçüte dayanır: ekibin bilgisi, projenin beklenen ömrü ve bakımı devralacak kişiyi bulma kolaylığı. En yeni teknoloji, en iyi teknoloji değildir; üç yıl sonra bakımını yapacak birini bulamadığınız teknoloji, en pahalı seçenektir.
"Sistemi başka bir ekibe devredebilir miyim?"
Devredilebilirlik baştan planlanmalıdır. Bunun için gerekenler: kaynak kodun sizde olması, kurulum ve mimari belgeleri, veritabanı şemasının göç dosyalarıyla yönetilmesi ve sırların düzenli tutulması. Bu dördü varsa devir birkaç haftalık bir iştir; yoksa aylara yayılır.
"Verilerimiz güvende mi?"
Bu sorunun cevabı somut olmalıdır: veriler nerede saklanıyor, yedekler ne sıklıkla alınıyor ve geri dönüş test edildi mi, kimler erişebiliyor, kişisel veriler için hangi önlemler alınmış? Kişisel veri işleyen sistemlerde mevzuat yükümlülükleri için KVKK kaynakları esas alınmalıdır.
Ekip ve iletişim
"Tek bir geliştirici yeterli mi?"
Küçük projelerde yeterli olabilir; ancak tek kişiye bağımlılık ciddi bir risktir. O kişi ayrıldığında veya hastalandığında proje durur. Bu riski azaltmanın yolu ekibi büyütmek zorunda değildir: kodun depoda olması, kurulum belgelerinin yazılı olması ve kararların kayıt altına alınması çoğu durumda yeterli koruma sağlar.
"Geliştiriciyle nasıl iletişim kurmalıyım?"
En verimli iletişim, örnek üzerinden yapılandır. "Rapor yanlış geliyor" cümlesi yerine, hangi filtreyle, hangi kaydı, ne beklediğinizi ve ne gördüğünüzü yazmak çözüm süresini belirgin biçimde kısaltır. Ekran görüntüsü ve tarih bilgisi eklemek de aynı işe yarar.
"Talepler neden sıraya alınıyor?"
Çünkü aynı anda beş işe başlamak, hiçbirini bitirmemek anlamına gelir. Öncelik sıralaması yapılmadığında en son konuşan kişinin isteği öne geçer ve önemli işler sürekli ertelenir. Sağlıklı yöntem, taleplerin görünür bir listede önceliklendirilmesidir.
Yayın sonrası
"Teslim sonrası ne oluyor?"
Yayın, sürecin sonu değil ikinci aşamasının başlangıcıdır. İlk haftalarda gerçek kullanım ortaya çıkar ve küçük düzeltmeler gerekir. Ardından düzenli bakım dönemi başlar: güvenlik güncellemeleri, yedek kontrolleri, performans izlemesi ve ortaya çıkan yeni ihtiyaçlar.
"Sistem yavaşlarsa ne yapılır?"
Önce ölçülür. Yavaşlığın kaynağı genellikle sunucu kapasitesi değil, veritabanı sorguları veya optimize edilmemiş görsellerdir. Ölçmeden yapılan donanım yükseltmesi, çoğu zaman parayı çözüm yerine erteleme satın almaya harcamaktır.
Sonuç
Yazılım projelerinde sürprizlerin çoğu, baştan sorulmayan sorulardan doğar. Kapsamı yazıya dökün, karar sahibini belirleyin, test sorumluluğunu paylaşın ve devredilebilirliği baştan planlayın. Bu dört madde netleştiğinde, geriye kalan teknik konular yönetilebilir hâle gelir.
Sık Sorulan Sorular
Tek ekranlı bir araç günlerle, çok kullanıcılı bir kurumsal modül 2-4 ayla ölçülür. Süreyi belirleyen kod miktarı değil, netleşmemiş karar sayısıdır; gereksinimler belirsizse tahmin de belirsiz olur.
Sabit fiyat, sabit kapsam gerektirir. Kapsam analizle netleştirilmeden verilen fiyat ya müşteri ya geliştirici aleyhine olur. Sağlıklı yol, analiz aşamasını ayrı bir çalışma olarak yapmaktır.
Çünkü çevre değişir: tarayıcılar, işletim sistemleri, mevzuat ve entegre olunan servisler güncellenir. Bakım, yazılımın çalışmaya devam etmesini sağlar; ayrıca güvenlik yamaları da bu kapsamdadır.
Bu, sözleşmeyle belirlenir ve mutlaka baştan netleştirilmelidir. Kaynak kodun müşteride olması, ileride farklı bir ekiple devam edebilme özgürlüğü sağlar.