Web Projesi Nasıl Planlanır? Kapsam, Wireframe ve Teknik Karar Süreci

Son güncelleme: Nisan 2026 · AnomixLabs Teknik Ekibi

Kötü planlanan projeler yazılım kalitesiyle değil, belirsiz kapsam ve yanlış beklentilerle başarısız olur. İyi plan, geliştirmeye başlamadan çoğu sorunu çözer.

Proje Planlamanın Neden Kritik Olduğu

AnomixLabs'ın yıllar içinde yürüttüğü projelerde en sık başarısızlık nedenleri:

1. Belirsiz kapsam — 'şunu da ekleyelim' baskısı (scope creep)
2. Yanlış süre tahmini — 'iki haftada biter' yanılgısı
3. Eksik kullanıcı araştırması — yapılan özelliği kullanan çıkmıyor
4. Teknik borç birikimi — hız için köşeleri kesmek, sonra ödenen bedel
5. İletişim kopuklukları — müşteri hayal ettiği, geliştirici yazdığı

Bunların büyük çoğunluğu iyi bir planlama süreciyle önlenebilir.

1. Adım: Discovery — Projeyi Anlamak

Geliştirmeye başlamadan önce cevaplanması gereken sorular:

• Kullanıcı kim? Teknik bilgi seviyesi nedir?
• Çözülmek istenen problem tam olarak ne?
• Başarı nasıl ölçülecek? (KPI'lar)
• Benzer çözümler var mı? Fark ne?
• Teknik kısıtlamalar var mı? (mevcut sistem entegrasyonu, API limitleri)
• Bütçe ve zaman kısıtı nedir?

Bu soruların cevapları tanım dokümanına dönüşür. Tanım dokümanı olmadan başlanan projeler neredeyse her zaman geç teslim edilir veya yarıda bırakılır.

2. Adım: User Story Mapping

User story'ler, özellikleri kullanıcının bakış açısından tanımlar:

Format: [Kullanıcı rolü] olarak [eylem] yapabilmek istiyorum
         böylece [kazanım] elde edeceğim.

Örnek:
  'Alıcı olarak ürünleri fiyata göre filtreleyebilmek istiyorum
   böylece bütçeme uygun seçenekleri hızlıca bulabileceğim.'

  'Yönetici olarak siparişlerin durumunu anlık görebilmek istiyorum
   böylece müşteri şikayetlerine hızlı yanıt verebileceğim.'

User story mapping'de tüm story'leri önce listelenir, ardından öncelik sıralaması yapılır. MVP için yalnızca 'must-have' story'ler seçilir.

3. Adım: Wireframe ile Görselleştirme

Wireframe, projenin görsel iskeletidir — tasarım değil, yapı. Figma veya FigJam ile hızlıca oluşturulabilir:

• Lo-fi wireframe: Kutu ve metin yerleşimi — saatler içinde
• Hi-fi prototype: Tıklanabilir, gerçeğe yakın — günler içinde
• Alternatif: Excalidraw (ücretsiz, tarayıcı tabanlı), Balsamiq

Wireframe, müşteriye 'ne yapılacak' sorusunu somut olarak gösterir ve yanlış anlamaları geliştirmeye başlamadan yakalar. AnomixLabs deneyimi: wireframe sonrası müşteri isteklerinin %40'ı değişiyor — bu değişikliklerin kodu yazdıktan sonra gelmesi 3-5x daha maliyetli.

4. Adım: Teknik Mimari Kararı

Teknoloji seçimi proje gereksinimlerine göre yapılmalı, alışkanlığa değil:

• İçerik yoğun site: Django + PostgreSQL — güçlü admin, ORM, auth
• API-heavy SPA: Django REST Framework + React/Vue
• Yüksek trafikli API: FastAPI + async veritabanı
• Basit vitrin site: No-code (Webflow, Framer) değerlendir
• E-ticaret MVP: Shopify değerlendir — sıfırdan geliştirme gerekmeyebilir

5. Adım: PERT ile Gerçekçi Süre Tahmini

PERT (Program Evaluation and Review Technique), üç senaryo kullanarak daha gerçekçi süre tahmini yapar:

PERT Formülü:
  Tahmini Süre = (İyimser + 4×Olası + Kötümser) / 6

Örnek — Kullanıcı girişi modülü:
  İyimser:   2 gün (her şey yolunda giderse)
  Olası:     4 gün (normal koşullar)
  Kötümser:  10 gün (OAuth entegrasyonu sorun çıkarırsa)

  PERT Tahmini = (2 + 4×4 + 10) / 6 = 4.67 gün ≈ 5 gün

Tampon kural: toplam tahminin %20-30'unu buffer olarak ekleyin.

Geliştirici tahmini her zaman iyimser — PERT bu önyargıyı dengelemek için tasarlandı. Deneyimsiz ekipler için tahmini 2x ile çarpmak pratik bir kural.

Scope Creep: En Büyük Proje Katili

Scope creep, tanımlı kapsam dışında sürekli yeni özellik eklenmesidir. Gerçek maliyet hesabı:

• Her 'küçük eklenti' geliştirme, test ve deployment maliyeti taşır
• Bağlam değişimi (context switching) geliştirici verimliliğini %20-40 düşürür
• Geç değişiklikler teknik borcun katlanmasına neden olur

Önleme yöntemi: Tanım dokümanına imza attırın. 'Bu kapsam dışı, Change Request açalım' cümlesini rahatça kullanın. Kapsam değişikliğini yeni görev olarak fiyatlandırın, mevcut projeye dahil etmeyin.

MVP vs Tam Proje

MVP (Minimum Viable Product), kullanıcıya değer sunan en az özellikli versiyondur:

• MVP maliyet: Tam projenin %20-30'u, 4-8 haftada teslim
• Tam proje: 3-12 ay, yüksek bütçe, uzun feedback döngüsü
• MVP avantajı: Erken kullanıcı geri bildirimi, pivot fırsatı, nakit akışı

AnomixLabs tavsiyesi: özellikle yeni ürün veya pazar doğrulaması gerektiren projelerde MVP başlayın. Kullanıcılar olmadan yazılan özellikler %64 kullanılmıyor (Standish Group Chaos Report).

No-Code Alternatifleri

Her proje kod gerektirmez — 2026'da no-code araçlar ciddi kabiliyetlere ulaştı:

• Webflow: Karmaşık, responsive site — geliştiricisiz CMS
• Framer: Tasarımcı odaklı, animasyon güçlü
• Bubble: Full-stack web app mantığı — veritabanı, kullanıcı yönetimi, iş akışları
• Notion + Super.so: İçerik odaklı siteler için

No-code doğru seçim için kriter: proje benzersiz iş mantığı gerektirmiyor, ölçek öngörülemiyor, hız öncelikli.

Agile Küçük Takım İçin

2-5 kişilik bir takımda tam Scrum seremonileri çoğunlukla overhead yaratır. Hafif agile önerileri:

• 2 haftalık sprint — commit sayısını kısıtlar, ilerlemeyi görünür kılar
• Sprint başında 30dk planlama, sonunda 30dk retrospektif
• Kanban board (GitHub Projects, Linear, Trello) — yapılacak / yapılıyor / bitti
• Günlük standup: 15 dakika, asenkron da olabilir (Slack mesajı)

Tanım Dokümanı Şablonu

1. Proje Adı ve Tarihi
2. Problem Tanımı (1 paragraf)
3. Hedef Kullanıcılar
4. Başarı Kriterleri (KPI)
5. Kapsam Dahil (bullet list)
6. Kapsam Dışı (net listele — önemi büyük)
7. Teknik Gereksinimler ve Kısıtlamalar
8. Wireframe Linkleri
9. Süre ve Teslimat Takvimi
10. İmzalar / Onay

Özet

İyi proje planlaması beş adım: discovery (projeyi anla), user story mapping (özellik önceliği), wireframe (görselleştir), PERT tahmini (gerçekçi süre), tanım dokümanı (kapsam kilitle). Bu adımlar geliştirme süresini kısaltmaz — ama başarısızlık olasılığını dramatik biçimde düşürür.