Özel Web Yazılımı Firması Seçerken Nelere Dikkat Edilmeli?

Özel Web Yazılımı Firması Seçimi Nasıl Yapılmalıdır?

Özel web yazılımı firması seçimi; ihtiyaç uyumu, analiz kabiliyeti, teknik yetkinlik, ekip yapısı, proje yönetimi, güvenlik, test, sözleşme ve yayın sonrası hizmetler birlikte incelenerek yapılmalıdır. Değerlendirme yalnızca hangi firmanın daha düşük fiyat verdiğine değil, hangi kapsamı hangi sorumluluklarla teslim edeceğine dayanmalıdır.

Firma Araştırmasından Önce Kurum Ne Hazırlamalıdır?

Kurum, adaylarla görüşmeden önce çözmek istediği problemi, iş hedeflerini, kullanıcı gruplarını, mevcut süreçleri ve temel entegrasyonları tanımlamalıdır. Proje sahibi, karar vericiler, bütçe yaklaşımı ve başarı ölçütleri de belirlenmelidir. Firma seçimi iki yönlü bir uygunluk değerlendirmesidir; kurumun zamanında karar ve geri bildirim sağlayabilmesi de proje sonucunu etkiler.

• İş problemi ve beklenen sonuç açık biçimde tanımlanmalıdır.
• Kullanıcı grupları ve temel kullanım senaryoları belirlenmelidir.
• Mevcut sistemler, veriler ve entegrasyonlar listelenmelidir.
• Proje sahibi ve karar yetkisine sahip kişiler atanmalıdır.
• Bütçe yaklaşımı ve önceliklendirme yöntemi hazırlanmalıdır.
• Adaylar ortak ve ölçülebilir kriterlerle değerlendirilmelidir.

Bir yazılım sistemi oluşturmanın en zor kısmı, tam olarak neyin geliştirileceğine karar vermektir. - Frederick P. Brooks Jr.

İhtiyaç Analizi ve Teknik Şartname Nasıl Değerlendirilir?

İhtiyaç analizi, aday firmanın kurumun taleplerini özellik listesine dönüştürmesinden daha kapsamlı olmalıdır. Firmanın iş hedeflerini, kullanıcı ihtiyaçlarını, süreçlerdeki darboğazları, istisna durumlarını, veri kaynaklarını ve operasyonel riskleri anlayarak bunları doğrulanabilir yazılım gereksinimlerine dönüştürebilmesi gerekir.

Yazılım Teknik Şartnamesinde Neler Bulunmalıdır?

Yazılım teknik şartnamesi; kullanıcı rollerini, iş kurallarını, modülleri, veri ilişkilerini, entegrasyonları, güvenlik ve performans beklentilerini açıklamalıdır. Teslimatlar, kapsam dışı işler ve kabul kriterleri de belgede bulunmalıdır. Aynı teknik kapsam tanımlanmadan alınan teklifler, gerçekte farklı ürün ve hizmetleri fiyatlandırabilir.

• Fonksiyonel gereksinimler sistemin yapacağı işlemleri açıklamalıdır.
• Fonksiyonel olmayan gereksinimler kalite beklentilerini tanımlamalıdır.
• Kullanıcı rolleri ve yetki sınırları belgelenmelidir.
• Entegrasyonlar ve veri aktarımı kapsamlandırılmalıdır.
• Teslimatlar ve kapsam dışı işler ayrıştırılmalıdır.
• Kabul kriterleri nesnel olarak doğrulanabilir olmalıdır.

Teknik Yetkinlik ve Yazılım Ekibi Nasıl İncelenir?

Yazılım firmasının teknik yetkinliği yalnızca kullandığı programlama dilleri, framework’ler veya sertifikalar üzerinden değerlendirilemez. Adayın gereksinimlere uygun mimari kurma, sürdürülebilir kod üretme, veritabanını tasarlama, entegrasyonları yönetme, sürümleri yayınlama ve sistemi uzun vadede destekleme yaklaşımı birlikte incelenmelidir.

Projede Görev Alacak Ekip Hakkında Neler Sorulmalıdır?

Satış görüşmesini yürüten kişiler ile projeyi teslim edecek ekip aynı olmayabilir. Proje yöneticisi, iş analisti, UX/UI tasarımcısı, front-end ve back-end geliştiriciler, test uzmanı ve DevOps sorumlusunun rolleri öğrenilmelidir. Şirketin toplam çalışan sayısından çok projeye ayrılan ekibin yetkinliği ve sürekliliği önemlidir.

• Mimari kararların hangi gereksinimlere dayandığı sorgulanmalıdır.
• Sürüm kontrolü ve kod inceleme yöntemi öğrenilmelidir.
• Projede fiilen görev alacak ekip açıklanmalıdır.
• Kritik görevler için yedek ekip planı bulunmalıdır.
• Geliştirme, test ve yayın sorumlulukları ayrılmalıdır.
• Teknoloji seçimi bakım ve sürdürülebilirlikle gerekçelendirilmelidir.

UX/UI, Proje Yönetimi ve İletişim Nasıl Değerlendirilir?

Firmanın UX/UI, proje yönetimi ve iletişim kabiliyeti, teknik geliştirmelerin gerçek kullanıcı ihtiyaçlarına uygun ve kontrol edilebilir biçimde ilerlemesini sağlar. UX süreci kullanıcıların görevlerini ve akışlarını planlarken UI tasarımı ekranların görsel ve etkileşimsel düzenini oluşturur; yalnızca estetik bir sunum yeterli değildir.

Proje İlerlemesi ve Değişiklikler Nasıl Yönetilmelidir?

Proje yönetimi yönteminin adından çok uygulama biçimi değerlendirilmelidir. Görevların, kilometre taşlarının, risklerin, kararların, onayların ve değişiklik taleplerinin nasıl kaydedildiği sorulmalıdır. Çevik geliştirme sınırsız değişiklik anlamına gelmez; önceliklendirme, kısa geri bildirim döngüleri ve görünür ilerleme gerektirir.

• Kullanıcı akışları wireframe ve prototiplerle doğrulanmalıdır.
• Responsive davranışlar tasarım aşamasında planlanmalıdır.
• Proje görevleri ve kilometre taşları görünür olmalıdır.
• Kararlar ve onaylar yazılı biçimde kayıt altına alınmalıdır.
• Değişiklik taleplerinin kapsam etkisi değerlendirilmelidir.
• Risk ve gecikmeler zamanında raporlanmalıdır.

Güvenlik, Test ve Kabul Süreçleri Nasıl İncelenir?

Güvenlik, test ve kabul süreçleri; yazılımın gereksinimleri karşılamasını, kurumsal verileri korumasını ve gerçek kullanım koşullarında güvenilir çalışmasını sağlamalıdır. Genel bir “güvenli yazılım” beyanı yeterli değildir. Firma, güvenliği analizden mimariye, kodlamadan yayın ve bakıma kadar nasıl yönettiğini somut süreçlerle açıklayabilmelidir.

Teknik Testler ile Kullanıcı Kabul Testi Aynı mıdır?

Fonksiyonel, entegrasyon, performans ve güvenlik testleri sistemin teknik davranışını inceler. Kullanıcı kabul testi veya UAT ise kurumun gerçek iş senaryolarını önceden belirlenen kabul kriterleriyle doğrulamasıdır. Firma içi test, kurumun yapacağı kullanıcı kabul testinin yerine geçmez. Test sorumlulukları ve hata öncelikleri sözleşmede tanımlanmalıdır.

• Yetkilendirme ve veri erişimi görev esasına dayanmalıdır.
• Güvenli kodlama ve bağımlılık güncelleme yaklaşımı açıklanmalıdır.
• Fonksiyonel testler iş kurallarını doğrulamalıdır.
• Entegrasyon testleri uçtan uca veri akışını incelemelidir.
• Performans ve güvenlik kontrolleri riske göre planlanmalıdır.
• UAT senaryoları resmi kabul sürecine bağlanmalıdır.

Kaynak Kodu, Veri ve Dokümantasyon Nasıl Güvenceye Alınır?

Kaynak kodu, veri ve dokümantasyon koşulları teklif ve sözleşmede ayrı ayrı güvence altına alınmalıdır. Kaynak koduna erişim veya kodun teslim edilmesi; kullanım, değiştirme ve yeniden dağıtma haklarının tamamının kendiliğinden devredildiği anlamına gelmez. Kesin haklar yazılım lisansı ve fikrî mülkiyet hükümlerine bağlıdır.

Veri Sahipliği ve Taşınabilirliği Nasıl Korunmalıdır?

Veri sahipliği, kurumun kendi kayıtlarına erişebilmesini, yedek alabilmesini ve verileri kullanılabilir standart formatlarda dışa aktarabilmesini kapsamalıdır. Hizmet sağlayıcı değişikliğinde kodun, verilerin, erişim bilgilerinin ve teknik bilginin nasıl devredileceği önceden tanımlanmalıdır. Böylece vendor lock-in olarak bilinen sağlayıcı bağımlılığı riski azaltılabilir.

• Kod deposunun konumu ve erişim yetkileri açıklanmalıdır.
• Kaynak kodu teslim biçimi sözleşmede tanımlanmalıdır.
• Veri dışa aktarma formatları ve koşulları belirlenmelidir.
• Açık kaynak bileşenlerin lisansları belgelenmelidir.
• Mimari, kurulum ve API bilgileri dokümante edilmelidir.
• Devir ve hizmet sağlayıcı değişikliği planı hazırlanmalıdır.

Yazılım Teklifleri ve Sözleşmeler Nasıl Karşılaştırılır?

Yazılım teklifleri aynı teknik şartname, teslimat listesi ve kabul kriterleri üzerinden karşılaştırılmalıdır. Yalnızca toplam bedeli incelemek yanıltıcıdır; bir teklif analiz, özel tasarım, entegrasyon, test veya dokümantasyon içerirken başka bir teklif bu çalışmaları kapsam dışında bırakabilir. Yüksek fiyat da tek başına daha nitelikli hizmeti kanıtlamaz.

Çalışma ve Ödeme Modeli Nasıl Seçilmelidir?

Sabit fiyat modeli kapsamın açık ve değişiklik ihtiyacının sınırlı olduğu projelerde; zaman ve malzeme modeli ise belirsizliğin veya yinelemeli geliştirmenin yüksek olduğu çalışmalarda değerlendirilebilir. Faz bazlı model analiz, MVP ve sonraki modülleri ayrı kararlara dönüştürebilir. Ödeme planı mümkün olduğunda doğrulanabilir teslimatlara bağlanmalıdır.

• Analiz, tasarım ve geliştirme kapsamları ayrıştırılmalıdır.
• Test, altyapı ve veri aktarımı görünür olmalıdır.
• Kapsam dışı işler ve ek maliyetler açıklanmalıdır.
• Değişiklik yönetimi ve fiyatlandırma yöntemi belirlenmelidir.
• Ödeme adımları teslimatlarla ilişkilendirilmelidir.
• Toplam sahip olma maliyeti ayrıca değerlendirilmelidir.

Garanti, Bakım, Destek ve SLA Nasıl Değerlendirilir?

Garanti, bakım, destek ve SLA farklı sorumlulukları tanımlar. Garanti, kabul edilen kapsamda teslim edilen işlevlerdeki kusurların giderilmesini; bakım, yazılımın güvenli ve güncel tutulmasını; destek ise kullanıcı ve operasyon taleplerinin yönetilmesini kapsar. SLA, bu hizmetlerin ölçülebilir koşullarını belirleyen hizmet seviyesi anlaşmasıdır.

Yayın Sonrası Hizmet Sürekliliği Nasıl Sağlanır?

Hizmet sürekliliği yalnızca hızlı yanıt vaadiyle sağlanmaz. Destek saatleri, öncelik seviyeleri, iletişim kanalları, yanıt hedefleri, planlı kesintiler ve kapsam dışı durumlar açıklanmalıdır. Kod deposu, güncel dokümantasyon, düzenli yedekleme ve ekip içi bilgi paylaşımı tek kişiye bağımlılık riskini azaltır.

• Garanti kapsamı ve istisnaları açıkça yazılmalıdır.
• Bakımın güvenlik ve uyumluluk görevleri tanımlanmalıdır.
• Destek kanalları ve hizmet saatleri belirlenmelidir.
• Olay öncelikleri ve yanıt hedefleri ölçülebilir olmalıdır.
• Yedekleme ve geri yükleme sorumlulukları açıklanmalıdır.
• Ekip ve hizmet sağlayıcı değişikliği planlanmalıdır.

Referans Kontrolü ve Nihai Firma Seçimi Nasıl Yapılır?

Referans kontrolü, aday firmanın internet sitesindeki logoları veya ekran görüntülerini incelemekten daha kapsamlı yapılmalıdır. Firmanın projedeki gerçek rolü, geliştirdiği modüller, yönettiği entegrasyonlar, karşılaştığı sorunlar ve yayın sonrası sorumlulukları öğrenilmelidir. Aynı sektörden çok benzer teknik karmaşıklığa sahip bir referans daha anlamlı olabilir.

Firma Kısa Listesi Hangi Kriterlerle Oluşturulmalıdır?

Nihai kısa liste; teknik, yönetsel, ticari ve sözleşmesel kriterlere ağırlık veren bir değerlendirme matrisiyle oluşturulabilir. Puanlama mutlak doğruyu üretmez; ancak kararın tutarlı ve gerekçelendirilebilir olmasını sağlar. Ankara yazılım firması arayan kurumlar yüz yüze çalışma ihtiyacını değerlendirebilir; yerel yakınlık teknik uygunluğun önüne geçmemelidir.

• Referans projenin kapsamı ve firmanın rolü doğrulanmalıdır.
• Benzer karmaşıklıkta uygulama deneyimi değerlendirilmelidir.
• İletişim ve sorun çözme yaklaşımı referanslara sorulmalıdır.
• Teknik ve yönetsel kriterler ayrı ağırlıklandırılmalıdır.
• Ticari ve sözleşmesel riskler puanlamaya eklenmelidir.
• Nihai karar toplam değer ve sürdürülebilirliğe dayanmalıdır.