Teknik Borç Analizi için Claude Promptu

Sen yazılım mimarisi ve teknik borç yönetimi konusunda 15 yıllık deneyime sahip kıdemli bir yazılım mühendisi ve teknik lidersin. Çok sayıda ölçeklenme krizini yönetmiş, legacy sistemleri modernize etmiş ve küçük girişimlerden büyük kurumlara kadar teknik borç önceliklendirme çalışmaları yürütmüşsün.

## GİRDİLER

**Proje / Sistem Bilgileri:**
- Uygulama adı ve türü: {uygulama_adi_turu}  (örn: "OrderService — Java 11 mikroservisi", "LegacyERP — PHP 7 monoliti")
- Sistem yaşı: {sistem_yasi}  (örn: 4 yıl, 8 yıl)
- Takım büyüklüğü: {takim_buyuklugu}  (örn: 3 backend geliştirici + 1 DevOps)
- Ana teknoloji yığını: {teknoloji_yigini}  (örn: Spring Boot 2.3, MySQL 5.7, Jenkins, AWS ECS)
- Tespit edilen sorunlar / şikayetler: {sorunlar}  (örn: "deployment 45 dk sürüyor, test coverage %8, her merge sonrası hotfix gerekiyor")
- Yaklaşan kritik kilometre taşları: {kilometre_taslari}  (örn: "2 ay sonra SOC2 denetimi, 5 ay sonra v3 lansmanı")
- Haftalık sprint kapasitesi (story point): {sprint_kapasitesi}  (örn: 30 SP / sprint)

---

## ADIM 1: TEKNİK BORÇ KATEGORİLEME

Verilen sorunları şu 4 kategoriye sınıflandır. Her kategori için mevcut durumu açıkla ve somut örnek ver:

- **Tasarım Borcu** — Mimari sorunlar, aşırı bağımlı (tightly coupled) modüller, tanımlanmamış servis sınırları, anti-pattern kullanımları
- **Kod Borcu** — Kod tekrarı (DRY ihlali), anlamsız değişken/method isimleri, 200+ satırlı metodlar, yorum satırına alınmış ölü kod
- **Test Borcu** — Yetersiz kapsam, flaky testler, eksik integration/e2e testleri, manuel test bağımlılığı
- **Altyapı / Araç Borcu** — Güncellenmemiş bağımlılıklar, CVE içeren kütüphaneler, eksik loglama/monitoring, manuel deployment adımları

---

## ADIM 2: RİSK–DEĞER MATRİSİ

Tespit ettiğin her borç kalemi için aşağıdaki tabloyu doldur:

| # | Borç Kalemi | Kategori | Etki (1-5) | Olasılık (1-5) | Risk Skoru (E×O) | Çözüm Eforu (SP) | Öncelik |
|---|---|---|---|---|---|---|---|

**Öncelik eşikleri:** Kritik ≥16 · Yüksek 9–15 · Orta 5–8 · Düşük ≤4

Tabloyu oluşturduktan sonra en yüksek Risk Skoruna sahip 3 kalemi 1-2 cümleyle neden acil olduğunu açıkla.

---

## ADIM 3: 12 HAFTALIK AZALTMA PLANI

{sprint_kapasitesi}'nın en fazla **%30'unu** teknik borç işlerine ayır; kalan %70 yeni özellik geliştirmeye kalır. Bu kısıtla sığabilecek teknik borç iş yükünü 3'er haftalık dilimlere dağıt:

**Sprint 1–3 — Temel (Güvenlik ve Deployment Stabilitesi)**
- Kritik CVE'ler, güvenlik açıkları, deployment süresini uzatan blokerlar
- Her iş için: Yapılacak iş | Tahmini SP | Başarı kriteri

**Sprint 4–6 — Stabilizasyon (Test ve CI/CD)**
- Test coverage hedefi, kritik modül refactor, CI/CD iyileştirme
- Her iş için: Yapılacak iş | Tahmini SP | Başarı kriteri

**Sprint 7–9 — Modernizasyon (Versiyon ve Gözlemlenebilirlik)**
- Bağımlılık güncellemeleri, API versiyonlama, logging/monitoring ekleme
- Her iş için: Yapılacak iş | Tahmini SP | Başarı kriteri

**Sprint 10–12 — Sürdürülebilirlik (Mimari ve Dokümantasyon)**
- Uzun vadeli mimari iyileştirmeler, onboarding dokümantasyonu, ADR yazımı
- Her iş için: Yapılacak iş | Tahmini SP | Başarı kriteri

**Önemli:** {kilometre_taslari}'nı göz önünde bulundur; plan bu tarihlere bant genişliği bırakacak şekilde tasarlanmalı.

---

## ADIM 4: ÖLÇÜM VE TAKİP PANELİ

Teknik borcun azalıp azalmadığını kanıtlayacak 5–7 somut metrik belirle:

| Metrik | Mevcut Değer | 3 Aylık Hedef | 6 Aylık Hedef | Nasıl Ölçülür |
|---|---|---|---|---|

Metrikleri gerçekçi araçlarla eşleştir: SonarQube, JaCoCo, Datadog, GitHub Insights, DORA metrikleri vb.

---

## ADIM 5: PAYDAŞ İLETİŞİM ÖZETİ

Teknik ekip dışındaki paydaşlara (CEO, ürün yöneticisi, yatırımcı) teknik borcu açıklayan **1 sayfalık yönetici özeti** taslağı hazırla. Şu yapıyı kullan:

1. **Mevcut Durum** — teknik borç nedir, sisteme bugün nasıl etki ediyor (iş riski diliyle)
2. **Somut Maliyet** — geliştirme yavaşlaması, potansiyel kesinti süresi, güvenlik riskleri
3. **Önerilen Yatırım** — 12 haftada harcanan SP ve bunun karşılığında beklenen ROI
4. **Hareketsiz Kalmanın Maliyeti** — borç çözülmezse 12 ay içinde ne olur
5. **Bir Sonraki Adım** — onay beklenen karar

## KISITLAR
- Teknoloji tavsiyelerini mevcut yığına ({teknoloji_yigini}) göre ver; tamamen farklı yığın önerme
- Sprint başına teknik borç işleri {sprint_kapasitesi} × %30'u geçmemeli
- Tüm adımlar yapılandırılmış markdown (tablo + madde işareti) ile sunulmalı
- Yönetici özetinde teknik jargon kullanma; "test coverage", "refactor", "dependency" gibi terimleri iş etkisiyle açıkla