{"id":1988,"date":"2026-06-04T03:00:44","date_gmt":"2026-06-04T03:00:44","guid":{"rendered":"https:\/\/news.jurskitech.pl\/blog\/uncategorized\/jak-realnie-mierzyc-dlug-techniczny-w-malej-firmie-wskazniki-ktore-dzialaja\/"},"modified":"2026-06-04T03:00:44","modified_gmt":"2026-06-04T03:00:44","slug":"jak-realnie-mierzyc-dlug-techniczny-w-malej-firmie-wskazniki-ktore-dzialaja","status":"publish","type":"post","link":"https:\/\/news.jurskitech.pl\/blog\/warto-wiedziec\/jak-realnie-mierzyc-dlug-techniczny-w-malej-firmie-wskazniki-ktore-dzialaja\/","title":{"rendered":"Jak realnie mierzy\u0107 d\u0142ug techniczny w ma\u0142ej firmie? Wska\u017aniki, kt\u00f3re dzia\u0142aj\u0105"},"content":{"rendered":"<h2 id=\"dugtechnicznyczytwojafirmagospacaczytylkodokadaszodsetki\">D\u0142ug techniczny \u2013 czy Twoja firma go sp\u0142aca, czy tylko dok\u0142adasz odsetki?<\/h2>\n<p>Gdy s\u0142yszysz \u201ed\u0142ug techniczny\u201d, pewnie my\u015blisz o syfie w kodzie, kt\u00f3ry kiedy\u015b trzeba b\u0119dzie posprz\u0105ta\u0107. I to prawda \u2013 ale tylko po\u0142owiczna. Bo d\u0142ug techniczny to nie tylko ba\u0142agan, to realny koszt biznesowy. Widz\u0119 to regularnie u klient\u00f3w: zesp\u00f3\u0142 sp\u0119dza 40% czasu na \u0142ataniu starego kodu zamiast na nowych funkcjach. Albo wdro\u017cenie nowego API trwa dwa tygodnie, bo \u201etrzeba najpierw przepisa\u0107 legacy\u201d.<\/p>\n<p>Problem w tym, \u017ce wi\u0119kszo\u015b\u0107 ma\u0142ych firm nie ma poj\u0119cia, jak zmierzy\u0107 ten d\u0142ug. Po prostu czuj\u0105, \u017ce \u201eco\u015b jest nie tak\u201d. A bez pomiaru nie ma zarz\u0105dzania. W tym artykule poka\u017c\u0119 Ci trzy konkretne wska\u017aniki, kt\u00f3re sam stosuj\u0119 w audytach u klient\u00f3w. Nie potrzebujesz do nich skomplikowanych narz\u0119dzi, tylko odrobiny analitycznego my\u015blenia.<\/p>\n<h2 id=\"dlaczegowikszofirmniemierzydugutechnicznegoidlaczegotobd\">Dlaczego wi\u0119kszo\u015b\u0107 firm nie mierzy d\u0142ugu technicznego (i dlaczego to b\u0142\u0105d)?<\/h2>\n<p>Zacznijmy od sedna: d\u0142ug techniczny to poj\u0119cie zapo\u017cyczone z finans\u00f3w. W coding world oznacza decyzje projektowe, kt\u00f3re s\u0105 szybsze w kr\u00f3tkim terminie, ale kosztuj\u0105 w przysz\u0142o\u015bci. Jak kredyt \u2013 bierzesz dzi\u015b, oddajesz jutro z odsetkami. Problem pojawia si\u0119, gdy odsetki zaczynaj\u0105 z\u017cera\u0107 Tw\u00f3j zysk.<\/p>\n<p>Wiele ma\u0142ych firm dzia\u0142a w trybie \u201enajpierw produkt, potem refaktor\u201d. Rozumiem to \u2013 sam tak robi\u0142em. Ale po latach widz\u0119, \u017ce to podej\u015bcie ma swoj\u0105 cen\u0119. Klient, kt\u00f3ry przyszed\u0142 do nas z aplikacj\u0105 SaaS, notowa\u0142 coraz wolniejszy rozw\u00f3j. Ka\u017cda nowa funkcja wymaga\u0142a modyfikacji w 5 miejscach, a testy regresyjne trwa\u0142y tydzie\u0144. Gdy zmierzyli\u015bmy jego d\u0142ug techniczny, okaza\u0142o si\u0119, \u017ce a\u017c 60% czasu zespo\u0142u idzie na utrzymanie i poprawki. Zamiast rozwija\u0107 produkt, gasili po\u017cary.<\/p>\n<p>Wi\u0119kszo\u015b\u0107 firm nie mierzy tego, bo nie wie jak. Albo boi si\u0119 wyniku. Albo my\u015bli, \u017ce d\u0142ug techniczny to tylko metafora. A prawda jest taka, \u017ce da si\u0119 go zmierzy\u0107 i \u2013 co wa\u017cniejsze \u2013 zarz\u0105dza\u0107 nim. Oto trzy wska\u017aniki, kt\u00f3re pokazuj\u0105 realny obraz.<\/p>\n<h2 id=\"wskanik1wspczynnikkosztwutrzymaniamaintenancecostratiomcr\">Wska\u017anik 1: Wsp\u00f3\u0142czynnik koszt\u00f3w utrzymania (Maintenance Cost Ratio \u2013 MCR)<\/h2>\n<p>To najprostszy i najbardziej wymowny wska\u017anik. MCR m\u00f3wi, jaki procent czasu zespo\u0142u idzie na utrzymanie istniej\u0105cego kodu (bugi, refaktoring, optymalizacje) w por\u00f3wnaniu z nowymi funkcjami.<\/p>\n<p><strong>Jak to zmierzy\u0107?<\/strong><\/p>\n<ul>\n<li>Zbierz dane z ostatnich 3\u20136 miesi\u0119cy (np. z Jiry, Asany, wykres\u00f3w commit\u00f3w).<\/li>\n<li>Oznacz zadania jako \u201eutrzymanie\u201d i \u201enowa funkcjonalno\u015b\u0107\u201d.<\/li>\n<li>Podziel czas po\u015bwi\u0119cony na utrzymanie przez ca\u0142kowity czas rozwoju i pomn\u00f3\u017c przez 100%.<\/li>\n<\/ul>\n<p><strong>Przyk\u0142ad:<\/strong><br \/>\nZesp\u00f3\u0142 4 os\u00f3b pracuje 160 godzin miesi\u0119cznie. Je\u015bli 80 godzin idzie na \u0142atki, refaktoring i obs\u0142ug\u0119 bug\u00f3w, MCR wynosi 50%.<\/p>\n<p><strong>Co to oznacza?<\/strong><\/p>\n<ul>\n<li>MCR &lt; 20% \u2013 jest dobrze, d\u0142ug nie z\u017cera bud\u017cetu.<\/li>\n<li>MCR 20\u201340% \u2013 ostrze\u017cenie, warto przyjrze\u0107 si\u0119 procesom.<\/li>\n<li>MCR &gt; 40% \u2013 alarm! Wi\u0119cej czasu tracisz na naprawianie ni\u017c na rozw\u00f3j.<\/li>\n<\/ul>\n<p>U jednego z klient\u00f3w (ma\u0142y e-commerce oparty na WooCommerce z customowym motywem) MCR wynosi\u0142 70%. Ka\u017cda aktualizacja wtyczki psu\u0142a integracj\u0119, a nowe funkcje by\u0142y odk\u0142adane w niesko\u0144czono\u015b\u0107. Po audycie wyodr\u0119bnili\u015bmy warstw\u0119 API i zrefaktorowali\u015bmy najgorsze fragmenty. Po 3 miesi\u0105cach MCR spad\u0142 do 30%. Oszcz\u0119dno\u015b\u0107 czasu: 40% tygodniowo.<\/p>\n<h2 id=\"wskanik2czaswprowadzeniazmianytimetoimplementtti\">Wska\u017anik 2: Czas wprowadzenia zmiany (Time to Implement \u2013 TTI)<\/h2>\n<p>TTI mierzy, ile czasu zajmuje wprowadzenie nowej, prostej funkcji \u2013 np. dodanie pola w formularzu czy zmiana koloru przycisku. Wybierz ma\u0142\u0105, powtarzaln\u0105 zmian\u0119 (np. dodanie kolumny w tabeli) i mierz czas od zg\u0142oszenia do wdro\u017cenia na produkcj\u0119.<\/p>\n<p><strong>Dlaczego to dzia\u0142a?<\/strong><br \/>\nW zdrowym kodzie taka zmiana zajmuje kilka godzin. W zad\u0142u\u017conym mo\u017ce trwa\u0107 dni, bo trzeba przejrze\u0107 20 plik\u00f3w, znale\u017a\u0107 w\u0142a\u015bciwe miejsce, a potem ba\u0107 si\u0119, \u017ce co\u015b zepsujesz.<\/p>\n<p><strong>Przyk\u0142ad:<\/strong><br \/>\nU klienta (platforma SaaS dla ma\u0142ych firm) dodanie prostego przycisku eksportu danych zajmowa\u0142o \u015brednio 3 dni. Po refaktoringu warstwy widok\u00f3w i API \u2013 3 godziny. Poniewa\u017c robili \u015brednio 4 takie zmiany miesi\u0119cznie, oszcz\u0119dzili 12 dni deweloperskich na miesi\u0105c.<\/p>\n<p><strong>Jak zinterpretowa\u0107?<\/strong><\/p>\n<ul>\n<li>TTI &lt; 1 dzie\u0144 \u2013 kod jest elastyczny.<\/li>\n<li>TTI 1\u20133 dni \u2013 umiarkowany d\u0142ug, warto poprawi\u0107 architektur\u0119.<\/li>\n<li>TTI &gt; 3 dni \u2013 powa\u017cny d\u0142ug, kt\u00f3ry hamuje rozw\u00f3j.<\/li>\n<\/ul>\n<h2 id=\"wskanik3gstodefektwdefectdensitydd\">Wska\u017anik 3: G\u0119sto\u015b\u0107 defekt\u00f3w (Defect Density \u2013 DD)<\/h2>\n<p>DD to liczba b\u0142\u0119d\u00f3w produkcyjnych na 1000 linii kodu (lub na funkcj\u0119). Im wy\u017csza, tym wi\u0119cej \u201edziur\u201d w kodzie, kt\u00f3re wymagaj\u0105 \u0142atania.<\/p>\n<p><strong>Jak mierzy\u0107?<\/strong><\/p>\n<ul>\n<li>Zlicz b\u0142\u0119dy zg\u0142oszone przez u\u017cytkownik\u00f3w w ostatnim kwartale.<\/li>\n<li>Podziel przez szacowan\u0105 liczb\u0119 linii kodu (lub liczb\u0119 funkcji).<\/li>\n<li>Wynik to DD.<\/li>\n<\/ul>\n<p><strong>Przyk\u0142ad:<\/strong><br \/>\nAplikacja ma 100 000 linii kodu i w kwartale zg\u0142oszono 50 b\u0142\u0119d\u00f3w. DD = 0,5 b\u0142\u0119du na 1000 linii. Je\u015bli po refaktoringu DD spadnie do 0,2, oznacza to popraw\u0119 jako\u015bci.<\/p>\n<p><strong>Dlaczego to wa\u017cne?<\/strong><br \/>\nWysoki DD nie tylko irytuje u\u017cytkownik\u00f3w, ale te\u017c generuje koszty wsparcia i \u0142atania. Klient z sektora fintech mia\u0142 DD na poziomie 1,2 \u2013 oznacza\u0142o to, \u017ce co miesi\u0105c tracili 20 godzin na poprawki krytycznych b\u0142\u0119d\u00f3w. Po wdro\u017ceniu test\u00f3w automatycznych i refaktoringu najgorszych modu\u0142\u00f3w DD spad\u0142 do 0,4.<\/p>\n<h2 id=\"jaktewskanikiczsiwobrazdugutechnicznego\">Jak te wska\u017aniki \u0142\u0105cz\u0105 si\u0119 w obraz d\u0142ugu technicznego?<\/h2>\n<p>Ka\u017cdy z nich patrzy z innej strony:<\/p>\n<ul>\n<li>MCR m\u00f3wi o kosztach utrzymania \u2013 ile czasu zjada stary kod.<\/li>\n<li>TTI m\u00f3wi o elastyczno\u015bci \u2013 jak szybko mo\u017cesz reagowa\u0107 na rynek.<\/li>\n<li>DD m\u00f3wi o jako\u015bci \u2013 jak bardzo kod jest podatny na b\u0142\u0119dy.<\/li>\n<\/ul>\n<p>Razem tworz\u0105 tr\u00f3jk\u0105t diagnostyczny. Je\u015bli MCR &gt; 40%, TTI &gt; 3 dni i DD &gt; 0,5 \u2013 masz powa\u017cny problem. Je\u015bli tylko jeden wska\u017anik jest podwy\u017cszony, mo\u017ce to wynika\u0107 z bie\u017c\u0105cego projektu.<\/p>\n<h2 id=\"praktycznekrokidoobnieniadugutechnicznegowmaejfirmie\">Praktyczne kroki do obni\u017cenia d\u0142ugu technicznego w ma\u0142ej firmie<\/h2>\n<p>Je\u015bli zmierzy\u0142e\u015b wska\u017aniki i wynik nie jest optymistyczny, nie panikuj. Oto co mo\u017cesz zrobi\u0107 bez zatrzymywania rozwoju:<\/p>\n<p><strong>1. Zrefaktoruj najcz\u0119\u015bciej modyfikowany kod<\/strong><br \/>\nNie pr\u00f3buj poprawi\u0107 wszystkiego naraz. Zidentyfikuj modu\u0142y, kt\u00f3re zmieniasz najcz\u0119\u015bciej (np. koszyk, panel logowania) i popraw ich architektur\u0119. To da najwi\u0119kszy zwrot z inwestycji.<\/p>\n<p><strong>2. Wprowad\u017a testy automatyczne dla krytycznych \u015bcie\u017cek<\/strong><br \/>\nBrak test\u00f3w to jedna z g\u0142\u00f3wnych przyczyn d\u0142ugu technicznego. Zacznij od test\u00f3w integracyjnych dla najwa\u017cniejszych proces\u00f3w (np. zakup w e-commerce, rejestracja u\u017cytkownika). Zobaczysz spadek DD w ci\u0105gu kilku miesi\u0119cy.<\/p>\n<p><strong>3. Ustal limit MCR<\/strong><br \/>\nUm\u00f3w si\u0119 z zespo\u0142em (lub z samym sob\u0105), \u017ce maksymalnie 30% czasu mo\u017ce i\u015b\u0107 na utrzymanie. Reszta \u2013 na nowe funkcje. Je\u015bli MCR przekracza limit, przeznacz sprint na refaktoring.<\/p>\n<p><strong>4. Mierz regularnie<\/strong><br \/>\nPostaw sobie przypomnienie co kwarta\u0142 \u2013 zmierz trzy wska\u017aniki i zanotuj. Po roku zobaczysz trend.<\/p>\n<h2 id=\"podsumowanie\">Podsumowanie<\/h2>\n<p>D\u0142ug techniczny to nie fatum, kt\u00f3re wisi nad ka\u017cdym projektem \u2013 to zjawisko, kt\u00f3rym mo\u017cna zarz\u0105dza\u0107. Klucz to przesta\u0107 go ignorowa\u0107 i zacz\u0105\u0107 mierzy\u0107. Wska\u017aniki MCR, TTI i DD to praktyczne narz\u0119dzia, kt\u00f3re mo\u017cesz wdro\u017cy\u0107 od r\u0119ki. Nie wymagaj\u0105 fancy narz\u0119dzi, tylko analizy Twojego procesu.<\/p>\n<p>Jako praktyk widz\u0119, \u017ce ma\u0142e firmy, kt\u00f3re regularnie mierz\u0105 d\u0142ug techniczny, szybciej rozwijaj\u0105 produkt, rzadziej pope\u0142niaj\u0105 b\u0142\u0119dy i lepiej reaguj\u0105 na zmiany rynku. A to przek\u0142ada si\u0119 na realne pieni\u0105dze.<\/p>\n<p>Je\u015bli potrzebujesz wsparcia w audycie technicznym swojego kodu \u2013 w JurskiTech.pl pomagamy firmom mierzy\u0107 i redukowa\u0107 d\u0142ug techniczny, \u017ceby mog\u0142y skupi\u0107 si\u0119 na rozwoju. Ale nawet je\u015bli zdecydujesz si\u0119 dzia\u0142a\u0107 samodzielnie, te trzy wska\u017aniki dadz\u0105 Ci solidny punkt wyj\u015bcia.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>D\u0142ug techniczny \u2013 czy Twoja firma go sp\u0142aca, czy tylko dok\u0142adasz odsetki? Gdy s\u0142yszysz \u201ed\u0142ug techniczny\u201d, pewnie my\u015blisz o syfie w kodzie, kt\u00f3ry kiedy\u015b trzeba b\u0119dzie posprz\u0105ta\u0107. I to prawda \u2013 ale tylko po\u0142owiczna. Bo d\u0142ug techniczny to nie tylko ba\u0142agan, to realny koszt biznesowy. Widz\u0119 to regularnie u klient\u00f3w: zesp\u00f3\u0142 sp\u0119dza 40% czasu na<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[704,435,58,570,539],"class_list":["post-1988","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-audyt-kodu","tag-dlug-techniczny","tag-koszty-it","tag-mala-firma","tag-optymalizacja-aplikacji"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1988","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=1988"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1988\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1988"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1988"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1988"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}