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

Jeśli zapytacie w firmie, ile kosztuje bug w produkcji, najczęściej usłyszycie: kilka godzin dewelopera, jeden hotfix, czasem plus support. Brzmi rozsądnie, bo jest policzalne, bliskie zespołowi IT i mieści się w tabelce. 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ądu. Kod jest tylko początkiem rachunku.

Skala problemu jest policzalna. Konsorcjum CISQ w raporcie o koszcie niskiej jakości oprogramowania w Stanach Zjednoczonych szacuje go za 2022 rok na co najmniej 2,41 biliona dolarów, a skumulowany dług techniczny na około 1,52 biliona. 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 nie o kilkanaście procent, tylko kilkukrotnie. Poniżej rozkładamy ten rachunek na czynniki pierwsze. Bez moralizowania, z mechanizmami, które sprawiają, że suma zawsze jest większa, niż Wam się wydaje.

Dlaczego wszyscy liczą tylko koszt naprawy

Najczęstszy błąd polega na tym, że patrzycie wyłącznie na koszt techniczny: ile godzin zajęło znalezienie problemu, ile czasu poświęcił deweloper, ile trwało wdrożenie poprawki. To koszty widoczne, łatwe do wpisania do arkusza i względnie bezpieczne politycznie, bo mieszczą się w świecie IT. Da się je policzyć bez rozmowy z biznesem i bez dotykania niewygodnych tematów w rodzaju utraconego przychodu czy odpływu klientów.

Jest też powód bardziej ludzki. Koszt naprawy to koszt, nad którym ktoś ma kontrolę: zespół, sprint, godziny, ticket. To świat, w którym da się powiedzieć „zrobione”. Koszt utraconych transakcji jest niekomfortowy, bo pokazuje, że błąd żyje poza IT i robi rzeczy, których nie da się cofnąć. Tego nikt nie chce słyszeć w trakcie rozmowy o incydencie. Wszyscy chcą naprawić i wrócić do pracy. Firma naprawia kod, ale koszt już się wydarzył.

Do tego dochodzą silosy. IT widzi czas dewelopera. Support widzi wzrost zgłoszeń. 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 domyślnie wygrywa liczba najłatwiejsza do policzenia. Lepszy model myślenia brzmi tak: naprawa to koszt wewnętrzny, produkcja generuje koszt zewnętrzny, a koszt zewnętrzny jest zwykle większy, bo dotyka klientów, przychodu i reputacji. Najprostszy test, czy u Was też tak jest: ile ról było zaangażowanych w obsługę ostatniego poważnego buga, nie tylko w jego naprawę. Jeśli więcej niż trzy, koszt naprawy 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. Support odbiera zgłoszenia i każda rozmowa ma swój czas, swoje emocje i swoją cenę. Opiekunowie klientów obiecują terminy, które potem trzeba dotrzymać. Marketing widzi spadek konwersji i kompensuje rabatami, choć problem nie jest marketingowy. Sprzedaż słyszy „wróćcie, jak będzie działać”, a lead, który był gorący, stygnie. Zespół przerywa pracę nad roadmapą, bo ktoś musi gasić. Liderzy robią spotkania kryzysowe, aktualizacje statusów, postmortem. Zarząd dostaje wiadomości, których nikt nie lubi.

Produkcja jest najdroższym środowiskiem testowym nie dlatego, że jest publiczna, tylko dlatego, że jest pełna zmiennych, których nie kontrolujecie: prawdziwy ruch, prawdziwe urządzenia, realne integracje i obciążenie, realne zachowania ludzi. Każda minuta błędu dzieje się w świecie, w którym ktoś próbuje kupić, zapłacić, zalogować się albo podpisać umowę. Piszemy o tym szerzej w tekście o tym, dlaczego „testujemy na produkcji” bywa mądrym wyborem, ale rzadko. Odwrotność tej zasady też działa: gdy błędy przestają docierać do produkcji, rachunek spada w każdym dziale naraz. Poniżej liczby, które klient z e-commerce potwierdził po uporządkowaniu procesów QA i automatyzacji regresji.

Źródło: dane potwierdzone przez klienta Quality Island, Argos, e-commerce, projekt automatyzacji testów i porządkowania procesów QA.

Zwróćcie uwagę na trzecią liczbę. Wzrost konwersji o 12 procent nie jest wynikiem kampanii ani nowej funkcji. Jest wynikiem tego, że checkout i płatności przestały się psuć. To dokładnie ten koszt, którego nikt wcześniej nie przypisywał do jakości, bo wpadał do worka „rynek, sezon, zachowanie klientów”.

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

Najbardziej zdradliwy koszt buga to odpływ klientów, ale nie ten spektakularny, gdzie klient krzyczy i żąda rekompensaty. Ten cichy. Klient napotyka błąd, traci zaufanie i nic nie mówi. Nie dlatego, że jest zadowolony. Dlatego, że nie ma energii. W e-commerce jest to brutalne, bo klient w koszyku ma najniższą tolerancję na chaos: jeśli płatność nie przechodzi, nie pisze maila, idzie do konkurencji. W SaaS mechanizm jest podobny, tylko wolniejszy. Błąd w krytycznej funkcji sprawia, że zespół klienta zaczyna szukać alternatywy, a decyzja mentalna zapada na długo przed rezygnacją.

Tego kosztu prawie nikt nie przypina do konkretnego defektu, bo odpływ jest rozłożony w czasie i rzadko ma metkę. W danych widzicie spadek, ale nie widzicie, że zaczął się od dwóch fatalnych doświadczeń w jednym tygodniu. W rozmowach sprzedażowych słyszycie „za drogo” albo „wybraliśmy kogoś innego”, a rzadko „nie ufamy, bo coś nie działało”. Klient nie ma interesu, żeby robić Wam analizę jakości. Ma interes, żeby mieć działający produkt. Jeśli chcecie to mierzyć, najprostszy start to powiązać incydenty z zachowaniem użytkowników: spadek konwersji w oknie incydentu, wzrost zwrotów, wzrost zgłoszeń i odsetek osób, które nie wróciły w kolejnych dniach.

Pięć koszyków kosztu buga

Uczciwe liczenie zaczyna się od zmiany pytania. Nie „ile kosztowała naprawa”, tylko „co się wydarzyło od momentu, gdy bug dotknął klienta, do momentu, gdy firma wróciła do normalnego rytmu”. Normalny rytm to ważne słowo. Czasem poprawka jest na produkcji po dwóch godzinach, ale organizacja jeszcze przez dwa tygodnie odpowiada na maile, negocjuje rekompensaty i wydłuża kolejne wydanie. To też jest koszt, tylko że wygląda jak praca. W praktyce pojawia się pięć koszyków. Istnieją niezależnie od branży, różni się tylko proporcja.

Dwie uwagi do koszyka przychodowego, bo to on robi największy rachunek w e-commerce, fintechu i SaaS. Po pierwsze, wybierzcie jedną metrykę, która bezpośrednio wiąże się z pieniędzmi: liczba transakcji w koszyku, aktywacja kluczowej funkcji, liczba podpisanych umów. Nie modelujcie od razu wartości klienta w całym cyklu życia, weźcie przychód tu i teraz, bo jest najłatwiejszy do obrony. Po drugie, liczcie konserwatywnie. Lepiej zaniżyć utracony przychód o 20 procent niż przesadzić i stracić wiarygodność przy pierwszej dyskusji z finansami. Zaniżona liczba i tak pokaże, że bug kosztuje wielokrotnie więcej niż naprawa.

Kiedy bug staje się incydentem bezpieczeństwa

Jest kategoria błędów, które potrafią zabić budżet jednym ruchem: te, które prowadzą do naruszenia danych. Coroczny raport IBM Cost of a Data Breach liczy średni koszt takiego incydentu w milionach dolarów i pokazuje, że rachunek zależy między innymi od tego, jak szybko organizacja wykryła i opanowała zdarzenie. To nie jest tylko kara. To koszty identyfikacji i opanowania incydentu, przestoje, komunikacja kryzysowa, koszty prawne i odpływ klientów. Jeśli bug ma wymiar bezpieczeństwa, liczenie go jako kilku godzin dewelopera jest jak liczenie pożaru jako kosztu zapałek. Ile taki rachunek potrafi wynieść i dlaczego rośnie z każdym dniem niewykrycia, opisujemy w tekście o tym, ile kosztuje luka bezpieczeństwa, której nikt nie szukał.

Szablon po incydencie, żeby liczenie nie umarło po tygodniu

Największy problem z liczeniem kosztu buga nie jest w matematyce. Jest w tym, że nikt nie ma rytuału, żeby robić to konsekwentnie. Dlatego najlepsza wersja tego modelu to nie prezentacja dla zarządu, tylko jedna strona wypełniana po każdym incydencie priorytetu pierwszego i po każdym defekcie, który dotknął klientów. Po kwartale macie nie opinie, tylko dane, a to są dane, które zmieniają rozmowę o budżecie na jakość.

Od czego zacząć, jeśli macie 30 minut

Na start nie musicie liczyć wszystkiego idealnie. Wystarczy, że policzycie konserwatywnie trzy pierwsze koszyki: techniczny, operacyjny i przychodowy, dla ostatniego poważnego incydentu. Już to zwykle pokazuje, że koszt buga jest wielokrotnie większy niż koszt naprawy. A potem zróbcie jedną rzecz, która robi największą różnicę: zestawcie tę sumę z inwestycjami w jakość, które dotąd wyglądały jak wydatek. Poprawka w pipeline, automatyzacja krytycznego przepływu albo dodatkowy przegląd bezpieczeństwa przestają być kosztem. Stają się polisą z bardzo konkretną stopą zwrotu. Jak ułożyć ten rachunek na poziomie całej organizacji, piszemy w tekście o tym, dlaczego jakość oprogramowania to Wasz największy niewidzialny koszt.

Podsumowanie

Bug w produkcji nigdy nie kosztuje tyle, ile naprawa. Kosztuje tyle, ile firma traci, zanim wróci do normalnego rytmu działania, a ten moment przychodzi znacznie później, niż się wydaje. Jeśli zaniżacie koszt bugów, zaniżacie też wartość jakości. A potem podejmujecie decyzje, które krótkoterminowo wyglądają rozsądnie, a długoterminowo stają się jednymi z najdroższych w całej organizacji.

W Quality Island pomagamy firmom zbudować model kosztu defektu, który obejmuje nie tylko IT, ale też sprzedaż, obsługę klienta, przychód i ryzyko. Zaczynamy od audytu QA: przeglądu procesów, incydentów z ostatnich miesięcy i miejsc, w których błędy przedostają się na produkcję. Kończymy listą trzech obszarów produktu, które są najdroższym źródłem strat, i planem, jak je domknąć. Bo najdroższe błędy to te, których koszt poznaje się dopiero po fakcie.