Web Sitesi İhtiyaç Analizi: Bütçe ve Zaman Çizelgesi Kurgusu

Bir web projesinin başarısı yalnız güzel bir arayüz ya da iyi yazılmış kodla belirlenmez; bütçe ve zaman çizelgesi kurgunuz, tıpkı mimaride taşıyıcı kolonlar gibi tüm kararların yükünü taşır. Yanlış kurgulanmış bir bütçe, son sprintte kritik özelliklerin kesilmesine; gerçekçi olmayan bir zaman çizelgesi ise kalite, güvenlik ve erişilebilirlikten ödün verilmesine yol açar. Üstelik web projeleri, birbirine bağımlı onlarca akıştan oluşur: bilgi mimarisi, içerik üretimi, görsel/video varlıkları, performans optimizasyonu (Core Web Vitals), erişilebilirlik, analitik, deney/A-B testleri, entegrasyonlar, güvenlik/KVKK, CMS geçişi, eğitim ve bakım… Her biri zaman ve para ister; her biri risk ve belirsizlik taşır.

1) Stratejik Mandat: Hedef–Kapsam–Bütçe Üçgeni
Bütçe ve zaman çizelgesinin temeli hedef–kapsam–bütçe üçgenidir. Yıllık MRR’de artış, randevu tamamlama oranında yükseliş, çok dilli pazara açılım gibi iş hedefleri; hangi kapsam öğeleri olmadan başarısız kalır? Örneğin “demo talebi +%30” hedefi varsa fiyat sayfası, güvenlik/uyumluluk içeriği, kalendar entegrasyonu ve hafif bir form akışı “olmazsa olmaz”dır. Bu öğeler “MVP” fazına; geri kalan “iyi olur” maddeler ise sonraki fazlara yazılır. Böylece bütçe ve süre, rastgele değil hedefe bağlı kurgulanır.
2) Kalem Kırılımı: Neye Para Harcıyoruz?
Net bütçe, kalemlere bölünmüş bütçedir: keşif/araştırma, bilgi mimarisi, içerik (üretim, redaksiyon, yerelleştirme), görsel/video varlıkları, UX/UI tasarımı, frontend ve backend geliştirme, CMS yapılandırması/göç, QA ve kullanılabilirlik testleri, erişilebilirlik düzeltmeleri, performans optimizasyonları (LCP/INP/CLS), güvenlik ve KVKK uyumu, analitik ve GTM kurulumu, A/B deney çerçevesi, ısı haritası/anket altyapısı, barındırma/CDN, eğitim ve dokümantasyon, go-live ve bakım. Her kalem için sorumlu ekip, teslimat ve kabul kriteri yazılmalı; bütçe açıklaması yalnız bir rakam değil, neden–ne–nasıl ölçeriz cümleleri içermelidir.
3) Kapasite ve Hız (Velocity): “Ne Kadar İş” Değil, “Bir Sprintte Ne Kadar”
Zaman çizelgesi, ancak ekip kapasitesine yaslandığında gerçektir. Tasarım, geliştirme ve içerik ekiplerinin haftalık/iki haftalık sprintlerde üretebileceği bitmiş iş miktarı; önceki projelerden ya da hızlı bir pilot sprintten ölçülmelidir. “Bu sprintte 12 bileşen tamamlanır” gibi çıktı tanımları, süslü gantt şemalarından daha güvenilirdir. Kapasiteyi şişirmek yerine, hata, revizyon ve bağımlılık tamponları ekleyin.
4) Fazlama ve MVP: Stratejik Kısıtlama Sanatı
Her şey ilk fazda bitmeyecek. MVP, iş hedefini doğrulayacak en küçük canlı dilimi temsil eder. Örneğin B2B’de “fiyat → demo → takvim” akışı, kamu tarafında “bilgi → randevu” akışı, e-ticarette “kategori → ürün → checkout” akışı MVP’dir. Vaka sayfaları, kapsamlı rehberler, çok dilli tüm varyantlar ve gelişmiş arama gibi öğeler ikinci/üçüncü fazlara yazılır. Zaman çizelgesine açık faz kapıları koyun: “MVP canlı + X gün izleme → Faz 2 başlangıç.”.
5) Bağımlılık Yönetimi: Zinciri Zayıf Halka Koparır
Takvim entegrasyonu, ödeme sağlayıcısı, SSO, CRM, DAM, çeviri yönetimi, harita/rota servisleri… Tek bir üçüncü taraf gecikmesi tüm planı kaydırabilir. İhtiyaç analizinde bağımlılık listesi çıkarın; her bağımlılık için tek muhatap, çözümleme zamanı, alternatif plan ve karantina süresi belirleyin. Örneğin “takvim sağlayıcısı gecikirse geçici olarak e-posta randevu yoluna düşer” gibi geçici çözüm reçetesini zaman çizelgesine yazın.
6) Kabul Kriterleri: Tarihler Kadar Şartlar da Net Olmalı
“31 Ocak’ta canlı” cümlesi eksiktir; hangi koşullarda sorusu yanıtlanmalıdır. Kabul kriterlerini iş, performans ve uyumluluk boyutlarıyla yazın: örneğin “Fiyat → Demo akışında P75 LCP ≤ 2,2 sn, INP ≤ 200 ms; form tamamlama ≥ %X; WCAG 2.2 AA raporu; KVKK aydınlatma ve CMP aktif; GA4 olay şeması canlı ve veri akıyor.” Tarihler, bu koşullar sağlandığında anlamlıdır.
7) Performans ve Erişilebilirlik Zaman/Bütçe Rezervleri
Core Web Vitals düzeltileri ve erişilebilirlik düzeltmeleri her zaman “beklediğinizden uzun” sürer. Görsel optimizasyon, kritik CSS, üçüncü taraf kısıntıları, “tıklayınca yükle” dönüşümleri, aria etiketleri, hata alanı düzeni, kontrast/odak düzeltmeleri için ayrı zaman ve bütçe rezervi ayırın. “Son sprintte bakarız” yanılgısı, en pahalı hatadır.
8) Güvenlik ve KVKK Blokları: Son Sprintlik Konu Değil
Pen test, güvenlik taraması, loglama, WAF kural setleri, veri minimizasyonu, CMP entegrasyonu, aydınlatma ve tercih merkezi, silme/erişim talepleri prosedürü—bunlar için ayrı bloklar ve hukuk–BT eşgüdümü gerekir. Zaman çizelgesine “güvenlik denetimi → düzeltme penceresi → yeniden test” üçlüsünü yazmadığınız her proje, ertelenmiş risk taşır.
9) Çok Dilli/Çok Lokasyon: Çarpan Etkisini Hesaplayın
Bir tasarım değişikliği yalnızca bir dilde yapılmaz; çeviri, kültürel uyarlama, vergi/para birimi metinleri, hreflang ve yönlendirme kuralları, şube çalışma saatleri ve yerel kanıt blokları ek iş üretir. Zaman çizelgesinde “dil × ülke × şube” çarpanı kadar revizyon döngüsü yazın; bütçede ise yerelleştirme ve içerik QA payı ayırın.
10) İçerik Üretimi ve Redaksiyon: En Fazla Geciktiren Kalem
İçerik yoksa sayfa yoktur. Metin iskeletleri, kaynak toplama, redaksiyon, hukuk onayı, görsel/video üretimi, altyazı ve transkript süreçleri, teknik doğrulama ve SEO uyumlu başlık/özet üretimi… Bunların her biri için tarihli teslim, sahiplik ve gerçekçi üretim hızı belirleyin. “İçerik yetişirse” diye yazılan takvimler, neredeyse hiç yetişmez.
11) Ekip ve Tedarikçi Karması: Kimin Zamanı, Hangi Fiyata?
Ajans, serbest uzman, iç ekip—her bileşenin maliyeti, müsaitliği ve senkronizasyon gereksinimleri farklıdır. Ajans tasarım bitirmeden geliştirici beklemek; geliştirici bitirmeden içerik beklemek; içerik yokken SEO denetimi beklemek… Zincirleme gecikme doğurur. Zaman çizelgesine eşzamanlı üretim pencereleri, paydaş onay pencereleri ve kilit bağımlılıklar için net “kapılar” koyun.
12) Tahmin Yöntemleri: Üstten–Alttan ve Üç Nokta
Bütçe ve süre tahmini için iki yönlü yaklaşım uygulayın.
-
Üstten aşağı: Benzer projelerden kıyaslama; “bu ölçekte MVP için X–Y hafta”.
-
Alttan yukarı: Bileşen/beklog kalemlerinden toplam süre; bağımlılıklar ve revizyonlar dahil.
-
Üç nokta tahmin: İyimser, kötümser, en olası. Hesap, tek sayı yerine aralık verir; proje riskini daha doğru yansıtır.
13) Tamponlar (Buffer): Revizyon, Hata, Bağımlılık ve Onay
Her projede revizyon olur. Hata düzeltme, hukuk/marka onayı, üçüncü taraf gecikmesi, içerik yetişmeme gibi durumlar için yüzde cinsinden tampon belirleyin. Tamponu saklamayın; paydaşlara şeffaf şekilde sunun: “Toplam sürenin %15’i, planlı tampondur; yalnız gerektiğinde kullanılır.”
14) Risk–Olasılık–Etki Matrisi: Kırmızı Alanlar İçin Bütçe Zırhı
“Ödeme sağlayıcısı geç kalırsa?” “Yerelleştirme ekibi yetişmezse?” “Pen test kritik açık bulursa?” Her risk için olasılık ve etki puanlayın; kırmızı alandaki risklere önleyici bütçe ve yedek plan atayın. Matris, yalnız sunum değil; zaman çizelgesinde somut karşılığı olan bir araç olmalıdır.
15) Analitik ve Deney Kurgusu: Kaynak Ayırmazsanız Ölçemezsiniz
GA4/GTM olay şeması, veri katmanı, pano setleri, deney/feature flag altyapısı “sonradan” değil, takvimde erken yer almalıdır. Deney yapacaksanız varyasyon hazırlığı, izleme ve istatistiksel güç için süre ayırın. Aksi hâlde “deney kültürü” lafta kalır, veriye dayalı kararlar ertelenir.
16) Performans Bütçesi: Zaman Çizelgesinde “Hız” İçin Slot
LCP/INP/CLS iyileştirmeleri, görsel dönüştürme, kritik CSS, üçüncü taraf temizliği, embed’leri tıklayınca yükle gibi işleri iteratif olarak ele alın. Her sprintte hız slotu olsun. Projenin sonunda “performans sprinti” bırakmak, genellikle yetmez.
17) Erişilebilirlik ve Kapsayıcı Dil: Tek Seferlik Düzeltme Değil
WCAG 2.2 AA hedefi; form etiketleri, odak halkaları, hata alanları, kısayol navigasyonu, dil anahtarının erişilebilirliği, kontrast ve video altyazıları… Her modül tamamlandığında erişilebilirlik kontrolü yapılmalı. Zaman çizelgesine “erişilebilirlik turu” ekleyin; bütçede ayrı bir kalemle güçlendirin.
18) Güvenlik ve Pen Test: “Go-Live” Öncesi Kilit Kapı
Güvenlik taraması ve pen test için bağımsız bir süre bırakın. Bulgu düzeltmeleri için “tampon” planlayın. KVKK/GDPR gereksinimleri (CMP, tercih merkezi, loglama, veri saklama süreleri) ve içerik güvenlik politikası gibi maddeler, “yayına 2 gün kala” konular değildir.
19) Go-Live ve Roll-Out: Kademeli, Ölçülü ve Geri Alınabilir
Canlıya geçiş bir anahtar değil, valf gibi yavaş açılmalıdır. Kademeli dağıtım, trafik sınırlama, geri alma planı, uyarı ve izleme kuralları, ekip hazır bulunuşluğu (war room) ve iletişim protokolü için tarihli maddeler yazın. Bütçede “go-live destek” penceresi (örneğin 7 gün) ayrı kalem olsun.
20) Eğitim, Devir ve Operasyon: Son Gün Sunumu Yetmez
CMS eğitimleri, modül kullanım belgeleri, içerik üretim SOP’ları, analitik panoların okuma kılavuzu, karar log’u ve bileşen kütüphanesi tanıtımı; tümü için oturum sayısı ve süre planlayın. Devir teslimin ölçütü “sunum yapıldı” değil, “ekip kendi başına bir sayfayı sıfırdan üretip yayınladı” gibi davranışsal kriter olsun.
21) Bakım Bütçesi ve Yol Haritası: Proje Değil, Ürün Yönetiyoruz
Go-live sonrası bakım ve iyileştirme bütçesi olmadan web sitesinin performansı ve güvenliği kısa sürede düşer. Aylık dönüşüm kliniği, çeyreklik huni revizyonu, yıllık teknik audit, 3. taraf temizliği ve içerik sağlık kontrolü için tekrarlayan süre ve bütçe ayırın. Yol haritasında “ölç + düzelt + dene + ölçekle” döngüsünü açıkça yazın.
22) RFP ve SLA ile Hizalama: Kâğıt, Takvimle Buluşsun
RFP’deki kabul kriterleri (CWV, WCAG, KVKK, analitik, güvenlik) takvimde somut tarih ve slot olarak görünmelidir. SLA’da yer alan yanıt ve çözüm süreleri, bakım döneminin gerçek kapasitesi ile tutarlı olmalıdır. İki belge birbirini beslemezse, ya takvim kağıt üzerinde kalır ya da sözleşme hükümsüzleşir.
23) Karar Log’u ve Değişiklik Yönetimi: Kapsam Kaymasının Panzehiri
Zaman ve bütçeyi kaçıran en yaygın neden, sessiz kapsam kaymasıdır. Her değişiklik talebi için kısa bir kayıt: “ne, neden, etkisi ne, plan ne” ve onaylayan kişi. Etkisi olan her değişiklik için zaman ve bütçe karşılığı yazılmalı; log şeffaf biçimde ekiplerle paylaşılmalıdır.
24) Vaka Çalışması (B2B SaaS): Fiyat → Demo → Takvim
Sorun: Dönüşüm hedefi agresif; takvim entegrasyonu ve güvenlik sayfaları gecikiyor.
Yaklaşım: MVP’de fiyat–demo–takvim akışı zorunlu; güvenlik/uyumluluk sayfası kısa sürümle açıldı, geniş sürüm Faz 2’ye taşındı. Takvim gecikme riskine karşı e-posta rezerv akışı yazıldı.
Sonuç: Zaman çizelgesi bozulmadan MVP canlı oldu; Faz 2’de uyumluluk içeriği genişletildi. Demo tıklaması ve form tamamlama çift haneli yükseldi.
25) Vaka Çalışması (E-Ticaret): Kategori–Ürün–Checkout
Sorun: Görsel ağırlığı yüksek tasarım ve üçüncü taraf piksel enflasyonu nedeniyle hız hedefleri kaçıyor.
Yaklaşım: “Hız slotları” her sprintte ayrıldı; görseller AVIF’e çevrildi; embed’ler tıklayınca yüklendi; CMP gelmeden pazarlama pikselleri durduruldu.
Sonuç: P75 LCP 1 saniye iyileşti, CLS hedef altına indi; satın alma oranı arttı. Bütçe, “performans rezervi” kalemi sayesinde taşmadı.
26) Vaka Çalışması (Kamu/Üniversite): Bilgi → Randevu
Sorun: İçerik ve onay süreçleri belirsiz; randevu modülü geç teslim ediliyor.
Yaklaşım: İçerik üretimi için haftalık “onay pencereleri” takvime yazıldı; randevu bileşeni gecikirse “çağrı/WhatsApp yönlendirmeli geçici akış” planlandı.
Sonuç: Zaman çizelgesi korunarak yayına çıkıldı; modül geldiğinde kesintisiz geçiş yapıldı; randevu tamamlama oranı anlamlı biçimde yükseldi.
27) Kurumsal Ritüeller: Zaman ve Bütçeyi Ayakta Tutan Alışkanlıklar
Haftalık demo, dönüşüm kliniği, 3. taraf temizliği, karar log’u turu, veri kalitesi kontrolü, CWV/erişilebilirlik nabzı… Bu ritüeller takvime yazılı olmadıkça yapılmaz. Her ritüel için sorumlu, gündem ve çıktılar önceden belli olmalıdır. Bütçe görüşmeleri de ritüelleşmeli: “aylık sağlık raporu → mini revize plan.”
28) Son Kilit Taşları: Anlam–Hız–Gizlilik–Kalite Dörtgeni
Başarılı bir bütçe ve zaman çizelgesi:
-
Anlam üretir: Hedefe bağlı kapsam ve fazlama, şeffaf tamponlar ve kabul kriterleriyle netlik sağlar.
-
Hız üretir: Kapasiteye dayalı plan, hız slotları ve bağımlılık yönetimiyle akışı sürdürür.
-
Gizlilik ve güvenlik üretir: KVKK/CMP ve pen test blokları takvime gömülüdür; son dakika paniği yoktur.
-
Kalite üretir: Erişilebilirlik, performans ve analitik/deney kurgusu için gerçek süre ve bütçe ayrılmıştır.
Sonuç
“Bütçe ve Zaman Çizelgesi Kurgusu”, web projesinin en insani kısmıdır; çünkü beklentiyi, emeği ve riski adilce dağıtır. İhtiyaç analizi aşamasında bu kurguyu sağlam yapan ekipler:
-
Hedefe bağlı kapsam ve fazlamayla gerçekçi plan kurar; ilk “değer dilimi”ni erken teslim eder.
-
Kapasite ve tampon yönetimiyle sürtünmeyi azaltır; bağımlılıkları ve onay pencerelerini görünür kılar.
-
Kabul kriterlerini tarihle birlikte yazarak tartışmaları azaltır; kaliteyi tarihe feda etmez.
-
Performans, erişilebilirlik, güvenlik ve KVKK için ayrı süre ve bütçe ayırarak “son sprint paniği”ni önler.
-
İçerik ve yerelleştirme süreçlerini zaman çizelgesine emdirerek “sayfa var ama metin yok” açmazını kapatır.
-
Analitik ve deney altyapısını baştan takvime koyup kararları kanıtla yönetir; “ölçmeden değiştir” döngüsünü kırar.
-
Karar log’u ve değişiklik yönetimi ile kapsam kaymasını kontrollü hale getirir; bütçe sürprizleri azalır.
-
Go-liveı bir valf gibi kademeli kurgular; geri alma ve izleme planlarıyla operasyonel güvenliğe yatırım yapar.
-
Bakım ve ritüeller için tekrarlayan bütçe ve süre koyarak projenizi “ürün”e dönüştürür—hız ve kalite sürdürülebilir olur.
Bugün bir “Bütçe–Zaman Karar Defteri” açın ve şunları yazın: hedef–kapsam–MVP zinciri; kalem bazlı bütçe; kapasite ve hız ölçümü; faz planı ve kapıları; bağımlılık listesi ve alternatif akışlar; kabul kriterleri; performans/erişilebilirlik/güvenlik/KVKK blokları; içerik ve yerelleştirme takvimi; analitik/deney kurgu; tamponlar ve risk matrisi; ritüeller ve bakım planı; karar log’u ve değişiklik protokolü. Böylece yalnız “takvim tutturmuş” değil; değer üreten, hızlı, güvenli ve saygılı bir web ürünü teslim edersiniz.

