Jak przekonać zarząd, że potrzebujesz QA, a nie tylko szybszych devów

Rozmowa zwykle wygląda tak samo. Prosicie o etat w zespole jakości, a w odpowiedzi słyszycie pytanie, czy nie prościej zatrudnić kolejnego programistę, który po prostu będzie pisał lepszy kod. Pytanie brzmi rozsądnie, bo zarząd porównuje dwie pozycje w budżecie i widzi, że jedna dowozi funkcje, a druga je sprawdza.

Argument, który wygrywa tę rozmowę, nie brzmi „potrzebujemy QA”, tylko „obecnie płacimy za to samo dwa razy, tylko później i drożej”. Ten tekst pokazuje, jak przygotować taką rozmowę: jakie liczby zebrać przed nią, jakich argumentów nie używać i co odpowiedzieć na cztery najczęstsze obiekcje.

Dlaczego argument o jakości przegrywa z argumentem o tempie

Zarząd nie jest przeciwko jakości. Zarząd wybiera między rzeczami, które da się porównać, a wniosek o etat w QA zwykle nie daje się porównać z niczym. Nowy programista ma oczywisty wynik: więcej funkcji w kwartale. Nowy tester ma wynik opisany jako „mniej błędów”, co brzmi jak obietnica bez miary i bez terminu.

Do tego dochodzi asymetria widoczności. Funkcja, która powstała, jest widoczna od razu, na demo i w komunikacji do klientów. Awaria, która się nie zdarzyła, jest niewidoczna zawsze. Jeśli nie przetłumaczycie jej na koszt, który firma poniosła w przeszłości i poniesie znowu, pozostanie hipotezą, a hipotezy przegrywają z demonstracjami.

Stąd pierwsza zasada takiej rozmowy: nie zaczynajcie od tego, czego potrzebujecie. Zacznijcie od tego, ile obecny stan już kosztował, licząc wyłącznie zdarzenia, które faktycznie miały miejsce w Waszej firmie.

Cztery liczby, które warto zebrać przed rozmową

Nie potrzebujecie systemu raportowania ani kwartału przygotowań. Wystarczą dane z ostatnich trzech do sześciu miesięcy, wyciągnięte z narzędzia do zgłoszeń i z kalendarza wydań. Każda z tych czterech liczb jest zrozumiała bez tłumaczenia.

Te cztery liczby robią coś, czego nie zrobi żadna prezentacja o znaczeniu jakości. Pokazują, że firma już płaci za brak QA, tylko płaci w innej walucie: czasem programistów, opóźnieniami i cierpliwością klientów. Rozmowa przestaje dotyczyć nowego kosztu, a zaczyna dotyczyć przesunięcia kosztu na wcześniejszy i tańszy moment.

Jak brzmi argument, który działa

Konstrukcja jest prosta i mieści się w czterech zdaniach. Najpierw stan faktyczny: w ostatnim kwartale zespół spędził tyle a tyle godzin na poprawkach produkcyjnych. Potem konsekwencja: to jest równowartość jednego etatu programisty, który nie zbudował żadnej nowej funkcji. Potem propozycja z kosztem i horyzontem. Na końcu miara, po której poznamy, czy zadziałało.

Warto tu wykorzystać wnioski z badań nad wydajnością dostarczania oprogramowania. Program DORA od lat pokazuje, że organizacje dowożące najczęściej mają jednocześnie najniższy odsetek nieudanych wdrożeń i najkrótszy czas przywrócenia usługi. To rozbraja najczęstszy kontrargument, czyli przekonanie, że kontrola jakości spowalnia zespół. W danych szybkość i stabilność występują razem, a nie zamiast siebie.

Drugą podporą jest skala zjawiska. 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 to dług techniczny. Tej liczby nie używa się jako dowodu we własnej firmie, bo dotyczy innej skali. Używa się jej jako odpowiedzi na pytanie, czy problem jest wyjątkiem, czy regułą.

Cztery obiekcje i odpowiedzi, które na nie działają

„Programiści powinni testować własny kod.” Powinni i testują, tylko sprawdzają wtedy, czy kod robi to, co zamierzyli. Testowanie polega na sprawdzeniu, czy robi coś jeszcze, czego nikt nie zamierzył. Autor rzadko wychodzi poza własne założenia, nie z braku umiejętności, tylko dlatego, że zna zamysł i podświadomie go broni.

„Mamy testy automatyczne, po co człowiek.” Testy automatyczne sprawdzają wyłącznie to, co ktoś wcześniej umiał przewidzieć i zapisać. Nie zauważą, że nowa funkcja jest logicznie poprawna, a praktycznie nie do użycia, ani że wymaganie zostało spełnione wbrew intencji zamawiającego.

„Zwolnimy tempo.” To jedyna obiekcja, na którą odpowiada twardy materiał zewnętrzny. Zespoły z najwyższą częstotliwością wdrożeń mają jednocześnie najniższy odsetek awaryjnych zmian, co pokazują kolejne edycje badania DORA. Spowalnia nie kontrola jakości, tylko naprawianie produkcji w środku sprintu.

„Zatrudnimy, jak urośniemy.” Koszt dodania jakości rośnie razem z produktem, bo rośnie zakres regresji i liczba integracji. Odkładanie decyzji nie usuwa kosztu, tylko go zwiększa i przenosi na moment, w którym zespół ma najmniej czasu, żeby cokolwiek uporządkować.

O co prosić, żeby faktycznie dostać

Wniosek o etat na stałe jest decyzją, którą łatwo odłożyć. Wniosek o ograniczony eksperyment z jasnym terminem i miarą jest decyzją, którą łatwo podjąć, bo ma zdefiniowany koszt maksymalny. Dlatego skuteczniejsza bywa prośba o trzy miesiące i jeden obszar produktu niż o pełną rozbudowę zespołu.

Zakres tego eksperymentu powinien obejmować obszar, w którym awarie już wystąpiły i są udokumentowane. Nie ten najciekawszy technicznie, tylko ten najdroższy w skutkach. Po trzech miesiącach przynosicie porównanie tych samych czterech liczb, które zebraliście na starcie, i to porównanie prowadzi rozmowę dalej, bez potrzeby przekonywania kogokolwiek.

Ta kolejność ma znaczenie: najpierw dowód na małym zakresie, potem rozmowa o skali. Odwrotna kolejność wymaga zaufania, którego w rozmowach budżetowych zwykle jeszcze nie ma.

Kto powinien prowadzić tę rozmowę i kiedy

Wniosek o zasoby dla jakości ma zupełnie inną wagę zależnie od tego, kto go składa. Jeśli przychodzi wyłącznie od zespołu QA, łatwo odczytać go jako obronę własnego obszaru. Jeśli stoi za nim dyrektor techniczny albo kierownik produktu, staje się wnioskiem o przewidywalność dowożenia, a to jest temat, który zarząd traktuje inaczej. Dlatego warto poświęcić tydzień na uzgodnienie liczb z tymi osobami, zanim trafią na spotkanie zarządu.

Moment też nie jest obojętny. Najgorszy jest tydzień po awarii, choć wtedy najłatwiej o zgodę. Decyzje podjęte w takim momencie mają krótkie życie, bo są odruchem, a nie planem, i pierwsza spokojna kwartalna rewizja budżetu je cofa. Najlepszy moment to planowanie kolejnego okresu, kiedy zarząd i tak porównuje inwestycje i szuka miejsc, w których da się skrócić czas wejścia na rynek.

Warto też ustalić z góry, kto będzie właścicielem wyniku. Jeśli eksperyment się powiedzie, ktoś musi przynieść porównanie liczb i powiedzieć, co dalej. Bez tej osoby nawet dobry wynik rozmyje się w kolejnym kwartale, a Wy zaczniecie rozmowę od nowa, tym razem z gorszej pozycji, bo z pytaniem, dlaczego poprzednia inwestycja nie została rozliczona.

Co zrobić, gdy usłyszycie odmowę

Odmowa rzadko oznacza, że argument był zły. Częściej oznacza, że w tym kwartale są pilniejsze wydatki albo że decydent nie chce podejmować ryzyka bez dowodu. W obu przypadkach najgorszą reakcją jest wycofanie tematu na rok i wrócenie do niego dopiero po kolejnej awarii, bo wtedy rozmowa zaczyna się od emocji.

Skuteczniejsze jest coś innego: zapytajcie wprost, jaka informacja byłaby potrzebna, żeby decyzja wyglądała inaczej. Odpowiedź zwykle jest konkretna i wykonalna. Bywa to koszt jednej awarii policzony razem z finansami, bywa opinia klienta, bywa porównanie z konkurencją. Zbierzcie dokładnie to i wróćcie za kwartał z tą jedną rzeczą, a nie z całą prezentacją od nowa.

Przez ten czas warto zbierać dane dalej, nawet bez zgody na etat. Rejestr kosztów poprawek produkcyjnych prowadzony przez pół roku jest argumentem, którego nie da się podważyć, bo składa się wyłącznie z tego, co firma sama zrobiła. To także najlepsze zabezpieczenie na wypadek, gdy rozmowa wróci nagle, w gorszych okolicznościach, i będziecie mieli kilka godzin na przygotowanie.

Jedno zdanie, które warto przećwiczyć przed spotkaniem

W praktyce cała rozmowa i tak sprowadza się do jednego momentu: ktoś pyta, po co nam to, i macie kilkanaście sekund na odpowiedź. Warto mieć ją przygotowaną w jednym zdaniu, opartym wyłącznie na własnych danych, bez przymiotników. Na przykład: w ostatnim kwartale straciliśmy tyle a tyle dni roboczych na poprawki produkcyjne, chcemy sprawdzić na jednym obszarze, czy da się to zmniejszyć o połowę, i rozliczyć to po trzech miesiącach.

Takie zdanie działa, bo zawiera wszystkie elementy decyzji: stan faktyczny, zakres, oczekiwany efekt i moment weryfikacji. Nie zawiera natomiast niczego, co można podważyć argumentem o priorytetach albo o kulturze pracy. To jest różnica między prośbą o zaufanie a propozycją, którą da się przyjąć albo odrzucić na podstawie liczb.