Web Sitesi Projesinde Revize Süreci Nasıl Yönetilmeli?

Web sitesi projesinde revize yapılması normaldir.

Tasarımı ilk kez gördüğünüzde:

• Başlığın değişmesini
• Bir bölümün taşınmasını
• Görselin değiştirilmesini
• Hizmet anlatımının yeniden düzenlenmesini

istemek projenin doğal parçasıdır.

Problem revizyon yapılması değil, revizyon sürecinin nasıl yönetildiğinin belli olmamasıdır.

Örneğin:

“Biraz daha kurumsal olsun.”

“Ana sayfa içimize sinmedi.”

“Yönetimden birkaç yorum daha geldi.”

“Bu arada siteye bayi paneli de ekleyebilir miyiz?”

gibi talepler aynı tür değişiklik değildir.

Bazıları mevcut tasarımın revizyonudur.

Bazıları içerik değişikliğidir.

Bazıları ise projenin kapsamını değiştirir.

Bu ayrım yapılmadığında revize süreci kolayca:

GERİ BİLDİRİM → YENİDEN TASARIM → YENİ GERİ BİLDİRİM → YENİ KAPSAM → GECİKME

döngüsüne dönüşebilir.

Daha sağlıklı model:

BASELINE → REVIEW → CONSOLIDATED FEEDBACK → REVISION → APPROVAL → NEXT PHASE

şeklindedir.

DigitalPlus’ta Web Sitesi Geliştirme projelerinde tasarım ve geliştirme aşamalarını birbirinden ayırarak önemli kararların mümkün olduğunca doğru aşamada onaylanmasını hedefliyoruz.

Web Sitesinde Revize Ne Demektir?

Revize, üzerinde anlaşılan proje kapsamı içerisindeki mevcut çıktının geri bildirim doğrultusunda düzeltilmesi veya iyileştirilmesidir.

Örneğin:

• Hero başlığını değiştirmek
• Buton metnini düzenlemek
• Bir görseli değiştirmek
• Bölümler arasındaki boşluğu düzeltmek
• Mevcut component içerisinde içerik sırasını değiştirmek

revizyon olabilir.

Ancak proje başlangıcında bulunmayan:

• Yeni üyelik sistemi
• Yeni ödeme altyapısı
• Yeni CRM entegrasyonu
• 10 yeni landing page
• Tamamen farklı bir tasarım yönü

istenmesi her zaman revize olarak değerlendirilemez.

Bunlar yeni scope oluşturabilir.

Revizyon ile Kapsam Değişikliği Arasındaki Fark Nedir?

Web sitesi projelerinde en önemli ayrımlardan biri budur.

Talep	Muhtemel Sınıf
Hero görselini değiştirelim	Revizyon
Başlığı daha açık yazalım	Revizyon
Buton biraz daha belirgin olsun	Revizyon
Yeni bir hizmet sayfası ekleyelim	Scope’a bağlı
Siteye üyelik sistemi ekleyelim	Yeni kapsam
Tasarım dilini tamamen değiştirelim	Büyük değişiklik / yeniden kapsamlandırma

Proje başlamadan kapsam ne kadar açık tanımlanırsa bu ayrımı yapmak o kadar kolaylaşır.

Neden Her Talebe “Revize” Dememek Gerekir?

Çünkü projenin:

• Scope
• Süre
• Bütçe
• Kaynak

birbiriyle bağlantılıdır.

Yeni iş eklenirken teslim tarihi ve bütçenin hiç değişmemesi beklendiğinde proje planı gerçekliğini kaybetmeye başlar.

Bu nedenle yeni talep geldiğinde önce şu soru sorulmalıdır:

Bu, mevcut çıktıyı mı düzeltiyor yoksa yeni çıktı mı oluşturuyor?

Web Sitesinde Revize Süreci Ne Zaman Başlamalı?

Revize yalnız proje sonunda yapılmamalıdır.

Web projesi aşamalara bölünerek her kritik aşamada review yapılabilir.

Örneğin:

1. Site mimarisi onayı
2. Tasarım onayı
3. Geliştirme review
4. İçerik kontrolü
5. Final QA

Böylece yanlış karar geliştirme bittikten sonra fark edilmez.

Neden Tasarım Geliştirmeden Önce Onaylanmalı?

Tasarım aşamasında bir bölümü değiştirmek genellikle daha kolaydır.

Aynı değişiklik frontend tamamlandıktan sonra:

• Yeni tasarım
• Yeni development
• Yeni responsive düzenleme
• Yeni QA

gerektirebilir.

Bu nedenle temel layout ve kullanıcı akışı mümkün olduğunca geliştirmeden önce netleştirilmelidir.

Web Sitesi Revize Süreci İçin Sağlıklı Akış Nasıl Olmalı?

Pratik bir workflow şu şekilde kurulabilir:

1. SUNUM

Ajans veya tasarımcı mevcut çıktıyı sunar.

↓

2. İÇ REVIEW

Müşteri kendi ekibinden geri bildirimleri toplar.

↓

3. TEK GERİ BİLDİRİM LİSTESİ

Çelişkiler çözülerek ajansa tek liste gönderilir.

↓

4. SINIFLANDIRMA

Revizyon, hata ve yeni scope ayrılır.

↓

5. UYGULAMA

Onaylanmış revizyonlar uygulanır.

↓

6. REVIEW

Değiştirilen alanlar kontrol edilir.

↓

7. ONAY

Aşama kapatılarak sonraki faza geçilir.

1. Proje Başında Revizyon Kuralları Belirlenmeli

Revize sürecini proje sonunda tartışmak yerine teklif veya proje başlangıcında açıklamak daha sağlıklıdır.

En azından şu konular netleşmelidir:

• Geri bildirim nasıl iletilecek?
• Kim nihai onay verecek?
• Revizyonlar hangi aşamalarda yapılacak?
• Yeni kapsam nasıl ele alınacak?
• Revizyonların proje takvimine etkisi nasıl yönetilecek?

2. Proje Scope’u Yazılı Olmalı

Revizyon yönetebilmek için önce neyin onaylandığını bilmek gerekir.

Örneğin web sitesi scope’unda:

• Sayfa sayısı
• Page template’leri
• Özel özellikler
• Formlar
• Entegrasyonlar
• İçerik sorumluluğu
• Diller

tanımlanabilir.

Böylece proje ortasında gelen yeni talebin mevcut scope içerisinde olup olmadığı daha kolay anlaşılır.

3. Müşteri Tarafında Tek Karar Sahibi Belirleyin

Web sitesi çoğu zaman yalnız bir kişinin görüşünü ilgilendirmez.

Projeye:

• Pazarlama
• Satış
• Yönetim
• IT
• İnsan kaynakları

gibi farklı ekipler dahil olabilir.

Bu kötü değildir.

Problem herkesin doğrudan ajansa ayrı talep göndermesidir.

Bir kişi:

“Bu alanı kaldırın.”

derken başka biri:

“Bu alanı ana sayfanın en üstüne taşıyalım.”

diyorsa tasarım ekibi artık revizyon değil kurum içi arabuluculuk yapmaya başlar.

Bu nedenle müşteri tarafında tek bir project owner belirlenmesi faydalıdır.

Project Owner Ne Yapmalı?

Project owner:

• Stakeholder yorumlarını toplar
• Çelişkili geri bildirimleri çözer
• Öncelikleri belirler
• Ajansa tek geri bildirim seti iletir
• Onay kararını takip eder

Bu kişinin bütün kararları tek başına vermesi gerekmez.

Ama ajansa ulaşan son kararın tek ve anlaşılır olması gerekir.

4. Feedback Tek Yerde Toplanmalı

Revizyon yorumlarının:

• WhatsApp
• E-posta
• Telefon
• Figma
• Slack
• Toplantı notları

arasında dağılması hata riskini artırır.

Mümkün olduğunda feedback için tek source of truth belirlenmelidir.

Bu:

• Figma comments
• Project management tool
• Paylaşılan doküman
• Ticket sistemi

olabilir.

Önemli olan bütün kararların aynı yerde izlenebilmesidir.

5. Feedback “Beğenmedim” Seviyesinde Kalmamalı

İyi geri bildirim problemi tarif eder.

Örneğin:

Zayıf feedback:

“Bu bölüm olmadı.”

Daha kullanışlı feedback:

“Hizmet kapsamı ilk ekranda anlaşılmıyor. Kullanıcının üç ana hizmeti daha hızlı görmesini istiyoruz.”

İkinci geri bildirim tasarımcının problemi anlamasına yardımcı olur.

Çözümü Müşteri mi Söylemeli, Problemi mi?

Müşteri isterse çözüm önerisi sunabilir.

Ancak özellikle UX ve tasarım kararlarında problemin açıklanması daha değerlidir.

Örneğin:

“Bu butonu kırmızı yapın.”

yerine:

“Ana CTA diğer elementlerin arasında yeterince fark edilmiyor.”

demek tasarım ekibine farklı çözümleri değerlendirme alanı verir.

6. Revizyonlar Tek Tek Değil Round Olarak Toplanabilir

Her yeni mesaj geldiğinde ayrı tasarım değişikliği yapmak verimsiz olabilir.

Örneğin müşteri sabah:

“Başlığı değiştirelim.”

öğleden sonra:

“Eski başlık daha iyiydi.”

ertesi gün:

“Yönetim üçüncü bir başlık önerdi.”

diyebilir.

Bunun yerine belirli review penceresinde bütün feedback toplanarak tek revizyon turu oluşturulabilir.

Revizyon Turu Nedir?

Revizyon turu, belirli aşamadaki geri bildirimlerin birlikte değerlendirilerek toplu olarak uygulanmasıdır.

Örneğin:

Round 1: Ana yapı ve UX

Round 2: Görsel ve içerik iyileştirmeleri

Round 3: Final küçük düzeltmeler

şeklinde proje özelinde bir süreç kurulabilir.

Bu örnek zorunlu standart değildir.

Revizyon sayısı projenin büyüklüğüne ve çalışma modeline göre belirlenmelidir.

Kaç Revizyon Hakkı Olmalı?

Her web sitesi için geçerli ideal bir sayı yoktur.

Basit landing page ile 50 farklı template içeren kurumsal portal aynı revizyon ihtiyacına sahip değildir.

Daha önemli olan:

• Revizyonun nasıl tanımlandığı
• Her turun hangi alanı kapsadığı
• Yeni scope’un nasıl ayrıldığı

konularının açık olmasıdır.

Sınırsız Revizyon Mantıklı mı?

“Sınırsız revizyon” müşteri açısından ilk bakışta güvenli görünebilir.

Ama kapsam ve onay mekanizması bulunmuyorsa proje kapanış noktasını belirsiz hale getirebilir.

Daha sağlıklı yaklaşım:

• Net scope
• Tanımlı review aşamaları
• Makul revizyon imkânı
• Yeni işler için change request

oluşturmaktır.

7. Büyük Revizyonları İlk Turda Yapın

İlk review sırasında:

• Sayfa yapısı
• Bilgi hiyerarşisi
• Section sırası
• Ana kullanıcı akışı
• Tasarım yönü

gibi büyük konulara odaklanmak daha verimlidir.

Font boyutundaki küçük farkları düzeltip sonraki turda bütün sayfa yapısını değiştirmek gereksiz tekrar çalışma yaratır.

İdeal sıra:

STRUCTURE → CONTENT → VISUAL DETAILS → FINAL POLISH

şeklinde düşünülebilir.

8. Mobil ve Desktop Tasarımları Birlikte Düşünün

Desktop tasarımın onaylanması bütün deneyimin tamamlandığı anlamına gelmez.

Mobil görünümde:

• Menü
• CTA
• Form
• Tablolar
• Görseller
• Uzun başlıklar

farklı davranabilir.

Bu nedenle review süreci mobil kullanıcı deneyimini de kapsamalıdır.

9. İçerik Revizyonu ile Tasarım Revizyonunu Ayırın

Bazen tasarımın kötü göründüğü düşünülür fakat gerçek problem içeriktir.

Örneğin hero alanına:

120 kelimelik açıklama

konulmuşsa tasarımın sıkışması yalnız UI problemi olmayabilir.

Benzer şekilde güçlü tasarım zayıf ve belirsiz copy’yi düzeltemez.

Bu nedenle:

• Copy feedback
• Design feedback
• Development feedback

mümkün olduğunca ayrı sınıflandırılmalıdır.

Sayfa metinlerinin yeniden hazırlanması gerekiyorsa Web İçeriği Üretimi projenin ayrı workstream’i olarak planlanabilir.

10. Bug ile Revizyon Aynı Şey Değildir

Teslim edilen tasarımda butonun biraz daha büyük istenmesi revizyon olabilir.

Butona tıklanınca hiçbir şey olmaması ise bug’dır.

Durum	Sınıf
Form gönderilmiyor	Bug
Form alanlarının sırası değişsin	Revizyon
Mobil menü açılmıyor	Bug
Menü tasarımı farklı olsun	Revizyon
Projede olmayan müşteri paneli eklensin	Yeni scope

Bu üç alan sözleşmede ve proje yönetiminde birbirine karıştırılmamalıdır.

11. Change Request Nedir?

Change request, mevcut proje scope’unu değiştiren yeni talebin kontrollü biçimde değerlendirilmesidir.

Basit model:

NEW REQUEST

↓

IS IT IN SCOPE?

↓

IMPACT ANALYSIS

↓

TIME + COST + DEPENDENCY

↓

APPROVE / REJECT / DEFER

Bu süreç yeni fikirlere karşı çıkmak için değil, yeni fikrin gerçek maliyetini görünür hale getirmek için kullanılır.

Yeni Özellik İstemek Yanlış mı?

Hayır.

Projeler ilerledikçe daha iyi fikirler çıkabilir.

Önemli olan yeni talebin:

• Teslim tarihine
• Bütçeye
• Development kapasitesine
• Diğer özelliklere

etkisinin görülmesidir.

Yeni özellik gerçekten değerliyse scope resmi olarak güncellenebilir.

12. “Küçük Bir Şey Daha” Talepleri Nasıl Yönetilmeli?

Tek başına küçük görünen talepler proje boyunca birikebilir.

Örneğin:

• Bir popup
• Yeni form alanı
• Yeni slider
• Yeni section
• Yeni filtre

ayrı ayrı küçük olabilir.

Ancak her biri:

• Tasarım
• Development
• Responsive
• QA

gerektiriyorsa toplam iş yükü büyür.

Bu nedenle küçük talepler de proje backlog’unda görünür tutulmalıdır.

13. Yeni Talep Geldiğinde Eski Bir İş Çıkarılabilir mi?

Evet.

Bütçe ve tarih sabit tutulmak isteniyorsa scope trade-off yapılabilir.

Örneğin:

Yeni talep: Referans filtreleme sistemi eklensin.

Bunun karşılığında daha düşük öncelikli başka bir özellik sonraki faza taşınabilir.

Bu yaklaşım:

ADD X → REMOVE / DEFER Y

mantığıyla proje kapsamını kontrol altında tutar.

14. Revizyon Teslim Tarihini Etkiler mi?

Etkileyebilir.

Özellikle:

• Feedback geç geliyorsa
• Büyük tasarım yönü değişiyorsa
• Yeni functionality isteniyorsa
• Onaylanan alanlar yeniden açılıyorsa

takvim değişebilir.

Bu nedenle web sitesi teslim süresini hesaplarken yalnız ajansın production süresi değil müşteri review süresi de dikkate alınmalıdır.

15. Feedback İçin Süre Belirlemek Mantıklı mı?

Evet.

Örneğin tasarım gönderildikten sonra müşteri tarafında belirli iş günü içerisinde feedback beklenebilir.

Kesin süre proje modeline göre değişir.

Ama review deadline bulunması:

• Kararların askıda kalmasını
• Development ekibinin beklemesini
• Teslim tarihinin belirsizleşmesini

azaltabilir.

Müşteri Geri Bildirimi Geç Verirse Ne Olur?

Ajans bütün ekibini boşta tutarak haftalarca aynı projeyi bekletemeyebilir.

Geciken onay sonucunda proje yeni uygun production slot’una taşınabilir.

Bunun nasıl yönetileceği proje başlangıcında açıklanmalıdır.

16. Onaylanan Tasarım Sonradan Değiştirilebilir mi?

Teknik olarak evet.

Ama değişikliğin hangi aşamada istendiği önemlidir.

Örneğin Figma’da onaylanmış hero alanı frontend geliştirme bittikten sonra tamamen değiştirilecekse:

• Design
• Development
• Responsive adaptation
• QA

yeniden gerekebilir.

Bu nedenle “onay” yalnız formalite olarak kullanılmamalıdır.

Onay Ne Anlama Gelmeli?

Onay:

“Bu aşamadaki temel kararlarla ilerleyebiliriz.”

anlamına gelmelidir.

Bu, daha sonra hiçbir küçük değişiklik yapılamayacağı anlamına gelmez.

Ama onaylanan temel kararın tekrar açılması proje planına etkisiyle birlikte değerlendirilmelidir.

17. WhatsApp Üzerinden Revize Yönetilir mi?

Küçük projelerde bazı hızlı iletişimler yapılabilir.

Ancak revizyonların yalnız mesaj geçmişinde tutulması uzun projelerde sağlıklı değildir.

Örneğin:

“Geçen salı attığım ses kaydının 2:40’ındaki değişiklik yapılmamış.”

gibi bir proje yönetim modelini geleceğin kurumsal standardı olarak görmek için henüz yeterli sebep yok.

Kritik feedback yazılı ve takip edilebilir sistemde tutulmalıdır.

18. Toplantıda Verilen Feedback Yazılı Hale Getirilmeli mi?

Evet.

Toplantı sonrasında kısa decision summary hazırlanabilir:

• Ne değişecek?
• Ne değişmeyecek?
• Kim sorumlu?
• Sonraki review ne zaman?

Böylece iki tarafın toplantıdan farklı kararlarla çıkması önlenir.

19. Figma Üzerinden Revizyon Yönetmek Mantıklı mı?

Tasarım projelerinde mantıklı olabilir.

Feedback doğrudan ilgili:

• Section
• Button
• Image
• Component

üzerine bırakılabilir.

Böylece:

“Ana sayfanın ortasındaki kutu.”

gibi hangi elementten bahsedildiği belirsiz ifadeler azalır.

Ancak yine de stakeholder yorumlarının çelişmemesi için müşteri tarafında review yapılmalıdır.

20. Her Stakeholder Figma’ya Yorum Yazmalı mı?

Yazabilir, ancak nihai karar mekanizması belirlenmelidir.

Beş kişinin aynı element için beş farklı çözüm istediği durumda tasarım ekibinin hepsini aynı anda uygulaması mümkün değildir.

Yorum toplamak ile karar vermek farklı görevlerdir.

21. Revizyon Listesi Nasıl Yazılmalı?

Her madde mümkün olduğunca:

• Sayfa
• Section
• Problem
• Beklenen değişiklik

içermelidir.

Örneğin:

Sayfa	Alan	Feedback
Ana Sayfa	Hero	Ana değer önerisi yeterince açık değil; başlıkta hizmet tipi belirtilmeli.
Hizmet	CTA	Teklif alma aksiyonu sayfanın sonunda tekrar görünmeli.
İletişim	Form	Şirket büyüklüğü alanı ilk temas için gerekli değil; kaldırılmalı.

Bu şekilde revizyonun ne olduğu kontrol edilebilir.

22. Ekran Görüntüsü ile Feedback Vermek Faydalı mı?

Evet.

Özellikle development sonrası sorunlarda:

• Ekran görüntüsü
• URL
• Cihaz
• Tarayıcı

bilgileri problemi yeniden üretmeyi kolaylaştırabilir.

Örneğin:

“Mobilde bozuk.”

yerine:

“iPhone Safari’de /iletisim/ sayfasındaki form ekran dışına taşıyor.”

daha uygulanabilir bir geri bildirimdir.

23. Revizyon Öncelikleri Belirlenmeli mi?

Özellikle büyük projelerde evet.

Basit olarak:

• BLOCKER
• IMPORTANT
• POLISH

gibi bir sınıflandırma kullanılabilir.

Örneğin formun çalışmaması blocker olabilir.

Bir ikonun birkaç piksel farklı hizalanması final polish olabilir.

Bu sayede ekip yayın öncesi gerçekten kritik konulara önce odaklanabilir.

24. Her Revizyon Yayın Öncesinde Bitmeli mi?

Hayır.

Siteyi kullanılamaz hale getirmeyen bazı düşük öncelikli geliştirmeler sonraki release’e bırakılabilir.

Örneğin:

• Ek animation
• Yeni küçük component
• Düşük öncelikli görsel iyileştirme

yayın sonrası backlog’a taşınabilir.

Ama:

• Çalışmayan form
• Bozuk navigation
• Kritik mobil sorun
• Yanlış iletişim bilgisi

gibi problemler yayın öncesinde çözülmelidir.

25. Revizyon ile QA Arasındaki Fark Nedir?

Revizyon, onaylı tasarım veya içerik üzerinde istenen değişikliktir.

QA, geliştirilen ürünün beklenen şekilde çalışıp çalışmadığını kontrol eder.

Örneğin tasarımda buton mavi olarak onaylandıysa ancak canlı sitede buton görünmüyorsa bu tasarım revizyonu değil implementation problemidir.

Final QA’da Neler Kontrol Edilmeli?

Projeye göre:

• Desktop görünüm
• Mobil görünüm
• Navigation
• Forms
• CTA’lar
• Links
• Responsive components
• Analytics
• SEO alanları
• Performance

kontrol edilebilir.

DigitalPlus’ın Web Sitesi Geliştirme sürecinde de test ve yayın geliştirmeden ayrı bir proje aşaması olarak ele alınır.

26. Final Revizyondan Sonra Yeni Talep Gelirse?

Talebin niteliğine bakılmalıdır.

Eğer:

• Bug ise düzeltilir
• Mevcut scope içerisindeki eksik teslimatsa tamamlanır
• Yeni özellikse yeni scope olarak değerlendirilir

Bu ayrım projenin gerçekten ne zaman tamamlandığını belirler.

27. Web Sitesi Yayına Alındıktan Sonra Revizyon Yapılabilir mi?

Evet.

Web sitesi yayına çıktıktan sonra gerçek kullanıcı verisiyle yeni iyileştirmeler yapılabilir.

Ancak bunlar artık ilk geliştirme projesinin revizyonundan ziyade:

• Bakım
• Optimization
• Yeni development

kapsamında değerlendirilebilir.

Yayın sonrasında düzenli içerik, teknik bakım veya küçük geliştirmeler gerekiyorsa Web Sitesi Yönetimi modeli kullanılabilir.

28. Kullanıcı Verisine Göre Yapılan Değişiklik Revizyon mudur?

Her zaman değil.

Örneğin site yayına çıktıktan sonra analytics veya kullanıcı davranışı verisi:

“Kullanıcıların önemli bölümü fiyatlandırma sayfasını bulamıyor.”

gösteriyorsa navigation yeniden değerlendirilebilir.

Bu artık:

“Müşterinin tasarımı beğenmemesi.”

değil:

“Yeni veriye göre ürün iyileştirmesi.”

haline gelir.

29. Revizyon Sürecinde SEO Ekibi Ne Zaman Dahil Olmalı?

Mevcut ve organik trafik alan site yeniden tasarlanıyorsa SEO yalnız final aşamada kontrol yapan ekip olmamalıdır.

Özellikle:

• Navigation değişiklikleri
• Sayfa silme
• URL değişiklikleri
• Content consolidation
• Heading yapısı
• Internal linking

SEO etkisi oluşturabilir.

Görsel olarak küçük görünen bir revizyon Search mimarisini etkiliyorsa SEO review gerekebilir.

30. “Bu Sayfayı Kaldıralım” Basit Tasarım Revizyonu mudur?

Mevcut site Google’dan trafik alıyorsa olmayabilir.

Silinecek URL’nin:

• Organic traffic
• Impressions
• Backlinks
• Internal links
• Search intent

değeri kontrol edilmelidir.

Gerekiyorsa redirect veya content migration planlanmalıdır.

31. Revizyonlarda Her Şeyi Rakibe Benzetmek Doğru mu?

Rakip siteler referans olabilir.

Ama:

“Rakipte böyle, bizde de aynısı olsun.”

tek başına kullanıcı ihtiyacını açıklamaz.

Önce rakipteki çözümün hangi problemi çözdüğü değerlendirilmelidir.

Sonra aynı problem sizin sitenizde gerçekten bulunuyorsa uygun çözüm seçilebilir.

32. Tasarım Kararlarında Kişisel Zevk Ne Kadar Belirleyici Olmalı?

Marka tercihi önemlidir.

Ancak web sitesi yalnız şirket yönetiminin bakacağı bir sunum değildir.

Kullanıcı:

• Hizmeti anlamalı
• Navigation’ı kullanabilmeli
• Metni okuyabilmeli
• CTA’yı bulabilmeli

Bu nedenle:

“Ben bu rengi sevmiyorum.”

ile:

“Bu renk kombinasyonu metnin okunabilirliğini düşürüyor.”

aynı ağırlıkta tasarım problemi değildir.

33. Yönetici Sonradan Projeye Girerse Ne Olur?

Bu web projelerinin klasik risklerinden biridir.

Proje haftalarca ilerler, tasarımlar onaylanır ve geliştirme başlar.

Son aşamada yeni karar verici projeye dahil olup:

“Ben baştan farklı düşünüyordum.”

diyebilir.

Bunu azaltmak için kritik stakeholder’ların temel:

• Site amacı
• Architecture
• Design direction

onaylarında erken aşamada yer alması faydalıdır.

34. Revizyon Geçmişi Tutulmalı mı?

Büyük projelerde evet.

Örneğin:

Tarih	Karar	Durum
12 Eylül	Hero copy değişecek	Completed
14 Eylül	Referans bölümü yukarı taşınacak	Completed
17 Eylül	CRM entegrasyonu talebi	Phase 2

Tablo yalnız örnek yapıdır.

Decision history aynı tartışmanın birkaç hafta sonra yeniden açılmasını azaltabilir.

35. Revizyon Sürecinde “Done” Tanımı Olmalı mı?

Evet.

Bir revizyonun tamamlanması yalnız:

“Developer kodu değiştirdi.”

anlamına gelmemelidir.

Örneğin done kriteri:

• Değişiklik uygulandı
• Desktop kontrol edildi
• Mobil kontrol edildi
• İlgili functionality çalışıyor
• Müşteri review tamamlandı

olabilir.

36. Revizyonların Maliyeti Nasıl Konuşulmalı?

Proje kapsamındaki normal revizyonlar teklif fiyatına dahil olabilir.

Ancak scope dışı iş için:

• Ek ücret
• Ek süre
• Yeni phase

gerekebilir.

Bu nedenle teklif karşılaştırırken yalnız toplam website fiyatını değil:

• Revizyon modelini
• Scope değişikliğinin nasıl fiyatlandığını
• Sonraki geliştirme ücretini

de sorun.

DigitalPlus’ın güncel hizmet kapsamlarını Fiyatlandırma sayfasından da inceleyebilirsiniz.

37. Revizyon Talebi Reddedilebilir mi?

Bazen evet.

Özellikle talep:

• Accessibility sorununa yol açıyorsa
• Teknik problemi büyütüyorsa
• Güvenliği etkiliyorsa
• Onaylanan proje hedefiyle çelişiyorsa

ajans neden önermediğini açıklayabilir.

Web ekibinin görevi her talebi düşünmeden uygulamak değil, kararın etkisini müşteriye göstermek de olmalıdır.

38. Ajans Revizyon Talebine Alternatif Çözüm Sunmalı mı?

İyi bir proje ilişkisinde evet.

Örneğin müşteri:

“Ana sayfaya bütün hizmetlerin açıklamasını koyalım.”

diyorsa amaç hizmetlerin görünür olmasını sağlamak olabilir.

Ajans bunun yerine:

• Daha kısa service cards
• Category navigation
• İlgili service pages’e bağlantılar

önerebilir.

Feedback’in arkasındaki gerçek ihtiyacı anlamak daha iyi çözüm üretir.

39. Revizyon Süreci Ajans ile Müşteri Arasında Kavga Alanı Olmak Zorunda mı?

Hayır.

Sağlıklı revizyon sistemi iki tarafı da korur.

Müşteri neyi talep ettiğini ve ne zaman teslim alacağını bilir.

Ajans ise hangi işin mevcut kapsamda olduğunu ve hangi işin yeni kaynak gerektirdiğini bilir.

Amaç:

REVİZYONU ENGELLEMEK

değil:

DEĞİŞİKLİĞİ GÖRÜNÜR VE YÖNETİLEBİLİR HALE GETİRMEK

olmalıdır.

40. Web Sitesi Revize Sürecinde Kullanılabilecek Basit Statüler

Durum	Anlamı
Feedback	Yeni yorum geldi
Accepted	Revizyon kabul edildi
Clarification	Ek bilgi gerekiyor
In Progress	Uygulanıyor
Ready for Review	Müşteri kontrolüne hazır
Approved	Onaylandı
Change Request	Mevcut scope dışında
Phase 2	Sonraki faza taşındı

41. Revizyon Toplantısında Hangi Sorular Sorulmalı?

1. Bu değişiklik hangi problemi çözüyor?
2. Mevcut scope içerisinde mi?
3. Kritik mi yoksa polish mi?
4. Başka sayfaları etkiliyor mu?
5. Mobil görünümü etkiliyor mu?
6. Yeni development gerektiriyor mu?
7. Teslim tarihini etkiliyor mu?
8. Bu kararın nihai onay sahibi kim?

42. Web Sitesi Revizyon Checklist’i

Kontrol	Durum
Project scope yazılı	Kontrol edilmeli
Tek project owner mevcut	Kontrol edilmeli
Feedback tek yerde toplanıyor	Kontrol edilmeli
Feedback’ler konsolide ediliyor	Kontrol edilmeli
Bug / revision / scope change ayrılıyor	Kontrol edilmeli
Revizyon turları tanımlı	Kontrol edilmeli
Review deadline mevcut	Kontrol edilmeli
Onay sahibi belli	Kontrol edilmeli
Change request sistemi mevcut	Kontrol edilmeli
Final QA ayrı yapılıyor	Kontrol edilmeli

Web Sitesi Projesinde Revize Süreci Nasıl Yönetilmeli?

Kısa cevap:

Revizyon süreci sınırsız ve dağınık geri bildirim alışverişi olarak değil, belirli review ve onay aşamalarından oluşan kontrollü proje süreci olarak yönetilmelidir.

En sağlıklı model:

1. SCOPE’U NETLEŞTİR

↓

2. KARAR SAHİBİNİ BELİRLE

↓

3. FEEDBACK’İ TEK YERDE TOPLA

↓

4. GERİ BİLDİRİMLERİ KONSOLİDE ET

↓

5. BUG / REVISION / NEW SCOPE AYRIMI YAP

↓

6. REVİZYONU UYGULA

↓

7. REVIEW VE QA YAP

↓

8. AŞAMAYI ONAYLA

şeklindedir.

Revizyon projenin kötü yönetildiğini göstermez.

Tam tersine doğru feedback web sitesini daha iyi hale getirebilir.

Problem, her yeni fikrin:

“Ufak bir revize.”

adıyla mevcut scope’a eklenmesidir.

Yeni talep gerçekten yeni iş oluşturuyorsa zaman, bütçe ve diğer deliverable’lar üzerindeki etkisi açık biçimde değerlendirilmelidir.

Böylece hem müşteri ne aldığını bilir hem geliştirme ekibi gerçekçi bir proje takvimiyle çalışabilir.

Kurumsal web sitesi projenizin keşif, tasarım, geliştirme, review, test ve yayın aşamalarını planlamak için Web Sitesi Geliştirme hizmetimizi inceleyebilirsiniz. Yayın sonrasındaki düzenli değişiklik, bakım ve geliştirmeler için Web Sitesi Yönetimi hizmetinden yararlanabilirsiniz.