---
name: tech-debt-triage
title: Triażowanie Długu Technicznego
description: "Systematyczny framework do oceny, kategoryzowania i priorytetyzowania długu technicznego. Tworzy inwentarz długu z oceną wpływu, szacunkami kosztów naprawy i priorytetyzowanym planem działania. Zamienia ogólnikowe „powinniśmy to zrefaktoryzować\" w konkretne decyzje: co naprawić, z czym żyć, co zaplanować i co usunąć."
category: coding
tags:
  - dług-techniczny
  - priorytetyzacja
  - refaktoryzacja
  - architektura
  - planowanie
  - zarządzanie
requires:
  - Claude
source: https://madejski.ai/pl/skilloteka/tech-debt-triage
locale: pl
license: MIT
---

# Triażowanie Długu Technicznego

## Co robi ten skill

Zamienia ogólnikowe „powinniśmy to zrefaktoryzować" w konkretne, priorytetyzowane decyzje. Tworzy inwentarz długu technicznego z analizą wpływu i jasnym planem działania.

Skill odpowiada na trzy pytania:
1. **Jaki dług faktycznie mamy?** (inwentarz)
2. **Który dług najbardziej nam szkodzi?** (priorytetyzacja)
3. **Co z tym zrobić?** (plan działania)

## Kategorie długu

| Kategoria | Opis | Przykład |
|-----------|------|---------|
| **Architektura** | Decyzje strukturalne ograniczające system | Monolit, który powinien być serwisami |
| **Design** | Organizacja kodu i naruszenia wzorców | God class, zależności cykliczne |
| **Jakość kodu** | Czytelność, duplikacja, złożoność | Plik 2000 linii, logika copy-paste |
| **Testowanie** | Brakujące lub nieadekwatne pokrycie testami | Brak testów integracyjnych, niestabilne testy |
| **Infrastruktura** | Przestarzałe zależności, brak automatyzacji | Framework sprzed 3 lat |
| **Dokumentacja** | Brakująca lub nieaktualna dokumentacja | README z początkowego commita |
| **Bezpieczeństwo** | Znane podatności jeszcze nienaprawione | Przestarzała biblioteka auth |

## Macierz oceny wpływu

Każdy element długu dostaje dwie oceny (1-5):

**Ocena bólu** — Jak bardzo to nam dziś szkodzi?
- 5: Blokuje prace nad funkcjami, powoduje incydenty
- 4: Znacząco spowalnia każdy sprint
- 3: Powoduje regularną irytację
- 2: Denerwujące, ale istnieje obejście
- 1: Teoretyczny problem, brak obecnego bólu

**Ocena ryzyka** — Jak niebezpieczne jest zostawienie tego?
- 5: Podatność bezpieczeństwa lub ryzyko utraty danych
- 4: Stabilność systemu zagrożona pod obciążeniem
- 3: Stanie się krytyczne w ciągu 3 miesięcy
- 2: Stanie się bolesne w ciągu 6 miesięcy
- 1: Niskie ryzyko, długi horyzont czasowy

**Priorytet = Ból x Ryzyko** (skala 1-25)

## Szacowanie kosztów naprawy

Dla każdego elementu oszacuj:
- **Rozmiar koszulkowy**: XS (godziny) | S (1-2 dni) | M (3-5 dni) | L (1-2 tygodnie) | XL (sprint+)
- **Ryzyko naprawy**: Jak prawdopodobne, że ta naprawa wprowadzi nowe problemy?
- **Zależności**: Co jeszcze musi się zmienić?

## Kategorie działań

Na podstawie priorytetu vs. kosztu:

| | Niski koszt | Wysoki koszt |
|---|---|---|
| **Wysoki priorytet** | **Napraw teraz** — szybkie wygrane redukujące ból | **Zaplanuj** — dedykowany sprint |
| **Niski priorytet** | **Oportunistycznie** — napraw przy okazji dotykania kodu | **Zaakceptuj** — udokumentuj i idź dalej |

Plus jedna specjalna kategoria:
- **Usuń** — kod/funkcje, których nikt nie używa. Najlepszy refaktoring to usunięcie.

## Proces

1. **Inwentaryzuj** — przeskanuj codebase, zbierz znane elementy długu od zespołu
2. **Kategoryzuj** — przypisz każdy element do kategorii długu
3. **Oceń** — oceń ból i ryzyko dla każdego elementu
4. **Szacuj** — rozmiar koszulkowy wysiłku naprawy
5. **Priorytetyzuj** — posortuj po wyniku priorytetu, pogrupuj w kategorie działań
6. **Zaplanuj** — stwórz konkretny harmonogram: co w tym sprincie, następnym, w tym kwartale

## Format wyjścia

```markdown
## Triażowanie Długu Technicznego: {nazwa projektu}

### Inwentarz długu

| # | Element | Kategoria | Ból | Ryzyko | Priorytet | Koszt | Działanie |
|---|---------|-----------|-----|--------|-----------|-------|-----------|
| 1 | ... | Architektura | 5 | 4 | 20 | L | Zaplanuj |
| 2 | ... | Bezpieczeństwo | 3 | 5 | 15 | S | Napraw teraz |

### Napraw teraz (ten sprint)
- Element 2: {opis + konkretne podejście do naprawy}

### Zaplanuj (dedykowany wysiłek)
- Element 1: {opis + zakres + sugerowany harmonogram}

### Oportunistycznie (przy dotykaniu tego kodu)
- ...

### Zaakceptuj (udokumentuj i idź dalej)
- ...

### Kandydaci do usunięcia
- ...
```

## Antywzorce

- Listowanie długu bez oceniania go (wszystko wydaje się równie ważne)
- Traktowanie całego długu jako równy priorytet
- Refaktoryzowanie bez mierzenia wpływu
- Perfekcjonizm — z częścią długu da się żyć
- Ignorowanie opcji „usuń" — nieużywany kod to najgorszy dług