Web Sitesi Kaç Günde Yapılır? Proje Takvimi, Aşamalar ve Gecikme Nedenleri

Web sitesi kaç günde yapılır, süreyi ne belirler?

Web sitesi kaç günde yapılır sorusunun cevabı, kapsamın netliğine, içeriğin hazır olup olmamasına, onay döngülerinin hızına ve entegrasyon sayısına bağlı olarak değişir. Yani tek bir gün sayısı yoktur; gerçekçi takvim, bu dört etkeni proje başında yazılı hale getirdiğinizde ortaya çıkar ve gecikmeler çoğunlukla teknik değil, karar ve içerik kaynaklıdır.

Bu yazıda kurumsal bir web sitesi projesinin aşamalarını, her aşamanın süresini uzatan etkenleri ve takvimi nasıl koruyacağınızı anlatıyoruz. Talha Aslan ve ekibi olarak 2012'den beri sahada gördüğümüz tablo şudur: tasarım ve kodlama nadiren darboğaz olur. Asıl zaman kaybı, metinleri beklerken ve kararın kimde olduğunu bilmeden geçen haftalarda kaybolur.

Kapsamı, aşamaları ve sorumlulukları baştan netleştiren bir çalışma düzenini web tasarım hizmetimizde nasıl kurduğumuzu ayrıca inceleyebilirsiniz. Burada ise kendi projenizde uygulayabileceğiniz pratik bir takvim mantığı veriyoruz.

Neden tek bir gün sayısı vermek yanıltıcıdır?

Çünkü iki “kurumsal site” arasındaki fark, bir broşür ile bir katalog arasındaki fark kadar büyük olabilir. Örneğin beş sayfalık bir tanıtım sitesi ile çok dilli, form ve CRM bağlantılı bir site aynı kelimeyle anılabilir. Ancak birinin işi birkaç karar ve hazır metinle ilerlerken diğeri onlarca karar, çeviri ve test ister.

Bu nedenle internette gördüğünüz kesin gün vaatlerine temkinli yaklaşın. Bir ajans size kapsamı sormadan süre söylüyorsa, ya çok dar bir paket düşünüyordur ya da gecikme riskini size sonradan yansıtacaktır. Öte yandan süreyi soran işletme sahibi de haklıdır: lansman, kampanya ya da fuar tarihi gibi gerçek bir hedef vardır.

Doğru yaklaşım, gün sayısını değil, aşama listesini ve her aşamanın kime bağlı olduğunu konuşmaktır. Böylece takvim bir tahmin olmaktan çıkar, iki tarafın da sorumluluk aldığı bir plana dönüşür. Kısacası soru “kaç gün” yerine “hangi adım, kim, ne zaman” biçimine dönmelidir.

Kurumsal bir web sitesi projesi hangi aşamalardan oluşur?

Ayrıntıları projeden projeye değişse de iskelet hemen her zaman aynıdır. Süreci bütünüyle anlattığımız kurumsal web sitesi tasarım süreci yazısını tekrar etmeden, burada yalnız takvime etkisi olan adımları sıralıyoruz:

1. Keşif ve kapsam: hedefler, sayfa listesi, işlevler ve entegrasyonları yazıya dökeriz.
2. Site haritası ve tel çerçeve: sayfaların iskeleti ve gezinme yapısını onaylarsınız.
3. Görsel tasarım: ana sayfa ve şablon sayfaları tasarlar, revizyon turlarını yürütürüz.
4. İçerik üretimi: metinler, görseller, belgeler ve çevirileri hazırlarsınız ya da bize devredersiniz.
5. Geliştirme ve entegrasyon: tasarım koda dönüşür, formları ve bağlantıları kurarız.
6. Test ve yayın: cihaz, hız, form ve arama motoru kontrollerini bitirip siteyi açarız.

Dikkat ederseniz bu adımların yarısı müşteri tarafının katkısına bağlıdır. Dolayısıyla takvimin gerçekçi olması için iki tarafın görev listesini birlikte görmesi gerekir. Ayrıca bazı adımlar paralel yürüyebilir; örneğin tasarım sürerken metin yazımı başlayabilir.

Kapsam süreyi nasıl uzatır ya da kısaltır?

Kapsam, takvimin en büyük değişkenidir. Sayfa sayısı tek başına belirleyici değildir; asıl etkiyi benzersiz şablon sayısı yapar. Örneğin aynı şablonu kullanan yirmi hizmet sayfası, birbirinden farklı beş sayfadan daha hızlı ilerleyebilir.

Takvimi uzatan kapsam kalemleri genellikle şunlardır:

• Birden fazla dil ve her dil için ayrı içerik onayı.
• Üye girişi, bayi paneli ya da teklif formu gibi işlevler.
• Ürün veya proje kataloğu gibi filtrelenebilir listeler.
• Özel animasyonlar, hesaplayıcılar ve etkileşimli bölümler.
• Eski siteden içerik ve adres taşıma ihtiyacı.

Bu yüzden kapsamı projenin ilk haftasında dondurmak ve sonradan gelen istekleri ayrı bir faz olarak planlamak takvimi korur. Hazır tema ile özel tasarım arasındaki seçim de süreyi doğrudan etkiler; bu karşılaştırmayı hazır tema mı özel web tasarım mı yazımızda ayrıntılı ele aldık.

İçerik hazırlığı neden en sık gecikme nedenidir?

Çünkü içerik, işletmenin kendisini anlatmasını gerektirir ve bu iş günlük operasyonun arasında hep geriye kayar. Tasarım hazır olur, geliştirme biter; ancak “Hakkımızda” metni, hizmet açıklamaları ya da referans görselleri gelmediği için yayın bekler.

Sahada en sık gördüğümüz tablo, metinlerin “son hafta toparlarız” diye bırakılmasıdır. Oysa metin geldiğinde tasarımda değişiklik ihtiyacı doğar: başlık uzundur, bölüm eksiktir ya da görsel oranı tutmaz. Böylece son hafta, yeni bir revizyon turuna dönüşür.

Önleme yolu basittir ama disiplin ister. İçeriği tasarımla aynı anda başlatın, her sayfa için bir sorumlu ve teslim tarihi belirleyin. Üstelik metnin ilk taslağının mükemmel olması gerekmez; yapıyı oturtmak için yeterli bir taslak, son haline göre çok daha değerlidir. Metin yazımını ajansa devretmek de seçenektir, ancak bu durumda bile bilgi ve onay sizden gelir.

Onay döngüleri ve karar verici sayısı takvimi nasıl etkiler?

Her onay, bir bekleme süresi demektir. Tek kişinin karar verdiği projelerde geri bildirim hızlı gelir. Öte yandan kurul, ortaklar ya da birden çok departman söz sahibiyse her tur, herkesin görüşünü toplama süresiyle uzar.

Daha zor olanı ise çelişen geri bildirimlerdir. Örneğin pazarlama birimi daha canlı bir renk isterken yönetim daha sade bir görünüm ister. Bu durumda ekip iki yön arasında gidip gelir ve aynı ekranı defalarca yeniden çizer.

Bu nedenle projenin başında tek bir karar vericiyi, yani son sözü söyleyen kişiyi belirleyin. Diğer paydaşlar görüş verebilir; ancak görüşleri tek bir kanaldan, toplu olarak ve belirli bir tarihe kadar iletmelidir. Ayrıca her aşama için kaç revizyon turu olacağını yazılı hale getirin. Bu madde, sözleşmenin de konusudur; ayrıntılar için web tasarım sözleşmesinde olması gereken maddeler yazısına bakabilirsiniz.

Entegrasyonlar süreye ne kadar ekler?

Entegrasyon, sitenin başka bir sistemle konuşmasıdır: CRM, ERP, ödeme altyapısı, randevu sistemi ya da e-posta pazarlama aracı gibi. Bu işler tasarımdan bağımsız riskler taşır, çünkü karşı tarafın erişim bilgisi, dokümantasyonu ve test ortamı gerekir.

Sahada gecikme genellikle kodda değil, erişimde ortaya çıkar. Örneğin CRM yöneticisi izindedir, API anahtarının kimde olduğunu kimse bilmez ya da üçüncü taraf firma test hesabı açmakta yavaştır. Dolayısıyla entegrasyonların listesini keşif aşamasında çıkarın ve erişim sahiplerini en başta tanımlayın.

Hangi entegrasyonların gerçekten ilk sürümde gerektiğini de sorgulayın. Bazı bağlantılar yayından sonra ikinci faza bırakabilirsiniz; böylece lansman tarihini korursunuz. Kurumsal sitelerde sık kullanılan bağlantıları kurumsal web sitesi entegrasyonları yazımızda ayrıca ele aldık.

Aşamaları ve sorumluları gösteren bir takvim tablosu neye benzer?

Aşağıdaki tablo gün sayısı vermez; her aşamada süreyi kimin belirlediğini ve hangi etkenin uzattığını gösterir. Kendi projenizde bu tabloya tarih sütunu ekleyerek bir takvim taslağı çıkarabilirsiniz.

Tablonun asıl mesajı şudur: yedi aşamanın yalnız biri tamamen ajansın elindedir. Yani takvimin sahibi tek taraf değildir.

Gerçekçi bir web sitesi takvimi nasıl kurarsınız?

Gerçekçi takvim, yayın tarihinden geriye doğru ilerler. Önce lansmanın neden o tarihte olması gerektiğini netleştirin; ardından her aşamaya hem iş süresini hem de bekleme süresini ekleyin.

1. Sabit tarihi yazın: fuar, kampanya ya da sezon başlangıcı gibi.
2. Aşama listesini çıkarın ve her birine sorumlu atayın.
3. Her onay adımı için ayrı bir geri bildirim süresi ayırın.
4. İçerik teslim tarihlerini tasarım tarihlerinden önceye koyun.
5. Test için ayrı bir pencere bırakın; bunu sıkıştırılabilir alan saymayın.
6. Son olarak toplam takvime bir tampon ekleyin.

Burada tampon, kötümserlik değildir. Hastalık, tatil ya da beklenmedik bir karar değişikliği hemen her projede karşımıza çıkar. Böylece tampon kullanılmazsa siteyi erken açarsınız; kullanırsanız tarih yine de kaçmaz. Örnek senaryo: bir işletme fuar öncesi yayın istiyorsa, test penceresini fuardan birkaç iş günü önce bitecek şekilde planlamak, son gece hata ayıklamaktan çok daha sağlıklıdır.

Web sitesi kaç günde yapılır sorusuna aralık vermek mümkün mü?

Mümkün, ancak yalnız kapsam netleştikten sonra ve garanti olmadan. Bu yüzden biz aralık konuşurken her zaman “saha tecrübesine dayalı başlangıç aralığı, garanti değil” ifadesini kullanıyoruz. Aralık, içerik ve onayların planlandığı gibi gelmesi varsayımına dayanır.

Aralığı doğru okumak için şu ayrımı yapın: iş süresi ve takvim süresi aynı şey değildir. İş süresi, ekiplerin fiilen çalıştığı zamandır. Takvim süresi ise beklemeleri, onayları ve tatilleri de içerir. Dolayısıyla “iki haftalık iş” rahatlıkla birkaç haftalık bir takvime yayılabilir.

Size süre veren tarafa şu soruları sorun: Bu süre hangi sayfaları kapsıyor? İçeriğin ne zaman hazır olacağını varsayıyorsunuz? Kaç revizyon turu dahil? Entegrasyonlar bu sürenin içinde mi? Cevaplar netse aralık anlamlıdır; değilse rakam yalnız bir umut ifadesidir. Teklifleri karşılaştırırken bu soruları web tasarım teklifi nasıl değerlendirilir yazısındaki ölçütlerle birlikte kullanabilirsiniz.

Brief hazırlığı takvimi nasıl hızlandırır?

İyi bir brief, keşif aşamasını kısaltır ve sonraki aşamalarda yanlış anlaşılmayı azaltır. Hedef kitle, öncelikli hizmetler, beğenilen ve beğenilmeyen örnekler, sayfa listesi ve entegrasyonlar baştan yazılıysa ekip ilk günden doğru yöne çalışır.

Brief'in nasıl hazırlanacağını web projesinde brief nasıl hazırlanır yazımızda adım adım anlattık; burada tekrar etmiyoruz. Takvim açısından önemli olan nokta şudur: brief'te yazılmayan her konu, ileride bir toplantı ve bir bekleme demektir.

Özellikle üç bilgiyi brief'e mutlaka ekleyin: sabit yayın tarihi ve nedeni, son kararı verecek kişi, içerikleri kimin hazırlayacağı. Bu üç cevap, takvim riskinin büyük kısmını daha ilk toplantıda ortaya koyar. Ayrıca erişim bilgisi gereken sistemleri de listeye ekleyin; böylece entegrasyon tarafı sürpriz üretmez.

Tasarım revizyonları kaç tur olmalı?

Tur sayısı ajanstan ajansa değişir; önemli olan sayısının yazılı ve herkesçe bilinmesidir. Sınırsız revizyon, kulağa cömert gelse de takvimi belirsizleştirir. Çünkü her yeni tur, bir önceki kararın yeniden açılması anlamına gelebilir.

Revizyonların verimli geçmesi için geri bildirimi toplu verin. Örneğin bir ekran için on ayrı e-posta yerine, tek bir belge içinde maddeler halinde yorum gönderin. Ayrıca “daha modern olsun” gibi genel ifadeler yerine, neyi neden değiştirmek istediğinizi örnekle anlatın.

Bir başka pratik kural: ana sayfayı ve bir iç sayfa şablonunu önce onaylayın. Bu iki ekran onaylanmadan diğer sayfalara geçmek, aynı değişikliği her sayfada tekrarlamak demektir. Böylece onaylanan dil, kalan sayfalara hızla geçer ve geri dönüş sayısı azalır.

Geliştirme aşamasında süre neden kayar?

Geliştirme, kapsamın en net olması gereken aşamadır. Bu noktada gelen yeni istekler, yalnız o özelliği değil, test ve yayın planını da etkiler. Örneğin tasarımda olmayan bir filtre eklemek, veri yapısını ve mobil görünümü yeniden düşünmeyi gerektirebilir.

Kaymayı önlemenin yolu bir değişiklik talebi sürecidir. Yeni istek geldiğinde ekip, etkisini takvim ve bütçe açısından yazılı olarak bildirir; siz de “şimdi mi, ikinci fazda mı” kararını verirsiniz. Bu yöntem kimseyi suçlamaz, yalnız kararı ortaya koyar.

Teknik tarafta da bazı belirsizlikler takvimi uzatır: alan adı ve barındırma erişimi, e-posta ayarları, eski sistemden veri aktarımı gibi. Bu nedenle bu erişimleri geliştirme başlamadan toplayın. Ayrıca üçüncü taraf eklenti ya da hizmetlerin lisans durumunu önceden kontrol edin; son haftada çıkan bir lisans sorunu yayını bekletebilir.

Test ve yayın aşamasına ne kadar zaman ayırmalısınız?

Test, takvim sıkıştığında ilk feda ettiğiniz aşamadır ve en pahalı hataları burada kaçırırsınız. Formların doğru adrese gitmesi, mobil görünüm, sayfa hızı, yönlendirmeler ve arama motoru ayarları yayından önce kontrol edilmelidir. Google'ın sitenizi Google'da gösterme rehberi de yayın sonrası temel adımları anlatır.

Kullanıcı deneyimi tarafında hız ve kararlılık ölçütleri için web.dev üzerindeki Core Web Vitals açıklamasına göz atabilirsiniz. Core Web Vitals, sayfanın yüklenme, etkileşim ve görsel kararlılık deneyimini ölçen Google metrikleridir.

Yayına alma adımlarını tek tek listelediğimiz web sitesi oluşturma ve yayına alma kontrol listesi yazısı bu aşamada işinizi kolaylaştırır. Yayından sonra ise SEO analiz aracımızla temel sayfa kontrollerini hızlıca yapabilirsiniz. Kısacası test penceresini takvimin sabit bir parçası olarak görün.

Gecikmeyi önceden gösteren uyarı işaretleri nelerdir?

Gecikme çoğu zaman bir anda olmaz; birkaç hafta önceden işaret verir. Bu işaretleri erken görürseniz takvimi sessizce kaçırmak yerine bilinçli bir karar verebilirsiniz.

• İlk içerik teslim tarihi geçmiş ama kimse yeni tarihi konuşmamış.
• Geri bildirimler farklı kişilerden, birbirini tutmayan biçimde geliyor.
• Toplantılarda karar alıyorsunuz ama kimse yazıya geçirmiyor.
• Entegrasyon için gereken erişim bilgisini hâlâ bekliyorsunuz.
• Kapsam dışı istekler “küçük bir şey” diye sürekli listeye giriyor.
• Test aşaması takvimde ayrı bir satır olarak görünmüyor.

Bu işaretlerden ikisi bir aradaysa haftalık kısa bir durum toplantısı yapın. Ardından eksik kalemleri, sorumluyu ve yeni tarihi yazılı olarak güncelleyin. Böylece sorunu büyümeden çözersiniz ve iki taraf da aynı tabloya bakar.

Takvim kaçarsa ne yapmalısınız?

Önce suçlu aramak yerine nedenin hangi aşamada olduğunu bulun. Gecikme içerikten mi, onaydan mı, entegrasyondan mı geliyor? Cevap, çözümü de belirler.

Sabit bir tarih varsa en etkili yöntem kapsamı daraltmaktır. Örneğin tüm hizmet sayfaları yerine en önemli olanlarla açılabilir, blog ya da ikinci dil sonraki faza bırakılabilir. Ancak test aşamasını kısaltmak gibi bir çözüme başvurmayın; bu, sorunu yayından sonraya taşır.

Bir başka seçenek, siteyi geçici bir tanıtım sayfasıyla açıp asıl siteyi kısa süre sonra yayınlamaktır. Bu yöntem, kampanya tarihini korur ve ekibe nefes alanı bırakır. Yine de geçici sayfanın da düzgün çalışan bir iletişim formuna ve doğru temel ayarlara sahip olmasına dikkat edin.

Bütçe ile süre arasında nasıl bir ilişki vardır?

Süre ve bütçe birbirine bağlıdır, ancak doğru orantılı değildir. Daha fazla bütçe, belirli işleri paralel yürütmeyi mümkün kılabilir; örneğin içerik yazımını da ajansa vermek gibi. Öte yandan bütçe artışı, karar ve onay beklemelerini kısaltmaz.

Bu yüzden “daha fazla ödeyelim, daha hızlı olsun” yaklaşımı her zaman işe yaramaz. Takvimi asıl hızlandıran şey, müşteri tarafındaki hazırlıktır. Fiyatı belirleyen etkenleri kurumsal web sitesi fiyatları yazımızda ayrıntılı anlattık; burada yalnız şunu vurgulayalım: aceleye getirilen proje, sonradan düzeltme maliyeti doğurabilir.

Pratik öneri olarak, teklif aşamasında süre ile kapsam arasındaki bağı açıkça sorun. Hangi kalem çıkarılırsa takvim nasıl değişir, hangisi eklenirse ne kadar uzar? Bu sorunun cevabı, iki tarafın beklentisini aynı zemine indirir.

Yayından sonra iş biter mi?

Hayır; yayın bir son değil, sitenin gerçek kullanıcıyla buluştuğu ilk gündür. İlk haftalarda form bildirimleri, analiz kurulumu ve arama motoru kaydı gibi kontroller devam eder. Üstelik gerçek ziyaretçi davranışı, bazı sayfalarda küçük düzenleme ihtiyacını ortaya çıkarır.

Takvim planlarken yayın sonrası için de kısa bir dönem ayırın. Bu dönemde gelen düzeltmeleri bir liste halinde toplayın ve önceliklendirin. Böylece küçük düzenlemeler acil iş gibi durmaz, planlı ilerler.

Uzun vadede ise bakım ayrı bir konudur: güncellemeler, yedekler ve güvenlik kontrolleri düzenli takip ister. Ayrıca içerik eklemeye devam eden siteler, arama motorlarında da daha canlı bir izlenim bırakır. Kısacası lansman tarihi kadar, lansmandan sonraki ilk dönemin planı da önemlidir.

İşletme sahibi olarak takvimi korumak için ne hazırlamalısınız?

Aşağıdaki kontrol listesi, projeye başlamadan önce sizin tarafınızda hazır olması gerekenleri toplar. Bu maddelerin çoğu teknik bilgi istemez; yalnız karar ve zaman ayırmayı gerektirir.

• Son kararı verecek tek bir kişi ve yedeği.
• Sabit yayın tarihi ve bu tarihin nedeni.
• Sayfa listesi ve her sayfanın içerik sorumlusu.
• Logo, kurumsal renkler ve mevcut görseller.
• Alan adı, barındırma ve e-posta erişim bilgileri.
• Bağlantı kuracağımız sistemlerin listesi ve yetkilileri.
• Geri bildirim için her hafta ayırdığınız bir zaman dilimi.

Bu liste hazırsa ekip ilk günden verimli çalışır. Üstelik projenin ortasında “bunu kim biliyor?” sorusuyla geçen haftalar ortadan kalkar. Yani takvimi korumanın en ucuz yolu, başlamadan önceki hazırlıktır.

Web sitesi kaç günde yapılır sorusunu ajansa nasıl sormalısınız?

Soruyu açık uçlu bırakmak yerine, kapsamı ve kısıtlarınızı vererek sorun. Böylece aldığınız cevap karşılaştırılabilir olur. Örneğin şöyle bir çerçeve kullanabilirsiniz: “Şu sayfaları, şu işlevleri ve şu entegrasyonu istiyoruz; içerikleri biz hazırlayacağız; karar verici tek kişi; yayın hedefimiz şu tarih.”

Ardından ajanstan aşama aşama bir plan isteyin. İyi bir plan, her aşamada sizden ne beklendiğini ve ne zaman beklendiğini gösterir. Ayrıca gecikme durumunda ne olacağını da konuşun: takvimi nasıl güncelleyeceksiniz, kapsamı nasıl daraltacaksınız?

Son olarak cevaptaki varsayımları not edin. Süre bir varsayıma dayanıyorsa, o varsayım bozulduğunda takvimin de değişeceğini baştan kabul edin. Bu dürüstlük, proje boyunca iki tarafın ilişkisini de korur.

Takvim konusunda en sık yapılan hatalar nelerdir?

Sahada tekrar tekrar gördüğümüz hatalar oldukça benzerdir. Bunları baştan bilmek, çoğunu kendiliğinden önler.

• Yayın tarihini kapsamı konuşmadan belirlemek.
• İçeriği tasarım bittikten sonra yazmaya başlamak.
• Birden fazla kişiye “son söz” yetkisi vermek.
• Kararları sözlü bırakıp yazıya geçirmemek.
• Test aşamasını takvimde ayrı göstermemek.
• Yeni istekleri etkisini sormadan eklemek.

Bu hataların ortak noktası, teknik olmamalarıdır. Dolayısıyla çözüm de teknik değil, yönetimseldir: net roller, yazılı kararlar ve gerçekçi tamponlar. Öte yandan bu kurallar katı bir bürokrasi gerektirmez; kısa bir paylaşılan takvim belgesi çoğu zaman yeterlidir.

Çok dilli bir site takvimi nasıl değiştirir?

Her yeni dil, aslında küçük bir içerik projesidir. Çeviriyi kimin yapacağını, kimin kontrol edeceğini ve hangi dilin ana dil olacağını baştan belirlemeniz gerekir. Aksi halde ana dilde yaptığınız her değişiklik, diğer dillerde zincirleme bir güncelleme ihtiyacı doğurur.

Pratikte en sağlıklı yol, önce ana dildeki metinleri tamamen onaylamak, ardından çeviriye geçmektir. Böylece çevirmen hareketli bir hedefle uğraşmaz. Ayrıca her dil için ayrı bir onay sorumlusu atayın; o dili bilen biri metni okumadan yayına çıkmayın.

Bir başka dikkat noktası tasarımdır. Bazı dillerde kelimeler daha uzun olur ve başlıklar taşabilir. Bu yüzden tasarım aşamasında en uzun dildeki örnek metinle de kontrol yapmanızı öneririz. Kısacası çok dilli bir projede takvimi dil sayısıyla değil, onay zinciriyle düşünün.

Eski siteden geçiş takvime ne ekler?

Mevcut bir siteniz varsa, yeni site yalnız tasarım değil, bir taşıma işidir. Hangi sayfaların kalacağını, hangilerinin birleşeceğini ve eski adreslerin nereye yönleneceğini planlamanız gerekir. Bu planı ihmal ederseniz, arama motorlarında emek verdiğiniz sayfaları kaybedebilirsiniz.

Bu nedenle keşif aşamasında eski sitenin sayfa listesini çıkarın ve her sayfa için bir karar yazın: koru, güncelle, birleştir ya da kaldır. Ardından yönlendirme listesini geliştirme sırasında hazırlayın, yayın günü uygulayın. Üstelik alan adı ve barındırma erişimi eski bir ajanstaysa, bu erişimi almak da ayrı bir süre ister.

Geçişin SEO tarafını tekrar anlatmıyoruz; ancak şunu hatırlatalım: yönlendirme planı yayın tarihinden sonraya kalırsa, sorunu siz değil ziyaretçileriniz fark eder. Dolayısıyla taşıma adımlarını takvimde ayrı bir satır olarak gösterin.

Proje boyunca iletişimi nasıl düzenlemelisiniz?

İletişim düzeni, takvimin görünmeyen omurgasıdır. Kararlar e-posta, telefon ve mesajlaşma uygulamaları arasında dağılırsa kimse son hali bilmez. Bu yüzden tek bir paylaşılan belge ya da proje panosu kullanın ve kararları oraya yazın.

Haftalık kısa bir durum toplantısı çoğu proje için yeterlidir. Bu toplantıda üç soruyu sorun: geçen hafta ne bitti, bu hafta ne bekleniyor, kimden ne eksik? Ardından cevapları belgeye işleyin. Böylece iki taraf da aynı tabloya bakar ve sürprizler azalır.

• Kararlar tek bir belgede yazılı durur.
• Geri bildirim tek kanaldan ve toplu gelir.
• Her eksik kalemin bir sorumlusu ve tarihi olur.

Öte yandan iletişimin sık olması, her gün toplantı yapmak anlamına gelmez. Kısa ve düzenli temas, uzun ve dağınık yazışmadan çok daha verimlidir. Ayrıca toplantı notlarını aynı gün paylaşmak, yanlış anlaşılmaları erkenden yakalamanızı sağlar ve kimsenin hafızasına yük bindirmez. Böylece proje bir kişinin yokluğunda da ilerleyebilir.

Sonuç: takvimi kim yönetmeli?

Takvim, ajans ile işletmenin ortak sorumluluğudur. Ajans aşamaları, riskleri ve teknik bağımlılıkları yönetir; işletme ise içerik, karar ve erişim tarafını zamanında sağlar. İki taraf da kendi satırını sahiplendiğinde takvim gerçekçi kalır.

Kısacası web sitesi kaç günde yapılır sorusunun en dürüst cevabı “hazırlığınız ve karar hızınız kadar” olacaktır. Kapsamı netleştirin, içeriği erken başlatın, tek karar verici belirleyin ve test için alan bırakın. Bu dört adım, takvimdeki sürprizlerin büyük kısmını önler.

Projenizi bu mantıkla planlamak isterseniz web tasarım hizmeti sayfamızdan çalışma biçimimizi inceleyebilir ve kapsamınıza göre teklif isteyebilirsiniz.