KPI dla zarządu: jak przełożyć wyniki QA na język, który rozumie CFO

KPI QA dla zarządu to temat, który rzadko ma dobry przekład na pieniądze, a to najczęstszy powód, dla którego dobre wyniki testowania nie przekonują zarządu.

Macie za sobą dobry kwartał. Pokrycie testami wzrosło, liczba zgłoszonych defektów spadła, regresja przyspieszyła.

Wchodzicie z tym slajdem na komitet zarządu i dostajecie dokładnie to, czego się spodziewaliście: uprzejme skinienie głową i pytanie o budżet na kolejny kwartał, zadane tak, jakby poprzedni slajd w ogóle nie padł.

Problem nie leży w wynikach. Problem w tym, że mówiliście o jakości, a CFO na sali liczy w złotówkach, ryzyku i marży. Wasze liczby przeleciały obok, nie dlatego że były złe, tylko dlatego że nie były w jego języku.

Ten artykuł jest instrukcją tego przekładu: jak wziąć metryki, które i tak już zbieracie, i policzyć je tak, żeby CFO zobaczył w nich to samo, co widzi przy każdej innej linii budżetu, czyli koszt, ryzyko i zwrot. Zanim przejdziemy do konkretnych przeliczników, warto zrozumieć, skąd ten rozdźwięk w ogóle się bierze.

Dlaczego zarząd nie słyszy raportów QA, mimo że ich słucha

QA i finanse mówią dwoma różnymi językami, i żaden z nich nie jest błędny. Po prostu optymalizują pod inny cel.

Zespół testowy raportuje pokrycie testami, gęstość defektów, wskaźnik wykonania przypadków testowych, procent automatyzacji. To są metryki procesu, opisują, jak dobrze wykonaliście pracę.

CFO patrzy na rachunek zysków i strat, rezerwy na ryzyko, zwrot z inwestycji, koszt kapitału. To są metryki wyniku, opisują, co organizacja z tej pracy dostała. Między jednym a drugim nie ma automatycznego przełożenia, dopóki ktoś świadomie go nie zbuduje.

Stąd bierze się scena znana chyba każdemu Head of QA: slajd „pokrycie testami wzrosło z 60 do 75%” trafia na komitet zarządu i pada w ciszy. Odpowiada na pytanie, którego nikt na tej sali nie zadał.

CFO nie finansuje procesów, finansuje wyniki. Pokrycie testami samo w sobie nie jest wynikiem, jest tylko krokiem do niego: mniej ryzyka, mniej błędów na produkcji, krótszy czas do wydania.

Dopóki ten krok nie zostanie doliczony do konkretnej złotówki albo konkretnego ryzyka, zostaje wewnętrzną miarą jakości pracy zespołu, nie argumentem biznesowym.

Dobra wiadomość jest taka, że naprawa tego nie wymaga mówienia mniej o jakości ani budowania nowego systemu raportowania od zera.

Wymaga dopisania jednej dodatkowej kolumny do metryk, które już zbieracie: ile ta liczba kosztuje albo ile chroni w złotówkach. Reszta tego artykułu pokazuje, skąd wziąć tę kolumnę i jak ją policzyć w sposób, który przetrwa pytanie kontrolne od CFO, nie tylko wygląda dobrze na jednym slajdzie.

Model kosztu jakości: wspólny język dla QA i finansów

Punktem wyjścia do tego przekładu jest model kosztu jakości, w skrócie COQ, spopularyzowany w latach pięćdziesiątych przez Josepha Jurana. Do dziś jest podstawową ramą American Society for Quality.

Dzieli on wszystkie pieniądze związane z jakością na cztery koszyki. Koszty prewencji to wszystko, co robicie, żeby błąd w ogóle nie powstał: przegląd wymagań, statyczna analiza kodu, szkolenia zespołu.

Koszty oceny to samo testowanie, czyli sprawdzenie, czy produkt spełnia wymagania, zanim trafi dalej. Koszty błędów wewnętrznych to defekty złapane przed wydaniem, ale wymagające poprawki, opóźnienia i ponownego testu.

Koszty błędów zewnętrznych to defekty, które wymknęły się na produkcję: obsługa zgłoszeń, naprawa na żywym systemie, czasem odszkodowanie albo utrata klienta.

Ta rama jest przydatna dla CFO z jednego konkretnego powodu: pieniądze wydane wcześnie, na prewencję i ocenę, widać wprost w budżecie QA. Pieniądze spalone na błędy są za to rozproszone po zupełnie innych liniach budżetu: wsparciu klienta, operacjach, czasem dziale prawnym.

Dlatego QA wygląda jak czysty koszt, mimo że w rzeczywistości jest jedynym działem, który zapobiega znacznie większym kosztom gdzie indziej w organizacji.

Dopóki nikt nie zsumuje tych rozproszonych kosztów błędów w jedno miejsce, porównanie „ile kosztuje QA” do „ile kosztowałby brak QA” jest niemożliwe do zrobienia uczciwie. A to właśnie to porównanie chce zobaczyć każdy CFO, zanim zaakceptuje budżet.

Pisaliśmy już o jednej stronie tego rachunku w tekście Dług technologiczny pożera nawet 40% budżetu IT, gdzie skupialiśmy się na tym, ile w ogóle kosztuje zaniedbana jakość w skali całej organizacji.

Tutaj patrzymy na ten sam problem z drugiej strony: nie ile to kosztuje w ogóle, tylko jak przełożyć konkretne, codzienne metryki QA na konkretne linie budżetu, które CFO już zna i którymi na co dzień operuje.

Cztery metryki QA i ich odpowiednik w języku CFO

Nie każda metryka QA nadaje się na slajd dla zarządu, i to nie jest wada tych metryk, tylko kwestia doboru. Dobry KPI QA dla zarządu składa się z kilku takich metryk, nie ze wszystkich naraz.

Dobra metryka na slajd zarządu ma jedną cechę: da się ją w rozsądnym czasie pomnożyć przez coś wyrażonego w złotówkach. Poniżej cztery metryki, które akurat tę cechę mają, razem z prostym przelicznikiem na start.

Dwie pozycje z tej tabeli warto rozwinąć, bo najczęściej to na nich pęka rozmowa z zarządem.

Pierwsza to odsetek wydań kończących się awarią, czyli change failure rate. Ta metryka jest ulubioną metryką CFO, mimo że rzadko pojawia się na slajdach QA.

Powód jest prosty: przestój ma bezpośredni, łatwy do policzenia koszt godzinowy. W e-commerce to utracona sprzedaż, w systemie wewnętrznym to godziny pracy zespołów, które czekają.

Wystarczy znać ten jeden koszt godzinowy, żeby każda poprawa change failure rate zamieniła się w konkretną kwotę oszczędności rocznie, bez żadnych dodatkowych założeń.

Druga to czas cyklu regresji. Zespoły QA traktują go jako metrykę wewnętrznej sprawności, ale dla CFO to wprost czas do rynku.

Każdy dzień, o który regresja wydłuża wydanie, to dzień, w którym konkurencja może wydać coś podobnego pierwsza, a funkcja czekająca w kolejce nie generuje jeszcze żadnego przychodu.

To dokładnie ten mechanizm stoi za czterema liczbami z naszego projektu dla klienta Argos, do których wracamy niżej. Skrócenie regresji nie było celem samym w sobie, było środkiem do szybszego wydawania, a szybsze wydawanie miało bezpośredni skutek finansowy.

Co pokazują liczby elitarnych zespołów, kiedy przełożyć je na przestój

Najlepszym publicznie dostępnym punktem odniesienia dla tabeli wyżej jest raport Accelerate State of DevOps od zespołu DORA przy Google. To metodologia, która do dziś jest branżowym standardem porównywania zespołów inżynierskich.

Raport dzieli organizacje na cztery poziomy wydajności i pokazuje, jak daleko od siebie leżą skrajne grupy w czterech twardych miarach.

Ostatnia liczba w tej tabeli, czas przywrócenia usługi po awarii, jest najprostsza do przeliczenia na złotówki ze wszystkich, jakie tu padły.

Wystarczy jedna dana wejściowa, którą Wasz dział finansowy zwykle już ma: koszt godziny niedostępności systemu.

Pomnóżcie różnicę godzin między Waszym dzisiejszym czasem przywrócenia usługi a poziomem elitarnym przez ten koszt, a dostaniecie dokładnie tę liczbę, której szuka CFO, bez żadnego dodatkowego modelu finansowego.

To samo dotyczy odsetka wdrożeń kończących się awarią: każdy punkt procentowy mniej to konkretna liczba unikniętych awarii rocznie, a każda z nich ma swój koszt godzinowy z tej samej tabeli wyżej.

Case: jak liczymy to u naszych klientów

Teoria jest tyle warta, ile da się z niej policzyć na żywym projekcie, więc przejdźmy do liczb, które mamy potwierdzone.

U klienta Argos, sklepu e-commerce, regresja przed każdym większym wydaniem trwała pięć dni. Po uporządkowaniu automatyzacji skróciła się do dziesięciu godzin.

Sama w sobie ta liczba jest metryką QA. W języku CFO oznacza to konkretnie tyle: zespół mógł wydawać częściej, a częstsze wydania bezpośrednio przełożyły się na trzy efekty biznesowe, wzrost konwersji o 12%, spadek liczby błędów krytycznych na produkcji o 46%, redukcję awarii w okresach szczytowych o 72%.

Rozpiszmy to dokładnie tak, jak rozpisalibyśmy dla CFO, nie dla zespołu QA.

Wzrost konwersji o 12% to bezpośredni przychód, policzalny z dowolnego miesiąca sprzedaży, bo stabilny checkout i płatności oznaczają mniej porzuconych koszyków.

Spadek błędów krytycznych o 46% to niższy koszt błędów zewnętrznych z modelu COQ wyżej: mniej zgłoszeń do wsparcia, mniej pilnych hotfixów wypychanych poza normalny cykl wydania.

Redukcja awarii w szczytach o 72% to wprost chroniony przychód w najdroższych godzinach roku, bo awaria checkoutu w Black Friday kosztuje zupełnie inaczej niż ta sama awaria we wtorek po południu.

Żadna z tych trzech liczb nie wymagała nowego modelu finansowego, tylko doliczenia jednej kolumny do metryki, którą zespół QA i tak już miał.

U klienta Autono, firmy z branży automotive i wynajmu samochodów, mechanizm był podobny, tylko inne było ryzyko biznesowe.

System pozostał stabilny przy obciążeniu większym o 120% w sezonie wakacyjnym, a liczba błędów krytycznych w procesie rezerwacji spadła o 55%.

W tej branży godzina niedostępności systemu rezerwacji w szczycie sezonu nie jest tylko utratą jednej transakcji, tylko utratą klienta, który w tym momencie ma otwarte trzy inne karty przeglądarki z konkurencją.

Tam KPI dla zarządu nie był procentem, tylko wprost liczbą rezerwacji, które system utrzymał zamiast stracić w najgorszym możliwym momencie.

Nie każdy klient da się rozliczyć jedną liczbą na dole slajdu, i to też jest ważna część tego artykułu.

Dla PKO BP opracowaliśmy i wdrożyliśmy strategię jakości oprogramowania dla całej organizacji razem z audytem procesów QA i szkoleniami zespołów. Dla ChaosGears, firmy z branży medycznej, budowaliśmy dokumentację testową i odbiorczą razem z procesami automatyzacji.

W obu przypadkach nie mamy jeszcze upublicznionych liczb finansowych z tych projektów, ale mechanizm przełożenia jest ten sam co wyżej. Tylko druga kolumna tabeli COQ nie nazywa się „koszt”, tylko „ryzyko regulacyjne” albo „ryzyko dla pacjenta”.

W sektorze regulowanym i w ochronie zdrowia CFO i tak liczy to w złotówkach, tylko robi to przez rezerwę na ryzyko albo potencjalną karę, nie przez utracony przychód.

Jak to wygląda w praktyce, kiedy robimy to u klienta

Nie sprzedajemy osobnej usługi o nazwie „przełożenie QA na finanse”, bo takiej pozycji nie ma w naszej ofercie.

Ten mechanizm jest jednak stałym elementem audytu QA: obok samego stanu procesów i pokrycia testami sprawdzamy, które metryki organizacja już zbiera i czy da się je w prosty sposób podłączyć do linii budżetowych, które zna Wasz CFO.

Tam, gdzie klient chce iść o krok dalej i mieć to na stałe, a nie jednorazowo, budujemy strategię jakości oprogramowania dla całej organizacji. Dokładnie taką, jaką wdrożyliśmy dla PKO BP: spójny zestaw KPI, jedna metoda liczenia, ustalona z góry częstotliwość raportowania do zarządu.

Tam, gdzie metryki są już dobre, ale rozproszone po kilku systemach i nikt nie zbiera ich w jedno miejsce w spójny sposób, pomaga uporządkowanie procesu, czyli TestOps i QualityOps.

To spięcie testowania, automatyzacji i CI/CD w jeden system, z którego jedna, zawsze ta sama formuła liczy dane wejściowe do slajdu dla zarządu, zamiast ręcznego zbierania liczb przed każdym komitetem.

Jak zbudować własny slajd KPI dla zarządu

Źródło: opracowanie własne Quality Island, metoda stosowana w naszych audytach QA.

Największa pułapka w tym procesie to pokusa, żeby na pierwszy slajd wrzucić wszystko, co zespół QA umie zmierzyć.

Im więcej liczb, tym słabszy każdy pojedynczy argument, bo CFO ma w pamięci dwie, może trzy liczby ze spotkania, nie piętnaście.

Lepiej zacząć od jednej metryki, którą umiecie przeliczyć bezbłędnie i obronić przy pytaniu kontrolnym, niż od całego panelu, w którym połowa liczb nie ma jeszcze przelicznika na złotówki.

Najczęściej zadawane pytania o KPI QA dla zarządu

Czy da się przełożyć KPI QA na pieniądze bez udziału działu finansów?

Tak, do pierwszej, przybliżonej wersji nie potrzebujecie nikogo z finansów w pokoju. Koszt godziny niedostępności, średni koszt obsługi zgłoszenia albo przychód z jednej funkcji miesięcznie to dane, które zwykle już gdzieś w organizacji istnieją, u operacji, w dziale obsługi klienta albo w produkcie. Dopiero kiedy chcecie, żeby liczba przetrwała pytanie kontrolne CFO co do metodologii, warto ją z finansami zweryfikować.

Która metryka QA najłatwiej przekłada się na język zarządu?

Odsetek wydań kończących się awarią i czas przywrócenia usługi po awarii, bo obie mają bezpośredni, prosty do ustalenia mnożnik: koszt godziny przestoju. Pokrycie testami jest trudniejsze, bo samo w sobie nie jest wynikiem finansowym, tylko wskaźnikiem ryzyka rezydualnego, więc wymaga dodatkowego kroku, oszacowania wartości tego, co przez niepokrytą ścieżkę faktycznie przechodzi.

Czy samo pokrycie testami w procentach to dobry KPI dla zarządu?

Nie wprost. Pokrycie testami to metryka procesu, nie wyniku biznesowego, więc sam wzrost z 60 do 80% nic zarządowi nie mówi, dopóki nie wiadomo, co konkretnie te dodatkowe 20% chroni. Lepiej pokazywać ją jako wejście do metryki ryzyka: wartość transakcji albo funkcji, które dzięki temu pokryciu są dziś zabezpieczone, a wcześniej nie były.

Jak często aktualizować taki slajd dla zarządu?

Kwartalnie, tą samą metodą liczenia za każdym razem. Trzecia teza wyżej nie jest przypadkowa: CFO ufa trendowi liczonemu jedną, powtarzalną formułą znacznie bardziej niż pojedynczej, efektownej liczbie z jednego kwartału, nawet jeśli ta liczba jest prawdziwa.

Powiązane na blogu Quality Island

• Dług technologiczny pożera nawet 40% budżetu IT
• Koszty i oszczędności testowania oprogramowania
• Audyt jakości oprogramowania

Pełna lista źródeł

• ASQ, Cost of Quality
• CISQ, Cost of Poor Software Quality in the US, 2022 Report
• Google Cloud DORA, Accelerate State of DevOps Report 2019