Projeler Kodda Değil, Seçimde Kaybedilir
Yazılım projelerinin büyük bölümü teknik nedenlerle başarısız olmaz. Bütçe aşımlarının, altı ay gecikmelerin ve "yeniden baştan yazalım" kararlarının kökeninde neredeyse her zaman aynı şey vardır: iş ortağı seçiminde yapılan hatalar. Yanlış ekiple çalışmanın maliyeti sadece ödenen faturalar değildir; kaybedilen pazar zamanı, moral bozukluğu ve devralınması gereken teknik borç çoğu zaman çok daha pahalıya patlar.
Bu yazıda, kurumsal bir projede iş ortağı değerlendirirken sorulması gereken soruları ve göz ardı edilen sinyalleri 12 başlıkta topladık.
1. Sektör Deneyimi, Teknoloji Listesinden Önemlidir
Bir ajansın web sitesindeki teknoloji rozetleri size çok az şey anlatır. Asıl sorulması gereken şudur: "Bizim iş modelimize benzer kaç projeyi baştan sona teslim ettiniz?" Üretim planlama, stok yönetimi veya B2B fiyatlandırma gibi alanların kendine has kuralları vardır. Bu kuralları daha önce görmüş bir ekip, ilk toplantıda doğru soruları sorar.
2. Referansları Sadece Okumayın, Arayın
Vaka çalışmaları pazarlama malzemesidir. Gerçek bilgi, eski müşterilerle yapılan on dakikalık telefon görüşmesinden gelir. Sorulacak üç soru yeterlidir:
- Proje ilk verilen takvimde teslim edildi mi, edilmediyse neden?
- Kapsam dışı bir talep geldiğinde nasıl davrandılar?
- Bugün aynı projeyi yeniden başlatsanız yine aynı ekiple mi çalışırdınız?
3. Ekip Kompozisyonunu Netleştirin
Satış toplantısına gelen kıdemli mimarın projede kaç saat çalışacağını mutlaka sorun. Sektörde yaygın bir sorun, teklif aşamasındaki ekiple sahaya inen ekibin farklı olmasıdır. Sözleşmeye "projeye atanacak kişiler ve kıdem seviyeleri" maddesi eklemek, bu riski büyük ölçüde ortadan kaldırır.
4. Kod Sizin Mi, Onların Mı?
Fikri mülkiyet hakları maddesi, sözleşmenin en kritik satırıdır. Kaynak kodun, veritabanı şemalarının, altyapı yapılandırmalarının ve tasarım dosyalarının tamamı proje sonunda size devredilmelidir. "Lisanslı kullanım" ifadesi gördüğünüz her yerde durun ve netleştirin.
5. Teslimat Sadece Kod Değildir
Sağlıklı bir teslimat paketi şunları içerir:
- Çalışan uygulamanın kaynak kodu ve sürüm geçmişi
- Kurulum ve dağıtım (deployment) dokümantasyonu
- API dokümantasyonu ve veri modeli şeması
- Ortam değişkenleri ve altyapı yapılandırması
- Yönetici kullanıcılar için eğitim oturumu
Bunların hiçbiri "ekstra hizmet" değildir; standart kapsamın parçasıdır.
6. Sabit Fiyat mı, Zaman ve Malzeme mi?
İki modelin de yeri vardır. Kapsamı net, değişme ihtimali düşük işlerde sabit fiyat güvenlidir. Keşif gerektiren, kullanıcı geri bildirimiyle şekillenecek ürünlerde ise zaman-malzeme modeli daha dürüst sonuç verir.
| Kriter | Sabit Fiyat | Zaman & Malzeme |
|---|---|---|
| Kapsam netliği | Yüksek olmalı | Esnek olabilir |
| Bütçe öngörülebilirliği | Yüksek | Orta |
| Değişikliğe uyum | Zayıf, ek sözleşme gerekir | Güçlü |
| Uygun proje tipi | Entegrasyon, kurumsal site | Yeni ürün, SaaS, MVP |
7. Güvenlik ve Uyumluluk Yaklaşımını Sorun
KVKK uyumu, veri saklama süreleri, log yönetimi, yetkilendirme modeli ve yedekleme politikası ilk toplantıda konuşulmalıdır. Bu başlıkları projenin sonuna bırakan bir ekip, size sonradan yeniden yazılması gereken bir mimari teslim eder.
8. Test ve Kalite Süreçlerini Görün
"Test ediyoruz" cümlesi yeterli değildir. Otomatik test kapsamı, kod inceleme (code review) pratiği, sürekli entegrasyon hattı ve hata takip sistemi somut olarak gösterilebilmelidir. Bir demo ortamına erişim istemek en hızlı doğrulama yöntemidir.
9. İletişim Ritmini Baştan Belirleyin
Haftalık demo, paylaşılan bir görev panosu ve tek bir muhatap kişi. Bu üçlü olmadan ilerleyen projelerde sorunlar ancak teslimat haftasında görünür hale gelir. İyi ekipler kötü haberi erken verir.
"Bir projede en pahalı hata, geç öğrenilen hatadır."
10. Bakım ve Destek Sözleşmesini Ayrı Değerlendirin
Yayına alma bir bitiş değil, başlangıçtır. Destek kapsamı; müdahale süreleri (SLA), kritik hata tanımı, mesai dışı erişim ve aylık geliştirme kotası gibi maddelerle netleştirilmelidir. Bu maddeler yoksa, projeniz canlıya çıktığı gün savunmasız kalır.
11. Ölçek ve Süreklilik Riskini Hesaplayın
Tek kişilik bir ekip düşük maliyetlidir ancak o kişi projeden ayrıldığında ortada devralınamayan bir sistem kalır. Karşılaştırma yaparken firmanın ekip büyüklüğü, çalışma geçmişi ve kurumsal sürekliliği önemli bir faktördür. Sektördeki oyuncuları tek bir yerden karşılaştırmak istiyorsanız, bağımsız değerlendirme platformları üzerinden ihtiyacınıza uygun bir yazilim firmasi araştırması yaparak kısa liste oluşturmak iyi bir başlangıç noktasıdır.
12. İlk Teklifin Kendisi Bir Testtir
Gelen teklifi bir belge değil, bir çalışma örneği olarak okuyun. İyi bir teklif; varsayımları açıkça yazar, kapsam dışında kalanları listeler, riskleri isimlendirir ve fazları gerekçelendirir. Tek sayfalık ve tek kalemlik bir fiyat teklifi, projenin nasıl yönetileceğine dair yeterince güçlü bir sinyaldir.
Kısa Bir Değerlendirme Kontrol Listesi
Görüşme sonrası şu soruların cevabı netse doğru yoldasınız:
- Projeye kim, ne kadar süre çalışacak?
- Kod ve tüm varlıklar kime ait olacak?
- İlk çalışan sürümü ne zaman göreceğim?
- Kapsam değişirse süreç nasıl işleyecek?
- Yayın sonrası destek neyi kapsıyor?
Luumtech Nasıl Çalışıyor?
Luumtech olarak web uygulamaları, CRM ve ERP çözümleri, B2B e-ticaret sistemleri ve altyapı-güvenlik projelerinde uçtan uca sorumluluk alıyoruz. Her projeye kısa bir keşif fazıyla başlıyor; teknik mimariyi, entegrasyon noktalarını ve riskleri yazılı hale getirdikten sonra geliştirmeye geçiyoruz. Haftalık demo ritmi, paylaşılan görev panosu ve teslimatta eksiksiz dokümantasyon standart çalışma biçimimizin parçası.
Değerlendirme sürecinizde teknik bir görüş almak isterseniz bizimle iletişime geçebilirsiniz — mevcut mimarinizi inceleyip yol haritası çıkarmak için yaptığımız ilk görüşme ücretsizdir.
Bu yazı Luumtech ekibi tarafından hazırlanmıştır. Kurumsal yazılım projeleriniz için hizmetlerimizi inceleyin.
Enjoyed this article?