Skip to main content

> teknik_borç_&_özellik_yol_haritası_dengesi_(%20_kuralı)

Teknik Borç & Özellik Yol Haritası Dengesi (%20 Kuralı)

Mühendislik ve ürün liderleri, sprint kapasitesini teknik borç tasfiyesi ile yeni özellik teslimatı arasında nasıl sistematik olarak paylaştırmalıdır?

Stack: LEADERSHIP INCIDENTS STACK →Staff/Principal (L6+)tradeoff

ÖZET VE TEKNİK CEVAP

Her sprint mühendislik kapasitesinin pazarlık konusu edilemez %20'sini mimari hijyen, kütüphane güncellemeleri ve geliştirici araçları borcuna ayırarak, bileşik teknik faizin ürün geliştirme hızını sıfırlamasını engeller.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Marty Cagan'ın %20 Kuralı, sürekli bir mühendislik kapasite bütçesi kurar. Borcu çeyrekler boyunca biriktirip ardından ürün yöneticilerinden 'refactoring sprinti' dilenmek (ki bu genellikle iptal edilir veya başarısız olur) yerine, mühendislik ekibi her sprintin %20'sine koşulsuz sahip olur. Bu kapasite; sık değişen kodların iyileştirilmesine, güvenlik açığı olan paketlerin güncellenmesine, test sürelerinin kısaltılmasına ve teknik faiz büyümeden borcun ödenmesine harcanır.

2. Doğru Kullanım Senaryosu

Genişleyen kod tabanına, eskiyen kütüphanelere veya uzayan sprint sürelerine sahip tüm çevik (agile) ve sürekli teslimat (CD) ürün takımlarında zorunludur.

3. Prodüksiyon Arıza Modları

Teknik borç iflası: Her küçük değişikliğin üç eski alt sistemi bozması yüzünden özellik geliştirmenin tamamen durması; milyonlarca dolar yakan ve çoğu zaman şirketi batıran 'sıfırdan yeniden yazma' çılgınlığı.

4. Teşhis ve Telemetri Sinyalleri

Ekibe yeni mühendis katılmasına rağmen çeyrekten çeyreğe düşen teslimat hızı, mühendislerin 'o modüle dokunursak baştan yazmamız gerekir' demesi ve biriken güvenlik açığı (CVE) listeleri.

5. Önleme ve Mimari Bariyerler

70/20/10 kuralını kurumsallaştırın (%70 ürün özellikleri, %20 teknik borç/altyapı, %10 inovasyon/Ar-Ge); teknik liderlerin bu %20'lik iş listesini ürün yöneticisi onayına ihtiyaç duymadan otonom önceliklendirmesini sağlayın.

6. Mimari Ödünleşimler (Trade-offs)

Kısa vadeli teorik sprint özellik çıktısını %20 düşürme karşılığında, uzun vadede sürekli ve öngörülebilir geliştirme hızı sağlar ve yıkıcı yeniden yazma krizlerini engeller.

Vaka İncelemesi (TinyCTO Örneği)

Bir fintech girişimi yatırımcı demoları uğruna iki yıl boyunca teknik borca %0 pay ayırdı. 24. ayda, düğümlenmiş ORM spagettisi yüzünden tek bir ödeme butonu değişikliği 6 hafta sürdü. 3 ay boyunca %20 kuralının uygulanması PR teslim süresini tekrar 2 güne indirdi.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

Özel 'refactoring sprintleri' neden bir anti-patern kabul edilir?

Mühendislik bakımını iş değerinden koparır, ürün-mühendislik sürtünmesi yaratır ve sürekli temizlik alışkanlığı oluşturmada başarısız olur.
Q2

%20'lik teknik borç bütçesindeki görevleri kim önceliklendirmelidir?

Ürün Yöneticisi değil, takımdaki Teknik Lider ve Staff Mühendisler.
Q3

Martin Fowler'ın Teknik Borç Dörtgenindeki temel ayrım nedir?

Borç iki eksende ayrılır: Bilinçli vs. İstemdışı, ve İhtiyatlı vs. Pervasız.

Teknik Borç & Özellik Yol Haritası Dengesi (%20 Kuralı) — Sıkça Sorulan Sorular

Teknik borcu teknik olmayan şirket yöneticilerine nasıl anlatırsınız?

Finansal kredi metaforunu kullanın: Kestirmeden gitmek borç almak gibidir; faizini (bakımını) ödemezseniz bileşik faiz büyür ve sonunda tüm geliriniz sadece borç faizine gider.

Bir Ürün Yöneticisi %20'lik kapasite payını tanımayı reddederse ne yapılmalıdır?

Mühendislik VP'si ve CPO'ya eskalasyon yaparak şirket politikasını teyit ettirin; borç birikiminin getirdiği hız kaybını ve kesinti risklerini verilerle ortaya koyun.

%20 kuralı henüz ürün-pazar uyumu (PMF) yakalamamış erken aşama girişimler için de geçerli midir?

Erken aşama girişimler paraları bitmeden PMF bulmak için daha fazla borç alabilir; ancak ölçeklenme başladığı anda %20 kuralı derhal devreye alınmalıdır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Teknik hijyene sürekli %20 pay ayıran ekipler, iki yıllık vadede borca sıfır pay ayıran takımlara kıyasla 2.5 kat daha hızlı özellik teslim eder.
  • ▸Teknik borç sadece kötü kod değildir; sistemin mevcut tasarımı ile bugünkü iş gereksinimlerinin gerektirdiği tasarım arasındaki farktır.

Yaygın Yanılgılar

  • ✗Teknik borcun birkaç aylık tek bir büyük yeniden yazma projesiyle kalıcı olarak çözülebileceğine inanmak.

Karar Kılavuzu & Önceliklendirme

Sprint planlamasında %20'lik mühendislik bütçesini tamamen teknik liderlerin yönettiği dokunulmaz bir operasyonel vergi gibi ele alın.

Doğrulanmış Kaynaklar & Referanslar