Znacie ten moment. Raport QA, nad którym zespół siedział trzy dni, idzie mailem do zarządu. Są metryki, wykresy, tabele, komentarze, na końcu nawet rekomendacje. Mija tydzień. Drugi. Budżet bez zmian, priorytety bez zmian, roadmapa jedzie dalej, jakby dokument nigdy nie powstał. I wtedy pojawia się pytanie, którego nikt nie lubi zadawać na głos: czy my w ogóle mówimy do kogokolwiek.
Najczęściej problem nie leży w jakości danych, tylko w tym, że raport jest napisany w języku QA, a decyzje zapadają w języku pieniędzy, ryzyka i przewidywalności dowożenia. Ten tekst pokazuje, dlaczego poprawny merytorycznie raport potrafi nie zmienić niczego, i jak przebudować go tak, żeby prowadził do decyzji zamiast do archiwum.
Zarząd nie ignoruje jakości. Ignoruje brak decyzji
To rozróżnienie jest ważniejsze, niż wygląda. Dyrektor finansowy nie zarządza defektami, tylko kosztami i ryzykiem strat. Prezes nie myśli w przypadkach testowych, myśli w ryzyku reputacyjnym i w tym, czy firma dowozi przewidywalnie. Dyrektor techniczny nie potrzebuje listy dwustu błędów, tylko odpowiedzi, czy pętla informacji zwrotnej działa i czy stabilność rośnie czy spada.
Raport QA zwykle odpowiada na pytanie, co zespół zrobił. Zarząd zadaje trzy inne pytania: co to znaczy dla pieniędzy, co to znaczy dla ryzyka i co robimy dalej. Dopóki dokument nie odpowiada na te trzy, będzie czytany jako informacja, a nie jako podstawa decyzji. A informacji zarząd dostaje dziennie kilkadziesiąt.
Pięć powodów, dla których raport ląduje w szufladzie
W praktyce audytowej te same pięć błędów wraca niezależnie od branży i wielkości organizacji. Żaden z nich nie jest błędem merytorycznym. Wszystkie są błędami tłumaczenia.
Ostatni wiersz jest najbardziej dotkliwy. Konsorcjum CISQ oszacowało koszt złej jakości oprogramowania w Stanach Zjednoczonych w 2022 roku na 2,41 biliona dolarów, z czego około 1,52 biliona przypada na dług techniczny. To liczba makro i nie wstawicie jej do własnego raportu jako argumentu, ale pokazuje skalę zjawiska, które w pojedynczej firmie objawia się jako „jakoś to działa”. Wasze zadanie polega na przetłumaczeniu tego zjawiska na własne dane.
Cztery elementy raportu, który zmienia decyzje
Raport zarządczy jest zaskakująco krótki i to jest pierwsza rzecz, która nie przechodzi przez gardło zespołom QA, bo QA żyje w szczegółach. Zarząd nie podejmuje decyzji na podstawie szczegółu, tylko na podstawie sygnału. Pierwsza strona ma być do przeczytania w dwie minuty i musi zawierać cztery rzeczy.
Pod tą warstwą może i powinna istnieć warstwa operacyjna: rozbicie na komponenty, analiza przyczyn, lista działań naprawczych. Ona jest potrzebna dyrektorowi technicznemu i liderom zespołów. Kłopot zaczyna się wtedy, gdy próbujecie obsłużyć oba odbiory jednym dokumentem. Zarząd dostaje wtedy za dużo szczegółu i zero decyzji, a zespół za mało szczegółu, żeby cokolwiek naprawić. Rozwiązanie nie wymaga nowej platformy, tylko dwóch dokumentów zamiast jednego.
Metryki, które zarząd rozumie bez tłumaczenia
Nie każda metryka QA nadaje się na poziom zarządu. Cztery działają prawie zawsze, bo każda ma oczywiste przełożenie na pieniądze albo na odporność operacyjną.
Liczba błędów, które doszły do klientów, wraz z trendem. To jedyna metryka jakości, której nikomu nie trzeba tłumaczyć. Rośnie, więc klienci widzą więcej awarii. Spada, więc coś zadziałało.
Czas naprawy incydentu. Program badawczy DORA używa czasu przywrócenia usługi jako jednej z czterech kluczowych miar wydajności dostarczania oprogramowania obok częstotliwości wdrożeń, czasu wprowadzenia zmiany i odsetka nieudanych wdrożeń. To język, który dyrektor techniczny i zarząd znają z innych obszarów operacyjnych.
Pokrycie krytycznych ścieżek. Nie ogólny procent pokrycia, tylko odpowiedź na pytanie, czy chronicie miejsca, w których są pieniądze: rejestrację, płatność, wyszukiwarkę, integrację z systemem rozliczeń.
Niestabilność testów. Google opisywał to zjawisko już w 2016 roku: około 1,5% wszystkich uruchomień testów kończyło się wynikiem niestabilnym, a niestabilne testy odpowiadały za 16% zbioru testowego i zużywały nawet 16% zasobów obliczeniowych. Zarządowi tłumaczy się to jednym zdaniem: jeśli zespół przestaje wierzyć czerwonemu wynikowi, cały mechanizm kontroli przestaje działać, a płacicie za niego dalej.
Zwróćcie uwagę, że żadna z tych liczb nie jest metryką testową. Wszystkie są metrykami biznesowymi, do których jakość doprowadziła. To jest dokładnie ten przeskok, którego brakuje w raportach kończących się liczbą przypadków testowych.
Szablon podsumowania, który możecie skopiować
Jeśli chcecie sprawdzić tę zmianę bez przebudowy całego procesu raportowania, przez najbliższy miesiąc trzymajcie się jednej struktury. Cztery zdania, potem jedna rekomendacja, potem załącznik.
Dwa pytania sprawdzają, czy raport ma szansę cokolwiek zmienić. Czy prezes po przeczytaniu pierwszej strony wie, w którą stronę idzie jakość. I czy dyrektor finansowy po tej samej stronie wie, czy rekomendacja jest inwestycją z sensownym zwrotem. Jeśli któraś odpowiedź brzmi „nie”, raport jest poprawny, ale będzie ignorowany.
Ostrożność w liczeniu kosztu uniknionego opłaca się bardziej niż efektowność. Lepiej pokazać trzy scenariusze i zaniżyć szacunek, niż podać jedną imponującą liczbę, której nie obronicie na pierwszym pytaniu. Wiarygodność w tej rozmowie jest walutą jednorazową.
Raport to rytuał, a nie dokument
Nawet dobrze napisane podsumowanie nie zmieni decyzji, jeśli trafia do zarządu przypadkowo: raz na kwartał, raz po awarii, raz przy okazji planowania budżetu. Dokument, który pojawia się nieregularnie, jest odbierany jako reakcja na kłopot, a nie jako stały element zarządzania. A reakcja na kłopot uruchamia obronę, nie decyzję inwestycyjną.
Rytm ma znaczenie większe niż forma. Stała data, ten sam układ, te same trzy metryki co miesiąc. Po trzecim albo czwartym powtórzeniu zarząd przestaje czytać raport jako nowość i zaczyna czytać go jako przyrząd pomiarowy: sprawdza, co się zmieniło od poprzedniego razu. Dopiero wtedy rekomendacje zaczynają być traktowane poważnie, bo mają tło. Zmiana układu co miesiąc zeruje ten efekt, więc opłaca się trzymać nudnej powtarzalności nawet wtedy, gdy kusi Was ładniejszy wykres.
Druga rzecz, którą warto ustawić od początku, to adresat rekomendacji. Zdanie „rekomendujemy zwiększenie pokrycia testami” nie ma właściciela, więc nie ma też decyzji. Zdanie „rekomendujemy przypisanie jednej osoby na dwa sprinty do stabilizacji testów płatności, koszt około X, oczekiwany efekt: skrócenie regresji z pięciu dni do dwóch” ma właściciela, koszt i moment, w którym da się sprawdzić, czy zadziałało. Różnica między tymi zdaniami decyduje o tym, czy raport wywoła rozmowę o budżecie, czy uprzejme podziękowanie.
Warto też przygotować się na pytanie, które prędzej czy później padnie: skąd wiadomo, że to zadziała. Uczciwa odpowiedź brzmi, że nie wiadomo na pewno, dlatego rekomendacja ma określony horyzont i mierzalny efekt. Zarząd nie oczekuje gwarancji, bo sam ich nie daje. Oczekuje hipotezy z ceną, terminem i sposobem sprawdzenia. To jest ten sam język, w którym rozmawia o kampanii marketingowej albo o wejściu na nowy rynek, więc jest w nim swobodny.
Ostatni element rytuału to zamknięcie pętli. Jeśli poprzednia rekomendacja została przyjęta, kolejny raport musi zaczynać się od tego, co z niej wyszło, także wtedy, gdy wyszło słabo. Zespoły QA często pomijają ten fragment, bo przyznanie się do połowicznego efektu wydaje się osłabiać pozycję. W praktyce działa odwrotnie: raport, który sam rozlicza własne rekomendacje, buduje wiarygodność szybciej niż seria dobrych wiadomości bez weryfikacji.
- Raporty QA nie są ignorowane dlatego, że są złe. Są ignorowane dlatego, że odpowiadają na inne pytania niż te, które zadaje zarząd.
- Pierwsza strona to sygnał, nie encyklopedia: wynik, trzy metryki jako trend, jedna rekomendacja z kosztem, ryzyka.
- Jeden dokument nie obsłuży zarządu i zespołu naraz. Podsumowanie idzie w górę, raport operacyjny zostaje jako załącznik.
- Metryka bez obszaru produktu nie generuje decyzji. Ta sama liczba w panelu administracyjnym i w płatnościach znaczy coś zupełnie innego.
- Koszt unikniony liczcie konserwatywnie i w widełkach. Wiarygodność przegrywa raz, a potem raport wraca do szuflady na stałe.
Jeśli chcecie przełożyć metryki QA na język ryzyka i pieniędzy, zacznijmy od przeglądu tego, co dziś raportujecie, i jednej strony podsumowania dla zarządu.
Zobaczcie strategię jakościPowiązane na Strefie QA
- Dlaczego Twój dashboard jakości kłamie i jak to naprawić
- Jak przekonać zarząd, że potrzebujesz QA, a nie tylko szybszych devów
- Ile naprawdę kosztuje bug w produkcji i czemu zaniżasz tę liczbę
Źródła:
- DORA, cztery kluczowe metryki dostarczania oprogramowania
- CISQ, The Cost of Poor Software Quality in the US, raport 2022
- Google Testing Blog, Flaky Tests at Google and How We Mitigate Them, 2016
- Strategia jakości oprogramowania, Quality Island
- Case Argos, dane potwierdzone przez klienta: 72% mniej awarii w szczycie, 46% mniej błędów krytycznych, regresja z 5 dni do 10 godzin, 12% wzrostu konwersji
