1. Change Management Nedir?
Change management; “ne değişti?” sorusundan önce “bu değişiklik ne kadar riskli, ne kadar denetim gerekir, ne zaman yayınlanmalı?” sorusunu yönetmektir. Özellikle otel projelerinde sezon ve kampanya dönemleri; B2B’de çeyreklik release’ler ve kritik iş saatleri değişiklik yönetimini zorunlu kılar. Bu yüzden hotfix minor major farkı kadar onay, test ve rollback disiplininin de yazılı olması gerekir.
Soru : Change management nedir, neden önemlidir?
Cevap: Change management; değişiklikleri risk ve iş etkisine göre sınıflandırıp doğru onay, test ve yayınlama zamanını belirleyen süreçtir. Yanlış zamanda deploy kaynaklı krizleri ve rollback ihtiyacını azaltır, bakım & destek operasyonunu öngörülebilir kılar.
☑ Mini Check
- •Değişiklikler “risk sınıfı” ile etiketleniyor mu?
- •Yayınlama için ortak bir release takvimi var mı?
- •Kritik dönemlerde (sezon/kampanya/iş saatleri) freeze kuralı yazılı mı?
Ne yapmalıyım?
- • Değişikliği “tür” olarak sınıflandırmadan yayınlama planı yapma.
- • Freeze dönemlerini önceden ilan et (özellikle otelde yüksek sezon).
- • Rollback planını değişiklik isteğinin parçası haline getir.
2. Değişiklik Türleri: Hotfix, Minor, Major, Proje
Değişiklik türleri; onay seviyesi, test kapsamı ve yayınlama zamanlamasını belirler. Buradaki amaç ITIL teorisi değil; pratik bir sınıflandırma. Acil müdahalenin response ve resolution hedefi ise hotfix taleplerinde SLA yönetimi ile netleşir.
Hotfix (acil, dar kapsam)
- •P1/P2 incident’ı çözmek için
- •Minimal değişiklik, hızlı test, hızlı rollout
- •Yayın sonrası kısa izleme penceresi şart
Minor (planlı küçük iyileştirme)
- •Küçük UX düzeltmeleri, içerik bileşeni güncellemeleri, küçük bug fix
- •Düzenli release günleri içinde yayınlanır
- •Smoke test + geri dönüş planı
Major (yüksek risk / altyapı etkisi)
- •Büyük refactor, dependency/versiyon yükseltme, routing değişimleri
- •Daha geniş test (staging, regresyon, ölçüm doğrulama)
- •Freeze döneminde genelde yapılmaz
Proje (büyük kapsamlı teslim)
- •Yeni modül, yeni sayfa ailesi, büyük entegrasyon
- •Sprint planı, CAB benzeri onay mekanizması, phased rollout
| Change Türü | Örnekler | Risk | Test | Onay | Rollback |
|---|---|---|---|---|---|
| Hotfix | P1/P2 incident’ı çözmek için | Acil, dar kapsam | Minimal değişiklik, hızlı test | Mini CAB / hızlı onay | Hızlı geri dönüş planı |
| Minor | Küçük UX düzeltmeleri, içerik bileşeni güncellemeleri, küçük bug fix | Düşük / orta | Smoke test | Planlı onay | Geri dönüş planı |
| Major | Büyük refactor, dependency/versiyon yükseltme, routing değişimleri | Yüksek risk / altyapı etkisi | Staging, regresyon, ölçüm doğrulama | Geniş onay | Rollback planı |
| Proje | Yeni modül, yeni sayfa ailesi, büyük entegrasyon | Büyük kapsamlı teslim | Sprint planı ve kapsamlı doğrulama | CAB benzeri onay mekanizması | Phased rollout |
Soru : Hotfix, minor ve major değişiklikler nasıl ayrılır?
Cevap: Hotfix acil ve dar kapsamlıdır (incident çözümü); minor planlı küçük iyileştirmedir; major ise altyapıyı/akışı etkileyen yüksek riskli değişikliktir. Bu ayrımı ticket’tan release kararına geçiş aşamasında yapmak, her sınıf için test, onay ve yayınlama zamanını doğru tanımlamayı kolaylaştırır.
☑ Mini Check
- •Bu değişiklik hangi sınıfa giriyor (hotfix/minor/major/proje)?
- •Etkilenen kritik akışlar (otel: rezervasyon; B2B: ödeme/lead) listeli mi?
- •Yayın sonrası izleme (metrics) planı var mı?
Ne yapmalıyım?
- • Sınıfı belirlemeden “ne kadar test” yapacağını seçme.
- • Major değişiklikleri freeze dışına planla; hotfix’i dar tut.
- • Her değişiklikte “etkilenen akışlar” listesini zorunlu alan yap.
3. Release Takvimi ve Freeze Dönemleri
Release takvimi, değişiklikleri “zaman pencereleri”ne oturtur. Freeze dönemi ise riskin kabul edilemez olduğu zamanlarda major/proje değişikliklerini durdurur. Ama freeze demek “hiçbir şey yapmamak” değildir; genelde sadece hotfix kanalı açık kalır. Bu akışın güvenli kalması için dev, test, staging ve prod geçişlerini release takvimi içinde birlikte düşünmek gerekir.
Freeze tasarımı (genel prensip)
- •Freeze-1 (yüksek risk): major + proje kapalı
- •Freeze-2 (orta risk): minor sınırlı, sadece düşük riskli değişiklikler
- •Hotfix kanalı: P1/P2 için açık (CAB/mini onayla)
Otel için sezon odaklı örnek kural seti
- •Yüksek sezon öncesi (2–4 hafta): major/proje minimum, risk azaltma sprint’i
- •Yüksek sezon ortası: freeze ağırlıklı; yalnız hotfix + bazı güvenli minor
- •Sezon sonrası: major/refactor ve iyileştirme penceresi
Özellikle otel projelerinde freeze dönemi planlama, kampanya trafiği, landing page güncellemeleri ve direkt rezervasyon akışıyla birlikte ele alınmalıdır.
B2B için çeyreklik büyük release yaklaşımı
- •Minor’lar: haftalık/iki haftada bir
- •Major: çeyreklik planlı release
- •Kritik iş saatlerinde deploy kısıtı (iş saatleri dışı pencere)
Soru : Release takvimi ve freeze dönemi nasıl planlanır?
Cevap: Önce kritik dönemleri belirleyin (otel: sezon/kampanya; B2B: iş saatleri/çeyreklik release). Sonra hotfix/minor/major için yayın pencereleri tanımlayın, freeze sırasında hangi değişikliklerin yasak/izinli olduğunu yazın ve onay mekanizmasını netleştirin. Deploy sonrası release sonrası teknik SEO kontrolü yapılmadan da süreci başarılı saymayın.
Key Statistics / Data Point (yumuşatılmış): Düzenli change süreci olan projelerde “yanlış zamanda deploy” kaynaklı krizler ve rollback ihtiyacı genelde belirgin şekilde azalır; çünkü riskli değişiklikler doğru zamana taşınır.
☑ Mini Check
- •Release günleri/pencereleri ilan edildi mi?
- •Freeze döneminde “izinli değişiklik listesi” var mı?
- •Hotfix için mini onay + hızlı test kapısı tanımlı mı?
Ne yapmalıyım?
- • Freeze’i “kural seti” olarak yaz: hangi sınıf ne zaman yapılır?
- • Release takvimini proje yönetimi takvimiyle birleştir.
- • Hotfix için ayrı lane aç: hızlı ama kontrollü.
4. Change Türleri & Release Takvimi Planlama Şablonunu İndir
Change Türleri & Release Takvimi Planlama Şablonunu İndir — Yazılım / Change Management (v1.0)
Bu şablon; değişiklikleri hotfix/minor/major/proje olarak sınıflandırıp her sınıf için onay, test ve rollback kurallarını standardize eder. Sezon/kampanya hassas projelerde release takvimi ve freeze dönemlerini görünür kılar. Sonuç; “yanlış zamanda deploy” riskinin azalması ve bakım & destek sürecinin öngörülebilir hale gelmesidir.
Kim Kullanır?
Otel ve B2B projelerinde ürün/operasyon lideri + teknik lider + ajans/IT yöneticisi.
Nasıl Kullanılır?
- Her değişiklik için change request’i doldurun (sınıf + risk + etkilenen akışlar).
- Release takvimine uygun pencere seçin; freeze ise kurala göre erteleyin veya hotfix hattına alın.
- Yayın sonrası izleme ve doğrulama kapısını tamamlayıp rapora işleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Değişiklik türü seçildi: Hotfix / Minor / Major / Proje
- ▢ ✅ Etkilenen kritik akışlar yazıldı (otel: rezervasyon; B2B: ödeme/lead)
- ▢ ✅ Risk değerlendirmesi yapıldı (düşük/orta/yüksek)
- ▢ ✅ Test kapsamı tanımlandı (smoke/regresyon/ölçüm doğrulama)
- ▢ ✅ Rollback planı yazıldı (tag/release, geri alma adımları)
- ▢ ✅ Yayın penceresi seçildi (takvim + freeze kontrolü)
- ▢ ✅ Onay mekanizması (mini CAB) tamamlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •Change türleri tablosu (hotfix/minor/major/proje)
- •Release takvimi + freeze kural seti
- •Change request şablonu + onay kapıları
- •Test & rollback runbook
- •Aylık change KPI raporu
5. Otel ve B2B İçin Örnek Change Süreçleri
Değişiklik süreci; sadece dev ekibinin değil, iş tarafının da (pazarlama/operasyon) içinde olduğu bir anlaşmadır. Bu yüzden CAB (Change Advisory Board) illa “kalabalık kurul” demek değildir; çoğu projede mini CAB yeterlidir.
Mini CAB (küçük onay mekanizması)
- •Kimler: ürün/PM + teknik lider + operasyon temsilcisi (otel: pazarlama/rezervasyon)
- •Ne yapar: sınıfı onaylar, risk ve yayın penceresini belirler
- •Ne üretir: change request kaydı + rollback planı + test listesi
Otel örneği: sezon ortasında değişiklik
- •Soru: “Sezon ortasında kod değiştirsek mi, riskli mi?”
- •Cevap: major/proje kaçın; hotfix gerekiyorsa dar kapsam + doğrulama + izleme ile yayınla.
Voice (tek cümle): Sezon ortasında major değişiklikten kaçın; gerekiyorsa yalnız dar kapsamlı hotfix’i kontrollü yayınlayın.
B2B örneği: çeyreklik release
- •Major: çeyrek başında planlı
- •Minor: düzenli küçük iyileştirme günleri
- •Hotfix: P1/P2 için her zaman kontrollü kanal
☑ Mini Check
- •Change request şablonu var mı?
- •Risk değerlendirmesi ve etkilenen akışlar yazılıyor mu?
- •Rollback ve izleme penceresi tanımlı mı?
Ne yapmalıyım?
- • Mini CAB’yi kur: karar mekanizması netleşsin.
- • Otelde sezon/kampanya takvimiyle release pencerelerini hizala.
- • B2B’de iş saatleri ve müşteri SLA beklentisine göre deploy penceresi belirle.
6. Competitor Gap’i Kapatan “Pratik Release Takvimi” Yaklaşımı
Türkiye’de change management çoğu zaman ITIL teorisinde kalır. Bu rehberin farkı; hotfix/minor/major ayrımı + freeze dönemleri + mini CAB + örnek takvim yaklaşımını otel/B2B web projelerine indirgemesidir. “Kural seti” net olursa, ekipler hem daha hızlı hem daha güvenli olur.
Sonuç (özet)
Değişiklikleri hotfix/minor/major olarak ayırıp her sınıf için onay–test–rollback kurallarını yazın. Otelde sezon ve kampanya dönemlerinde freeze uygulayarak major riskini düşürün; B2B’de çeyreklik major, düzenli minor ve kontrollü hotfix hattı kurun. Deploy sonrası hata, performans ve dönüşüm farkını release etkilerinin raporlanması ile görünür kılın. Böylece bakım & destek süreci öngörülebilir ve güvenli hale gelir. Operasyonel modeli kurmak için Bakım ve Destek hizmetiyle release takviminizi kontrollü yönetin ve uygulama detayları için Bakım ve Destek hakkında sık sorulan sorular sayfasına geçin.
Bir Sonraki Adım
Sezon ve kampanya hassasiyeti olan otel ve B2B projelerinde riskli deploy’ları azaltmak isteyen ekipler için.
Sık Sorulan Sorular
Change management nedir, neden önemlidir?▾
Hotfix, minor ve major değişiklikler nasıl ayrılır?▾
Release takvimi ve freeze dönemi nasıl planlanır?▾
Otel ve B2B projelerinde change süreci nasıl tasarlanmalı?▾
Hangi değişiklikte ne kadar onay gerekir?▾
İlgili İçerikler