Website Geliştirme Süreci Açıklandı
Her website geliştirme yöntemi aynı aşamaları farklı dizer. Yöntemin adından çok aşamaların kendisini — her birinin ne ürettiğini ve neyin kapattığını — anlamak işe yarar, çünkü projenin olması gereken yerde olup olmadığını size o söyler.
Bu rehber yedi aşamayı, orta ölçekli bir site için tipik süreleri ve her birinde gerçek bir onayın neye benzediğini ele alıyor.
Yedi aşama#
Buradaki süreler küçük bir ekiple orta ölçekli özel bir siteyi varsayıyor. Sayfa sayısından çok içerik hacmi ve entegrasyonlarla uzarlar.
| Aşama | Ürettiği | Tipik süre |
|---|---|---|
| 1. Keşif | Hedefler, kitle, kapsam, kısıtlar | 1–2 hafta |
| 2. Yapı | Sayfa yapısı, içerik modeli, tel çerçeveler | 1–2 hafta |
| 3. Tasarım | Şablonlar, bileşen sistemi, duyarlı kurallar | 2–4 hafta |
| 4. Yapım | Çalışan şablonlar, CMS, entegrasyonlar | 4–10 hafta |
| 5. İçerik | Sistemdeki gerçek metin, görsel ve veri | Paralel yürür — çoğu zaman en uzunu |
| 6. Test | İşlevsel, tarayıcılar arası, performans, erişilebilirlik | 1–2 hafta |
| 7. Yayın | Canlı site, yönlendirmeler, izleme, devir | 2–5 gün |
Aşan aşama 5’tir. Paralel çizilmesinin sebebi küçük olması değil, 2. aşamada başlaması gerektiğidir.
Her aşamayı ne kapatır#
Bir aşama zaman geçti diye bitmez. Yetkisi olan biri belirli bir şeyi yazılı olarak onayladığında biter. Bu olmadan iş, hâlâ hareket edebilen bir zemin üzerinde sürer.
- Keşif: açık bir kapsam dışı listesiyle imzalanmış kapsam.
- Yapı: onaylanmış sayfa yapısı ve ekibinizin anladığı alan adlarıyla içerik modeli.
- Tasarım: mobil ve boş durumlar dahil her farklı düzen için onaylı şablonlar.
- Yapım: her şablonun staging’de gerçekçi içerikle gösterilmesi.
- İçerik: yayın için gerekli her sayfanın doldurulup adı belli biri tarafından okunması.
- Test: üzerinde anlaşılmış, yayını engelleyenler ve sonrası diye ayrılmış bir sorun listesi.
- Yayın: tamamlanmış yayın öncesi kontrol listesi ve doğrulanmış erişim devri.
Şelale, çevik ya da arası#
Gerçek fark kapsamın ne zaman sabitlendiğidir. Sabit kapsamlı projeler kesin fiyatlanır ve değişikliği kötü yönetir; iteratif projeler değişikliği iyi yönetir ve sabit bir toplam vaat edemez. Website işlerinin çoğu ikisinin arasındadır: yayın için sabit kapsam, sonrası iteratif.
| Sabit kapsam | İteratif | |
|---|---|---|
| Fiyat | Baştan belli | Sprint ya da ay başına ücret |
| Değişiklik | Resmî talep, yeniden fiyatlanır | Öncelik değiştirilerek soğurulur |
| Kime uyar | Net ve durağan gereksinimler | Gelişen ürünler ve belirsiz gereksinimler |
| Sizin riskiniz | Artık uymayan bir şeye para ödemek | Maliyetin sert bir durak olmadan sürüklenmesi |
| Sizden istenen | Baştan kararlar | Öncelik belirlemek için sürekli erişilebilirlik |
Muğlak kapsamla sabit fiyattan kaçının. En kötü bileşim budur: geliştirici belirsizliği dar yorumlayarak kârını korur ve her açıklama bir pazarlığa dönüşür.
Süreç genelde nerede bozulur#
Aşımların çoğunu aynı dört aksaklık üretir ve hiçbiri teknik değildir.
- Yer tutucu içerikle onaylanan tasarım. Gerçek metin iki katı uzunlukta gelir ve düzen yeniden kurulur.
- Geç keşfedilen entegrasyonlar. Sekizinci haftada "bir de stok sistemimizle konuşması lazım" bir değişiklik değil yeni bir projedir.
- Tek karar verici yok. Geri bildirim beş kişiden gelir, ikisi çelişir ve kimsenin çözme yetkisi yoktur.
- Testin alışkanlık değil aşama sayılması. Üçüncü haftada girmiş bir hatayı onuncu haftada bulmak birkaç kat pahalıya düzeltilir.
Sık sorulan sorular
Tipik bir website ne kadar sürer?
Şablon tabanlı küçük bir site iki ile dört hafta. Orta ölçekli özel bir site uçtan uca genelde üç ile beş ay. Mağazalar ve uygulamalar daha uzun. Bunları en çok hareket ettiren değişken kodun karmaşıklığı değil, müşteri tarafında içeriğin hazır olması ve kararların hızıdır.
Aşamalar üst üste binebilir mi?
Bazıları binmeli. İçerik yapı aşamasında başlamalı, test ise yalnız sonda değil yapım boyunca yürümeli. Binmemesi gereken şey aynı şablonun tasarımı ile yapımıdır — hâlâ hareket eden bir tasarıma göre inşa etmek yeniden işi garantiler ve "biz bunu zaten yapmıştık" tartışmalarının en yaygın kaynağıdır.
Proje ortasında bir şeyi değiştirmemiz gerekirse?
Gerekeceğini varsayın ve mekanizmayı baştan anlaşın: kim talep edebilir, kim fiyatlar ve yayın tarihini değiştirir mi. Sessizce soğurulan küçük değişiklikler, bir projenin ne zaman olduğunu kimsenin söyleyemediği bir ay sürüklenmesinin yoludur. Yazılı bir değişiklik kaydı bunun çoğunu çözer.
Aşama başına mı ödemeliyim?
İnceleyebileceğiniz teslimatlara bağlanmış kilometre taşı ödemeleri iki taraf için de en adil yapıdır — genelde bir kapora, sonra tasarım onayında, yapım bitiminde ve yayında ödemeler. Tamamını peşin ödemekten kaçının; tamamını bitişte ödemekten de, çünkü nakit akışı riskinin tamamını geliştiriciye yükler ve genelde size daha pahalıya gelir.
website geliştirme süreciweb geliştirme aşamalarıwebsite proje aşamalarıçevik web geliştirmewebsite takvimigeliştirme metodolojisi
