7 książek, które zmieniły moje myślenie o pracy w IT

Listy książek dla testerów zwykle zawierają te same pozycje o technikach testowania i przechodzą przez branżę bez śladu. Ta lista jest inna, bo żadna z siedmiu książek nie jest podręcznikiem QA. Wszystkie zmieniły natomiast sposób, w jaki patrzę na jakość, zespoły i decyzje w projektach informatycznych, a kilka z nich zmieniło konkretne rzeczy, które robimy u klientów.

Wspólny mianownik jest jeden: każda z nich pokazuje, że problemy z jakością prawie nigdy nie są problemami technicznymi. Są problemami przepływu pracy, mierzenia niewłaściwych rzeczy, dawania zespołom sprzecznych celów albo braku odwagi w rozmowie o kosztach. Poniżej co dała mi każda z nich i komu warto ją podsunąć.

Projekt Feniks, czyli po co komu przepływ pracy

Powieść o kierowniku, który dostaje do naprawy pogrążony w chaosie dział informatyki. Brzmi jak lektura obowiązkowa dla działu operacji, a jest lekturą dla każdego, kto zastanawia się, dlaczego jego zespół pracuje na pełnych obrotach i nic nie kończy. Ta książka wyjaśnia, że praca w toku zachowuje się jak korek na autostradzie: im więcej równoległych zadań, tym wolniej porusza się każde z nich.

Dla QA to lektura o tym, dlaczego testowanie ustawione na końcu procesu zawsze będzie wąskim gardłem i zawsze będzie obwiniane o opóźnienia. Nie dlatego, że testerzy pracują wolno, tylko dlatego, że dostają całą kumulację wcześniejszych opóźnień w ostatnim tygodniu przed wydaniem. Po tej lekturze zaczyna się inaczej rozmawiać z zarządem: nie o liczbie testerów, tylko o kolejce.

Accelerate, czyli intuicja podparta danymi

Jeśli macie przeczytać z tej listy tylko jedną pozycję, niech to będzie ta. To książka o badaniach nad wydajnością dostarczania oprogramowania, z których wyrósł program DORA i cztery miary używane dziś w setkach organizacji: częstotliwość wdrożeń, czas wprowadzenia zmiany, czas przywrócenia usługi i odsetek nieudanych wdrożeń.

Wartość tej książki dla ludzi z QA polega na czymś jeszcze. Pokazuje, że szybkość i stabilność nie są przeciwstawne, co burzy najczęstszy argument używany przeciwko jakości: „nie mamy czasu na testy, musimy dowozić”. Zespoły, które dowożą najczęściej, mają jednocześnie najniższy odsetek nieudanych wdrożeń. To jest dokładnie ten argument, którego brakuje w rozmowach o budżecie.

Pragmatyczny programista, czyli jakość zaczyna się w kodzie

Książka o rzemiośle programisty, ale czytana przez testera brzmi jak katalog przyczyn błędów, które potem znajdujemy. Zasada nieduplikowania wiedzy, ortogonalność, kruche założenia, kod bez asercji. Każde z tych pojęć ma bezpośrednie przełożenie na to, ile znajdziemy defektów i jak trudno będzie je odtworzyć.

Praktyczna korzyść dla testera jest taka, że po tej lekturze łatwiej rozmawia się z zespołem programistów o przyczynach, a nie o objawach. Zgłoszenie „ten sam błąd wraca w trzech miejscach” brzmi inaczej, gdy potraficie nazwać mechanizm, który go powiela.

Czysty kod, czyli skąd naprawdę biorą się błędy

Pozycja, o którą w branży toczą się spory, i słusznie, bo część zaleceń zestarzała się gorzej niż inne. Zostaje jednak myśl podstawowa: kod czyta się wielokrotnie częściej, niż się go pisze, a większość defektów bierze się z niezrozumienia istniejącego kodu, nie z braku umiejętności.

Dla zespołu jakości ma to konsekwencję operacyjną. Jeśli obszar produktu jest trudny do czytania, będzie też trudny do przetestowania i to tam warto zawczasu skierować uwagę. Czytelność bywa lepszym predyktorem ryzyka niż liczba zmian w module.

Systemy danych intensywnych, czyli jakość w skali

Najbardziej techniczna pozycja na liście i jedyna, przy której trzeba się realnie napracować. W zamian daje coś, czego nie da żaden kurs testowania: zrozumienie, co dokładnie może pójść nie tak, gdy dane wędrują między usługami, replikami i kolejkami.

Po tej lekturze inaczej pisze się scenariusze testowe dla integracji. Przestaje wystarczać sprawdzenie, że dane doszły. Zaczynacie pytać, co się stanie przy powtórzeniu komunikatu, przy zmianie kolejności, przy chwilowej niedostępności jednej usługi i przy odczycie z repliki, która nie zdążyła się zaktualizować. To są miejsca, w których rodzą się najdroższe awarie produkcyjne.

Staff Engineer, czyli wpływ bez stanowiska

Książka o ścieżce eksperckiej dla inżynierów, którzy nie chcą zarządzać ludźmi, ale chcą mieć wpływ na to, co dzieje się w organizacji. Dla testerów z kilkunastoletnim stażem to często brakujące ogniwo, bo w wielu firmach jedyną awansową ścieżką jest przejście na stanowisko kierownicze.

Najbardziej użyteczna część dotyczy pracy nad projektami, które nie mają właściciela, i budowania zaufania w organizacji, zanim będzie potrzebne. Osoba, której zdanie liczy się w rozmowie o architekturze, wpływa na jakość mocniej niż osoba pisząca najlepsze przypadki testowe.

The Making of a Manager, czyli kultura wygrywa z procesem

Podręcznik dla świeżo upieczonych liderów, napisany bez patosu i bez teorii przywództwa. Dla mnie najważniejszy był fragment o tym, że proces jest tylko zapisem zachowań, które zespół i tak akceptuje. Jeśli ludzie uważają, że wydanie w piątek wieczorem jest w porządku, żadna procedura tego nie zatrzyma.

To wyjaśnia, dlaczego wdrożenia procesów jakościowych tak często kończą się dokumentem, do którego nikt nie zagląda. Zmiana zaczyna się od tego, co zespół uzna za wstyd, a nie od tego, co zapiszecie w regulaminie.

Dlaczego akurat te siedem

Bo żadna z nich nie mówi, jak testować, a każda zmienia to, co uznajecie za problem wart uwagi. Podręczniki testowania są potrzebne i uczymy z nich na szkoleniach, ale one odpowiadają na pytanie „jak”. Te książki odpowiadają na pytanie „dlaczego to nie działa”, a to jest pytanie, które zadaje sobie każdy, kto pracuje w jakości dłużej niż kilka lat.

Jest też powód praktyczny. W rozmowie z zarządem, architektem albo kierownikiem produktu rzadko przydaje się wiedza o technikach projektowania testów. Przydaje się wspólny język: przepływ pracy, koszt opóźnienia, gwarancje spójności, kultura zespołu. Te książki tego języka uczą, a bez niego argumenty z obszaru jakości zatrzymują się na granicy działu.

Jeśli macie czas na jedną, weźcie Accelerate. Jeśli na dwie, dołóżcie Projekt Feniks. Reszta świetnie się dokłada, ale te dwie zmieniają rozmowę o jakości najszybciej, bo dają ramy i liczby jednocześnie.

Czego na tej liście nie ma i dlaczego

Nie ma tu ani jednej pozycji o technikach projektowania testów, o narzędziach ani o certyfikacji. Nie dlatego, że są niepotrzebne, bo są i sam z nich korzystam. Powód jest inny: ta wiedza starzeje się szybko i lepiej czerpać ją z aktualnej dokumentacji oraz z praktyki niż z książki wydanej pięć lat temu. Narzędzie opisane w druku zdąży zmienić interfejs, zanim skończycie rozdział.

Nie ma też klasyków o zarządzaniu jakością, które traktują ją jako zestaw procedur do wdrożenia. Mają swoją wartość historyczną, ale w projektach, które prowadzimy dzisiaj, procedura rzadko bywa problemem. Problemem jest to, że nikt jej nie stosuje, bo nie rozumie po co, albo że stosuje ją formalnie, żeby mieć spokój przy audycie. Na to książka o procedurach nie pomoże.

Świadomie pominąłem też literaturę o zwinnych metodykach. Nie dlatego, że temat jest nieważny, tylko dlatego, że w większości zespołów, które odwiedzamy, sposób pracy jest już wybrany i nikt go nie będzie zmieniał z powodu przeczytanej książki. Znacznie więcej daje zrozumienie mechanizmów, które działają niezależnie od nazwy metodyki: kolejka pracy, koszt przełączania kontekstu, sprzężenie zwrotne, zaufanie w zespole.

Ostatnia uwaga dotyczy tempa. Siedem książek to nie jest lista na kwartał. To zestaw na dwa, trzy lata, przy założeniu, że po każdej lekturze próbujecie zmienić w pracy jedną rzecz. Bez tej próby zostaje wam poczucie oczytania i nic więcej, a to akurat w jakości nie zmienia żadnej metryki.

Jak czytać, żeby cokolwiek z tego zostało

Metoda, która sprawdza się u mnie i u kilku osób z zespołu, jest banalna. Po każdym rozdziale zapisujecie jedno zdanie: co z tego dotyczy naszego projektu. Nie streszczenie, nie cytat, tylko konkret. Po skończonej książce macie kilkanaście takich zdań, z czego zwykle dwa albo trzy nadają się do wdrożenia od razu, a reszta przyda się przy kolejnej decyzji.

Druga rzecz to czytanie w parze z kimś z innego obszaru. Ta sama książka czytana przez testera i przez programistę albo przez kierownika produktu wywołuje zupełnie inne wnioski, a rozmowa o tej różnicy bywa cenniejsza niż sama lektura. W kilku zespołach, z którymi pracowaliśmy, tak zaczynały się realne zmiany w procesie wydawniczym: nie od decyzji z góry, tylko od rozmowy dwóch osób nad tym samym rozdziałem.

Powiązane na Strefie QA

• Najlepsi testerzy, których znałem, nie byli najlepsi technicznie
• Nie chodzi o lepszych ludzi, chodzi o system: jakość jako kultura, nie dział
• Po czym poznać, że Twój pipeline testów jest za wolny, by mieć sens

Źródła:

• Gene Kim, Kevin Behr, George Spafford, The Phoenix Project, IT Revolution
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate, IT Revolution
• Andrew Hunt, David Thomas, The Pragmatic Programmer, wydanie na 20 lecie
• Martin Kleppmann, Designing Data Intensive Applications
• Will Larson, Staff Engineer: Leadership Beyond the Management Track
• Julie Zhuo, The Making of a Manager
• DORA, program badawczy i cztery kluczowe metryki wywodzące się z Accelerate