Bir web sitesi için fiyat araştırması yapılırken genellikle ilk konuşulan konu sayfa sayısı oluyor. “Beş sayfalık bir kurumsal site ne kadar?” sorusu, ilk bakışta oldukça mantıklı görünüyor. Sonuçta ortada hazırlanacak belirli sayıda sayfa var. Ana sayfa, hakkımızda, hizmetler, blog ve iletişim sayfası tamamlandığında işin de tamamlanacağı düşünülüyor.

Fakat web projelerinde sayfa sayısı, işin büyüklüğünü tek başına anlatmıyor. Hatta bazen projenin gerçek kapsamı hakkında neredeyse hiçbir şey söylemiyor.

Aynı sayıda sayfaya sahip iki web sitesi arasında ciddi bir iş yükü farkı bulunabilir. Birinde hazır bir tasarım düzenlenip içerikler yerleştirilirken diğerinde markaya özel bir arayüz hazırlanması, yönetim panelinin geliştirilmesi, harici servislerin bağlanması ve farklı kullanıcı senaryolarının düşünülmesi gerekebilir.

İki proje de dışarıdan bakıldığında “beş sayfalık web sitesi” olarak tanımlanır. Ancak geliştirme sürecinde yapılacak işler aynı değildir.

Sayfa Sayısı Yalnızca Görünen Kısmı Anlatır

Bir web sitesinde ziyaretçinin gördüğü sayfalar, projenin sadece ön yüzüdür. Bu sayfaların arkasında çalışan sistemler çoğu zaman doğrudan görünmez.

Örneğin bir iletişim sayfasında yalnızca birkaç form alanı bulunabilir. Ad, telefon, e-posta ve mesaj alanlarından oluşan basit bir form gibi görünür. Ancak bu formun düzgün çalışması için verilerin doğrulanması, istenmeyen mesajlara karşı korunması, bildirimlerin doğru adrese gönderilmesi ve kullanıcıya başarılı veya hatalı işlem bilgisinin gösterilmesi gerekir.

Gönderilen formlar yönetim panelinde saklanacaksa ayrıca bir kayıt sistemi hazırlanır. Belirli kullanıcılara bildirim gönderilecekse yetkilendirme ve bildirim kuralları devreye girer. Form bir CRM sistemine aktarılacaksa harici bir servisle entegrasyon yapılır.

Ekranda hâlâ tek bir iletişim sayfası vardır. Fakat o sayfanın arkasındaki iş artık yalnızca birkaç form alanı eklemekten ibaret değildir.

Benzer durum diğer sayfalarda da görülür. Bir hizmetler sayfası sabit içerikten oluşabileceği gibi kategori, filtreleme ve dinamik detay sayfaları içeren bir yapıya da sahip olabilir. Hakkımızda sayfası yalnızca metin ve görsel içerebilir ya da ekip üyelerinin yönetim panelinden düzenlenebildiği özel bir modüle dönüşebilir.

Bu nedenle “kaç sayfa olacak?” sorusu gereksiz değildir ama tek başına yeterli de değildir. Asıl soru, bu sayfaların ne yapacağıdır.

Beş Sayfalık Bir Site Yirmi Sayfalık Bir Siteden Daha Zor Olabilir

Sayfa sayısının fazla olması her zaman projenin daha karmaşık olduğu anlamına gelmez.

Yirmi sayfalık bir web sitesinde bütün sayfalar aynı tasarım şablonunu kullanabilir. Başlık, açıklama, görsel ve içerik alanları değişir; sayfanın genel yapısı aynı kalır. İlk şablon doğru biçimde hazırlandıktan sonra diğer sayfaların oluşturulması daha düzenli ilerleyebilir.

Beş sayfalık başka bir projede ise her sayfanın kendine ait bir düzeni olabilir. Ana sayfada özel animasyonlar, hizmetler bölümünde filtreleme, iletişim sayfasında harita ve CRM entegrasyonu, kullanıcı tarafında çoklu dil desteği, yönetim tarafında da özel içerik alanları bulunabilir.

Bu durumda sayfa sayısı azdır ancak her sayfa ayrı bir çalışma gerektirir.

İş yükünü belirleyen konulardan bazıları şunlardır:

  • Tasarımın özgünlüğü: Hazır bir temanın düzenlenmesiyle sıfırdan hazırlanan kullanıcı arayüzü aynı süreç değildir. Özel tasarımda marka dili, renk sistemi, tipografi, bileşenler ve farklı ekran boyutları ayrıca çalışılır.

  • Yönetim paneli: İçeriklerin kim tarafından ve nasıl yönetileceği belirlenmelidir. Basit bir metin alanıyla tekrarlanabilir içerik blokları, kullanıcı rolleri ve onay akışları aynı kapsamda değerlendirilemez.

  • Çoklu dil desteği: Bir dil seçici eklemek, çok dilli bir sistem kurmak anlamına gelmez. Sayfaların, bağlantıların, meta bilgilerinin, formların ve dinamik içeriklerin her dil için yönetilmesi gerekir.

  • Formlar ve entegrasyonlar: Formların e-posta göndermesi, veritabanına kaydedilmesi, CRM sistemine aktarılması veya farklı ekip üyelerine yönlendirilmesi ayrı ihtiyaçlardır.

  • İçerik girişi: Metin ve görsellerin hazır olmasıyla içeriklerin geliştirici tarafından düzenlenip sisteme girilmesi arasında ciddi zaman farkı vardır. Görsellerin boyutlandırılması ve içerik yapısına uygun hâle getirilmesi de bu sürece dahildir.

  • SEO altyapısı: Sayfa başlıkları, meta açıklamaları, kalıcı bağlantılar, yönlendirmeler, site haritası, yapılandırılmış veriler ve sosyal medya paylaşım alanları projenin başında düşünülmelidir.

  • Performans: Görsel optimizasyonu, önbellekleme, sorguların düzenlenmesi, dosya boyutlarının azaltılması ve sunucu yapılandırması sayfa sayısından bağımsız işlerdir.

  • Güvenlik: Yetkilendirme, form doğrulama, dosya yükleme kontrolleri, güncelleme politikası ve yedekleme yapısı özellikle yönetim panelli projelerde önemlidir.

  • Test ve yayına alma: Mobil cihaz kontrolleri, tarayıcı testleri, form denemeleri, alan adı yönlendirmeleri, SSL kurulumu ve canlı ortam ayarları da proje süresinin parçasıdır.

Bunların hiçbiri ana menüde ayrı bir sayfa olarak görünmez. Ancak web sitesinin sağlıklı çalışması için hepsine zaman ayrılması gerekir.

“Basit Bir Site” Aslında Ne Kadar Basit?

“Çok detaylı bir şey istemiyorum, basit bir web sitesi olacak” cümlesi çoğu zaman tasarımın sade olmasını ifade ediyor. Fakat sade görünen bir tasarım, teknik olarak basit olmak zorunda değildir.

Temiz ve ferah bir arayüz hazırlamak bazen kalabalık bir sayfa hazırlamaktan daha fazla düşünmeyi gerektirir. Gereksiz öğeleri kaldırmak, içerik hiyerarşisini doğru kurmak ve ziyaretçiyi yormadan yönlendirmek ciddi bir tasarım çalışmasıdır.

Aynı şekilde kullanıcı açısından basit görünen bir işlem, arka tarafta birden fazla adım çalıştırabilir. Kullanıcı tek bir butona basar fakat sistem o sırada veriyi kontrol eder, kaydeder, bildirim gönderir, başka bir servisle haberleşir ve işlemin sonucunu ekrana yansıtır.

Buradaki sorun “basit” kelimesinin kullanılması değil. Sorun, bu kelimenin proje kapsamı tanımlanmadan fiyat ölçüsüne dönüştürülmesidir.

Bir proje gerçekten basit olabilir. Sabit içerikler, standart sayfa düzeni, hazır logo ve metinler, temel bir iletişim formu ve sınırlı yönetim ihtiyacı varsa süreç daha kısa ilerler. Ancak bunun anlaşılabilmesi için önce ihtiyaçların netleştirilmesi gerekir.

Sağlıklı Bir Teklif Nasıl Hazırlanır?

Bana göre bir web sitesi teklifi hazırlanırken yalnızca sayfa listesi çıkarmak yeterli değildir. Her sayfanın içeriği ve davranışı da konuşulmalıdır.

Ana sayfada hangi bölümlerin bulunacağı, hizmetlerin nasıl yönetileceği, blog yapısının nasıl çalışacağı, formların nereye iletileceği ve içerikleri kimin gireceği baştan netleştirilmelidir. Yönetim panelindeki kullanıcı rolleri, çoklu dil ihtiyacı ve harici servis bağlantıları da aynı aşamada belirlenmelidir.

Bu çalışma hem geliştiriciyi hem de müşteriyi korur.

Geliştirici, üstleneceği işi daha doğru planlar. Müşteri ise hangi hizmetler için teklif aldığını bilir. Böylece yalnızca toplam bir rakam üzerinden değil, gerçek ihtiyaçlar üzerinden değerlendirme yapılabilir.

Farklı firmalardan veya geliştiricilerden gelen teklifler arasında büyük farklar olduğunda da yalnızca son rakama bakmak yanıltıcı olabilir. Tekliflerden biri tasarım, içerik girişi, SEO altyapısı, performans çalışması ve yayın sonrası desteği içerirken diğeri yalnızca hazır temanın kurulmasını kapsıyor olabilir.

Bu iki teklif aynı iş için verilmiş gibi görünür ama teslim edilecek sonuç aynı değildir.

Bu nedenle teklif karşılaştırırken şu sorular daha anlamlıdır:

  • Tasarım hazır bir yapı üzerinden mi ilerleyecek?

  • Mobil uyumluluk ayrıca test edilecek mi?

  • İçerikleri kim hazırlayacak ve sisteme kim girecek?

  • Yönetim panelinden hangi alanlar düzenlenebilecek?

  • Formlar ve harici entegrasyonlar teklife dahil mi?

  • Temel SEO ve performans çalışmaları yapılacak mı?

  • Yayına alma sürecini kim yönetecek?

  • Teslim sonrası destek hangi kapsamda verilecek?

Bu sorular cevaplandığında teklifin yalnızca fiyatı değil, içeriği de görünür hâle gelir.

Revizyon ile Kapsam Değişikliği Aynı Şey Değildir

Web projelerinde en fazla karışan konulardan biri revizyon ve kapsam değişikliği arasındaki farktır.

Hazırlanan bir bölümde yazı boyutunun değiştirilmesi, boşlukların düzenlenmesi, bir rengin güncellenmesi veya mevcut alanların sıralamasının değiştirilmesi genellikle revizyon olarak değerlendirilir. Çünkü çalışma, daha önce belirlenen yapı içinde devam eder.

Fakat proje başladıktan sonra üyelik sistemi eklenmesi, ödeme altyapısının bağlanması, yeni bir kullanıcı rolü oluşturulması ya da içeriklerin farklı bir mantıkla yönetilmesinin istenmesi mevcut yapının dışına çıkar. Bunlar yalnızca görünüm değişikliği değildir. Veritabanını, yönetim panelini, iş akışını ve test sürecini etkileyebilir.

Dolayısıyla kapsam değişikliği, “küçük bir ekleme” gibi görünse bile yeni bir geliştirme çalışması anlamına gelebilir.

Bu ayrımın baştan konuşulması, her değişiklik için ek ücret isteneceği anlamına gelmez. Ama projenin sınırlarını anlaşılır hâle getirir. Hangi değişikliklerin mevcut çalışmanın parçası olduğu, hangi taleplerin yeni iş oluşturduğu daha kolay belirlenir.

Aksi hâlde proje boyunca eklenen her özellik revizyon olarak görülmeye başlanır. Başlangıçta planlanan işle teslim aşamasında ortaya çıkan sistem birbirinden tamamen farklı olabilir.

Fiyatı Sayfalar Değil, Yapılacak İş Belirler

Bir web sitesinin fiyatını değerlendirirken sayfa sayısını tamamen görmezden gelmek doğru olmaz. Daha fazla içerik ve daha fazla özgün sayfa düzeni doğal olarak daha fazla çalışma gerektirebilir.

Ancak sayfa sayısı yalnızca ölçütlerden biridir.

Asıl maliyeti belirleyen; tasarımın ne kadar özgün olduğu, sistemin hangi özellikleri taşıdığı, yönetim tarafının nasıl çalıştığı, hangi servislerle bağlantı kurulacağı ve projenin yayına hazır hâle gelmesi için ne kadar iş yapılacağıdır.

Dışarıdan benzer görünen iki web sitesinin arkasında tamamen farklı sistemler bulunabilir. Biri yalnızca birkaç sabit sayfadan oluşurken diğeri içerik yönetimi, entegrasyon, güvenlik, performans ve operasyon ihtiyaçlarını birlikte çözebilir.

Bu nedenle bir web projesi için doğru başlangıç sorusu yalnızca “Kaç sayfa olacak?” değildir.

Daha doğru soru şudur:

“Bu web sitesi ne yapacak ve bunu yapabilmesi için hangi çalışmalar gerekecek?”

Bu soru cevaplandığında hem proje kapsamı hem de teklif çok daha anlaşılır hâle gelir.