Ankara Web Tasarım Fiyatları: Teklifte Hangi İş Kalemleri Ayrılmalı?

Aynı web sitesi adı farklı işler içerebilir

Web sitesi için alınan iki teklif arasında belirgin fark olduğunda ilk tepki, pahalı olanın gereksiz maliyet içerdiğini veya ucuz olanın eksik olduğunu düşünmektir. Oysa teklifler farklı üretim biçimlerini kapsıyor olabilir. Hazır bir düzenin içerikle kurulması, kuruma özgü sayfa tasarımları yapılması ve iş süreçlerine bağlanan özel yazılım geliştirilmesi aynı iş değildir. Toplam tutarı değerlendirmeden önce satın alınan çıktının sınırını görmek gerekir.

Ankara'da bir kurumsal danışmanlık firmasının tanıtım sitesiyle, yüzlerce teknik ürün sunan bir tedarikçinin web sitesi aynı sayfa sayısına sahip görünse bile farklı emek gerektirebilir. Ürün verisinin temizlenmesi, teknik belgelerin eşleştirilmesi ve filtre düzeninin kurulması ayrı işlerdir. Bu yüzden ilk karşılaştırmayı sayfa adedi üzerinden yapmayın. Hangi sayfa türlerinin, hangi içeriklerin ve hangi işlemlerin teslim edileceğini karşılaştırın. Böylece bütçe tartışması somut bir zemine oturur.

Keşif ve içerik çalışmasını görünür kılın

Teklifte ihtiyaç analizi varsa bunun çıktısı belirtilmelidir. Görüşme yapılması tek başına teslim değildir; sayfa ağacı, kullanıcı akışları, içerik envanteri veya kapsam belgesi gibi somut sonuçlar aranmalıdır. Mevcut sitenin taşınacağı projede eski adreslerin, dosyaların ve içeriklerin incelenmesi de iş yükü yaratır. Bu hazırlık görünmez bırakıldığında tasarım başladıktan sonra yeni gereksinimler çıkabilir. Her yeni gereksinim, süre ve bütçe değerlendirmesini yeniden açabilir.

Metin ve görsel sorumluluğunu özellikle sorun. “İçerik müşteri tarafından sağlanır” cümlesi, metin düzenlemesini, görsel seçimini ve ürün verisi girişini kendiliğinden açıklamaz. Ajans yalnızca verilen dosyaları mı yerleştirecek, metinleri mi yeniden yazacak, eksik görseller için üretim mi yapılacak? Dil sayısı ve çeviri kontrolü de ayrıca belirtilmelidir. Kurumsal site içerik planı hazırlamak, bu işlerin hangi ekipte olduğunu ve kaç teslim gerektirdiğini önceden ortaya koyabilir.

Tasarım kapsamını ekran sayısıyla karıştırmayın

Ana sayfa, hizmet detayı, ürün detayı, liste sayfası ve iletişim farklı tasarım türleri olabilir. Aynı düzenden üretilen onlarca hizmet sayfası, onlarca ayrı tasarım anlamına gelmez. Buna karşılık tek bir ürün yapılandırma ekranı çok sayıda etkileşim durumu içerebilir. Yüklenme, boş sonuç, hata, başarı ve dar ekran görünümleri de tasarımın parçasıdır. Teklifte yalnızca “on sayfa tasarım” yazması bu ayrıntıları açıklamaya yetmez.

Tasarım revizyonunun nasıl yönetileceği de konuşulmalıdır. Önceden onaylanan kapsam içindeki düzeltmeyle yeni bir sayfa türü istemek farklı taleplerdir. Görüşlerin hangi aşamada toplanacağı, karar verecek kişinin kim olduğu ve onay sonrası değişikliklerin nasıl ele alınacağı netleştirilmelidir. Amaç revizyonu engellemek değildir; küçük düzeltmelerin ve yeni işlerin birbirine karışmasını önlemektir. Tasarım çalışmasının çıktıları arasında kaynak dosyaların ve kullanılan görsel lisanslarının durumu da yer almalıdır.

Yazılım ve entegrasyonları ayrı tarif edin

Yönetim paneli, çoklu dil, site içi arama, ürün filtresi, üyelik veya teklif sepeti gibi özellikler tek tek açıklanmalıdır. “Dinamik site” ifadesi hangi içeriğin kim tarafından değiştirilebildiğini söylemez. Örneğin editör fiyatı güncelleyebiliyor ama ürün ailesi ekleyemiyorsa bunun günlük operasyona etkisi vardır. Yönetilebilir alanların listesi ve rol yetkileri, teklif karşılaştırmasında teknik ayrıntıdan çok kullanım bilgisi sağlar. Gösterim talep etmek bu belirsizliği azaltabilir.

ERP, CRM, ödeme veya kargo bağlantıları için veri yönünü sorun: hangi bilgi nereden gelir, ne sıklıkta güncellenir, hata olursa kim müdahale eder? API, sistemlerin belirlenmiş kurallarla veri alışverişi yapmasına yarayan arayüzdür. Bağlantının mevcut olması, bütün iş kurallarının kendiliğinden çözülmesi anlamına gelmez. Gerekli erişimlerin, test ortamlarının ve dış sağlayıcı ücretlerinin teklif kapsamına dahil olup olmadığı yazılmalıdır. Bu ayrım özellikle özel yazılım içeren projelerde karşılaştırmayı anlamlı kılar.

Test, yayın ve işletim maliyetlerini unutmayın

Test kalemi yalnızca sitenin açılmasına bakmak değildir. Form, dosya indirme, mobil menü, ürün arama ve içerik güncelleme gibi esas görevlerin denenmesi gerekir. Erişilebilirlik açısından alan isimlerinin açıklığı da kontrol edilebilir. W3C WAI etiketleme rehberi bu alanların amaçlarının tanımlanmasını ele alır. Teklifte hangi görevlerin ve hangi tarayıcıların kontrol edileceği yazılıysa teslimin sınırı daha kolay anlaşılır. Test çıktısının nasıl paylaşılacağı da sorulabilir.

Alan adı, barındırma, e-posta, ücretli eklenti, lisanslı font ve üçüncü taraf hizmetler ayrı giderler oluşturabilir. İlk kurulumda dahil olan bir kalem sonraki yıl yenileme gerektirebilir. Bunların kimin hesabında tutulacağı, ödemeyi kimin yapacağı ve hizmet sona erdiğinde erişimlerin nasıl devredileceği net olmalıdır. Bakım hizmetinin içeriği de güncelleme, izleme, içerik girişi ve yeni geliştirme olarak ayrılabilir. Tek bir “yıllık destek” cümlesi bütün bu işleri güvenilir biçimde tarif etmez.

Teklif görüşmesinde örnek değişiklik isteyin

Kapsamı anlamanın pratik yollarından biri, olası bir değişikliği birlikte değerlendirmektir. Yeni bir dil eklemek, hizmet sayfasına belge alanı açmak veya mevcut CRM bağlantısını değiştirmek hangi işleri doğurur? Bu varsayımsal talebin nasıl analiz edileceğini sorun; hemen kesin bir tutar beklemeyin. Yanıtın girdileri, bağımlılıkları ve onay adımlarını açıklaması önemlidir. Bu küçük çalışma, proje başladıktan sonra değişikliklerin hangi yöntemle yönetileceğini gösterir ve iki tarafın beklentisini daha baştan aynı düzleme getirir.

Karşılaştırmayı ortak bir kapsam dosyasıyla yapın

Aday ekiplere aynı kısa dosyayı gönderin: sayfa türleri, dil sayısı, yönetilecek içerikler, gerekli bağlantılar, mevcut verinin durumu ve hedef yayın aralığı. Sonra tekliflerde her işin karşılığını işaretleyin. Dahil, hariç, müşteri sorumluluğunda ve keşif sonrası netleşecek kalemleri ayrı görün. Netleşmeyen bir işin otomatik olarak ücretsiz yapılacağını varsaymayın. Teklifte teslimlerin hangi sırayla onaylanacağı da yer alsın; içerik ve yazılım kararlarının birbirini beklediği işler takvimde açıkça gösterilsin. Bütçe kadar, belirsizliklerin ne kadarının çözülmüş olduğuna da bakın. Proje sırasında en fazla zaman kaybettiren konular çoğu kez bu boşluklarda bulunur.

Nihai kararda yalnızca ilk ödeme tutarını değerlendirmek yerine siteyi kullanacak ekibin yükünü de hesaba katın. Her güncelleme için dışarıya talep açmakla, yetkili kişinin güvenli bir panelden içerik değiştirmesi farklı çalışma düzenleridir. İhtiyacınıza uygun ayrıntıda hazırlanmış teklif, satın alma görüşmesinin temel belgesidir. Görüşmenin sonunda “hangi dosya, hangi özellik, hangi test ve hangi sorumlu” sorularını cevaplayabiliyorsanız fiyatı da daha bilinçli değerlendirebilirsiniz.