Yazılım Projesi Yaptırmadan Önce Yazılım Firmasına Sorulması Gereken 10 Kritik Soru

Yazılım firması deneyimi hangi soruyla doğrulanır?

1. Daha önce benzer kapsam ve gereksinimlere sahip hangi projeleri geliştirdiniz? Bu soru, firmanın yalnızca genel yazılım deneyimini değil, planlanan projeye benzeyen problemlerde üstlendiği gerçek sorumlulukları anlamayı sağlar. Sektör benzerliği yararlı olabilir; ancak iş akışları, kullanıcı rolleri, entegrasyonlar, güvenlik seviyesi ve ölçek ihtiyacı çoğu zaman daha belirleyici ölçütlerdir.

Referans yanıtında hangi kanıtlar aranmalıdır?

Firmanın proje adı veya müşteri logosu paylaşması tek başına yeterli değildir. Çözümün hangi bölümünü geliştirdiği, sistemin aktif kullanılıp kullanılmadığı, karşılaşılan sorunları nasıl çözdüğü ve bakım sorumluluğunu sürdürüp sürdürmediği sorulmalıdır. özel yazılım geliştirmenin kurumsal katkılarını bilmek, referansların işletme ihtiyacıyla teknik açıdan ne kadar örtüştüğünü değerlendirmeyi kolaylaştırır.

• Projenin amacı, kapsamı ve hedef kullanıcıları
• Firmanın doğrudan geliştirdiği modüller ve entegrasyonlar
• Projede çözülen teknik ve operasyonel sorunlar
• Sistemin aktif kullanım ve bakım durumu
• Doğrulanabilir referans veya anonimleştirilmiş vaka anlatımı

Sadelik, güvenilirliğin ön koşuludur. - Edsger W. Dijkstra

Yazılım firması ihtiyaç analizini nasıl yürütmelidir?

2. İş ihtiyaçlarımızı ve teknik gereksinimlerimizi nasıl analiz edeceksiniz? Güçlü bir yanıt; paydaş görüşmeleri, mevcut süreçlerin incelenmesi, kullanıcı senaryoları, veri gereksinimleri, entegrasyonlar ve başarı ölçütlerini kapsayan sistemli bir yöntem sunmalıdır. Firma, müşterinin ilk özellik listesini doğrudan geliştirmeye başlamadan önce varsayımları ve öncelikleri doğrulamalıdır.

Analiz sürecinin beklenen çıktıları

Analiz sonunda ortaya çıkacak belgeler de görüşmede netleştirilmelidir. İşlevsel kapsam, kullanıcı rolleri, süreç akışları, kabul kriterleri ve kapsam dışı ihtiyaçlar yazılı hâle getirilmezse firmalar farklı çözümler üzerinden teklif verebilir. özel yazılım geliştirme sürecinin nasıl planlandığını incelemek, analiz ile geliştirme arasındaki sorumlulukların ayrılmasına yardımcı olur.

• Paydaş, kullanıcı ve mevcut süreç görüşmeleri
• İşlevsel ve işlevsel olmayan gereksinimlerin ayrılması
• Kullanıcı rolleri ve temel kullanım senaryoları
• Entegrasyon, veri ve güvenlik gereksinimleri
• Öncelikler, kapsam sınırları ve kabul kriterleri
• Onaylanabilir analiz ve kapsam dokümanı

Teknoloji ve proje ekibi nasıl değerlendirilmelidir?

3. Projede hangi teknoloji ve yazılım mimarisini neden kullanacaksınız? Profesyonel yazılım firması, teknoloji tercihini popülerlik veya alışkanlıkla değil; kullanıcı yükü, güvenlik, entegrasyon, performans, ölçeklenebilirlik ve bakım gereksinimleriyle açıklamalıdır. Önerilen mimarinin avantajları kadar sınırlılıkları, lisans koşulları ve uzun vadeli güncelleme ihtiyacı da belirtilmelidir.

Teknoloji kararında aranacak açıklık

Mimari yaklaşım; sistemin modülerliğini, yeni özelliklere uyumunu, test edilebilirliğini ve teknik borcun nasıl yönetileceğini göstermelidir. Firma, hangi bileşenleri kendisinin geliştireceğini ve hangi üçüncü taraf servislerden yararlanacağını açıklamalıdır. Teknoloji isimlerinin sıralanması yerine her kararın proje ihtiyacıyla ilişkisi değerlendirilmelidir.

Projede çalışacak ekibin sürekliliği

4. Projede kimler görev alacak ve ekip sürekliliği nasıl sağlanacak? Teklif veren kişilerle projeyi geliştirecek ekip farklı olabilir. Bu nedenle analist, proje yöneticisi, tasarımcı, geliştirici, test uzmanı ve DevOps sorumlularının kim olduğu; çalışma kapasiteleri ve görev sınırları öğrenilmelidir. Ekip değişikliğinde bilgi aktarımı ve yerine koyma yöntemi de sözleşmeye yansıtılmalıdır.

• Teknoloji ve mimari kararlarının gerekçeleri
• Performans, güvenlik ve ölçeklenebilirlik yaklaşımı
• Üçüncü taraf bileşenler ve lisans bağımlılıkları
• Projede görev alacak kişilerin rolleri
• Ekip değişikliği ve bilgi aktarımı yöntemi
• Kod inceleme ve teknik karar onay süreci

Yazılım proje süreci ve teslimatlar nasıl yönetilir?

5. Proje süreci, kilometre taşları, iletişim ve teslimatlar nasıl yönetilecek? Sağlıklı bir proje modeli; kapsamı yönetilebilir aşamalara ayırmalı, her aşama için teslimat, sorumlu taraf, inceleme yöntemi ve kabul kriteri tanımlamalıdır. Yalnızca başlangıç ve bitiş tarihi içeren bir plan, ilerlemenin ve risklerin zamanında görülmesi için yeterli değildir.

İletişim ve onay mekanizması

Firma; toplantı sıklığını, ilerleme raporlarını, görev takip aracını, kararların nasıl kaydedileceğini ve kurumdan beklenen onayları açıklamalıdır. Prototip, temel modüller, entegrasyon, test ve canlıya geçiş gibi kilometre taşları görünür olmalıdır. Projenin çevik yürütülmesi, kapsam ve sorumlulukların belirsiz bırakılması anlamına gelmemelidir.

• Aşamalar, kilometre taşları ve teslim edilecek çıktılar
• Her teslimat için ölçülebilir kabul kriterleri
• Toplantı, raporlama ve görev takip düzeni
• Kurum ve firma tarafındaki karar yetkilileri
• Risk, engel ve bağımlılıkların bildirilme yöntemi
• Canlıya geçiş ve gerektiğinde geri dönüş planı

Yazılım firması test ve güvenliği nasıl sağlamalıdır?

6. Test, kalite güvence, veri güvenliği ve kullanıcı kabul süreçleri nasıl uygulanacak? Firma, kaliteyi yalnızca geliştirme tamamlandıktan sonra yapılan manuel kontrollerle sınırlamamalıdır. Kod inceleme, birim testleri, entegrasyon testleri, güvenlik kontrolleri ve kullanıcı kabul testleri proje planının başından itibaren tanımlanmalıdır.

Güvenlik sorumluluklarının belirlenmesi

Kimlik doğrulama, yetkilendirme, hassas verilerin korunması, işlem kayıtları, yedekleme ve güvenlik güncellemeleri için sorumlu taraflar açıkça belirlenmelidir. ERP ve CRM sistemleriyle kurumsal yazılım entegrasyonu gibi veri alışverişinin yoğun olduğu projelerde erişim sınırları, hata senaryoları ve veri bütünlüğü ayrıca test edilmelidir.

• Kod inceleme ve otomatik test yaklaşımı
• Entegrasyon, performans ve hata senaryoları
• Kullanıcı kabul testinin kapsamı ve sorumluları
• Yetkilendirme ve hassas veri koruma yöntemi
• Güvenlik açığı takibi ve güncelleme süreci
• Yedekleme, geri yükleme ve olay kayıtları

Özel yazılım teklifinde hangi hizmetler bulunmalıdır?

7. Teklif kapsamına hangi geliştirme, entegrasyon, dokümantasyon ve destek hizmetleri dâhil? Özel yazılım teklifi yalnızca modül adları ve toplam bedelden oluşmamalıdır. Analiz, UX/UI tasarımı, geliştirme, veri aktarımı, entegrasyon, test, yayınlama, eğitim, dokümantasyon ve garanti gibi teslimatlar ayrı ayrı açıklanmalıdır.

Kapsam içi ve kapsam dışı çalışmalar

Firmanın sunacağı hizmetlerle kurumun üstleneceği veri, içerik, test ve onay sorumlulukları birbirinden ayrılmalıdır. Üçüncü taraf lisansları, sunucu giderleri ve harici servis abonelikleri de açıkça gösterilmelidir. özel yazılım geliştirme maliyetini etkileyen unsurlar, farklı teklifleri aynı kapsam üzerinden değerlendirmek için yararlı bir çerçeve sağlar.

• Analiz, tasarım ve yazılım geliştirme kapsamı
• Veri aktarımı ve sistem entegrasyonları
• Test, devreye alma ve kullanıcı eğitimi
• Teknik ve kullanıcı dokümantasyonu
• Üçüncü taraf lisans ve servis giderleri
• Kapsam dışı işler ve müşteri sorumlulukları

Kaynak kodu ve fikrî mülkiyet nasıl düzenlenir?

8. Kaynak kodu, veriler, hesaplar ve fikrî mülkiyet hakları kime ait olacak? Bu sorunun tek ve her proje için geçerli bir cevabı yoktur; ancak sahiplik, lisanslama, kullanım, değiştirme ve devir haklarının sözleşmede açıkça tanımlanması gerekir. Kurum, hangi varlıkları proje sonunda teslim alacağını ve sistemi bağımsız olarak geliştirme hakkına sahip olup olmadığını bilmelidir.

Eksiksiz devir teslim kapsamı

Kaynak kodu teslimi tek başına sürdürülebilir devir sağlamaz. Sürüm kontrol deposu, veri tabanı, kurulum yönergeleri, tasarım dosyaları, lisans kayıtları, servis hesapları ve teknik dokümantasyon birlikte değerlendirilmelidir. Teklifte kullanılan açık kaynak veya ticari bileşenlerin lisans koşulları da kurumun gelecekteki kullanımını sınırlayıp sınırlamadığı açısından incelenmelidir.

• Kaynak kodu ve sürüm kontrol deposuna erişim
• Veriler, yedekler ve dışa aktarım hakları
• Tasarım dosyaları ve teknik dokümantasyon
• Sunucu, alan adı ve üçüncü taraf hesapları
• Fikrî mülkiyet ve kullanım hakları
• Başka firmaya geçiş ve devir desteği

Kapsam değişiklikleri ve gecikmeler nasıl yönetilir?

9. Kapsam değişiklikleri, ek talepler ve proje gecikmeleri nasıl yönetilecek? Yazılım projelerinde yeni ihtiyaçlar veya teknik bulgular ortaya çıkabilir. Önemli olan her değişikliğin kapsam, süre, maliyet, güvenlik ve mevcut özellikler üzerindeki etkisinin analiz edilmesi; yetkili kişilerce onaylandıktan sonra plan ve dokümantasyona işlenmesidir.

Değişiklik ve gecikme prosedürü

Her gecikme doğrudan firmadan kaynaklanmayabilir; müşteri onayları, harici servisler, veri hazırlığı ve kapsam değişiklikleri de takvimi etkileyebilir. Bu nedenle neden, sorumluluk, bildirim süresi ve yeniden planlama yöntemi önceden belirlenmelidir. Sözlü talepler yerine kayıtlı değişiklik formları kullanılması, bütçe ve teslimat anlaşmazlıklarını azaltır.

• Değişiklik talebinin yazılı olarak tanımlanması
• Teknik, finansal ve takvim etkisinin analiz edilmesi
• Yetkili kişi tarafından onay verilmesi
• Plan, kapsam ve kabul kriterlerinin güncellenmesi
• Gecikme nedeninin ve sorumluluğun kaydedilmesi
• Yeni teslim tarihinin taraflarla paylaşılması

Garanti, bakım ve teknik destek nasıl belirlenir?

10. Garanti, bakım, güncelleme, teknik destek ve devir teslim koşulları nelerdir? Garanti, teslim edilen kapsamın kabul kriterlerine aykırı çalışan bölümlerindeki hataların giderilmesini ifade eder. Bakım ve destek ise güvenlik güncellemeleri, izleme, yedekleme, kullanıcı desteği, iyileştirme ve yeni geliştirme gibi ayrı hizmetlerden oluşabilir. Bu kapsamların sözleşmede birbirinden ayrılması gerekir.

Firma görüşmesi için son karşılaştırma listesi

Destek kanalları, talep öncelikleri, yanıt yöntemi, çalışma saatleri, sorumluluk sınırları ve ücretlendirme modeli açık olmalıdır. özel yazılım geliştirme firması seçim kriterleri de incelenerek kısa listedeki firmaların 10 soruya verdiği cevaplar aynı form üzerinde puanlanmalı; belirsiz maddeler teklif ve sözleşme öncesinde yazılı olarak netleştirilmelidir.

• Benzer proje deneyimi ve doğrulanabilir referanslar
• Açık analiz, teknoloji ve ekip yaklaşımı
• Ölçülebilir kapsam, teslimat ve kabul kriterleri
• Tanımlanmış kaynak kodu ve veri sahipliği
• Yazılı değişiklik ve gecikme prosedürü
• Ayrıştırılmış garanti, bakım ve destek koşulları
• Dokümantasyon ve devir teslim yükümlülükleri