Dlaczego baseline = władza decyzyjna#

Wskaźniki DORA bez baseline’u są tylko ładnym dashboardem. Dopiero punkt zerowy daje liderowi argumenty inwestycyjne: ile potrwa skrócenie Lead Time, jaki budżet dotyka konkretnej zmiany, gdzie leży najtańsza dźwignia.

Tydzień 1 — instrumentacja#

1.1 Zbieranie surowych zdarzeń#

Podłącz webhooki GitHub/GitLab do prostego endpointa zapisującego zdarzenia push, pull_request, deployment oraz incident. Nie potrzebujesz jeszcze SaaS-a — wystarczy Vercel KV, Cloudflare D1 lub plik JSON na S3.

1.2 Wybór definicji#

Zdefiniuj „awarię” w sposób audytowalny. Najczęstsza heurystyka: rollback w 24h LUB hotfix wdrożony w ramach incydentu LUB deploy wprost wskazany w post-mortem.

Tydzień 2 — pierwszy odczyt#

Zlicz wartości dla rolling-window 14 dni i porównaj z benchmarkiem SMB. Nie porównuj się do „Elite” z raportu DORA dla Google — to inny ekosystem. Cel na koniec drugiego tygodnia: jedna liczba na każdą z czterech metryk i jedna hipoteza o wąskim gardle.

Tydzień 3 — pierwsza interwencja#

Wybierz jedno wąskie gardło i zaproponuj jedną zmianę z mierzalnym efektem. Najczęściej:

• Lead Time wysoki → automatyzacja code review, redukcja batch size PR-ów.
• CFR wysoki → wprowadzenie quality gate w CI (test, statyczna analiza, scan podatności).
• MTTR wysoki → runbooki + deploy preview + rollback w jednym kliknięciu.
• Deployment Frequency niski → trunk-based dev + feature flags.

Tydzień 4 — przegląd przy stole#

Zaprezentuj 4 liczby + jedną hipotezę + jedną interwencję. Zarząd ma zobaczyć, że nie kupują „dashboardu”, tylko system uczący, który po kwartale zwróci konkretną oszczędność godzin inżynierskich.

Baseline to nie cel. To początek negocjacji o tym, gdzie ulokować inżynierską godzinę.