Zmienił się apetyt na ryzyko. Organizacje w końcu kładą nacisk na budowę kultury jakości

Pandemia, spowolnienie gospodarcze czy zwolnienia w branży spowodowały, że 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ę, że 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, że 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ć, że 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ć, że 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, że 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, że dwutygodniowa, urlopowa nieobecność QA nie jest dla zespołu żadnym wielkim wyzwaniem.  

Co Twoim zdaniem sprawia, że zawód QA jest przyszłościowy?

To, co od zawsze było w nim w pewnym sensie pociągające: fakt, że 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. Obecnie 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, że 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, że 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ść, że 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, że „to zależy” to najlepszy wstęp do ciekawej dyskusji.

Nauka programowania, work-life balance, a może zarobki w IT?

Powiedz nam, o czym najchętniej czytasz. Chcemy poznać Cię lepiej – po to, by dobierać jeszcze bardziej interesujące treści!