Łukasz Pietrucha, z którym rozmawiamy, od czterech lat pełni funkcję QA Managera w Netguru. Jak mówi, jego głównym zadaniem jest “zadbanie o to, abyśmy na poziomie organizacji posiadali pewien wzór, szablon, na podstawie którego można wyprowadzać strategię testowania, dopasowaną do kontekstu konkretnego accounta, konkretnego klienta, konkretnego projektu”. I właśnie na kulturze jakości skupiliśmy się podczas poniższej rozmowy.
“Zostawić jakość na później” to niestety maksyma wielu firm, które gonią za premierą produktu, by gwałtownie na nim zarobić, jakość zostawiają w tyle. Coś możemy z tym zrobić?
Przede wszystkim rozmawiać! W moim odczuciu “jakość” nie ma jednej definicji – to zawsze swoista relacja między człowiekiem, wartością i czasem. Patrząc z tej perspektywy, składowe jakości są różnie definiowane przez pryzmat potrzeb różnych grup odbiorców (którymi notabene są nie tylko użytkownicy końcowi, ale też wewnętrzni interesariusze – jak np. zespół projektowy), a do tego te potrzeby zmieniają się w czasie! Pamiętajmy też, iż istotną (czasem najważniejszą) składową będzie właśnie Time-to-Market. Grunt to dobrze zbudować oczekiwania – widzę sporą przestrzeń do poprawy w tym zakresie.
Potrzebna jest zmiana. Na czym powinna ona polegać?
Dobrym ćwiczeniem na start każdego projektu jest zmapowanie wszystkich interesariuszy – przyda się na pewno, nie tylko w kontekście jakości. Następnym naturalnym krokiem jest zrozumienie potrzeb poszczególnych grup, ustalenie z każdą z nich osobnej „definicji jakości” – inne jej składowe znajdą się na górze listy priorytetów dla zespołu projektowego, inne dla klienta, jeszcze inne dla użytkowników końcowych. Takie ćwiczenie buduje też świadomość, co do tego, jak skomplikowany jest to temat.
Niestety zbyt często przyjmujemy, iż jesteśmy w stanie ulepić jedną, spójną definicję dla wszystkich zainteresowanych. W konsekwencji priorytety zaczynają się rozjeżdżać, siła przykładana jest w niewłaściwych miejscach i rodzą się problemy… Moim zdaniem najważniejsze elementy każdej dobrej strategii jakości to:
1) dobra definicja tego, kto jest zainteresowany jakością i jak ją definiuje,
2) cel i zakres czynności, które mają tym definicjom odpowiadać,
3) produkty pracy, które służyć będą pokazaniu efektów i ocenie dopasowania do zdefiniowanych celów.
C-level team, decydenci czy inna grupa nadzorcza rozumie potrzebę dbania o jakość?
Myślę, iż tak – tylko pamiętajmy, iż oceniają poziom zadbania o tę jakość z perspektywy własnych celów/KPI’s. Rozliczają więc zespoły z efektów, a nie z włożonych wysiłków. W Netguru dążymy do tego, aby osiągać stan „quality built-in”, co przekłada się na to, aby budować procesy/praktyki, które w swoim core uwzględniają jakość i nie generują potrzeby stawiania kolejnych „bramek jakościowych” i dodatkowych etapów sprawdzeń.
Czasem wydawać się może, iż decydenci są „odklejeni od rzeczywistości”, natomiast wkładając wysiłek w rzemiosło samo w sobie, często zapominamy, by w tym wszystkim uwzględnić kontekst biznesowy. W niektórych przypadkach może to oznaczać świadome kompromisy i pominięcie pewnych aspektów jakościowych.
O zagrożeniach wynikających z braku zadbania o jakość chyba nie ma co mówić. Może przemówią zatem korzyści z podejścia do projektu, w którym jakość stawia się wyżej niż termin dostarczenia produktu?
Będąc liderem dużego zespołu QA w dużej organizacji mam przyjemność spotykania się z wieloma historiami, gdzie postawienie na jakość przyniosło spore korzyści biznesowe. U jednego z naszych klientów z branży retail nasi inżynierowie QA zadbali m.in. o to, aby:
- stosowane były dobre praktyki, takie jak m.in. code reviews czy stałe monitorowanie produkcji,
- utrzymywana była aktualna dokumentacja,
- istniała wyważona automatyzacja, tj. dotycząca krytycznych ścieżek biznesowych.
Trzymanie się tych zasad przyniosło wymierne korzyści! Cytując zespół, były to m.in:
- bezstresowe, częste wydania, dostarczające regularnie wartość użytkownikom,
- krótki time-to-market – w przypadku wystąpienia problemu na produkcji jesteśmy w stanie dostarczyć fixa w ciągu jednego dnia lub mniej,
- na przestrzeni ostatniego roku brak sytuacji, w których produkcja była niedostępna dla użytkowników, co świadczy o jej niezawodności – dzięki temu przybywa użytkowników i aplikacja zarabia.
Wszystko, o czym za mało mówi się w branży IT.
Prosto na Twoją skrzynkę.
Pandemia, spowolnienie gospodarcze czy zwolnienia w branży spowodowały, iż organizacje bardziej stawiają na jakość? Czy nie miało to żadnego wpływu na ich podejście?
Od wielu znajomych z branży (pozdrowienia m.in. dla Polish Quality Retreat) słyszę, iż przede wszystkim zmienił się apetyt na ryzyko. Ten trend postępował jeszcze przed wystąpieniem zjawisk, o których mówisz. Jeszcze kilka(naście) lat wstecz nie wyobrażaliśmy sobie testów na produkcji, z ostrożnością korzystaliśmy z A/B testów czy “phased rollout”. Dzisiaj to już normalność. Organizacje nie dążą do uzyskania najwyższej jakości od samego początku. Raczej nastawione są na eksperymenty, iterowanie i udoskonalanie etapami, na bazie spływających opinii od użytkowników końcowych.
Dużo ważniejsze jest, by w ogóle zaistnieć ze swoją usługą/produktem niż dopieszczać ją bardzo długo, narażając się na to, iż konkurencja (nawet w niedoskonałej formie) zacznie zgarniać nam potencjalnych klientów. Patrząc na to z jeszcze innej strony (jakkolwiek brutalnie to nie brzmi), to redukcje w zespołach niejako wymuszają, by przekrojowo budować kulturę jakości, gdy nie stać nas na dedykowany do tego etat.
Zatrzymajmy się na chwilę na kulturze jakości. Jak podchodzisz do strategii testowania? Jak ona wygląda w Twoim zespole?
Na wstępnie muszę nadmienić, iż nie prowadzę zespołu projektowego, tylko zespół jako całość – jako praktykę. Dlatego moim zadaniem jest przede wszystkim zadbanie o to, abyśmy na poziomie organizacji posiadali pewien wzór, szablon, na podstawie którego można wyprowadzać strategię testowania, dopasowaną do kontekstu konkretnego accounta, konkretnego klienta, konkretnego projektu. Trzeba jednak pamiętać, iż kultura jakości to pojęcie dużo szersze, wykraczające daleko poza ramy zespołu QA.
Jednym z filarów w naszej organizacji, który przyczynia się do budowania kultury jakości są tzw. “Delivery Fundamentals”, czyli zestaw najlepszych praktyk inżynieryjnych, dzięki którym dbamy zarówno o produkt, jak i proces, prowadzący do jego powstania. Wśród tych zasad znajdziemy między innymi te, dotyczące dbania o dokumentację, możliwość szybkiego i częstego deploymentu (wraz z potencjalnym rollbackiem) czy też monitorowania produkcji i szybkiego reagowania w razie problemów.
Który zespół odpowiada za jakość wytwarzanego kodu – Product Engineering czy QA?
Zawsze cały zespół! Najbardziej dojrzała z mojej perspektywy definicja roli inżyniera ds. jakości to ta, która mówi, iż jest to osoba odpowiadająca za zbudowanie powtarzalnego i godnego zaufania procesu analizy jakości, osoba będąca mentorem i katalizatorem wszystkich aktywności wokół jakości (rozsądnie je przyspieszając lub spowalniając). Natomiast za skuteczne wykonanie i dowiezienie tej jakości odpowiedzialni są solidarnie wszyscy członkowie zespołu projektowego.
Brzmi świetnie, ale czy tylko w teorii? Praktyka pokazuje coś innego?
Niekoniecznie. To jedno z tych pytań, na które aż kusi, by odpowiedzieć “to zależy”. Może nie jestem w stanie sypać przykładami jak z rękawa, ale mamy w organizacji przykłady projektów, w których “Whole team approach” przyniósł doskonałe rezultaty – do tego stopnia, iż dwutygodniowa, urlopowa nieobecność QA nie jest dla zespołu żadnym wielkim wyzwaniem.
Co Twoim zdaniem sprawia, iż zawód QA jest przyszłościowy?
To, co od zawsze było w nim w pewnym sensie pociągające: fakt, iż kompletnie nie wiemy, co nas czeka! W IT nie ma nudy, ciągle coś się zmienia. Biblioteki mają kolejne, lepsze wersje, technologie zmieniają się i rozkwitają. Dlatego zawsze czeka nas coś nowego, co będzie wymagało nauki, pogłębienia tematu, odnalezienia się w tej nowej rzeczywistości. w tej chwili generative AI jest praktycznie wszędzie – to otwiera szereg możliwości i perspektyw, które brzmią naprawdę ekscytująco. A patrząc już tak zupełnie z lotu ptaka, to zaczęliśmy od tego, iż o jakości wciąż mówi się za mało. I to nie jest nic nowego i raczej zawsze ten głos sumienia będzie potrzebny.
Jak dbasz o to, by zespół, za który odpowiadasz rozwijał się?
Gdy opowiadam o swojej roli, to często mówię o tym, iż muszę łączyć dwa światy: świat potrzeb biznesu (w tym również, a może przede wszystkim naszych klientów) i świat potrzeb ludzi. Trzeba być wrażliwym na potrzeby jednej i drugiej strony, obserwować zmieniające się trendy na rynku, ale też słuchać sugestii naszych QA oraz pogłębiać potrzeby pojawiające się przy okazji startowania nowych projektów (lub rozmów z klientami jeszcze na etapie sprzedaży).
Sposób realizacji jest dla mnie wtórny: bardzo często podobną wiedzę można zdobyć albo poprzez warsztat, albo w sesjach mentoringowych, albo zwyczajnie udając się na konferencję czy też czytając książkę. Każdy z nas ma swój ulubiony sposób. Mając do dyspozycji budżet rozwojowy dla całego zespołu, dysponuję nim tak, by pewną część przeznaczyć na wnioski indywidualne, a pewną na grupowe przedsięwzięcia.
Co jest sukcesem w pracy QA Managera? Jak mierzysz, czy to, co robisz, ma sens?
”Biorców” efektów mojej pracy jest wielu: jest organizacja ze swoimi celami i KPI mierzącymi ich realizację (revenue, marża), są członkowie zespołu, którzy chcą się rozwijać i pracować w zadowalających projektach (tutaj miarą jest ich zadowolenie, a ściślej to, w jakim stopniu poleciliby znajomym dane miejsce pracy) i wreszcie są nasi klienci, którzy chcieliby mieć pewność, iż dostają jak najlepiej dostarczoną usługę, za którą zapłacili (tutaj miarą jest NPS, czyli Net Promoter Score). Oczywiście każda z tych grup ma swoje wyobrażenie „świętego Graala”, czyli największego spełnienia oczekiwań. W praktyce często trzeba balansować i dążyć do tego, by jak najbardziej się do niej zbliżyć.
“Wisienką na torcie” może być wewnętrzna widoczność w innych działach: gdy słyszy się “super prowadzisz dział QA, chcę swój prowadzić w podobny sposób”, to jeden z najlepszych komplementów, jaki może usłyszeć QA Manager.
Łukasz Pietrucha. QA Staff Engineering Manager w Netguru. Doświadczony tester, konsultant, menedżer. Lider, trener i mentor testerów, specjalizujący się głównie usprawnianiu procesów i budowaniu efektywnych zespołów. Popularyzator oraz pasjonat zapewnienia jakości oraz zwinnego podejścia do wytwarzania oprogramowania. Współzałożyciel oraz organizator WrotQA – lokalnej społeczności testerskiej we Wrocławiu. Mówca polskich i zagranicznych konferencji testerskich. Uważa, iż „to zależy” to najlepszy wstęp do ciekawej dyskusji.
