Ile naprawdę kosztuje bug w produkcji i czemu zaniżasz tę liczbę

Jeśli zapytasz w firmie, ile kosztuje bug w produkcji, najczęściej usłyszysz odpowiedź w stylu: kilka godzin developera, jeden sprint, jeden hotfix, czasem plus support. To brzmi rozsądnie, bo jest policzalne, bliskie zespołowi IT i da się to wpisać do tabelki. Tylko że to nie jest koszt buga. To jest koszt naprawy kodu. A bug w produkcji rzadko jest jednym zdarzeniem, które zaczyna się błędem i kończy commitem. To sekwencja konsekwencji rozlana po całej organizacji: od obsługi klienta, przez marketing i sprzedaż, po reputację i decyzje zarządcze. Kod jest tylko początkiem rachunku.

CloudQA w raporcie o kosztach błędów pokazuje skalę problemu na poziomie makro, wskazując globalny koszt błędów i niskiej jakości oprogramowania w bilionach dolarów oraz to, że pojedyncze defekty w produkcji potrafią kosztować setki tysięcy dolarów w zależności od wpływu. A mimo to w większości firm nadal liczy się tylko to, co najłatwiejsze do policzenia. W efekcie prawie każdy zaniża koszt buga i to dramatycznie.

Poniżej rozkładam to na czynniki pierwsze. Bez moralizowania. Z konkretnymi mechanizmami, które sprawiają, że rachunek zawsze jest większy, niż Ci się wydaje.

Dlaczego wszyscy liczą tylko koszt fixa

Najczęstszy błąd w liczeniu kosztu buga polega na tym, że patrzymy wyłącznie na koszt techniczny. Ile godzin zajęło znalezienie problemu. Ile czasu poświęcił developer. Ile trwało wdrożenie poprawki. To są koszty widoczne, łatwe do wpisania do Excela i względnie bezpieczne politycznie, bo mieszczą się w świecie IT. Da się je policzyć bez rozmowy z biznesem, bez dotykania wrażliwych tematów typu utracony przychód czy churn. I właśnie dlatego firmy tak lubią ten model. Jest wygodny, bo nie wymaga dyskusji o tym, co boli najbardziej.

Jest też drugi powód, bardziej ludzki. Koszt fixa to koszt, nad którym ktoś ma kontrolę. Developer, zespół, sprint, godziny, ticket. To jest świat, w którym da się powiedzieć zrobione. Natomiast koszt utraconych transakcji, spadku konwersji czy odpływu klientów jest niekomfortowy, bo pokazuje, że błąd żyje poza IT i robi rzeczy, których nie da się już cofnąć. Tego nikt nie chce słyszeć w trakcie incident calla. Wszyscy chcą naprawić i wrócić do pracy. Problem w tym, że firma naprawia kod, ale koszt już się wydarzył.

Do tego dochodzi jeszcze jeden mechanizm, który w praktyce robi ogromną różnicę. W wielu organizacjach koszty są porozrzucane w silosach. IT widzi czas dewelopera. Support widzi wzrost ticketów. Marketing widzi spadek konwersji. Sprzedaż widzi utracone leady. Finanse widzą wynik na koniec miesiąca. Nikt nie widzi całości w jednym miejscu, więc naturalnie wszyscy widzą tylko swoją część. A skoro nikt nie widzi całości, to domyślnie wygrywa ta najłatwiejsza do policzenia, czyli koszt fixa.

I tu dochodzimy do tego, dlaczego ta liczba jest prawie zawsze zaniżona. Bo koszt fixa jest tylko jednym elementem rachunku, często najmniejszym. Lepszy model myślenia brzmi tak. Fix to koszt wewnętrzny. Produkcja generuje koszt zewnętrzny. I koszt zewnętrzny jest zwykle większy, bo dotyka klientów, przychodu i reputacji.

BetterQA opisuje znaną zasadę 1 10 100, czyli wzrost kosztu naprawy defektu w zależności od momentu wykrycia. Ten sam błąd wykryty wcześnie kosztuje ułamek tego, co kosztuje w produkcji, bo w produkcji dochodzą hotfixy, rollbacki, komunikacja, support i strata reputacji. (betterqa.co) Z perspektywy zarządu to nie jest ciekawostka o procesie. To mechanizm ekonomiczny. Im później błąd wyjdzie, tym więcej ludzi i działów zaczyna pracować nad jego skutkami. Właśnie dlatego tak często słyszysz, że bug kosztował kilka godzin, a firma przez ten sam bug straciła dużo więcej, tylko nikt tego nie zsumował.

Jeśli chcesz najprostszy test, czy u Ciebie też tak jest, zapytaj o jedną rzecz. Ile osób było zaangażowanych w obsługę buga w produkcji, nie tylko w jego naprawę. Jeśli odpowiedź brzmi więcej niż trzy role, to koszt fixa już dawno przestał być głównym kosztem.

Produkcja to najdroższe środowisko testowe świata

W momencie, gdy bug trafia na produkcję, przestaje być problemem QA. Staje się problemem całej firmy. I to jest moment, w którym koszt zaczyna się mnożyć, nawet jeśli sam fix jest prosty. Bo teraz nie naprawiasz tylko kodu. Naprawiasz konsekwencje.

Support zaczyna odbierać zgłoszenia i każda rozmowa ma swój czas, swoje emocje i swoją cenę. Customer Success tłumaczy się klientom i obiecuje terminy, które potem trzeba dotrzymać. Marketing widzi spadek konwersji i zaczyna kompensować rabatami, choć problem nie jest marketingowy. Sprzedaż słyszy wróćcie, jak będzie działać, a lead, który był gorący, nagle stygnie. Zespół developerski przerywa pracę nad roadmapą, bo ktoś musi gasić. Liderzy robią incident calle, aktualizacje statusów, postmortem. Zarząd zaczyna dostawać wiadomości, których nikt nie lubi, i zadaje pytania, na które nikt nie ma gotowej odpowiedzi.

I tu wchodzi rzecz najbardziej niewygodna. Koszty pozatechniczne prawie nigdy nie są przypisywane do incydentu jakościowego. Zostają rozlane po budżetach, po działach i po emocjach. W praktyce firma płaci, ale formalnie nie widzi rachunku w jednym miejscu. A jeśli nie widzi, to podejmuje kolejne decyzje w oparciu o zaniżone liczby, zwykle redukując inwestycje w jakość, bo wygląda to jak oszczędność.

CISQ pokazuje ogromną skalę ekonomiczną kosztu niskiej jakości oprogramowania i zwraca uwagę, że organizacje, które mają lepszą widoczność i kontrolę nad jakością oraz długiem technicznym, potrafią znacząco redukować koszty. (it-cisq.org) To jest dokładnie to. Widoczność nie jest ozdobą. Widoczność jest dźwignią finansową. Jeśli widzisz, ile kosztuje incydent, możesz uzasadnić inwestycję, która go redukuje. Jeśli tego nie widzisz, zostajesz z intuicją, a intuicja w budżecie przegrywa.

Warto też dodać, że produkcja jest najdroższym środowiskiem testowym nie tylko dlatego, że jest publiczna. Jest najdroższa, bo jest pełna zmiennych, których nie kontrolujesz. Prawdziwy ruch, prawdziwe urządzenia, prawdziwe integracje, realne obciążenie, realne dane, realne zachowania użytkowników. Każda minuta błędu dzieje się w świecie, w którym ktoś próbuje kupić, zapłacić, zalogować się, podpisać umowę albo wykonać operację. I jeśli mu się nie udaje, firma płaci, niezależnie od tego, czy ktoś zdążył założyć ticket.

Najbardziej niedoszacowany element: klient, który po prostu odchodzi

Najbardziej zdradliwy koszt buga w produkcji to churn, ale nie ten spektakularny, gdzie klient krzyczy, robi reklamację i domaga się rekompensaty. Ten cichy. Klient, który napotyka błąd, traci zaufanie i nic nie mówi. Nie dlatego, że jest zadowolony. Dlatego, że nie ma energii. W e commerce to jest brutalne, bo klient w checkout ma najniższą tolerancję na chaos. Jeśli płatność nie przechodzi, jeśli koszyk znika, jeśli formularz krzyczy bez sensu, klient nie pisze maila. On idzie do konkurencji. W SaaS mechanizm jest podobny, tylko wolniejszy. Błąd w krytycznej funkcji powoduje, że zespół klienta zaczyna szukać alternatywy. Nawet jeśli kontrakt jeszcze trwa, decyzja mentalna często zapada już wtedy. A potem przy pierwszej okazji pojawia się rezygnacja albo renegocjacja w dół.

Najgorsze jest to, że tego kosztu prawie nikt nie przypina do konkretnego defektu, bo churn jest rozłożony w czasie i rzadko ma metkę. W danych widzisz odpływ, ale nie widzisz, że zaczęło się od dwóch fatalnych doświadczeń w jednym tygodniu. W callach sprzedażowych słyszysz za drogo albo wybraliśmy kogoś innego, ale rzadko usłyszysz nie ufamy, bo coś nie działało. Klient nie ma interesu, żeby robić Ci analizę jakości. On ma interes, żeby mieć działający produkt.

Dlatego bug w krytycznej ścieżce to nie tylko koszt naprawy. To koszt utraty zaufania. A zaufanie jest w IT walutą. Jeśli je tracisz, płacisz później wyższym CAC, większym rabatem, dłuższym cyklem sprzedaży i mniejszą skłonnością klientów do powrotu. I to jest powód, dla którego prawdziwy koszt buga w produkcji prawie zawsze jest większy, niż liczba, którą masz w głowie.

Jeśli chcesz to mierzyć bardziej konkretnie, najprostszy start to powiązać incydenty jakościowe z metrykami zachowania użytkowników, na przykład spadkiem konwersji w oknie czasowym incydentu, wzrostem refundów, wzrostem ticketów i odsetkiem użytkowników, którzy nie wrócili w kolejnych dniach. Nawet prosta korelacja potrafi pokazać, że klient, który po prostu odchodzi, jest najdroższą częścią rachunku.

NIST i najboleśniejsza statystyka o jakości

NIST w materiale o ekonomicznych skutkach niedostatecznej infrastruktury testowej wskazuje, że duża część defektów jest wykrywana dopiero downstream, a więc późno, co generuje duże koszty ekonomiczne. W praktyce w wielu firmach oznacza to jedno: użytkownik jest Twoim testerem końcowym, nawet jeśli nie chcesz tego przyznać. A gdy użytkownik znajduje błąd, koszt jest zawsze większy, bo błąd ma już skutki biznesowe.

To jest powód, dla którego firmy tak często zaniżają koszt buga. One widzą tylko naprawę, a nie widzą, że w tym samym czasie użytkownik już zapłacił cenę w postaci frustracji, przerwanego procesu albo utraconej transakcji.

Kiedy bug staje się incydentem bezpieczeństwa i wtedy rachunek nie ma sufitu

Jest jeszcze jedna kategoria bugów, które potrafią zabić budżet jednym ruchem. To błędy, które prowadzą do incydentów bezpieczeństwa. CERT Orange Polska pokazuje w raporcie za 2024 rok skalę zdarzeń i zagrożeń oraz to, jak istotnym elementem krajobrazu ryzyka są problemy wynikające z błędów i słabości po stronie oprogramowania.

A raport IBM o koszcie naruszeń danych pokazuje, że średnie koszty incydentów liczone są globalnie w milionach dolarów, a koszt zależy między innymi od szybkości wykrycia i opanowania zdarzenia. Jeśli bug ma wymiar bezpieczeństwa, to liczenie go jako kilku godzin developera jest jak liczenie pożaru jako kosztu zapałek.

Płatności i te dwa procent, które wyglądają jak drobiazg, a niszczą marżę

W e commerce jest jeszcze jeden klasyk niedoszacowania. Błędy i przestoje w płatnościach. Kiedy płatność nie przechodzi, firma najczęściej widzi po prostu spadek konwersji. Rzadko widzi to jako konkretny koszt jakości.

Materiały przywołujące wnioski z raportów o rynku płatności wskazują, że przestoje i fraudy potrafią kosztować firmy średnio około 2 procent przychodów. Dla wielu firm to jest większa kwota niż cały roczny budżet QA. Tylko że nie wygląda jak QA, bo wpada do worka pod nazwą rynek, sezon, kampanie, zachowanie klientów.

Efekt domina, którego nikt nie liczy, bo nie da się go łatwo przypisać

Bug w produkcji bardzo rzadko kończy się jednym fixem. Często uruchamia efekt domina: zespół przestaje pracować nad roadmapą, bo gasi. Feature, który miał przynieść przychód, wpada do kolejnego kwartału. Marketing wstrzymuje kampanię. Sprzedaż robi się ostrożniejsza. Organizacja zaczyna działać defensywnie. Te koszty są trudne do policzenia, ale są absolutnie realne.

To jest też miejsce, w którym widać, czemu firmy zaniżają koszt bugów systemowo. Nie dlatego, że chcą oszukać. Dlatego, że nie mają modelu, który obejmuje koszty alternatywne i koszty rozlane między działy.

Jak policzyć koszt buga uczciwie, bez udawania i bez magii

Uczciwe liczenie kosztu buga zaczyna się od zmiany pytania. To nie jest pytanie: ile kosztował fix. To jest pytanie: co się wydarzyło od momentu, gdy bug dotknął klienta do momentu, gdy firma wróciła do normalnego rytmu. I normalny rytm to ważne słowo. Bo czasem poprawka jest na produkcji po dwóch godzinach, ale organizacja jeszcze przez dwa tygodnie żyje w cieniu incydentu, odpowiada na maile, gasi wątpliwości klientów, negocjuje rekompensaty, robi dodatkowe kontrole i wydłuża release. To też jest koszt, tylko że już nie wygląda jak bug. Wygląda jak praca.

Najlepsze podejście jest zaskakująco proste. Nie próbujesz udawać księgowego od razu. Budujesz model, który jest wystarczająco dobry, żeby podejmować decyzje. A potem go doszlifowujesz. W praktyce potrzebujesz trzech rzeczy: jednej definicji incydentu jakościowego, jednego sposobu przypisania go do czasu i przychodu oraz jednej tabeli, którą umiesz wypełnić w 15 minut po post mortem.

Zacznij od tego, co naprawdę dzieje się w firmie, gdy bug trafia na produkcję. W większości przypadków pojawia się pięć koszyków kosztów. One prawie zawsze istnieją, niezależnie od branży. Różni się tylko proporcja.

Koszt techniczny

Tu wchodzą elementy, które IT ma pod kontrolą i które najczęściej są jedyną częścią liczoną w firmach. Diagnoza, fix, review, wdrożenie, rollback, hotfixy, dodatkowe testy, odtworzenie danych, przerwane prace zespołu. I to przerwanie jest kluczowe, bo to jest koszt, którego nikt nie wpisuje do ticketu. Jeśli pięć osób miało robić roadmapę, a przez dwa dni robiło triage, to koszt nie jest tylko w roboczogodzinach. Koszt jest w tym, że feature, który miał dać wartość, przesuwa się w czasie.

Jak to policzyć praktycznie, bez filozofii. Liczysz liczbę osób zaangażowanych oraz liczbę godzin w dwóch kategoriach: gaszenie i naprawa, a potem mnożysz przez uśredniony koszt godziny, który przyjmujesz konsekwentnie. Nie musisz mieć idealnej stawki. Musisz mieć stały model.

Koszt operacyjny

Tu wchodzą koszty, które dzieją się poza IT, a które niemal zawsze są większe niż się wydaje. Support, customer success, obsługa zwrotów, obsługa reklamacji, komunikacja kryzysowa, moderacja opinii, obsługa social media, dodatkowe zgłoszenia do dostawców, dodatkowe zgłoszenia do operatorów płatności, wszystko to, co ludzie robią, gdy klient pyta co się dzieje.

Jak to policzyć prosto. Liczysz liczbę ticketów ponad baseline w oknie incydentu, mnożysz przez średni koszt obsługi jednego zgłoszenia, dodajesz czas customer success na rozmowy oraz czas managerów, bo to też jest praca. Jeśli nie masz kosztu ticketu, weź uśredniony czas obsługi i pomnóż przez koszt roboczogodziny. Nie jest to idealne, ale już robi różnicę.

Koszt przychodu

To jest część, którą firmy najczęściej pomijają, bo jest niewygodna. A jednocześnie to jest część, która robi największy rachunek przy błędach w krytycznych ścieżkach, zwłaszcza w e commerce, fintech i SaaS.

W tym koszyku masz utracone transakcje, spadek konwersji, downtime, spadek skuteczności płatności, wzrost chargebacków, wzrost refundów, wzrost porzuceń w checkout, utracone leady w B2B, spadek rejestracji. To są rzeczy, które widać w analityce, tylko rzadko ktoś łączy je z incydentem jakościowym.

Jak to policzyć uczciwie i konserwatywnie. Wybierasz wskaźnik, który bezpośrednio wiąże się z pieniędzmi. Dla e commerce będzie to liczba transakcji lub conversion rate na checkout. Dla SaaS będzie to rejestracja trial, aktywacja kluczowej funkcji, upgrade planu. Dla B2B będzie to liczba leadów, liczba prób demo, liczba podpisanych umów, cokolwiek jest mierzalnym krokiem do przychodu. Następnie bierzesz różnicę między baseline a stanem w oknie incydentu i mnożysz przez średnią wartość. Nie próbuj od razu modelować całego LTV. Weź przychód tu i teraz, bo on jest najłatwiejszy do obrony.

Ważna uwaga. Jeśli chcesz być uczciwy, zawsze licz konserwatywnie. Lepiej zaniżyć przychód utracony o 20 procent niż przesadzić i stracić wiarygodność. Zaniżona liczba nadal pokaże, że bug kosztuje więcej niż fix.

Koszt relacji

Tu zaczyna się prawdziwy długi ogon. Churn, spadek NPS, spadek zaufania, utrata poleceń, wydłużenie cyklu sprzedaży w B2B, większa presja na rabaty, większa liczba pytań o compliance, więcej audytów klienta, więcej proofów, że potraficie działać stabilnie.

To jest najtrudniejszy koszyk, bo tu rzadko da się przypisać jeden do jednego. Ale da się go oszacować. Najprostszy sposób to liczyć klientów dotkniętych incydentem, czyli tych, którzy weszli w problematyczną ścieżkę, a potem obserwować ich zachowanie w kolejnych tygodniach w porównaniu do grupy kontrolnej. Jeśli w grupie dotkniętej spada retencja albo rośnie liczba rezygnacji, masz sygnał. Możesz go wycenić przez prosty model utraconego przychodu, nawet jeśli to tylko widełki.

Tu liczy się nie precyzja, tylko kierunek. Koszt relacji to często coś, co zamienia incydent w trend, a trend jest zabójczy.

Koszt ryzyka

Tu wchodzą rzeczy, które najczęściej ignoruje się do momentu, gdy jest za późno. Bezpieczeństwo, zgodność, ryzyko kar, koszty audytów, koszty działań naprawczych, koszty raportowania incydentu, koszty konsultacji prawnych, koszty działań PR, koszty dodatkowych kontroli. W firmach regulowanych ten koszyk potrafi samodzielnie przebić wszystko inne.

Jeśli incydent ma choć cień ryzyka bezpieczeństwa, to nie licz tego jako zwykłego buga. Wtedy mówimy o potencjalnym breach, a tam rachunki działają inaczej.

Jak to wdrożyć w praktyce, żeby to nie umarło po tygodniu

Największy problem z liczeniem kosztu buga nie jest w matematyce. Problem jest w tym, że nikt nie ma rytuału, żeby to robić konsekwentnie. Dlatego najlepsza wersja tego modelu to nie prezentacja. To szablon po incydencie. Jedna strona, którą wypełniasz po każdym P1 i po każdym defekcie, który dotknął klientów.

Minimalny szablon powinien mieć:

• kiedy zaczęło się zdarzenie i kiedy wróciliśmy do normalnego rytmu
• ilu użytkowników zostało dotkniętych i w której ścieżce
• ile godzin poszło na gaszenie i naprawę, z podziałem na role
• ile było dodatkowych ticketów i jaki był koszt obsługi
• jaki był spadek kluczowej metryki przychodowej w oknie incydentu
• czy był wpływ na bezpieczeństwo lub zgodność

To wystarczy, żeby po kwartale mieć nie opinie, tylko dane. I to są dane, które zmieniają rozmowę o budżecie jakości.

Od czego zacząć, jeśli masz tylko 30 minut

Na start nie musisz liczyć wszystkiego idealnie. Wystarczy, że policzysz konserwatywnie trzy pierwsze koszyki, czyli techniczny, operacyjny i przychodowy. Dodaj do tego prostą estymację utraconego przychodu w czasie incydentu. Już to zwykle pokazuje, że koszt buga jest wielokrotnie większy niż koszt fixa.

A potem zrób jedną rzecz, która robi największą różnicę. Zacznij zestawiać te koszty z inwestycjami w jakość. Wtedy nagle okazuje się, że poprawka w pipeline, dodatkowa automatyzacja krytycznego flow albo dodatkowy review bezpieczeństwa nie są kosztami. Są polisą, która ma bardzo konkretną stopę zwrotu.

Podsumowanie

Bug w produkcji nigdy nie kosztuje tyle, ile fix. Kosztuje tyle, ile firma traci zanim wróci do normalnego rytmu działania. A ten moment bywa znacznie później, niż się wydaje.

Jeśli zaniżasz koszt bugów, zaniżasz też wartość jakości. A potem podejmujesz decyzje, które krótkoterminowo wyglądają rozsądnie, a długoterminowo stają się jednymi z najdroższych w całej organizacji.

Jeśli chcesz policzyć realny koszt bugów w swojej organizacji, a nie tylko zgadywać, w Quality Island pomagamy firmom budować model kosztu defektu, który obejmuje nie tylko IT, ale też sprzedaż, obsługę klienta, przychód i ryzyko. Kończymy jednym prostym dashboardem, na którym widać, ile kosztuje Was jakość w produkcji i które trzy obszary produktu są najdroższym źródłem strat. Bo najdroższe błędy to te, których koszt poznaje się dopiero po fakcie.