1. Bakım Roadmap’i Nedir?
Bakım roadmap’i; sistemin sürdürülebilirliğini korumak için planlanan işleri görünür hale getirir: güvenlik yamaları, performans iyileştirmeleri, teknik borç eritme, izleme/runbook, refactor ve kritik akış testleri. Ürün roadmap’i ise “değer üreten özellikleri” planlar. İkisi ayrı yönetilirse, ekip iki farklı dünyada koşar; aynı dünyada planlanırsa denge kurulur. Bu nedenle ürün roadmap’i ile teknik bakım hizalama, web ve yazılım operasyonlarında stratejik planlamanın parçası olarak ele alınmalıdır.
Soru : Bakım roadmap’i nedir, ürün roadmap’inden farkı nedir?
Cevap: Ürün roadmap’i yeni özellik ve iş hedeflerini; bakım roadmap’i ise sürdürülebilirlik, risk azaltma ve teknik borç önceliklendirme dahil teknik bakım işlerini planlar. Fark; çıktının “yeni özellik” değil “süreklilik ve hız” olmasıdır.
Ne yapmalıyım?
- • Bakımı roadmap’te ayrı lane olarak görünür yap.
- • Bakım kalemlerini kategoriye ayır (security/perf/tech debt/SEO/ops).
- • Bakımın değerini KPI ile ifade et (incident, hız, CWV, dönüşüm).
2. Ürün Roadmap’i ile Çakışmalar
Çakışma genelde iki anda patlar: (1) kritik kampanya/sezon, (2) büyük release/major değişiklik. Bakım görünmezse, bu dönemlerde “yapmayalım” denir ve borç daha da büyür.
Çakışma türleri
- •Zaman çakışması: aynı haftaya feature + major bakım
- •Kapsam çakışması: aynı modülde hem feature hem refactor
- •Risk çakışması: sezon ortasında kritik altyapı değişikliği
Mini örnek (otel): Sezon öncesi kampanya landing’leri hazırlanırken, CWV düşüklüğü ve rezervasyon akışı riskleri teknik SEO bakım backlog’u içinde görünmüyorsa “sonra” denir; sezonda kriz ihtimali yükselir.
Mini örnek (B2B): Çeyreklik ürün release’i sırasında dependency upgrade ertelenirse, bir sonraki çeyrekte major upgrade “big bang”e döner.
Ne yapmalıyım?
- • Kritik dönemlerde bakım lane’ini “risk azaltma” odaklı tut.
- • Aynı modülde feature + refactor’ı parçalara böl, sıralandır.
- • Çakışma kararını “kimin sesi yüksek” değil “risk matrisi” ile ver.
3. Kapasite Planlama: Feature vs Maintenance
Asıl dönüşüm burada olur: bakımın “boşlukta” değil, kapasite yüzdesiyle planlanması. En pratik yaklaşım; ekip kapasitesini ikiye ayırmaktır: Feature lane ve Maintenance lane. Özellikle feature ve maintenance kapasite planlama kararı iç ekip, dış kaynak veya hibrit bakım modeline göre farklılaşabilir.
Kapasite yüzdesi nasıl seçilir?
- •Düşük risk / olgun sistem: %80 feature / %20 bakım
- •Orta risk / büyüyen sistem: %70 feature / %30 bakım
- •Yüksek risk / sık incident: %50–60 feature / %40–50 bakım (kısa dönem)
Varsayım: Çoğu otel/B2B canlı web projesinde başlangıç için %70/%30 dengesi uygulanabilir; sonra KPI ile kalibre edilir.
| Dönem | Feature % | Maintenance % | Bakım Odakları | Not |
|---|---|---|---|---|
| Normal dönem | 70 | 30 | tech debt, perf, security | KPI ile kalibre |
| Sezon öncesi (otel) | 60 | 40 | load test, funnel test, hardening | risk azaltma |
| Sezon ortası (otel) | 80 | 20 | hotfix + düşük risk bakım | change freeze yaklaşımı |
| Çeyrek başı (B2B) | 65 | 35 | upgrade/refactor paketi | planlı bakım |
| Çeyrek ortası (B2B) | 75 | 25 | küçük bakım + izleme | stabilizasyon |
Ne yapmalıyım?
- • Kapasiteyi yüzdeyle sabitle; her sprint’te aynı kural.
- • Bakım lane’ini kategori bazlı dağıt (ör. security %30, perf %30, debt %40).
- • 90 günde bir kalibrasyon yap (incident/hız trendi).
4. Otel ve B2B İçin Yıllık Yol Haritası Örneği
Yıllık plan, bakımın “kaçınılmaz” olduğunu yönetim diline çevirir. Otelde sezon ritmi; B2B’de çeyreklik release ritmi belirleyicidir. Bu ritmi otel projelerinde roadmap alignment yaklaşımıyla kampanya ve rezervasyon hedeflerine bağlamak, bakım bloklarının ertelenmesini zorlaştırır.
Otel: sezon bloklarıyla bakım
- •Q1: sezon öncesi checkup (performans, funnel, entegrasyon, güvenlik)
- •Q2–Q3: yüksek sezon → düşük risk bakım + hızlı hotfix lane
- •Q4: büyük iyileştirme penceresi (refactor, büyük upgrade, borç eritme)
B2B: çeyreklik bakım paketleri
- •Her çeyrekte 1 “iyileştirme paketi”: dependency upgrade + refactor + izleme
- •Ay bazında: küçük bakım işleri + teknik borç register pay-down
- •Kritik müşteri dönemlerinde change freeze/planlı release
Key Statistics / Data Point (yumuşatılmış): Roadmap’inde bakım blokları olan ekiplerde, teknik borç ve “acil yangın” sayısının orta vadede azalması daha sık raporlanır; çünkü riskler planlı şekilde eritilir. Bu ilerlemeyi bakım KPI’ları ve roadmap raporlama disipliniyle görünür kılmak karar kalitesini artırır.
Ne yapmalıyım?
- • Otelde sezon öncesi bakım bloklarını kilitle (tarihle).
- • B2B’de her çeyreğe “bakım paketi” koy (dependency + refactor + ops).
- • Birleşik timeline’ı paydaşlarla düzenli güncelle (aylık).
5. Yönetimle Beklenti Yönetimi
“Patron hep yeni özellik istiyor” cümlesi, genelde bakımın değerinin doğru anlatılmamasından kaynaklanır. Bakımı “teknik ekip istedi” diye değil; risk, gelir ve hız diliyle konuşmak gerekir.
Voice: “Patron hep yeni özellik istiyor, bakıma nasıl alan açarım?”
Kısa cevap: Ürün ve bakım roadmap’ini aynı timeline’da göster, bakım için sabit kapasite yüzdesi belirle ve bunu feature maintenance kapasite raporlaması ile düzenli olarak görünür kıl.
Yönetim sunumu için 1 sayfa şablon
- •Bu çeyrek: feature hedefleri + bakım hedefleri
- •Risk haritası (en kritik 3 risk)
- •KPI trendi (incident, hız, CWV, dönüşüm)
- •Onay isteyen kararlar (kapasite yüzdesi, bakım blok tarihleri)
Ne yapmalıyım?
- • Bakım dilini “risk ve gelir”e çevir (özellikle otelde sezon).
- • Kapasite yüzdesini yönetimle “kural” olarak anlaş.
- • Her ay kısa raporla: kapanan borç/iyileşen KPI → güveni büyüt.
6. Bakım + Feature Roadmap & Kapasite Planlama Şablonunu İndir — Yazılım / Roadmap Hizalama (v1.0)
Bakım + Feature Roadmap & Kapasite Planlama Şablonunu İndir — Yazılım / Roadmap Hizalama (v1.0)
Bu şablon; ürün ve bakım işlerini tek backlog’ta iki lane (feature/maintenance) olarak planlamanıza, kapasite yüzdelerini dönem bazlı belirlemenize ve sezon/çeyrek bloklarıyla roadmap’i öngörülebilir hale getirmenize yardımcı olur. Yönetimle beklenti yönetimini KPI ve risk diliyle yapmayı kolaylaştırır. Otel (sezon) ve B2B (çeyreklik release) ritimlerine uyarlanır.
Kim Kullanır?
Ürün/operasyon lideri + teknik lider + ajans PM (yönetim onayıyla planlar).
Nasıl Kullanılır?
- Tek backlog’u feature ve maintenance olarak etiketle.
- Dönem bazlı kapasite yüzdesi seç ve timeline’a yerleştir.
- Her ay KPI trendi ve risklerle planı güncelle; yönetimle paylaş.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Feature/maintenance lane ayrımı yapıldı
- ▢ ✅ Kapasite yüzdesi yazıldı ve onaylandı
- ▢ ✅ Sezon/çeyrek blokları timeline’a işlendi
- ▢ ✅ Top 3 risk ve bakım önlemleri yazıldı
- ▢ ✅ KPI raporu ve iletişim ritmi belirlendi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Kontrol listesi
- •Feature/maintenance lane ayrımı yapıldı
- •Kapasite yüzdesi yazıldı ve onaylandı
- •Sezon/çeyrek blokları timeline’a işlendi
- •Top 3 risk ve bakım önlemleri yazıldı
- •KPI raporu ve iletişim ritmi belirlendi
7. Competitor Gap’i Kapatan “Roadmap Hizalama Modeli”
Pek çok ekip bakım ve ürün roadmap’ini ayrı yürütür, sonra da iki taraf birbirini suçlar: “özellik gecikti” / “bakım yapılmadı.” Bu yazının farkı; tek backlog + iki lane + kapasite yüzdesi + sezon/çeyrek blokları + yönetim ritmini pratik bir model olarak vermesidir. Böylece tartışma “hissettim”den “planladık ve ölçtük”e taşınır. Bu modeli düzenli sürece çevirmek için Bakım ve Destek hizmetiyle roadmap alignment sürecinizi netleştirin; kapsam ve işleyiş soruları için Bakım ve Destek hakkında sık sorulan sorular sayfasına göz atabilirsiniz.
Bir Sonraki Adım
Feature geliştirme ile bakım/teknik borç işlerini aynı timeline’da dengelemek isteyen otel, ajans ve B2B ekipleri için.
Sık Sorulan Sorular
Bakım roadmap’i nedir, ürün roadmap’inden farkı nedir?▾
Feature vs bakım kapasitesini nasıl dengelemeliyim?▾
Otel ve B2B projelerinde yıllık bakım yol haritası nasıl hazırlanır?▾
Yönetimle bakım işlerini nasıl konuşmalıyım?▾
Tek backlog mu, ayrı backlog mu?▾
İlgili İçerikler