Aydınlatma metni yükleniyor…
Bir web yazılım firmasının teknik yeterliliği yalnızca portföyündeki proje sayısı, kullandığını söylediği teknolojiler veya etkileyici bir sunumla ölçülemez. Asıl değerlendirilmesi gereken; firmanın ihtiyacı nasıl keşfettiği, teknik kararlarını hangi gerekçeyle verdiği, güvenlik ve test sorumluluklarını nasıl yönettiği, canlıya geçişi nasıl planladığı ve proje sonunda müşteriyi kendisine bağımlı bırakmadan neleri teslim ettiğidir.
Bu nedenle aday firmalara yalnızca “Hangi teknolojiyi kullanıyorsunuz?” diye sormayın. Her önemli başlıkta üç şeyi birlikte isteyin:
- Projenize özgü sorunun açık cevabı
- Cevabı destekleyen belge, süreç veya örnek
- Teslim edilecek işin sınırı ve sorumlusu
Bu rehberdeki yedi kapılı kontrol listesi, firmaları tek bir teknolojiye veya büyüklüğe göre sıralamaz. Ama genel vaatlerle doğrulanabilir teknik yeterliliği ayırmanıza yardımcı olur.
Teknik Yeterlilik Ne Anlama Gelir?
Teknik yeterlilik, her projede en yeni aracı kullanmak veya mümkün olan en karmaşık mimariyi kurmak değildir. İhtiyaca uygun çözümü tasarlayabilmek; güvenlik, performans, veri, entegrasyon, süreklilik ve bakım sorumluluklarını görünür hâle getirebilmek; geliştirilen sistemi test edip kontrollü biçimde yayına alabilmek ve başka bir ekip tarafından sürdürülebilecek şekilde teslim edebilmektir.
Aynı firma, basit bir kurumsal site ile çok sayıda kullanıcı rolü, özel veri akışı ve kritik entegrasyon içeren bir web uygulamasında aynı yöntemi ve test derinliğini kullanmamalıdır. Gereksiz karmaşıklık da yetersiz hazırlık kadar sorun yaratabilir.
NIST Güvenli Yazılım Geliştirme Çerçevesi, güvenli geliştirme uygulamalarının iş gereksinimleri, risk toleransı ve mevcut kaynaklarla uyumlu biçimde önceliklendirilmesini önerir. Çerçeve, üretici ile yazılımı satın alan taraf arasında ortak bir dil kurulmasına da yardımcı olur. Bu bakış açısıyla teknik yeterlilik, ezberlenmiş bir kontrol listesinden çok, projenin riskine uygun kararları gerekçelendirebilme becerisidir.
Değerlendirmeden Önce Bütün Firmalara Aynı İhtiyacı Verin
Firmalar farklı ihtiyaç tariflerine göre teklif hazırladıysa teknik yaklaşımlarını adil biçimde karşılaştıramazsınız. Bir firma yalnızca tanıtım sayfalarını, diğeri çoklu dili ve entegrasyonları, bir başkası ise veri taşıma ve içerik girişini hesaba katmış olabilir.
Önce bütün adaylarla aynı proje özetini paylaşın. İş amacı, kullanıcı grupları, temel iş akışları, içerik ve veri durumu, entegrasyonlar, beklenen kullanım hacmi, güvenlik gereksinimleri, hedef tarih ve teslim beklentisi aynı belgede yer alsın. Bu çalışma henüz yapılmadıysa web sitesi ihtiyaç dokümanı hazırlama rehberindeki sorularla başlayabilirsiniz.
Ardından her teknik başlığı şu dört durumdan biriyle işaretleyin:
- Doğrulandı: Yanıt proje özelinde verildi ve belge, süreç, test veya teslim kalemiyle desteklendi.
- Kısmen doğrulandı: Yaklaşım makul ancak kapsam, sorumlu veya çıktı belirsiz.
- Belirsiz: Genel bir vaat var; doğrulanabilir açıklama yok.
- Uygulanamaz: Bu başlık proje için gerekli değil ve neden gerekli olmadığı açıklandı.
“Uygulanamaz” her zaman düşük yeterlilik anlamına gelmez. Önemli olan, gereksiz bir hizmeti satmak yerine ihtiyaca uygun sınırı gerekçelendirebilmektir.
1. Teknik Keşif ve Mimari Karar Kapısı
Teknoloji seçimi, ihtiyaç anlaşılmadan verilen ilk cevap olmamalıdır. Firma; ekran listesinin ötesinde sistemi kimlerin kullanacağını, verinin nereden gelip nereye gideceğini, hangi hataların iş açısından kritik olduğunu ve projenin nasıl büyüyebileceğini anlamalıdır.
Kumsal Ajans teknik keşifte proje kapsamına göre şu alanları birlikte değerlendirir:
- Projenin çözmesi gereken iş problemi ve başarı ölçütü
- Kullanıcı grupları, roller, yetkiler ve onay mekanizmaları
- Mevcut site, yazılım, veri tabanı ve korunacak veriler
- ERP, CRM, muhasebe, ödeme, kargo, e-posta, SMS ve diğer API bağlantıları
- Beklenen ziyaretçi, kullanıcı, işlem ve veri hacmi ile yoğun dönemler
- Çoklu dil, çoklu firma, bayi, şube veya mobil uygulama ihtiyacı
- Kurum içi güvenlik politikaları ve projeyi etkileyen yükümlülükler
- Sunucu, alan adı, mevcut teknolojiler, yedekleme ve süreklilik beklentisi
- Büyüme planı, hedef tarih, bütçe aralığı ve karar sorumluları
İncelenebilecek çıktılar
- Keşif soru seti veya toplantı çıktısı
- Kullanıcı rolleri ve yetkileri tablosu
- Entegrasyon ve veri akışı listesi
- Kapsam, varsayım ve teknik risk kaydı
- Üst düzey sistem veya bileşen şeması
- Performans, güvenlik ve süreklilik gibi işlev dışı gereksinimler
Bu belgelerin tamamı her projede aynı ayrıntıda hazırlanmayabilir. Firma, hangi çıktının neden gerekli olduğunu ve sözleşme kapsamında hangisini teslim edeceğini açıklayabilmelidir.
Kırmızı bayraklar
- İş akışı ve mevcut veri sorulmadan teknoloji veya fiyatın kesinleştirilmesi
- Entegrasyonların yalnızca servis adlarıyla anılması; veri yönü ve hata sorumluluğunun açıklanmaması
- Beklenen kullanım hacmi bilinmeden performans veya ölçek garantisi verilmesi
- Varsayımlar ile kapsam dışı işlerin yazılı hâle getirilmemesi
2. Güvenli Geliştirme ve Erişim Kontrolü Kapısı
“Güvenli yazılım geliştiriyoruz” sözü tek başına yeterli değildir. Güvenlik; rollerin nasıl ayrıldığı, kullanıcı girdilerinin nasıl kontrol edildiği, hassas bilgilerin nerede tutulduğu, bağımlılıkların nasıl güncellendiği ve olayların nasıl izleneceği gibi proje özelindeki kararlarda görünür olmalıdır.
OWASP Application Security Verification Standard, web uygulaması teknik güvenlik kontrollerini test etmek ve güvenli geliştirme gereksinimlerini tanımlamak için açık bir temel sunar. OWASP, ASVS’nin satın alma ve sözleşme süreçlerinde güvenlik doğrulama gereksinimlerini belirtmek için de kullanılabileceğini açıklar. Bu, her projede standardın bütün maddelerinin uygulanması gerektiği anlamına gelmez; uygun doğrulama kapsamının risk ve işlevlere göre yazılması anlamına gelir.
Kumsal Ajans projelerinde güvenlik modeli, verinin niteliği, kullanıcı sayısı, entegrasyonlar ve sektörel gereksinimler değerlendirilerek oluşturulur. Projeye göre rol bazlı erişim, geliştirme-test-canlı ortam ayrımı, TLS, form ve dosya kontrolleri, uygulama katmanı önlemleri, yönetim erişimi sınırları, loglama, yedekleme ve güncelleme takibi kapsamlandırılabilir. Bağımsız sızma testi veya ileri güvenlik denetimi gerekiyorsa ayrıca tanımlanır.
Sorulacak sorular
- Kullanıcı rolleri ve en az yetki yaklaşımı nasıl uygulanacak?
- API anahtarları, veritabanı bilgileri ve diğer hassas erişimler nerede yönetilecek?
- Geliştirme, test ve canlı erişimleri kimlerde olacak?
- Kullanıcı girdileri, dosya yüklemeleri ve kritik işlemler nasıl doğrulanacak?
- Kullanılan paketler ve sunucu bileşenleri nasıl izlenecek ve güncellenecek?
- Güvenlik olayları veya şüpheli işlemler için hangi kayıtlar tutulacak?
- Proje bağımsız güvenlik testi gerektiriyorsa kapsamı ve sorumlusu kim olacak?
OWASP Secrets Management rehberi, gizli bilgilere erişimde en az yetkiyi; oluşturma, yenileme, iptal ve süre sonu gibi yaşam döngüsü adımlarını; denetim kayıtlarını ve geri yükleme prosedürlerinin test edilmesini ele alır. Dolayısıyla “bilgileri güvenli tutuyoruz” yerine erişim, saklama, aktarma ve devir yöntemini sorun.
İncelenebilecek çıktılar
- Projeye özgü güvenlik gereksinimleri veya kontrol listesi
- Rol-yetki matrisi
- Ortam ve erişim sorumluları listesi
- Bağımlılık/güncelleme yaklaşımı
- Güvenlik testi kapsamı ve kabul ölçütleri
- Hassas erişimlerin teslim yöntemi
Kırmızı bayraklar
- “Yüzde yüz güvenli” veya “asla saldırıya uğramaz” gibi doğrulanamaz garantiler
- Canlı erişimlerin kimlerde olduğunun bilinmemesi
- API anahtarları ve parolaların kaynak kod içinde tutulmasının normal kabul edilmesi
- Güvenlik testinin adı verildiği hâlde kapsamının, aracının veya sorumlusunun açıklanmaması
3. Kod, Değişiklik ve Bağımlılık Yönetimi Kapısı
Kaynak kodun varlığı tek başına sürdürülebilirliği göstermez. Kodun hangi sürümünün canlıda olduğu, değişikliklerin nasıl izlendiği, üçüncü taraf bileşenlerin nasıl yönetildiği ve başka bir geliştiricinin projeyi nasıl çalıştıracağı da önemlidir.
OWASP SAMM, güvenli yazılım yaşam döngüsünü risk odaklı ve ölçülebilir biçimde geliştirmek için teknoloji ve süreçten bağımsız bir model sunar. SAMM’nin “her kurum için tek reçete yoktur” yaklaşımı, firmaları yalnızca belirli bir aracı kullanıp kullanmadığına göre değil, karar ve süreç olgunluğuna göre incelemeyi destekler.
Sorulacak sorular
- Kaynak kod hangi depoda tutulacak ve değişiklik geçmişi korunacak mı?
- Canlı sürüm ile depo sürümü nasıl eşleştirilecek?
- Kod kontrolleri kim tarafından ve hangi aşamada yapılıyor?
- Kullanılan açık kaynak, lisanslı veya üçüncü taraf bileşenler nasıl kaydediliyor?
- Kritik bir güncelleme gerektiğinde etki ve uyumluluk nasıl değerlendiriliyor?
- Yeni ekip projeyi kurmak için hangi bilgilere ihtiyaç duyacak?
İncelenebilecek çıktılar
- İsimler ve gizli bilgiler kapatılmış örnek depo yapısı
- Sürüm veya değişiklik kaydı örneği
- Kurulum ve ortam gereksinimleri belgesi
- Kullanılan önemli bileşenler ve lisanslar listesi
- Kod kontrolü veya değişiklik onayı sürecinin açıklaması
Her firmanın depo, dal veya yayın yöntemi aynı olmak zorunda değildir. Önemli olan, yapılan değişikliğin izlenebilir ve teslim edilebilir olmasıdır.
Kırmızı bayraklar
- Canlıdaki kodun güncel bir kopyasının nerede bulunduğunun bilinmemesi
- Teslim edilecek kaynak kodun kapsamının belirsiz olması
- Üçüncü taraf bileşen ve lisansların “kodun tamamı müşterinin” cümlesi içinde kaybolması
- Projeyi başka ortamda kurmak için yalnızca sözlü bilgiye güvenilmesi
4. Test Ortamı ve Müşteri Kabul Kapısı
Bir sayfanın geliştirici bilgisayarında çalışması, projenin kabul testini geçtiği anlamına gelmez. Roller, formlar, entegrasyonlar, mobil görünüm, hata durumları ve gerçek iş senaryoları ayrı testlerde ele alınmalıdır.
Kumsal Ajans projeyi doğrudan canlı sistem üzerinde geliştirmez. Proje yapısı izin verdiği ölçüde geliştirme, test ve canlı ortamları ayrılır. İç testlerden sonra müşteri, canlı veriyi ve kullanıcıları etkilemeyen test ortamında belirlenen senaryoları kontrol eder. Kapsam içindeki hata ve eksikler tamamlandıktan sonra canlıya hazırlık yapılır.
Sorulacak sorular
- Hangi işlevler, roller, cihazlar ve entegrasyonlar test edilecek?
- Test senaryolarını kim hazırlayacak, kim uygulayacak ve kim onaylayacak?
- Müşteri kabulü hangi ortamda ve hangi ölçütlerle yapılacak?
- Hatalar nerede kaydedilecek ve yeniden test nasıl belgelenecek?
- Test verisi gerçek kişisel veya ticari veri içeriyorsa nasıl korunacak?
İncelenebilecek çıktılar
- Örnek test senaryosu veya kabul kontrol listesi
- Ayrı test ortamı ve erişim yöntemi
- Hata/eksik takip kaydı
- Müşteri kabul onayı veya teslim ölçütleri
- Entegrasyonların başarı ve hata durumlarını kapsayan senaryolar
Kırmızı bayraklar
- Geliştirmenin ve müşteri kontrolünün yalnızca canlı ortamda yapılması
- “Her şey test edilir” denmesine rağmen test kapsamının yazılmaması
- Müşteri kabulünün yalnızca sayfaların görsel olarak incelenmesine indirgenmesi
- Entegrasyonların hata ve kesinti durumlarının hiç konuşulmaması
5. Canlıya Alma, Yedek ve Geri Dönüş Kapısı
Canlıya alma, dosyaları sunucuya kopyalamaktan ibaret değildir. Veri tabanı, alan adı, TLS, e-posta servisleri, entegrasyon anahtarları, zamanlama, yedek ve geri dönüş kararı birlikte planlanmalıdır.
Kumsal Ajans sürecinde mevcut sistem varsa geçiş öncesinde dosya ve veri tabanı yedeği alınır. Onaylanan sürüm planlanan zaman aralığında canlıya aktarılır; kritik sayfalar, formlar, kullanıcı işlemleri ve entegrasyonlar üretim ortamında yeniden kontrol edilir. Kritik sorun oluşursa bir önceki kararlı sürüme veya uygun yedeğe dönüş yöntemi projenin veri yapısına göre uygulanır.
Sorulacak sorular
- Yayın öncesi kontrol ve onay kimde olacak?
- Alan adı, TLS, veri tabanı, dosya ve servis değişiklikleri hangi sırada yapılacak?
- Yayın öncesi hangi yedekler alınacak ve geri yükleme yöntemi test edildi mi?
- Veri tabanı değişikliği varsa geriye dönüş nasıl yönetilecek?
- Yayından sonra hangi kritik senaryolar tekrar çalıştırılacak?
- Sorun halinde geri dönme kararını kim, hangi eşikte verecek?
İncelenebilecek çıktılar
- Canlıya alma kontrol listesi
- Yedek ve geri dönüş planı
- Yayın sorumluları ve iletişim listesi
- Yayın sonrası kritik kontrol listesi
- Veri taşıma veya değişiklik sırası
Geri dönüş için evrensel bir süre vaat etmek doğru değildir. Süre; veri hacmine, veri tabanı değişikliklerine, entegrasyonlara ve altyapıya bağlıdır. Firma bunun yerine yöntem, sorumlu ve karar eşiğini açıklamalıdır.
Kırmızı bayraklar
- Yedek alınmasının geri yükleme planıyla karıştırılması
- Veri tabanı değişiklikleri varken geri dönüşün hiç ele alınmaması
- Yayın sonrası form ve entegrasyon kontrollerinin planlanmaması
- Bütün erişim ve karar sorumluluğunun tek kişide toplanması fakat alternatif iletişim planı bulunmaması
6. İzleme, Bakım ve Güvenlik Sürekliliği Kapısı
Bir proje yayına çıktığında teknik sorumluluk sona ermez. Hataların nasıl bildirileceği, logların kim tarafından inceleneceği, güncellemelerin ve yedeklerin nasıl yönetileceği, üçüncü taraf değişikliklerinde kimin ne yapacağı ve yeni geliştirmelerin nasıl ayrılacağı yazılı olmalıdır.
NIST SSDF; güvenli yazılım üretmenin yanında, yayımlanan sürümlerde kalan açıkların belirlenmesi ve bunlara uygun şekilde yanıt verilmesini de ayrı bir uygulama grubu olarak ele alır. Teknik yeterlilik değerlendirmesi bu nedenle yalnızca ilk teslimi değil, sorun ve değişiklik yönetimini de kapsamalıdır.
Sorulacak sorular
- Hata, erişim sorunu ve güvenlik bildirimi hangi kanaldan yapılacak?
- Log, yedek, güncelleme ve çalışma sürekliliği sorumlulukları kimde olacak?
- Destek, garanti niteliğindeki hata giderme, bakım ve yeni geliştirme nasıl ayrılacak?
- Üçüncü taraf servis değiştiğinde inceleme ve ücretlendirme yöntemi ne olacak?
- Hizmet sona erdiğinde son sürüm, erişimler ve operasyon bilgileri nasıl devredilecek?
Kumsal Ajans’ta aksi teklif veya sözleşmede belirtilmedikçe özel yazılım projelerinde canlıya geçiş ya da nihai teslimden sonra altı aylık ücretsiz teknik destek sunulur. Bu dönem teslim edilen kapsamdaki yazılım hatalarının giderilmesini ve proje kaynaklı teknik sorunların incelenmesini kapsar. Yeni özellikler, kapsam genişletme, düzenli bakım, üçüncü taraf değişiklikleri ve dış servis ücretleri ayrı değerlendirilir.
İncelenebilecek çıktılar
- Destek kapsamı ve başlangıç-bitiş tarihi
- Bildirim kanalı ve sorumlular
- Bakım, güncelleme, yedek ve izleme kapsamı
- Hata ile yeni talebi ayıran kabul ölçütleri
- Hizmet sonu devir adımları
Kırmızı bayraklar
- “Destek var” denmesine rağmen süre, kanal ve kapsamın belirtilmemesi
- Garanti, bakım ve yeni geliştirme kavramlarının tek bir belirsiz hizmete dönüştürülmesi
- Güncelleme ve yedek sorumluluğunun taraflar arasında açıkça paylaşılmaması
- Hizmet sona erdiğinde erişim ve son sürüm devrinin tanımlanmaması
7. Dokümantasyon, Erişim ve Müşteri Sahipliği Kapısı
Teknik yeterliliğin en görünür sonuçlarından biri teslimdir. Müşteri yalnızca çalışan bir arayüz değil; sözleşmede kararlaştırılan kodu, veriyi, hesapları, erişimleri ve sistemi çalıştırmak için gerekli bilgileri de alabilmelidir.
Kumsal Ajans, mümkün olduğunda alan adı, sunucu, e-posta ve üçüncü taraf servis hesaplarının doğrudan müşteri adına açılmasını tercih eder. Özel geliştirme projelerinde teslim kapsamı sözleşmeye göre belirlenir. Projenin niteliğine göre şu öğeler teslim listesine girebilir:
- Güncel kaynak kod ve proje deposu erişimi
- Canlı ve test sunucusu erişimleri
- Alan adı, DNS, hosting, bulut veya sunucu hesapları
- Veri tabanı ve yönetim paneli erişimleri
- Üçüncü taraf servis hesapları ve entegrasyon bilgileri
- Kurulum, yayınlama, yedekleme ve geri yükleme açıklamaları
- Ortam gereksinimleri ve kullanılan teknoloji bilgileri
- Gerekli veri yapısı veya API açıklamaları
- Yönetim paneli kullanım dokümanı veya eğitim
- Lisanslar, bilinen teknik sınırlar ve sonraki geliştirme önerileri
Parola, API anahtarı ve benzeri hassas erişimler herkese açık dokümanların içine yazılmamalı; kontrollü yöntemle yetkili kişilere aktarılmalıdır.
Sorulacak sorular
- Hangi kod, veri, tasarım, belge ve hesaplar teslim edilecek?
- Üçüncü taraf veya yeniden kullanılabilir bileşenlerin lisans sınırları neler?
- Hesaplar müşteri adına mı açılacak; ajans hesabındaysa geçiş yöntemi ne?
- Başka bir ekip projeyi devralmak için hangi belge ve erişimlere ihtiyaç duyacak?
- Hassas erişimler nasıl teslim edilecek ve yetkiler nasıl değiştirilecek?
Kırmızı bayraklar
- Kaynak kod, veri veya hesap sahipliğinin yalnızca sözlü açıklanması
- Müşteriye ait servislerin gerekçe ve çıkış planı olmadan yalnızca firma hesabında tutulması
- Teslim listesinde sürüm, yedek, kurulum veya ortam bilgilerinin bulunmaması
- Hassas erişimlerin kontrolsüz dosya veya açık mesajla paylaşılmasının standart yöntem olması
Yedi Kapılı Teknik Değerlendirme Kontrol Listesi
Her aday için aşağıdaki tabloyu doldurun. “İncelenecek çıktı” sütununa belge adını, teklif sayfasını, örnek çıktıyı veya cevaplanmamış soruyu yazın.
| Teknik kapı | Sorulacak temel soru | İncelenebilecek çıktı örneği | Durum |
|---|---|---|---|
| Keşif ve mimari | Çözüm hangi iş akışı, veri, entegrasyon ve hacim varsayımlarına dayanıyor? | Keşif çıktısı, rol/veri/entegrasyon listesi, sistem şeması | Doğrulandı / Kısmen / Belirsiz / Uygulanamaz |
| Güvenlik | Güvenlik kontrolleri proje riskine göre nasıl seçilecek ve test edilecek? | Güvenlik gereksinimi, rol matrisi, test kapsamı, erişim planı | |
| Kod ve değişiklik | Canlı sürüm, kod geçmişi ve bağımlılıklar nasıl izlenecek? | Depo/sürüm yaklaşımı, kurulum belgesi, bileşen listesi | |
| Test ve kabul | Hangi senaryolar kim tarafından, hangi ortamda onaylanacak? | Test senaryosu, hata kaydı, kabul ölçütü | |
| Yayın ve geri dönüş | Geçiş, yedek, üretim kontrolü ve geri dönüş nasıl yürütülecek? | Yayın kontrol listesi, geri dönüş planı, sorumlular | |
| Süreklilik | Hata, bakım, güncelleme ve yeni talep nasıl ayrılacak? | Destek kapsamı, bakım planı, bildirim süreci | |
| Teslim ve sahiplik | Proje başka ekibe devredilecek olsa hangi varlıklar hazır? | Kod, hesap, erişim ve dokümantasyon teslim listesi |
Tek bir toplam puan kullanmak yerine kritik gereksinimleri ayrıca işaretleyin. Örneğin ödeme entegrasyonu, özel nitelikli veri, kesinti toleransı veya mevzuat yükümlülüğü bulunan bir projede ilgili kapı “belirsiz” kaldıysa diğer alanlardaki güçlü yanıtlar bu boşluğu otomatik olarak kapatmaz.
Açıkça Kurgulanmış Bir Değerlendirme Senaryosu
Aşağıdaki senaryo gerçek müşteri vakası değildir; yöntemin nasıl uygulanacağını göstermek için kurgulanmıştır.
Birden fazla şubesi bulunan bir kurumun içerik yönetimi, departman bazlı yetkilendirme ve iki harici sistemden veri toplama ihtiyacı olduğunu düşünün. Firma A, modern bir teknoloji listesi ve hızlı teslim tarihi sunuyor; ancak veri akışını, test ortamını ve teslim belgelerini açıklamıyor. Firma B ise daha uzun bir keşif aşaması öneriyor; kullanıcı rollerini, entegrasyon hata durumlarını, test senaryolarını, yayın planını ve kaynak kod teslimini yazılı hâle getiriyor.
Bu senaryoda Firma B’nin otomatik olarak “en iyi” olduğu söylenemez. Fiyat, süre, ekip uygunluğu ve çözümün gereksiz karmaşıklık üretip üretmediği ayrıca değerlendirilmelidir. Ancak teknik risklerin hangi çıktılar ve kontrollerle yönetileceği karşılaştırılabilir hâle gelmiştir. Firma A da eksik başlıkları yazılı olarak tamamlayarak aynı doğrulama düzeyine ulaşabilir.
Amaç marka veya teknoloji seçmek değil; kritik belirsizlikleri sözleşmeden önce görünür kılmaktır.
Teknik Görüşmede Sorulacak 15 Kısa Soru
- Önerdiğiniz mimari hangi kullanıcı, veri ve entegrasyon varsayımlarına dayanıyor?
- Projenin en kritik üç teknik riski nedir?
- Hangi gereksinimler mevcut bilgilerle kesinleşmedi?
- Kullanıcı rolleri ve kritik yetkiler nasıl doğrulanacak?
- Hassas erişimler koddan ve genel dokümandan nasıl ayrılacak?
- Güvenlik testinin kapsamını proje riskine göre nasıl belirleyeceksiniz?
- Canlı sürüm ile kaynak kod deposu arasındaki ilişki nasıl korunacak?
- Geliştirme, test ve canlı ortamları nasıl ayrılacak?
- Müşteri kabulü hangi senaryolar ve ölçütlerle yapılacak?
- Entegrasyon hata verdiğinde hangi taraf hangi bileşeni inceleyecek?
- Canlıya alma öncesinde hangi yedekler ve kontroller hazırlanacak?
- Geri dönüş hangi koşulda, kim tarafından ve hangi yöntemle başlatılacak?
- Yayın sonrası hangi kritik işlemler tekrar test edilecek?
- Destek, bakım ve yeni geliştirme nasıl ayrılacak?
- Proje başka ekibe geçerse hangi kod, veri, hesap ve belgeler teslim edilecek?
Yanıtların teklif veya ek teknik belgede yer almasını isteyin. Farklı firmaların genel sunumlarını değil, aynı proje için verdikleri doğrulanabilir cevapları karşılaştırın. Ticari kapsamı da aynı düzende incelemek için web sitesi tekliflerini karşılaştırma puan kartını kullanabilirsiniz.
Sonuç: Teknoloji Listesini Değil, Karar ve Teslim Yetkinliğini İnceleyin
Web yazılım firması seçerken teknik yeterlilik; en uzun teknoloji listesine, en düşük fiyata veya en iddialı güvenlik cümlesine indirgenmemelidir. İyi bir teknik yaklaşım, ihtiyacı keşfeder; riskleri görünür kılar; güvenlik ve test kapsamını projeye göre belirler; kontrollü yayın ve geri dönüş yöntemini açıklar; kodu, veriyi, erişimleri ve sorumlulukları teslim edilebilir hâle getirir.
Yedi teknik kapıyı bütün adaylar için aynı sırayla değerlendirin. Kritik bir başlık belirsizse yazılı açıklama ve ilgili çıktıları isteyin. Projeniz için gerekli olmayan bir başlığın uygulanamaz olarak gerekçelendirilmesi, gereksiz hizmet ve karmaşıklıktan kaçınmanıza da yardımcı olabilir.
Projenizin teknik kapsamını, güvenlik ve entegrasyon gereksinimlerini değerlendirmek için Kumsal Ajans web yazılım hizmetini inceleyebilirsiniz.
Sık Sorulan Sorular
Teknik bilgisi sınırlı bir ekip web yazılım firmasını değerlendirebilir mi?
Evet. Ekip, teknoloji seçiminin doğruluğunu tek başına denetlemek zorunda değildir. Aynı soruları bütün firmalara yöneltip varsayımların, sorumluların, testlerin ve teslim kalemlerinin yazılı olup olmadığını karşılaştırabilir. Kritik güvenlik veya mimari kararlar için bağımsız bir teknik danışman incelemesi ayrıca alınabilir.
Güçlü bir portföy teknik yeterlilik için yeterli midir?
Hayır. Portföy, firmanın belirli türde işler yapmış olabileceğini gösterir; ancak sizin projenizde keşif, güvenlik, test, entegrasyon, yayın ve teslim süreçlerinin nasıl yürütüleceğini tek başına açıklamaz. Portföyü proje özelindeki süreçler, belgeler ve örnek çıktılarla birlikte değerlendirin.
Her web yazılım projesinde bağımsız sızma testi yapılmalı mı?
Her proje için aynı güvenlik testi gerekli değildir. Veri niteliği, kullanıcı rolleri, ödeme veya kritik entegrasyonlar, erişim düzeyi ve sektörel yükümlülükler test kapsamını etkiler. Bağımsız sızma testi gerekiyorsa kapsamı, ortamı, sorumlusu ve bulguların giderilme yöntemi ayrıca yazılmalıdır.
Kaynak kodun teslim edilmesi teknik yeterliliği gösterir mi?
Tek başına göstermez. Teslim edilen kodun güncel sürüm olması, kurulum bilgilerinin bulunması, bağımlılık ve lisansların açıklanması, veri ve hesap erişimlerinin devredilmesi ve başka bir ekibin sistemi sürdürebilmesi de önemlidir.
Farklı teknolojiler öneren firmalar nasıl karşılaştırılır?
Teknoloji adlarını doğrudan puanlamak yerine her önerinin aynı iş akışı, veri, entegrasyon, güvenlik, performans, bakım ve teslim gereksinimlerini nasıl karşıladığını inceleyin. Firma, seçimin gerekçesini, sınırlarını ve operasyonel sorumluluğunu açıklayabilmelidir.