Yazılım Ajansı Seçimi: 100 Puanlık Teknik Değerlendirme

Önce “en iyi” ifadesini kendi projeniz için tanımlayın

Bir bayi portalı, bir tüketici uygulaması ve şirket içi teklif sistemi aynı ajans değerlendirmesini gerektirmez. Bayi portalında müşteri bazlı fiyat, erişim ve stok tutarlılığı önem kazanır. Tüketici uygulamasında cihaz davranışı ve kullanıcı deneyimi öne çıkabilir. Öncelikleriniz yazılı değilse, en güzel sunumun en uygun mühendislik çözümü olduğunu varsaymanız kolaylaşır.

Bu nedenle değerlendirmeyi üç kritik iş üzerinden başlatın. Kullanıcı ne yapmak istiyor? Bu işin yanlış yapılması kimi etkiliyor? Çıktının doğru olduğunu kim onaylayacak? Örneğin “CRM geliştirilecek” ifadesi yerine “satış çalışanı yalnızca kendisine atanmış müşterinin teklifini görecek; yönetici onaylanmış teklifi değiştirdiğinde yeni sürüm oluşacak” yazın. Ajansa teknoloji önerisini bu akış üzerinden açıklama fırsatı verin.

Aşağıdaki puan kartı Ganz Dijital için hazırlanmış önerilen bir satın alma aracıdır. Türkiye’deki ajansların araştırılmış sıralaması, bağımsız ödül veya sertifikasyon değildir. Amaç teklifleri daha anlaşılır hale getirmektir; profesyonel teknik incelemenin yerini almak değildir.

100 puanlık kartı nasıl kullanmalısınız?

Her alanı 0–3 arasında değerlendirin: 0, kanıt yok; 1, yalnızca sözlü açıklama; 2, incelenebilir belge veya kayıt; 3, sizin akışınızla ilişkili, tekrar edilebilir doğrulama. Alan puanı, ağırlık ile seviyenin üçte birinin çarpımıdır. Örneğin güvenlik alanında 2 seviye, 20 × 2 / 3 = yaklaşık 13,3 puandır. Toplamı son aşamada yuvarlayın.

Kanıtın gizli müşteri verisi içermesini istemeyin. Anonimleştirilmiş kayıt, sentetik test ortamı veya ajansın bu iş için kurduğu örnek yeterli olabilir. Başkasının kaynak kodunu izinsiz gösteren bir sunumu şeffaflık göstergesi saymayın. Projenin sorumluluğunu alacak kişinin açıklaması ile satış sunumunu yapan kişinin açıklamasını da ayırın.

Güzel demoyu küçük bir stres senaryosuna dönüştürün

Örnek değerlendirmede iki kullanıcı rolü ve tek bir teklif kaydı kullanın. Satış çalışanı teklif oluşturur; yönetici onaylar; çalışan eski sekmesinden fiyatı değiştirmeye çalışır. Ekran ne gösterir? Sunucu neyi kabul eder? Değişiklik geçmişinde hangi kayıt kalır? Sonuç, yalnızca doğru buton renginden daha fazla bilgi verir.

Ardından kontrollü test ortamında bağlantıyı kesip aynı kaydı tekrar göndermeyi deneyin. Beklenti herkesin her testi anında geçmesi değildir. Beklenti, ekibin davranışı açıklaması, riski tanıması ve gerekli düzeltmeyi ölçülebilir bir işe dönüştürmesidir. Bilinmeyen bir duruma dürüstçe yaklaşan ekip ile soruyu geçiştiren ekip arasında önemli bir değerlendirme farkı vardır.

Testler yalnızca yetkili olduğunuz ortamda yapılmalıdır. Canlı müşterilerin siparişlerine, ödemelerine veya hesaplarına dokunmayın. Demo aşamasında bile kayıtların sentetik olduğunu ve otomatik e-posta gibi yan etkilerin kapalı bulunduğunu doğrulayın. Satın alma incelemesi yeni bir operasyon sorunu üretmemelidir.

Teknoloji adını değil, kararın gerekçesini değerlendirin

“Mikroservis kullanıyoruz” tek başına kalite göstergesi değildir. Microsoft’un mimari rehberi bağımsız dağıtım gibi yararların yanında sistem karmaşıklığı, servisler arası iletişim ve veri tutarlılığı zorluklarını da açıklar. Bu nedenle ajansın seçtiği yaklaşımın işletim yükünü kimin taşıyacağını sorun. [2]

Kısa bir karar kaydı isteyin: problem, değerlendirilen seçenekler, seçilen çözüm, kabul edilen dezavantaj ve kararın yeniden ele alınacağı koşul. “İlk sürüm modüler tek uygulama olacak; raporlama ayrı ölçek gerektirdiğinde ayrıştırma değerlendirilecek” ifadesi bir gerekçe içerir. “En yeni teknoloji olduğu için” ifadesi ise projenize özgü karar sunmaz.

Benzer şekilde kaynak kodundaki satır sayısı, kullanılan dil sayısı veya geliştirilen ekran adedi tek başına başarı ölçütü olmamalıdır. Seçilen yapının gereksiz parçaları azaltıp azaltmadığına, yeni bir ekibin sistemi anlayabilmesine ve kritik işlerin nasıl doğrulandığına bakın. İddialı bir mimari çizim kadar sade bir sınır çizimi de değerlidir.

Güvenlikte belge ile doğrulamayı ayırın

OWASP ASVS, uygulama güvenliği gereksinimlerinin doğrulanmasına yönelik bir çerçevedir. Adının teklif üzerinde bulunması, uygulamanın bağımsız olarak denetlendiğini veya sertifikalandırıldığını göstermez. Hangi sürümün hangi gereksinimlerinin seçildiğini, nasıl test edildiğini ve açık bulguların durumunu sorun. [1]

Önerilen kritik geçiş koşulları belirleyin. Örneğin başka müşterinin kaydına erişim, açıklanamayan veri kaybı veya işletmenin temel hesaplara erişememesi, toplam puan yüksek olsa da ayrıca çözülmelidir. Kritik bir güvenlik açığını iyi tasarım puanıyla telafi etmeyin. Puan kartı riskleri görünür kılar; ortalamayla görünmez yapmamalıdır.

İlk görüşmede eksik kanıt bulunması doğrudan eleme gerektirmeyebilir. Kanıtın ne zaman ve hangi kapsamda üretileceğini teklif aşamasına bağlayabilirsiniz. Ancak doğrulanmamış bir maddeyi tamamlanmış gibi işaretlemeyin. “Planlandı”, “uygulandı” ve “test edildi” durumları ayrı tutulmalıdır.

Teslim gününden sonraki ilk soruyu şimdiden sorun

Proje açıldıktan sonra bir müşteri sorun bildirdiğinde kim neye bakacak? Hangi sürümün çalıştığı nasıl anlaşılacak? Eski sürüme dönüş veri değişikliklerini de kapsıyor mu? İşletim planını sonradan eklenen belirsiz bir bakım cümlesine bırakmayın.

Kod deposu, alan adı, bulut hesabı, mağaza hesabı ve üçüncü taraf lisanslarının sorumlusunu listeleyin. Ajansın kendi araçları ile müşteriye ait operasyon hesaplarının sınırını netleştirin. Devir için sadece bir ZIP dosyası değil; kurulum, ortam değişkenlerinin isimleri, veri modeli, yedekleme ve bilinen sınırlamaları içeren bir paket tanımlayın. Gizli anahtarların açık belgede tutulmasını istemeyin.

Kararı puanla birlikte kısa bir gerekçeye bağlayın

Önerilen değerlendirme dosyası her aday için tek sayfalık sonuç içersin: puan, güçlü kanıtlar, eksik kanıtlar, kritik koşullar ve sonraki doğrulama. Adayları aynı senaryoyla değerlendirin. Ağırlıkları teklifleri gördükten sonra belirli bir firmayı kazandırmak için değiştirmeyin; değişiklik gerekiyorsa gerekçesini tüm adaylara eşit uygulayın.

Referans görüşmesinde “Memnun musunuz?” sorusuyla yetinmeyin. Kapsam değiştiğinde ne oldu, teslim sonrası hata nasıl ele alındı, hesap devri sorunsuz muydu? Görüşmeyi izinle ve proje bağlamını koruyarak yapın. Bir müşterideki iyi deneyimi bütün sektörler için otomatik yeterlilik saymayın.

Teknik ekibim yoksa bu kartı kullanabilir miyim?

İş akışı, sorumluluk ve teslim maddelerini kullanabilirsiniz. Güvenlik veya mimari kanıtını doğrulayacak uzmanınız yoksa bağımsız inceleme kapsamını ayrıca planlayın. Anlamadığınız bir diyagrama sırf profesyonel göründüğü için yüksek puan vermeyin.

En yüksek puanlı ajans mutlaka doğru seçim midir?

Hayır. Bütçe, zamanlama, iletişim ve projenize özgü kritik koşullar karara dahildir. Kartın değeri otomatik kazanan üretmesi değil, kararın hangi kanıta dayandığını göstermesidir. İyi başlangıç, büyük bir sıfat değil; doğrulanabilir bir çalışma anlaşmasıdır.