Kurumsal web sitesi projesi kaç ay sürer?

Kurumsal bir web sitesi projesinin süresi, sayfa sayısından çok kurumun kendi hızıyla belirlenir. Aşağıdaki aralıklar bir planlama varsayımıdır, sözleşme taahhüdü değildir; sitenin karmaşıklığına, entegrasyonlara ve içeriğin hazır olup olmadığına göre değişir. Ama ‘kaç ay’ sorusuna dürüst bir başlangıç noktası vermek gerekir: sıfırdan kurulan, orta ölçekli bir kurumsal site için 14 ile 22 hafta, yani yaklaşık 3 ile 5 ay.

Aşamalar şöyle sıralanır. Keşif ve hedeflerin netleşmesi 2 ile 3 hafta. Bilgi mimarisi ve içerik planı 2 ile 3 hafta. Tasarım 3 ile 4 hafta. Geliştirme 4 ile 8 hafta. İçerik girişi ve testler 2 ile 3 hafta. Yayın ve ilk izleme 1 hafta. Alt sınırları topladığınızda 14, üst sınırları topladığınızda 22 hafta çıkar. Aşamalar kısmen üst üste biner, ama içerik hazır olmadan geliştirmenin bitmesi sizi kazandırmaz; bitmiş bir iskelet boş bir binadır.

Bu aralığı bir yönetim kararı olarak okuyun: lansman tarihiniz belliyse, tarihten 22 hafta geriye sayın ve o gün proje başlamış olmalıdır. Bir ihale, fuar ya da kurumsal lansman nedeniyle sabit bir tarihiniz varsa, 14 haftalık alt sınıra güvenmek risk almaktır.

Projelerin büyük çoğunluğu teknik nedenlerle değil, bekleme nedeniyle uzar. İlk neden içeriktir. Sayfa metinleri, ekip fotoğrafları, referans izinleri ve ürün bilgileri çoğu kurumda tek bir kişinin gündeminde ‘yapılacaklar’ listesinin altına düşer. Geliştirme hazır olduğu hâlde içerik gelmediği için iki hafta beklenen bir proje, takvimini kendi hâline bırakmış demektir.

İkinci neden onay zinciridir. Her onay turu için 5 iş günü ayırın ve tur sayısını 3 ile sınırlayın. Dördüncü tur artık revizyon değil kapsam değişikliğidir ve takvimi en az 1 hafta ötelemek anlamına gelir. Onaylayan kişi sayısı 3’ü aşıyorsa, her biri farklı bir şey söylediği için turlar katlanarak çoğalır. Tek bir karar sahibi belirlemek, projeyi kısaltmanın en etkili yoludur.

Üçüncü neden eski sistemdir. Mevcut sitenin içeriğini yeni yapıya taşımak, eski adreslerin yeni adreslere yönlendirmesini kurmak ve arama sıralamasını korumak ayrı bir iş kalemidir ve çoğu zaman teklifte görünmez. Bu konu başlı başına bir risk olduğu için teknik SEO rehberimiz taşıma öncesi kontrolleri ayrıntılı veriyor.

Keşif: sonunda yazılı bir hedef cümlesi olmalıdır. ‘Yeni bir site’ bir hedef değildir; ‘kurumsal alıcıdan gelen aylık talebi artırmak ve ilk yanıt süresini 1 saatin altına indirmek’ bir hedeftir. Hedef yoksa, tasarım turları zevk tartışmasına döner.

Bilgi mimarisi ve içerik planı: sonunda sayfa ağacı, her sayfanın amacı ve her sayfanın içerik sahibi belli olmalıdır. Hangi sayfanın metnini kimin ne zamana kadar yazacağı bu aşamada tarihle yazılır. Bu belge yoksa içerik gecikmesi kaçınılmazdır.

Tasarım: sonunda onaylanmış masaüstü ve mobil ekranlar ve ana bileşenler olmalıdır. Mobil ekranlar ayrı onaylanmalı; masaüstü onayıyla yetinilirse mobilde sürpriz yaşanır. Hız hedefi de bu aşamada yazılır: ana sayfa için en büyük içerik öğesinin yüklenme süresi 2,5 saniyenin altında olmalıdır.

Geliştirme: sonunda içerik girişine hazır bir yönetim paneli olmalıdır. Panelin kullanımını sizin ekibinizin öğrenmesi, ajansa e-posta atmadan içerik girebilmesi anlamına gelir; bu konuyu içerik girmek için neden hâlâ ajansa e-posta atmak zorundayız yazısında ayrıca ele aldık.

Test ve yayın: sonunda yönlendirme haritası sınanmış, formlar ve bildirimler denenmiş, mobil hız ölçülmüş ve ilk 30 günlük izleme planı yazılmış olmalıdır. Yayın günü bir bitiş değil, izleme döneminin başlangıcıdır; yayından sonra kimin neyden sorumlu olduğu da bu noktada netleşmelidir.

Birincisi haftalık 20 dakikalık durum toplantısıdır. Gündem tek bir sorudur: bu hafta bizden bekleyen ne var? Çoğu projede ajans değil müşteri tarafı bekletir; metin, görsel ya da onay hâlâ içeride kalmıştır. Bu toplantıda bekleyen madde sayısı 3’ü aşıyorsa takvim zaten kaymaya başlamıştır ve bunu açıkça söylemek, üç hafta sonra şaşırmaktan iyidir.

İkincisi kapsam dondurma tarihidir. Tasarım onayından sonra yeni sayfa ya da yeni özellik eklenmesi, geliştirme aşamasının başlangıcında dondurulmalı; sonradan gelen her istek ayrı bir listeye yazılıp yayın sonrasına bırakılmalıdır. Kapsam sürekli genişleyen bir proje 22 haftalık üst sınırı da aşar.

Üçüncüsü yayın kriterlerinin baştan yazılmasıdır. ‘Hazır olunca yayına alırız’ cümlesi bir kriter değildir. Ana sayfada en büyük içerik öğesinin yüklenmesi 2,5 saniyenin altında mı, etkileşim gecikmesi 200 milisaniyenin altında mı, eski adreslerin tamamı yönlendirilmiş mi? Bu sorulara evet diyemeden yayına çıkmak, sorunu yayın sonrasına taşımak demektir. Mobil hız konusunda ayrıntı için sayfa hızı rehberimize bakabilirsiniz.

Ajanslardan gelen tekliflerde süre genellikle tek bir satırdır: ‘12 hafta’. Bu satırın neyi kapsadığını sorun. İçerik hazırlığı dahil mi, yoksa içeriğin tamamen sizin tarafınızdan teslim edildiği varsayımıyla mı? Onay turları süreye dahil mi? Eski adreslerin yönlendirmesi ve taşıma kapsamda mı? Bu üç sorunun cevabı ‘hayır’ ise 12 hafta aslında 18 haftanın ilk parçasıdır.

Aynı mantık fiyat farkları için de geçerli. Üç tekliften biri 10 hafta, öbürü 16 hafta söylüyorsa, kısa olan daha hızlı olduğu için değil, daha az şeyi kapsadığı için kısa olabilir. Tekliflerin neden farklı çıktığını ajanslardan gelen üç teklif neden üç farklı fiyat söylüyor yazısında kapsam farklarıyla birlikte anlattık.

Projeye başlamadan önce son bir karar daha var: yenileme mi yoksa tamir mi? Mevcut sitenin sorunları gerçekten yapısal değilse, 5 aylık bir proje yerine 4 haftalık bir iyileştirme daha doğru olabilir. Bu ayrımı sitemizi yenilemeli miyiz, yoksa tamir mi etmeli yazısındaki kriterlerle yapabilirsiniz. Platform seçimi de takvimi etkiler; hazır tema ile özel yazılım arasındaki fark için hazır tema mı, özel yazılım mı yazısına bakın.

Takviminiz ya da önceki bir projenizin gecikmesi için iki olasılık var.

Gecikme içerik ve onaydan geliyorsa, 20 dakikalık iştir. Sayfa listesini çıkarın, her sayfanın yanına içerik sahibini ve teslim tarihini yazın, onaylayan kişi sayısını 3’ün altına indirin ve her onay turu için 5 iş günü kuralını yazılı hâle getirin. Bu dört adım, çoğu projenin takvimini üç hafta kısaltmaya yeter.

Gecikme mimariden geliyorsa, hiçbir takvim ya da proje yönetimi aracı çözmez. Eski sistem içeriği dışarı vermiyorsa, yönlendirme haritası çıkarılamıyorsa, yönetim paneli olmadığı için her içerik değişikliği geliştiriciye gidiyorsa, süre uzamasının nedeni kimsenin yavaş çalışması değil, yapının kendisidir. O durumda önce yapıyı düzeltmek, sonra takvim yapmak gerekir.

Hangi durumda olduğunuzdan emin değilseniz, mevcut sitenizin sayfa listesini ve lansman hedef tarihinizi bizimle paylaşın; birlikte bakıp takvimi geriye doğru kurabiliriz. Konuyu daha geniş görmek isterseniz kurumsal web sitesi rehberimiz tüm süreci başından anlatıyor.