Web tasarım tekliflerini nasıl karşılaştırmalısınız?

Aynı fiyat her zaman aynı kapsam değildir

Bir web sitesi teklifini değerlendirirken ilk soru “Kaç sayfa var?” değil, “Hangi iş sonucuna ulaşmak istiyoruz?” olmalıdır. Bir üreticinin teknik katalog ve teklif toplama ihtiyacı, randevuyla çalışan bir işletmenin ihtiyacından farklıdır. Teklifleri karşılaştırmadan önce hedef müşteriyi, ziyaretçinin yapmasını istediğiniz işlemi ve ilk sürümde zorunlu olan özellikleri yazın. Böylece tasarım kararları ile yazılım geliştirme ihtiyaçlarını birbirinden ayırabilirsiniz.

Kapsamı üç gruba bölün: ilk yayında zorunlu olanlar, sonraki sürümde eklenebilecekler ve ileride değerlendirilmesi gereken fikirler. Bu ayrım bütçeyi yalnızca azaltmak için değil, teslimin ne zaman tamamlandığını objektif biçimde belirlemek için de yararlıdır.

Teklifte hangi kalemler ayrı görünmeli?

Özgün arayüz tasarımı, sayfa şablonları, içerik girişi ve yazılım geliştirme ayrı kalemlerdir. Örneğin bir hizmet detay şablonu on hizmet için kullanılabilir; ancak her hizmetin metnini hazırlamak ayrıca zaman gerektirir. Birden fazla dil varsa çevirinin kim tarafından sağlanacağı, dil geçişlerinin nasıl çalışacağı ve her dilin arama görünürlüğü açıklanmalıdır.

Yönetim panelinin kapsamını da somutlaştırın. Başlık değiştirebilmek ile yeni sayfa açabilmek aynı özellik değildir. Blog, referans, kategori, görsel, yayın tarihi, sıralama ve yönlendirme yönetiminin hangilerinin dahil olduğunu sorun. Bir demo kaydını ekleme, düzenleme ve silme işlemleriyle test etmek, özellik listesini okumaktan daha açıklayıcıdır.

Alan adı, hosting, e-posta, ücretli tema, font ve üçüncü taraf servislerin ilk yıl ve yenileme maliyetlerini ayrı isteyin. Lisans ve hesapların işletmeniz adına tutulup tutulmadığını öğrenin. Ucuz başlayan fakat devri mümkün olmayan bir yapı uzun vadede farklı maliyetler doğurabilir.

Entegrasyonların sınırını belirleyin

“CRM entegrasyonu” tek başına yeterli bir teslim tanımı değildir. Hangi verinin hangi yönde aktarılacağını, aktarımın ne sıklıkta yapılacağını ve bağlantı kesilince ne olacağını yazılı hale getirin. Aynı talebin iki kez gönderilmesi, bir alanın eksik gelmesi veya dış servis kotasının dolması gibi senaryoları kabul testine ekleyin.

Dış servislerin üyelik bedelleri ve API erişimleri geliştirme ücretine dahil olmayabilir. Test hesabı, canlı hesap, anahtar yönetimi ve hata bildirimi sorumluları başlangıçta belirlenmelidir. Ayrıntılar için özel yazılım ve servis takip rehberini inceleyebilirsiniz.

Teslim kabulü hangi kanıtlara dayanmalı?

Bir test listesi oluşturun: mobil menü açılıp kapanıyor mu, form gerçek bir yönetici kaydı oluşturuyor mu, yanlış girişler anlamlı hata veriyor mu, eski URL yeni sayfaya yönleniyor mu? Klavye ile form alanlarına erişimi ve telefon bağlantılarını kontrol edin. Tasarım onayı ile teknik kabulü ayrı aşamalar olarak tutun.

Yedek alındığını görmek yeterli değildir; yedeğin ne kadar sürede geri yüklenebildiğini de sorun. Dosyalar, veri, erişim yetkileri ve üçüncü taraf ayarları birlikte ele alınmalıdır. Proje kapanışında erişim listesi, kullanım eğitimi ve bakım sorumluluğu teslim edilmelidir.

Değişiklik ve bakım maliyetini nasıl yönetirsiniz?

Kapsam dışı talepler için önceden belirlenmiş bir değerlendirme yöntemi kullanın. Talebin etkisi, maliyeti ve takvim değişikliği uygulamadan önce yazılı olarak açıklansın. “Sınırsız revizyon” gibi ifadeler yerine tasarım aşamalarını ve her aşamanın onay koşulunu netleştirin.

Yayın sonrası bakım; içerik güncellemesi, hata düzeltmesi ve yeni özellik geliştirmesinden ayrılmalıdır. Destek saatleri, kritik hata tanımı ve yanıt hedefleri açık olursa teklifleri karşılaştırmak kolaylaşır. Web tasarım hizmet kapsamımızı inceleyebilir veya projeniz için kapsam görüşmesi başlatabilirsiniz.

İlgili hizmet: Web Tasarım & Geliştirme