Yazılım Tekliflerini Karşılaştırırken Yalnızca Fiyata Bakmayın

Kısa özet: İki yazılım teklifinin aynı proje başlığını taşıması, aynı kapsamı sunduğu anlamına gelmez. Bir teklif yalnızca tasarım ve geliştirmeyi kapsarken diğeri analiz, kullanıcı deneyimi, güvenlik, test, SEO geçişi, kaynak kod devri, hosting kurulumu, dokümantasyon ve bakım hizmetlerini de içerebilir. Sağlıklı karşılaştırma için önce teklif kapsamları eşitlenmeli, ardından toplam sahip olma maliyeti değerlendirilmelidir.

Kısa doğrudan cevap

Yazılım teklifleri yalnızca toplam fiyat üzerinden karşılaştırılmamalıdır. Şu alanlar ayrı ayrı incelenmelidir:

• Analiz ve kapsam belirleme
• Kullanıcı deneyimi ve tasarım
• Teknik mimari
• Kaynak kod ve hesap sahipliği
• Hosting ve altyapı
• Yönetim paneli
• Test ve kabul süreci
• Güvenlik
• SEO ve veri geçişi
• Dokümantasyon ve eğitim
• Bakım ve proje sonrası destek

En düşük teklif; analiz, test, dokümantasyon, güvenlik veya bakım gibi önemli kalemleri kapsamıyorsa proje sonunda ek maliyet, gecikme ve tedarikçiye bağımlılık oluşturabilir.

Aynı proje için teklifler neden bu kadar farklı olabilir?

Bir işletme üç farklı yazılım firmasından “kurumsal web sitesi”, “mobil uygulama” veya “özel yazılım” teklifi aldığında fiyatlar arasında ciddi farklar görebilir. Bunun temel nedeni yalnızca firmaların kâr oranları değildir. Tekliflerin kapsamı farklı olabilir. Örneğin üç firma aynı proje için şu teklifleri verebilir:

Bu üç teklif aynı proje adıyla sunulsa da aynı hizmet değildir. İlk teklif daha düşük olabilir; ancak proje sırasında şu işler ayrıca fiyatlandırılabilir:

• Yeni sayfa şablonu
• Mobil uyarlama
• Yönetim paneli
• Form entegrasyonu
• Veri aktarımı
• SEO yönlendirmeleri
• Mağaza yayını
• Güvenlik düzenlemeleri
• Test
• Hosting kurulumu
• Eğitim
• Bakım

Bu nedenle teklif karşılaştırmasının ilk adımı fiyatlara bakmak değil, kapsamları eşitlemektir.

Yazılım teklifini karşılaştırmadan önce proje kapsamını sabitleyin

Firmalara farklı bilgiler verildiğinde gelen tekliflerin karşılaştırılabilir olması beklenmemelidir. Bir firma yalnızca kısa bir telefon görüşmesine göre fiyat verirken başka bir firma ayrıntılı analiz yapmış olabilir. Teklif istemeden önce mümkün olduğunca ortak bir proje özeti hazırlanmalıdır.

Proje özetinde bulunması gerekenler

• Projenin amacı
• Hedef kullanıcılar
• Temel kullanıcı akışları
• Kullanıcı rolleri
• Web ve mobil kapsamı
• Yönetim paneli ihtiyacı
• Ödeme veya abonelik
• Bildirimler
• Entegrasyonlar
• Çoklu dil
• Veri aktarımı
• İçerik girişi
• SEO geçişi
• Hosting beklentisi
• Bakım ve destek beklentisi
• Hedef yayın dönemi

Bu doküman nihai teknik şartname olmak zorunda değildir. Ancak bütün tedarikçilerin aynı problemi ve beklentiyi değerlendirmesini sağlamalıdır.

Belirsiz kapsamın sonucu

“Modern bir web sitesi istiyoruz” ifadesiyle teklif alınırsa her firma “modern” kelimesini farklı yorumlayabilir. Bir firma:

• Hazır tema
• Beş sayfa
• Temel iletişim formu

önerirken başka bir firma:

• Marka analizi
• Özel UX
• Özgün tasarım sistemi
• CMS
• SEO migration
• Performans optimizasyonu
• Analytics

öneriyor olabilir. Fiyat farkının sebebi ancak kapsam kalemleri yan yana getirildiğinde anlaşılır.

1. Analiz kapsamını karşılaştırın

Analiz, yazılım projesinin ne yapacağının ve ne yapmayacağının belirlendiği aşamadır. Bazı teklifler doğrudan tasarım ve geliştirmeyle başlar. Bazıları ise önce süreç analizi ve kullanıcı gereksinimleri çalışması sunar.

Analiz aşaması neleri kapsayabilir?

• İş hedefleri
• Hedef kullanıcılar
• Mevcut süreç
• Sorun ve ihtiyaçlar
• Kullanıcı rolleri
• Kullanıcı akışları
• Entegrasyonlar
• Veri modeli
• Yetkilendirme
• MVP kapsamı
• Teknik kısıtlar
• Kabul kriterleri
• Riskler
• Proje aşamaları

Neden önemlidir?

Analiz yapılmadan başlayan projelerde şu problemler oluşabilir:

• Kapsam sürekli değişir.
• Özellikler farklı anlaşılır.
• Yeni taleplerin teklife dâhil olup olmadığı tartışılır.
• Kullanıcı rolleri geliştirme sonunda fark edilir.
• Entegrasyon ihtiyacı sonradan ortaya çıkar.
• Yönetim panelinin kapsamı belirsiz kalır.
• Proje tamamlanmış sayılsa bile işletmenin süreci çalışmaz.

Teklifte aranması gereken ifadeler

• Analiz toplantılarının sayısı
• Süreç haritası teslimi
• Kullanıcı rol matrisi
• Fonksiyon listesi
• Teknik gereksinim dokümanı
• MVP kapsamı
• Kabul kriterleri
• Kapsam dışı maddeler
• Revizyon ve değişiklik yönetimi

“İhtiyacınıza göre geliştirilecektir” ifadesi tek başına analiz kapsamını açıklamaz.

2. Tasarım sürecini karşılaştırın

“UI/UX tasarım dâhil” ifadesi her teklifte aynı anlama gelmeyebilir. Bir teklif hazır tema veya mevcut komponent kütüphanesi üzerinde renk değişikliği sunabilir. Başka bir teklif özgün kullanıcı deneyimi ve tasarım sistemi hazırlayabilir.

Tasarım kapsamındaki olası farklar

Tasarımda sorulması gerekenler

• Hazır tema mı kullanılacak?
• Tasarımlar Figma veya benzeri formatta teslim edilecek mi?
• Masaüstü ve mobil ekranlar ayrı tasarlanacak mı?
• Kaç özgün sayfa veya ekran şablonu bulunuyor?
• Kaç revizyon turu dâhil?
• Tıklanabilir prototip hazırlanacak mı?
• Tasarım sistemi oluşturulacak mı?
• Tablet görünümü ayrıca değerlendirilecek mi?
• Erişilebilirlik hedefi bulunuyor mu?
• Tasarım dosyalarının sahipliği ve erişimi kimde olacak?

WCAG 2.2; web içeriklerinin algılanabilir, kullanılabilir, anlaşılabilir ve sağlam olması için test edilebilir erişilebilirlik kriterleri sunar. Teklifte erişilebilirlik sözü veriliyorsa hangi WCAG seviyesinin veya hangi testlerin hedeflendiği açıklanmalıdır.

3. Teknik mimari yalnızca teknoloji isimlerinden oluşmaz

Teklifte “React, Next.js, Node.js ve PostgreSQL kullanılacaktır” yazması tek başına teknik mimari açıklaması değildir. Teknoloji isimleri kadar sistemin nasıl kurulacağı önemlidir.

Teknik mimaride değerlendirilmesi gerekenler

• Frontend ve backend ayrımı
• Veri tabanı modeli
• Kullanıcı ve yetki sistemi
• API yapısı
• Dosya depolama
• Bildirim altyapısı
• Ödeme sistemi
• Loglama
• Hata izleme
• Yedekleme
• Deployment
• Test ortamı
• Ölçeklenme
• Entegrasyonlar
• Güvenlik sınırları

Tedarikçiye sorulabilecek sorular

• Sistem tek uygulama mı, ayrı frontend ve backend mi olacak?
• Kullanıcı yetkileri nasıl uygulanacak?
• Staging ortamı bulunacak mı?
• Production dağıtımları nasıl yapılacak?
• Hata durumunda eski sürüme dönülebilecek mi?
• Veri tabanı yedekleri nasıl alınacak?
• Yoğun trafik durumunda sistem nasıl ölçeklenecek?
• Üçüncü taraf servislerin çalışmaması nasıl yönetilecek?
• Loglara ve hata raporlarına kim erişecek?
• Teknik yapı dokümante edilecek mi?

Teknik teklif, yalnızca kullanılacak araçları değil; sistemin güvenli ve sürdürülebilir biçimde nasıl işletileceğini de açıklamalıdır.

4. Kaynak kod sahipliğini ve dijital hesapları netleştirin

Yazılım projesinin sonunda yalnızca çalışan bir ürün değil, onu yönetmek için gerekli dijital varlıklar da bulunur.

İşletmenin kontrolünde olması önerilen varlıklar

• Kaynak kod repository’si
• Domain hesabı
• DNS
• Hosting veya cloud hesabı
• Veri tabanı
• Apple Developer hesabı
• Google Play Console
• Ödeme sağlayıcısı
• Analytics
• Search Console
• E-posta ve SMS servisleri
• Firebase veya bildirim sistemi
• Tasarım dosyaları
• Üçüncü taraf lisanslar
• SSL ve güvenlik anahtarları

Kaynak kod konusunda açıklığa kavuşturulması gerekenler

• Kaynak kodun mülkiyeti kime ait olacak?
• İşletmeye tam devir mi yapılacak?
• Yalnızca kullanım lisansı mı verilecek?
• Tedarikçi kendi hazır altyapısını mı kullanacak?
• Yeniden kullanılabilir komponentlerin durumu ne olacak?
• Açık kaynak bileşenler var mı?
• Üçüncü taraf lisans koşulları neler?
• Sözleşme bittiğinde repository erişimi devam edecek mi?
• Başka bir ekip projeyi devralabilecek mi?
• Devir için ek ücret var mı?

Fikri haklar ve kaynak kod sahipliği ülkeye, sözleşmeye ve kullanılan bileşenlere göre değişebilir. Bu nedenle “kaynak kod teslim edilir” ifadesi tek başına yeterli değildir; mülkiyet, lisans ve devir hükümleri sözleşmede açıkça düzenlenmeli ve gerektiğinde hukuk uzmanı tarafından incelenmelidir.

Repository neden şirket organizasyonunda bulunmalı?

GitHub organizasyonları, repository erişimlerinin kişi ve ekip bazında rollerle yönetilmesini sağlar. GitHub ayrıca tek bir kişinin erişilemez hale gelmesi durumunda proje erişiminin kaybolmaması için organizasyonlarda birden fazla owner bulundurulmasını önerir. Sağlıklı model: Şirket GitHub organizasyonu ├── Şirket yöneticileri ├── İç teknik ekip └── Yazılım tedarikçisi Riskli model: Tedarikçinin kişisel hesabı └── Şirketin bütün kaynak kodu İkinci modelde tedarikçi değişimi, erişim, devir ve iş sürekliliği problemleri oluşabilir.

5. Hosting ve altyapı teklifini ayrı değerlendirin

“Hosting dâhil” ifadesi şu soruların cevabını vermez:

• Hangi sağlayıcı?
• Hangi plan?
• Ne kadar trafik?
• Ne kadar depolama?
• Veri tabanı dâhil mi?
• Yedekleme dâhil mi?
• CDN var mı?
• E-posta servisi var mı?
• Log saklama var mı?
• Limit aşılırsa ne olur?
• Hesap kimin adına?
• Fatura kime gelir?

Hosting modelleri

Tedarikçi hesabında hosting

Avantajı:

• Teknik kurulum daha kolay olabilir.
• İşletmenin ilk aşamada altyapı yönetmesi gerekmez.

Riskleri:

• Maliyet görünürlüğü azalabilir.
• Tedarikçi değişiminde taşıma gerekebilir.
• Hesap ve loglara erişim sınırlı olabilir.
• Proje başka müşterilerle aynı altyapıda bulunabilir.

İşletme hesabında hosting

Avantajı:

• Hesap ve fatura kontrolü işletmededir.
• Tedarikçi değişimi kolaylaşır.
• Kullanım ve maliyet görünürdür.
• Erişimler rol bazlı verilebilir.

Riskleri:

• Kurulum ve güvenlik sorumlulukları açıkça yönetilmelidir.
• İşletmenin hesap sahipliğini koruması gerekir.

Teklifte bulunması gereken altyapı bilgileri

• Cloud veya hosting sağlayıcısı
• Başlangıç planı
• Beklenen aylık maliyet
• Kullanım limitleri
• Otomatik ölçeklenme
• Veri bölgesi
• Yedekleme
• İzleme
• Loglama
• Felaket kurtarma
• Maliyet artış senaryosu
• Hesap sahipliği
• Taşıma ve devir süreci

İlk yıl ücretsiz veya düşük maliyetli olan altyapının sonraki dönem maliyeti de değerlendirilmelidir.

6. Yönetim panelinin kapsamını karşılaştırın

“Yönetim paneli dâhil” ifadesi çok geniştir. Bir yönetim paneli yalnızca blog yazısı eklemeyi sağlayabilir. Başka bir panel bütün kullanıcı, sipariş, ödeme ve operasyon süreçlerini yönetebilir.

Yönetim panelinde bulunabilecek alanlar

• Sayfa ve içerik yönetimi
• Blog
• Görsel ve dosyalar
• Kullanıcılar
• Kullanıcı rolleri
• Ürünler
• Siparişler
• Rezervasyonlar
• Ödemeler
• Kampanyalar
• Bildirimler
• Form kayıtları
• Entegrasyon hataları
• Raporlama
• Sistem ayarları
• Audit log

Sorulması gerekenler

• Hangi içerikler panelden değiştirilebilir?
• Yeni sayfa oluşturulabilir mi?
• Sadece mevcut alanlar mı düzenlenebilir?
• SEO title ve description yönetilebilir mi?
• Kullanıcı ve rol yönetimi var mı?
• İşlem geçmişi tutuluyor mu?
• Excel veya CSV dışa aktarma var mı?
• Çoklu dil yönetilebilir mi?
• Görsel boyutlandırma otomatik mi?
• Form alanları değiştirilebilir mi?
• Panel mobil cihazda kullanılabilir mi?
• Eğitim verilecek mi?

Yönetim paneli kapsamı net değilse proje sonunda her küçük değişiklik için yeniden geliştiriciye ihtiyaç duyulabilir.

7. Test ve kabul sürecini karşılaştırın

“Test edilerek teslim edilecektir” ifadesi hangi testlerin yapılacağını açıklamaz.

Yazılım projesindeki test türleri

• Fonksiyon testi
• Kullanıcı akışı testi
• Mobil uyumluluk testi
• Tarayıcı testi
• API testi
• Entegrasyon testi
• Yetkilendirme testi
• Güvenlik testi
• Performans testi
• Erişilebilirlik testi
• Yük testi
• Veri aktarım testi
• Regression testi
• Kullanıcı kabul testi

Teklifte sorulması gerekenler

• Testleri kim yapacak?
• Ayrı QA süreci var mı?
• Hangi cihazlar ve tarayıcılar destekleniyor?
• Test senaryoları paylaşılacak mı?
• Otomatik test yazılacak mı?
• Hata takip sistemi kullanılacak mı?
• Müşteri kabul testi için süre verilecek mi?
• Kabul kriterleri önceden belirlenecek mi?
• Yayın sonrası hata garanti süresi var mı?
• Kritik ve küçük hatalar nasıl sınıflandırılacak?

Kabul kriteri örneği

Belirsiz ifade: Ödeme sistemi çalışacaktır. Daha ölçülebilir ifade: Kullanıcı başarılı kart ödemesi yapabildiğinde sipariş oluşturulmalı, ödeme kaydı backend’de doğrulanmalı, kullanıcıya onay ekranı ve e-postası gösterilmeli, başarısız ödemelerde sipariş tamamlanmamalıdır. Kabul kriterleri ne kadar açık olursa “proje tamamlandı mı?” tartışması o kadar azalır.

8. Güvenlik teklifin ayrı bir kalemi olmalıdır

Güvenlik yalnızca SSL sertifikası eklemekten oluşmaz. NIST Secure Software Development Framework, güvenli geliştirme uygulamalarının mevcut yazılım geliştirme yaşam döngüsüne entegre edilmesini önerir. OWASP SAMM de güvenliği yönetişim, tasarım, uygulama, doğrulama ve operasyon boyunca ele alan bir model sunar.

Güvenlik kapsamında değerlendirilmesi gerekenler

• Kimlik doğrulama
• Yetkilendirme
• Kullanıcı rolleri
• Parola güvenliği
• Çok faktörlü doğrulama
• Oturum yönetimi
• Veri doğrulama
• Dosya yükleme
• API güvenliği
• Rate limit
• Secret yönetimi
• Audit log
• Veri şifreleme
• Güvenlik başlıkları
• Dependency taraması
• Güvenli deployment
• Yedekleme
• Olay müdahalesi

Güvenlik için sorulması gerekenler

• Yetkilendirme sunucu tarafında uygulanıyor mu?
• Kullanılan paketler zafiyet açısından taranıyor mu?
• Kod incelemesi yapılıyor mu?
• Production secret’ları nasıl saklanacak?
• Yönetici hesaplarında MFA olacak mı?
• Audit log tutulacak mı?
• Güvenlik güncellemeleri proje sonrasında kim tarafından yapılacak?
• Kritik açık durumunda müdahale süresi nedir?
• Penetrasyon testi dâhil mi?
• Kişisel veriler nasıl korunacak?
• Veri saklama ve silme süreçleri var mı?

“Güvenli yazılım geliştirilecektir” ifadesi, uygulanacak güvenlik kontrolleri belirtilmeden ölçülebilir değildir.

9. Web projelerinde SEO geçişini ayrı değerlendirin

Mevcut bir web sitesi yenileniyorsa SEO geçişi teklifin önemli parçasıdır. Yeni sitenin daha modern görünmesi, mevcut organik görünürlüğün otomatik olarak korunacağı anlamına gelmez.

SEO geçiş kapsamı

• Mevcut URL envanteri
• Organik trafik alan sayfalar
• Eski ve yeni URL eşleştirmesi
• 301 yönlendirmeler
• Metadata aktarımı
• Canonical
• XML sitemap
• Robots ayarları
• Structured data
• İç bağlantılar
• Çoklu dil ve hreflang
• Analytics
• Search Console
• Dönüşüm olayları
• Yayın sonrası index takibi

Google, URL değişikliği bulunan site taşıma işlemleri için eski ve yeni URL’lerin eşleştirilmesini ve mümkün olduğunda kalıcı sunucu tarafı yönlendirmelerin kullanılmasını önerir. Site taşıma sonrasında Google’ın sayfaları yeniden tarayıp indexlemesi sırasında görünürlük dalgalanmaları yaşanabilir.

SEO teklifte yoksa ne olabilir?

• Eski URL’ler 404 verir.
• Trafik alan sayfalar kaybolur.
• Bütün eski URL’ler ana sayfaya yönlendirilir.
• Metadata aktarılmaz.
• Sitemap güncellenmez.
• Analytics dönüşümleri çalışmaz.
• Çoklu dil sayfaları karışır.
• Search Console izleme yapılmaz.

“SEO uyumlu yazılım” ifadesi tek başına SEO migration hizmeti anlamına gelmez.

10. Dokümantasyon ve eğitim kapsamını değerlendirin

Yazılım tamamlandığında sistemin yalnızca geliştiren ekip tarafından anlaşılabiliyor olması işletme açısından risktir.

Teknik dokümantasyon

• Sistem mimarisi
• Kurulum adımları
• Ortam değişkenleri
• Deployment süreci
• Veri tabanı yapısı
• API dokümantasyonu
• Entegrasyonlar
• Yedekleme ve restore
• Kullanıcı rolleri
• Kritik operasyonlar
• Bilinen sınırlamalar

Kullanıcı dokümantasyonu

• Yönetim paneli kullanımı
• Kullanıcı daveti
• İçerik ekleme
• Sipariş veya operasyon yönetimi
• Raporlama
• Sık karşılaşılan sorunlar
• Destek talebi oluşturma

Eğitim

• Kaç saat eğitim verilecek?
• Kimler katılacak?
• Eğitim kaydedilecek mi?
• Yeni çalışanlar için materyal olacak mı?
• Yönetici ve son kullanıcı eğitimi ayrı mı?
• Eğitim sonrası destek süresi var mı?

Dokümantasyonun olmadığı projelerde ekip veya tedarikçi değişimi daha uzun ve maliyetli olabilir.

11. Bakım ve proje sonrası desteği karşılaştırın

Projenin yayına alınması, yazılım yaşam döngüsünün sonu değildir. Bakım kapsamında şu alanlar bulunabilir:

• Kritik hata müdahalesi
• Güvenlik güncellemeleri
• Paket ve framework güncellemeleri
• Uptime ve hata izleme
• Yedekleme
• Hosting yönetimi
• Küçük içerik değişiklikleri
• Teknik SEO kontrolleri
• Mağaza uyumluluğu
• Aylık raporlama

Teklifte açıklanması gerekenler

• Garanti süresi
• Bakım başlangıç tarihi
• Aylık bakım ücreti
• Dâhil olan teknik süre
• Müdahale süresi
• Destek saatleri
• Mesai dışı destek
• Güvenlik güncellemeleri
• Major sürüm geçişleri
• Yeni geliştirmelerin fiyatlandırılması
• Kullanılmayan bakım saatlerinin durumu
• Sözleşme sona erdiğinde devir

Ucuz bir geliştirme teklifi, yüksek ve zorunlu bakım ücretiyle uzun vadede daha pahalı hale gelebilir.

Tekliflerde görünmeyen maliyetler

Proje sırasında çıkabilecek ek maliyetler

• Ek ekran
• Ek kullanıcı rolü
• Yeni entegrasyon
• Veri aktarımı
• İçerik girişi
• Çoklu dil
• Yeni tasarım revizyonu
• Ödeme altyapısı
• App Store veya Google Play işlemleri
• SEO yönlendirmeleri
• Üçüncü taraf lisansları
• Test cihazları
• Cloud kullanımı

Proje sonrasında çıkabilecek maliyetler

• Hosting
• Veri tabanı
• Depolama
• E-posta ve SMS
• Harita API’si
• Ödeme komisyonu
• Hata izleme
• Yedekleme
• Güvenlik taraması
• Bakım
• Teknik destek
• Major sürüm yükseltmeleri
• Yeni özellikler

Geçiş maliyetleri

• Eski verinin temizlenmesi
• Kullanıcı aktarımı
• Domain ve DNS değişimi
• Eski URL yönlendirmeleri
• E-posta şablonları
• Kullanıcı eğitimi
• Eski sistemle paralel çalışma
• Yeni sisteme geçiş desteği

Teklifin düşük görünmesinin nedeni bazı maliyetlerin “müşteri tarafından karşılanacaktır” şeklinde kapsam dışında bırakılması olabilir.

Toplam sahip olma maliyetini hesaplayın

Yalnızca ilk geliştirme maliyetini karşılaştırmak yerine en az üç yıllık toplam maliyet değerlendirilmelidir.

Örnek formül

3 yıllık toplam sahip olma maliyeti = Analiz ve tasarım + geliştirme + veri ve içerik geçişi + lisanslar + hosting ve cloud + bakım + güvenlik ve sürüm yükseltmeleri + zorunlu entegrasyonlar + tedarikçi değişim maliyeti

Örnek karşılaştırma

İlk fiyatı düşük olan teklif, toplam maliyette daha pahalı olabilir.

Yazılım teklifleri için puanlama matrisi

Her teklifi 100 puan üzerinden değerlendirebilirsiniz.

Puanlama yöntemi

Her kriter için 1–5 arasında puan verin:

• 1: Yetersiz veya belirsiz
• 2: Sınırlı
• 3: Kabul edilebilir
• 4: Güçlü
• 5: Çok güçlü ve açık

Örnek: Kriter puanı = Verilen puan / 5 × kriter ağırlığı

Örnek hesaplama

Analiz kriteri 15 puan ve firma 4/5 aldıysa: 4 / 5 × 15 = 12 puan Bu yöntem, fiyatın bütün kararı tek başına belirlemesini engeller.

Fiyat ayrıca nasıl değerlendirilir?

Fiyat kriteri yalnızca en düşük teklife en yüksek puanı vermemelidir. Şunlara birlikte bakılmalıdır:

• Kapsam açıklığı
• Ek maliyet riski
• Ödeme planı
• Toplam sahip olma maliyeti
• Bakım maliyeti
• Lisans ve altyapı
• Değişiklik fiyatlandırması
• Devir maliyeti

Teklifte kırmızı bayraklar

Kapsamla ilgili kırmızı bayraklar

• “Sınırsız revizyon”
• “İhtiyacınız olan her şey dâhil”
• Fonksiyon listesinin bulunmaması
• Kapsam dışı işlerin belirtilmemesi
• Yönetim panelinin açıklanmaması
• Entegrasyonların isimlendirilmemesi
• Kullanıcı rollerinin tanımlanmaması
• Proje kabul kriterinin bulunmaması

Teknik kırmızı bayraklar

• Teknoloji seçiminin gerekçesiz olması
• Test ortamının bulunmaması
• Yedekleme planının olmaması
• Kaynak kod repository’sinin paylaşılmaması
• Production hesaplarının ajansın kişisel hesabında olması
• Güvenlik kapsamının yalnızca SSL’den oluşması
• Veri tabanı ve kullanıcı yetkilerinin açıklanmaması
• Dokümantasyon teslim edilmemesi

Ticari kırmızı bayraklar

• Çok düşük başlangıç fiyatı, belirsiz ek maliyetler
• Ödeme planının teslimata bağlanmaması
• Kaynak kod devri için sonradan ücret istenmesi
• Zorunlu ve yüksek bakım sözleşmesi
• İptal veya devir sürecinin bulunmaması
• Üçüncü taraf lisanslarının açıklanmaması
• Hosting maliyetinin görünmemesi
• Sözlü vaatlerin teklifte yer almaması

Proje yönetimi kırmızı bayrakları

• Sorumlu kişinin belli olmaması
• İletişim ve raporlama takviminin bulunmaması
• Değişiklik taleplerinin nasıl yönetileceğinin açıklanmaması
• Teslimatların aşamalara ayrılmaması
• Demo veya ara teslim bulunmaması
• Gecikme durumunun nasıl ele alınacağının belirtilmemesi

Çok düşük teklif neden riskli olabilir?

Düşük teklif mutlaka kötü teklif değildir. Tedarikçi:

• Hazır altyapıya
• Uzman ekibe
• Tekrarlanabilir sürece
• Sektörel deneyime
• Verimli teknolojiye

sahip olduğu için uygun fiyat sunabilir. Ancak düşük fiyat şu nedenlerden de kaynaklanabilir:

• Analiz yapılmaması
• Hazır temanın özel tasarım gibi sunulması
• Testin sınırlı olması
• Junior ekip kullanılması
• Bakım ve destek dışarıda bırakılması
• Kaynak kod devrinin olmaması
• SEO geçişinin yapılmaması
• Projenin ileride ek ücretlerle tamamlanması
• Güvenlik ve dokümantasyonun atlanması

Doğru soru: “Neden bu kadar ucuz?” değil, “Bu fiyatın içinde hangi işler bulunuyor ve hangi işler bulunmuyor?” olmalıdır.

En yüksek teklif her zaman en iyi teklif midir?

Hayır. Yüksek fiyat da otomatik olarak yüksek kalite anlamına gelmez. Yüksek teklif şu durumlarda gereksiz olabilir:

• İşletmenin ihtiyacından fazla kapsam sunuluyorsa
• Gereksiz kurumsal süreçler ekleniyorsa
• MVP yerine bütün gelecek özellikler ilk sürüme alınıyorsa
• Kullanılmayacak teknolojiler öneriliyorsa
• Basit site için karmaşık cloud mimarisi kuruluyorsa
• İşletmenin ihtiyaç duymadığı uzun danışmanlık süreçleri sunuluyorsa
• Marka veya ajans primi çok yüksekse

İyi teklif; en düşük veya en yüksek teklif değil, iş ihtiyacını doğru kapsam ve sürdürülebilir maliyetle karşılayan tekliftir.

Referans ve ekip nasıl değerlendirilmelidir?

Referans listesinde tanınmış marka bulunması tek başına yeterli değildir. Şunları sorun:

• Benzer kapsamda proje yapıldı mı?
• Referanstaki işi aynı ekip mi yaptı?
• Projede hangi rol üstlenildi?
• Tasarım mı, geliştirme mi, bakım mı yapıldı?
• Proje hâlâ yayında mı?
• Devam eden bakım ilişkisi var mı?
• Benzer entegrasyon deneyimi bulunuyor mu?
• Projede çalışan kişiler sizin projenizde de görev alacak mı?

Ekipte bulunabilecek roller

• Proje yöneticisi
• İş analisti
• UX tasarımcı
• UI tasarımcı
• Frontend geliştirici
• Backend geliştirici
• Mobil geliştirici
• DevOps
• QA
• Güvenlik uzmanı
• SEO uzmanı

Her projede bütün bu rollerin ayrı kişiler olması gerekmez. Ancak gerekli sorumlulukların kim tarafından üstlenildiği açık olmalıdır.

Proje planı ve ödeme takvimini karşılaştırın

Ödemenin tamamının proje başlangıcında veya yalnızca takvim tarihine göre yapılması yerine teslimat aşamalarına bağlanması daha ölçülebilir olabilir.

Örnek aşamalar

• Analiz ve kapsam onayı
• Wireframe ve kullanıcı akışları
• UI tasarım onayı
• Temel yazılım geliştirme
• Entegrasyonlar
• Test ve kullanıcı kabulü
• Production yayını
• Dokümantasyon ve devir

Ödeme takviminde sorulması gerekenler

• Başlangıç ödemesi ne kadar?
• Ödemeler hangi teslimata bağlı?
• Revizyon gecikmesi takvimi nasıl etkiler?
• Müşterinin geciken içerikleri nasıl yönetilir?
• Ek kapsam nasıl fiyatlandırılır?
• Proje durdurulursa yapılan işler nasıl teslim edilir?
• Ödeme yapılmış fakat tamamlanmamış çalışmaların durumu nedir?
• Vergiler ve üçüncü taraf giderleri dâhil mi?

Sözleşmede bulunması gereken temel başlıklar

Bu bölüm genel kontrol listesidir ve hukuki danışmanlık değildir.

• Taraflar
• Proje kapsamı
• Teslimatlar
• Kapsam dışı işler
• Proje takvimi
• Müşteri sorumlulukları
• Ödeme planı
• Revizyonlar
• Değişiklik yönetimi
• Kabul kriterleri
• Hata ve garanti süresi
• Bakım ve destek
• Gizlilik
• Kişisel veri sorumlulukları
• Kaynak kod ve fikri haklar
• Açık kaynak ve üçüncü taraf bileşenler
• Hosting ve hesap sahipliği
• Gecikme ve mücbir sebepler
• Sözleşmenin sona ermesi
• Devir ve veri teslimi
• Uyuşmazlık çözümü

Sözleşme, teklif dokümanında bulunan sözlü ve yazılı vaatlerle uyumlu olmalıdır.

Yazılım teklifini karşılaştırma kontrol listesi

Analiz

• İş hedefleri açık mı?
• Hedef kullanıcılar belirtilmiş mi?
• Kullanıcı rolleri tanımlı mı?
• MVP kapsamı belli mi?
• Kapsam dışı işler yazılmış mı?
• Kabul kriterleri bulunuyor mu?
• Entegrasyonlar isimlendirilmiş mi?

Tasarım

• Hazır tema mı, özgün tasarım mı?
• Mobil ekranlar ayrıca tasarlanacak mı?
• Wireframe hazırlanacak mı?
• Tıklanabilir prototip var mı?
• Tasarım sistemi oluşturulacak mı?
• Revizyon sayısı belli mi?
• Tasarım dosyaları teslim edilecek mi?
• Erişilebilirlik kapsamı var mı?

Teknik

• Teknik mimari açıklanmış mı?
• Frontend ve backend kapsamı belli mi?
• Veri tabanı planı var mı?
• Kullanıcı ve yetki modeli açıklanmış mı?
• Staging ortamı bulunuyor mu?
• Deployment ve rollback süreci var mı?
• Yedekleme tanımlı mı?
• İzleme ve loglama var mı?

Kaynak kod ve hesaplar

• Kaynak kod sahipliği açık mı?
• Repository şirket kontrolünde mi?
• Cloud hesabı işletmeye mi ait?
• Domain ve DNS şirket hesabında mı?
• Tasarım dosyaları teslim edilecek mi?
• Üçüncü taraf lisansları açıklandı mı?
• Proje sonunda tam devir yapılacak mı?
• Devir için ek ücret var mı?

Yönetim paneli

• Hangi alanların yönetileceği belli mi?
• Kullanıcı ve rol yönetimi var mı?
• SEO alanları değiştirilebilir mi?
• Çoklu dil desteği bulunuyor mu?
• Form kayıtları görülebiliyor mu?
• Raporlama ve dışa aktarma var mı?
• Yönetim paneli eğitimi verilecek mi?

Test

• Test türleri belirtilmiş mi?
• Desteklenen cihaz ve tarayıcılar belli mi?
• Test senaryoları hazırlanacak mı?
• Otomatik test var mı?
• Kullanıcı kabul süresi bulunuyor mu?
• Hata garanti süresi var mı?
• Yayın sonrası kontrol yapılacak mı?

Güvenlik

• Güvenlik gereksinimleri yazılı mı?
• Kimlik ve yetkilendirme kapsamı açık mı?
• Dependency taraması yapılacak mı?
• Secret yönetimi açıklanmış mı?
• Audit log gerekli mi?
• MFA ihtiyacı değerlendirildi mi?
• Güvenlik güncellemeleri kim tarafından yapılacak?
• Penetrasyon testi dâhil mi?

SEO ve geçiş

• Mevcut URL envanteri çıkarılacak mı?
• 301 yönlendirmeler hazırlanacak mı?
• Metadata taşınacak mı?
• Sitemap ve canonical kontrol edilecek mi?
• Analytics ve Search Console kurulacak mı?
• Dönüşümler test edilecek mi?
• Yayın sonrası indexleme izlenecek mi?

Bakım ve destek

• Garanti süresi belli mi?
• Aylık bakım ücreti açık mı?
• Müdahale süresi belirtilmiş mi?
• Mesai dışı destek var mı?
• Güvenlik güncellemeleri dâhil mi?
• Major sürüm geçişleri dâhil mi?
• Yeni geliştirme fiyatlandırması belli mi?
• Sözleşme bitiminde devir süreci var mı?

İşletmeler için teklif karşılaştırma tablosu

Bu tablo doldurulmadan tekliflerin yalnızca toplam bedellerini yan yana koymak sağlıklı bir karşılaştırma sağlamaz.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın değerlendirmesidir; resmî standart ve platform dokümanlarından ayrıdır. Yazılım tekliflerinde en sık yapılan hata, fiyatın doğrudan ürün kalitesini temsil ettiğini düşünmektir. Gerçekte fiyat; kapsam, ekip, yöntem, teslimat ve proje sonrası sorumlulukların sonucudur. İkinci hata, tekliflerde aynı kelimelerin aynı hizmeti anlattığını varsaymaktır. Örneğin:

• “Özel tasarım”
• “SEO uyumlu”
• “Güvenli yazılım”
• “Yönetim paneli”
• “Mobil uyumlu”
• “Sınırsız destek”

ifadeleri ölçülebilir kapsamlar değildir. Her ifade şu soruyla açılmalıdır: Tam olarak hangi teslimatlar ve kriterler bu hizmetin içinde? Üçüncü hata, yalnızca ilk geliştirme ücretini karşılaştırmaktır. Projenin gerçek maliyeti:

• Hosting
• Lisanslar
• Bakım
• Paket güncellemeleri
• Veri aktarımı
• SEO geçişi
• Yeni özellikler
• Tedarikçi değişimi

dâhil edildiğinde ortaya çıkar. Dördüncü hata, kaynak kod teslimiyle dijital bağımsızlığın sağlandığını düşünmektir. Kaynak kod teslim edilse bile:

• Cloud hesabı
• Domain
• Veri tabanı
• App Store hesabı
• Ödeme hesabı
• Tasarım dosyaları
• Secret ve sertifikalar
• Deployment bilgisi

tedarikçide kalırsa işletme yine bağımlı olabilir. Beşinci hata, proje sonrasını proje başlamadan konuşmamaktır. Şunlar geliştirme başlamadan belirlenmelidir:

• Hataları kim düzeltecek?
• Hangi süre içinde müdahale edilecek?
• Güvenlik güncellemeleri kimde?
• Yeni özellikler nasıl fiyatlandırılacak?
• Tedarikçi değişirse devir nasıl yapılacak?
• Sistem destek dışı sürüme geldiğinde ne olacak?

InoviqLab açısından doğru teklif seçimi süreci şu şekilde ilerlemelidir:

• İş hedefi ve proje özeti hazırlanır.
• Firmalara aynı bilgiler gönderilir.
• Teklif kapsamları satır bazında eşitlenir.
• Belirsiz maddeler yazılı olarak açıklanır.
• Üç yıllık toplam maliyet hesaplanır.
• Teknik, ticari ve operasyonel kriterler puanlanır.
• Ekip ve benzer proje deneyimi incelenir.
• Sözleşme ve devir şartları kontrol edilir.
• Fiyat, bütün bu değerlendirmeden sonra ele alınır.

Sonuç

Yazılım tekliflerinde en düşük fiyat her zaman en ekonomik seçenek değildir. En yüksek fiyat da her zaman en kaliteli çözümü göstermez. Doğru teklif:

• İşletmenin gerçek ihtiyacını anlayan
• Kapsamı açıkça tanımlayan
• Analiz ve tasarım sürecini açıklayan
• Güvenlik ve testi ölçülebilir hale getiren
• Kaynak kod ve hesap sahipliğini netleştiren
• Bakım ve destek modelini gösteren
• Toplam maliyeti öngörülebilir kılan

tekliftir. Teklifleri karşılaştırırken yalnızca şu soruyu sormayın: “Toplam fiyat ne kadar?” Şunları da sorun:

• Bu fiyatın içinde tam olarak ne var?
• Hangi işler kapsam dışında?
• Proje sonunda hangi varlıkları teslim alacağız?
• Sistemi başka bir ekip devralabilir mi?
• Güncellemeleri ve güvenliği kim yönetecek?
• Üç yıl içindeki toplam maliyet ne olacak?
• Projenin tamamlandığını hangi kriterlerle kabul edeceğiz?

Yazılım yatırımında fiyat önemli bir kriterdir. Ancak fiyat, kapsam eşitlendikten sonra anlamlı hale gelir.