5 decyzji o jakości, których na pewno pożałujesz za rok

Są decyzje, które w momencie podjęcia wydają się rozsądne, a czasem wręcz odważne. Zwłaszcza wtedy, gdy wszyscy są zmęczeni, roadmapa puchnie, a presja na dowiezienie wyniku jest większa niż cierpliwość do „kolejnych tematów jakościowych”. Wtedy padają zdania, które brzmią jak zdrowy rozsądek. Teraz musimy być szybsi. Teraz nie ma budżetu. Teraz dowieziemy funkcję, a potem się uporządkuje.

I przez chwilę faktycznie wygląda to jak sukces. Wydanie poszło, wykresy nie spadły, nikt nie krzyczał. Problem w tym, że jakość oprogramowania rządzi się innymi prawami niż marketing czy sprzedaż. Jakość rzadko rozlicza od razu. Najpierw jest cisza, a potem przychodzi rachunek z opóźnieniem. Jako koszt, pożar, utracone zaufanie, wstydliwe wycofanie wydania, incydent bezpieczeństwa albo ten najgorszy rodzaj problemu: dziwny spadek wyników, którego nikt nie potrafi sensownie wytłumaczyć. To dlatego decyzje o jakości są tak zdradliwe. Świetnie wyglądają w kwartale, w którym je podejmujecie, i źle w kwartale, w którym za nie płacicie.

Pięć decyzji w jednej tabeli

Decyzja 1: „Tniemy QA, bo musimy dowieźć szybciej”

Ta decyzja prawie zawsze wygląda niewinnie. Jedno stanowisko mniej. Dwa stanowiska mniej. W arkuszu robi się miejsce, w prezentacji budżetowej jest sukces. Problem w tym, że to oszczędność z wbudowanym mechanizmem odsetek. Ten sam defekt kosztuje zupełnie inne pieniądze, gdy poprawiacie go na etapie wymagań, a zupełnie inne, gdy naprawiacie go na produkcji, razem ze wsparciem klienta, ponownym wdrożeniem, ryzykiem reputacyjnym i utraconym przychodem. Pięć koszyków tego rachunku rozpisujemy w tekście o tym, ile naprawdę kosztuje bug w produkcji.

Żal po roku nie brzmi „czemu mamy mniej QA”, tylko „czemu tyle czasu tracimy na gaszenie”. Bo redukcja QA rzadko oznacza mniej pracy. Oznacza przeniesienie pracy na później, gdy jest drożej, głośniej i gdy zjada kalendarz ludzi, którzy mieli budować produkt. Jeśli naprawdę musicie ciąć koszt, tnijcie zakres testów niskiej wartości i ręczną regresję, a nie ludzi, którzy wiedzą, gdzie system pęka. Jak wygląda odwrotny kierunek, pokazuje klient z e-commerce, u którego uporządkowanie QA i automatyzacja regresji dały 46 procent mniej błędów krytycznych na produkcji i regresję skróconą z 5 dni do 10 godzin.

Decyzja 2: „Bezpieczeństwo zrobimy później, teraz jest roadmapa”

Wiele firm dalej traktuje bezpieczeństwo jak osobny świat, a nie element jakości. To błąd, który potrafi kosztować nie tylko pieniądze, ale też prawo do spokojnego snu. Coroczny raport IBM Cost of a Data Breach liczy średni koszt naruszenia danych w milionach dolarów i pokazuje, że szybkość wykrycia i opanowania incydentu mocno wpływa na ostateczny rachunek. Wiele organizacji myśli o jakości w kategoriach „bug w interfejsie”, a potem budzi się, gdy problem jest już incydentem bezpieczeństwa z obowiązkiem zgłoszenia, a nie defektem do naprawienia w sprincie.

Żal po roku brzmi zawsze podobnie: „dlaczego nikt nie powiedział, że to może nas tyle kosztować”. A prawda jest taka, że ktoś mówił, tylko nie miał języka i danych, które przebiłyby się przez sprinty i roadmapę. Które luki QA zgłasza najczęściej i jak je opisać, żeby trafiły na listę decyzji o wydaniu, a nie do backlogu, piszemy w tekście o dziurach bezpieczeństwa, które QA widzi, a nikt nie słucha.

Decyzja 3: „Płatności działają, nie dotykajmy, bo to ryzyko”

To decyzja, którą e-commerce podejmuje częściej, niż lubi przyznać. Płatności są delikatne, integracje trudne, operatorzy mają swoje zasady, więc lepiej nie ruszać. Tylko że nieruszana płatność nie znaczy stabilna płatność. Psuje się w najmniej wygodnym momencie: przy zmianie ruchu, promocji albo zależności po stronie dostawcy. I psuje się cicho, jako spadek konwersji, który wpada do worka „rynek, sezon, zachowanie klientów”.

Jeśli chcecie znaleźć najszybszy sposób na żal po roku, to właśnie tu. Decyzja „nie ruszajmy płatności” zamienia się w decyzję „płacimy podatek od problemów płatności”, a ten podatek rośnie razem z wolumenem. Klient z e-commerce, o którym piszemy wyżej, po stabilizacji checkoutu i płatności potwierdził wzrost konwersji o 12 procent. Nie dlatego, że zmienił ofertę. Dlatego, że przestał tracić klientów w ostatnim kroku.

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

Decyzja 4: „Robimy jakość przez checklisty, a nie przez pętlę informacji zwrotnej”

To decyzja, która wygląda jak dojrzałość, a w praktyce bywa pozorem. Organizacja ma proces, bramki, listy, procedury. Tylko że jakość nie wynika z liczby procedur. Wynika z szybkości uczenia się, czyli z tego, jak szybko dowiadujecie się, że coś się psuje, i jak szybko potraficie to poprawić. Program badawczy DORA od lat mierzy tę zdolność czterema wskaźnikami: częstotliwością wdrożeń, czasem od zmiany do produkcji, odsetkiem wdrożeń kończących się awarią i czasem przywracania usługi. Żaden z nich nie liczy checklist.

Żal po roku brzmi tu zwykle: „mamy proces, a i tak produkcja płonie”. I wtedy zaczyna się nerwowe dodawanie kolejnych bramek, które jeszcze bardziej spowalniają informację zwrotną. To spirala, z której wychodzi się jednym ruchem: skracając pętlę i budując testy tam, gdzie dają szybki sygnał, a nie późny raport. Po czym poznać, że pipeline już przestał wpływać na decyzje, opisujemy w tekście o tym, po czym poznać, że pipeline testów jest za wolny.

Decyzja 5: „QA nie musi mówić językiem biznesu, to sprawa techniczna”

To najbardziej podstępna decyzja na tej liście, bo wydaje się niewinna. QA raportuje do CTO, mówi o pokryciu, liczbie testów, liczbie błędów. Wszyscy są zadowoleni, dopóki budżet się spina. Gdy zaczynają się cięcia, QA bardzo często jest pierwszą pozycją do dyskusji, bo z perspektywy biznesu nie widać wpływu, tylko koszt. Żal po roku jest prosty i bolesny: „czemu tak późno dowiedzieliśmy się, że ryzyko jest tak duże”. Bo nikt nie pokazał tego ryzyka w języku przychodu, kosztu incydentu, utraconych transakcji i utraconego zaufania.

Naprawa nie wymaga nowego narzędzia. Wymaga jednej strony dla zarządu: koszt defektów z produkcji w kwartale, liczba i koszt incydentów, trzy obszary największego ryzyka i to, jak są chronione. Dziesięć pytań, które zarząd powinien zadać, żeby tę stronę wymusić, zebraliśmy w tekście o dziesięciu pytaniach o jakość dla każdego CEO.

Podsumowanie

Te pięć decyzji w momencie ich podejmowania nie wygląda jak błędy. Wyglądają jak rozsądne kompromisy. Jakość to nie kwestia perfekcjonizmu, tylko świadomego zarządzania ryzykiem, a w ciągu roku zmieni się zespół, produkt, dojdą integracje, ruch, promocje i presja. To, co dziś „jakoś działa”, jutro zacznie pękać dokładnie w tych miejscach, które dziś uznaliście za nie priorytet. Jeśli chcecie uniknąć żalu po roku, nie zaczynajcie od „zwiększmy QA”. Zacznijcie od pytania, które zmienia perspektywę: gdzie dokładnie dziś tracimy pieniądze przez jakość, tylko jeszcze tego nie mierzymy.

W Quality Island pomagamy organizacjom zamienić jakość z tematu technicznego w temat biznesowy, bez lania wody i bez slajdów, które nic nie zmieniają. Robimy audyt QA pod kątem ryzyka i pieniędzy, budujemy prosty widok jakości dla zarządu i wskazujemy trzy ruchy, które w najkrótszym czasie obniżają koszt defektów i incydentów. Jeśli chcecie zobaczyć, które z tych pięciu decyzji już dziś wpływają na Wasz zespół zza kulis, lepiej policzyć to teraz, niż tłumaczyć za rok.