Sprawdzone sposoby planowania budżetu na QA na cały rok

Planowanie budżetu na jakość ma w większości firm jedną wadę: powstaje jako lista narzędzi i etatów, a broni się go argumentem o znaczeniu jakości. Dyrektor finansowy widzi wtedy pozycję kosztową bez wyniku, dyrektor techniczny widzi zbyt małą kwotę na to, co trzeba zrobić, a rozmowa kończy się przycięciem o dwadzieścia procent, bo tak wygląda kompromis, gdy nikt nie umie porównać wariantów.

Budżet, który przechodzi, jest zbudowany odwrotnie: zaczyna się od kosztu, który firma już ponosi, a kończy na czterech pozycjach, z których każda ma własny wynik i własną miarę. Poniżej model w pięciu krokach, którego używamy przy planowaniu rocznym u klientów, wraz z szablonem podziału kwoty i sposobem rozliczania go co kwartał.

Krok 1: ustalcie, co w Waszej firmie znaczy jakość

To brzmi jak ćwiczenie warsztatowe, a jest decyzją finansową. Dla dyrektora finansowego jakość zwykle znaczy przewidywalność: brak niespodziewanych kosztów, brak kar umownych, brak nagłych przesunięć w harmonogramie sprzedaży. Dla dyrektora technicznego znaczy najczęściej coś innego: możliwość wydawania zmian bez strachu i bez zamrażania zespołu na tydzień przed każdym wydaniem.

Te dwie definicje prowadzą do różnych budżetów. Pierwsza kieruje pieniądze na kontrolę ryzyka i zgodność, druga na skrócenie pętli informacji zwrotnej i automatyzację. Jeśli nie uzgodnicie tego na starcie, powstanie budżet, który próbuje zrobić obie rzeczy po połowie i nie robi żadnej do końca.

Praktyczne ćwiczenie zajmuje godzinę. Każda z tych osób wypisuje trzy zdarzenia z ostatniego roku, które uznaje za najbardziej kosztowne. Jeśli listy się pokrywają, macie wspólny cel. Jeśli nie, macie temat na rozmowę, którą i tak trzeba odbyć, tylko lepiej we wrześniu niż w marcu.

Krok 2: policzcie koszt obecnego stanu, choćby ostrożnie

Bez tej liczby budżet na jakość jest prośbą o zaufanie. Z nią staje się propozycją przesunięcia kosztu na wcześniejszy i tańszy moment. Nie potrzebujecie precyzji księgowej, potrzebujecie porządku wielkości i danych, których nikt nie podważy, bo pochodzą z Waszych własnych systemów.

Cztery pozycje wystarczą na start: godziny zespołu spędzone na poprawkach produkcyjnych, liczba wydań wycofanych lub poprawianych na gorąco, długość regresji przed wydaniem oraz zgłoszenia od klientów dotyczące błędów. Pierwsza pozycja zwykle robi największe wrażenie, bo pokazuje, że część mocy wytwórczej już dziś idzie na jakość, tylko w najdroższym możliwym momencie.

Warto też mieć pod ręką punkt odniesienia spoza firmy. 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. Tej liczby nie używa się jako dowodu we własnej sprawie, ale odpowiada ona na pytanie, czy problem jest wyjątkiem, czy regułą, a takie pytanie pada na każdym posiedzeniu budżetowym.

Krok 3: podzielcie budżet na cztery pozycje, których da się bronić

Budżet w jednej kwocie jest łatwy do przycięcia, bo cięcie nie ma widocznej ceny. Budżet rozbity na cztery pozycje z osobnymi wynikami zmienia rozmowę: przycięcie którejkolwiek oznacza rezygnację z konkretnego efektu, a to już jest decyzja, którą ktoś musi podpisać.

Proporcje zależą od dojrzałości organizacji, ale pewna prawidłowość powtarza się na tyle często, że warto ją znać. Firmy, które dopiero porządkują jakość, powinny większość kwoty kierować do dwóch pierwszych pozycji, bo bez ochrony krytycznych ścieżek i wiarygodnej informacji zwrotnej reszta i tak nie zadziała. Organizacje z ustawionym procesem przesuwają środek ciężkości do trzeciej i czwartej, bo tam leży ich największy koszt jednostkowy.

Krok 4: rozpiszcie budżet na zasoby, nie tylko na narzędzia

Najczęstszy błąd w budżetach jakościowych polega na tym, że licencje i narzędzia są policzone co do złotówki, a praca ludzi pojawia się jako „zasoby zespołu” bez kwoty. Konsekwencja jest przewidywalna: narzędzie zostaje kupione, nikt nie ma czasu go wdrożyć, a po roku pojawia się w zestawieniu jako koszt bez efektu i staje się argumentem przeciwko kolejnym wnioskom.

Rozpisanie na zasoby wymaga odpowiedzi na cztery pytania: ile etatów wewnętrznych, ile wsparcia zewnętrznego, ile czasu zespołu programistów zostanie przeznaczone na jakość i ile na szkolenia. Ostatnia pozycja bywa pomijana, a jest najtańszą dźwignią w całym budżecie, bo podnosi skuteczność wszystkich pozostałych.

Warto tu policzyć dwa warianty obok siebie: własny zespół i wsparcie zewnętrzne w modelu wypożyczenia kompetencji. Nie po to, żeby wybrać jeden na stałe, tylko po to, żeby mieć gotową odpowiedź, gdy padnie pytanie o elastyczność. Budżet, który pokazuje oba warianty z kosztem, wygląda na przemyślany, a nie na obronę stanu posiadania.

Krok 5: ustalcie z góry, jak będziecie to rozliczać

Budżet bez sposobu rozliczenia zamienia się w rytuał: co roku ta sama rozmowa, te same argumenty i te same wątpliwości. Rozliczenie nie musi być skomplikowane. Wystarczą trzy miary, ustalone przed startem roku, mierzone co kwartał i pokazywane zawsze w tym samym układzie.

Dobór miar warto oprzeć na czymś, co ma zewnętrzne umocowanie, żeby nie było podejrzenia, że zespół wybrał sobie wygodne wskaźniki. Program badawczy DORA używa czterech miar wydajności dostarczania oprogramowania: częstotliwości wdrożeń, czasu wprowadzenia zmiany, czasu przywrócenia usługi i odsetka nieudanych wdrożeń. Dwie ostatnie są bezpośrednio związane z jakością i nadają się do rozliczania budżetu bez tłumaczenia, czym są.

Do tego dochodzi jedna miara własna, wynikająca z tego, co ustaliliście w kroku pierwszym. Jeśli celem była przewidywalność, będzie to liczba wydań wymagających poprawek na gorąco. Jeśli tempo, będzie to długość regresji. Trzy miary, cztery przeglądy w roku, ten sam układ. Po roku macie historię, której nie da się podważyć anegdotą.

Szablon budżetu, który mieści się na jednej stronie

Dokument, który przechodzi przez posiedzenie zarządu, ma jedną stronę i pięć bloków. Pierwszy to koszt obecnego stanu w liczbach z Waszych systemów. Drugi to cel roku wyrażony w jednym zdaniu, uzgodniony z dyrektorem finansowym i technicznym. Trzeci to podział kwoty na cztery pozycje z tabeli wyżej, z krótkim uzasadnieniem przy każdej.

Czwarty blok to rozpisanie na zasoby: etaty, wsparcie zewnętrzne, czas zespołu programistów, szkolenia. Piąty to sposób rozliczenia: trzy miary, cztery przeglądy, wartości wyjściowe podane dziś, żeby za rok nie było sporu, od czego liczymy. Reszta, czyli szczegółowe zestawienia i oferty dostawców, idzie do załącznika.

Ta jedna strona robi coś, czego nie zrobi żadne zestawienie: pozwala zarządowi porównać budżet na jakość z innymi wnioskami inwestycyjnymi w tym samym języku. Dopóki wniosek jest opisany technicznie, konkuruje o uwagę, a nie o pieniądze.

Trzy pułapki, które psują dobry budżet

Wszystko na nowe narzędzia. Zakup platformy jest jednorazowy i łatwy do zaakceptowania, a wdrożenie wymaga miesięcy pracy, których nikt nie zaplanował. Bezpieczna proporcja: jeśli narzędzia przekraczają jedną trzecią budżetu, a nie macie przypisanych osób do ich wdrożenia, coś jest nie tak.

Budżet oderwany od planu produktowego. Jeśli w przyszłym roku firma wchodzi na nowy rynek albo wdraża wymogi regulacyjne, jakość musi być policzona razem z tym przedsięwzięciem, a nie obok. Osobny budżet jakościowy zawsze przegra z budżetem projektu, który ma datę i klienta.

Brak rezerwy na to, czego nie wiecie. Rok zawsze przynosi jedną rzecz, której nikt nie planował: awarię, audyt, zmianę przepisów, migrację wymuszoną przez dostawcę. Rezerwa rzędu dziesięciu procent nie jest oznaką braku planu, tylko jego elementem, i lepiej ją nazwać wprost, niż potem prosić o dofinansowanie w środku roku.

Kiedy zacząć i z kim rozmawiać najpierw

Kalendarz ma tu znaczenie większe, niż się wydaje. Wniosek złożony w momencie, gdy zarząd zamyka już zestawienie na kolejny rok, konkuruje z pozycjami, które były przygotowywane od miesięcy, i przegrywa nie treścią, tylko terminem. Praktyczna zasada mówi, żeby liczby zacząć zbierać kwartał przed planowaniem, a rozmowy prowadzić wtedy, gdy budżety są jeszcze otwarte.

Kolejność rozmów też nie jest obojętna. Najpierw dyrektor techniczny, bo bez jego zgody wniosek wygląda jak inicjatywa jednego działu. Potem osoba odpowiedzialna za finanse, i to nie po to, żeby prosić o pieniądze, tylko żeby uzgodnić sposób liczenia kosztu obecnego stanu. Uzgodniona metoda liczenia jest warta więcej niż najlepsza prezentacja, bo usuwa najczęstszy sposób odrzucenia wniosku, czyli podważenie danych wejściowych.

Na koniec warto przygotować wariant minimalny. Nie jako ustępstwo z góry, tylko jako odpowiedź na pytanie o cięcie, które i tak padnie. Wariant minimalny powinien obejmować wyłącznie ochronę krytycznych ścieżek i tyle informacji zwrotnej, żeby zespół wiedział, kiedy coś się psuje. Wszystko powyżej tego progu jest inwestycją w tempo, a nie w bezpieczeństwo, i tak też warto to nazwać w rozmowie.

Czego lepiej nie wpisywać do budżetu na jakość

Nie warto wpisywać pozycji, których nie umiecie rozliczyć. Każda taka pozycja obniża wiarygodność całości, bo pierwsze pytanie na przeglądzie kwartalnym dotyczy zwykle właśnie jej. Jeśli chcecie sfinansować coś, czego efekt jest odległy albo trudny do zmierzenia, lepiej opisać to wprost jako inwestycję rozwojową z horyzontem dwuletnim niż ukrywać w pozycji operacyjnej.

Nie warto też wpisywać kosztów, które w rzeczywistości należą do innego obszaru. Migracja infrastruktury, przepisanie starego modułu albo wdrożenie nowego systemu księgowego mają swoje budżety i swoich właścicieli. Doklejenie ich do jakości wygląda na próbę przemycenia kosztu i, co gorsza, sprawia, że w rozliczeniu rocznym wynik jakościowy będzie zależał od czegoś, na co zespół QA nie ma wpływu.

Powiązane na Strefie QA

• Jak przekonać zarząd, że potrzebujesz QA, a nie tylko szybszych devów
• Ile kosztuje własny zespół QA, a ile body leasing
• Ile naprawdę kosztuje bug w produkcji i czemu zaniżasz tę liczbę

Źródła:

• DORA, cztery kluczowe metryki dostarczania oprogramowania i ich definicje
• CISQ, The Cost of Poor Software Quality in the US, raport 2022
• Modele współpracy QA, Quality Island
• Audyt QA, Quality Island
• Case Argos i Autono, dane potwierdzone przez klientów: regresja z 5 dni do 10 godzin, 72% mniej awarii w szczycie, 12% wzrostu konwersji, 55% mniej błędów krytycznych w rezerwacjach