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

Czytamy wiele książek. Część z nich daje inspirację, część porządkuje wiedzę, część po prostu dobrze się czyta. Ale tylko nieliczne realnie zmieniają decyzje, które później podejmujesz jako lider, head zespołu, architekt, QA Lead, czasem po prostu jako człowiek, który ma dowieźć wynik i nie zwariować. Te siedem zrobiło dokładnie to. Nie sprawiły, że pisałem lepszy kod. Sprawiły, że inaczej patrzę na ludzi, procesy, ryzyko i jakość. I co ważne, to nie są tytuły na półkę, tylko takie, po których w pewnym momencie łapiesz się na tym, że mówisz inaczej na spotkaniach, inaczej budujesz backlog i inaczej liczysz koszt błędów.

Nie obiecuję, że po nich będziesz szczęśliwszy. Obiecuję, że będziesz bardziej świadomy. A w IT świadomość zwykle kończy się lepszymi decyzjami.

The Phoenix Project, moment, w którym DevOps przestał być buzzwordem

To była pierwsza książka, po której naprawdę zrozumiałem, że DevOps nie jest zestawem narzędzi ani magiczną nazwą na nowy pipeline. To jest sposób myślenia o całej organizacji. Fabuła jest tylko pretekstem, bo sedno leży w tym, jak system pracy potrafi zmielić ludzi nawet wtedy, gdy wszyscy są kompetentni i mają dobre intencje. Najmocniej zostają trzy rzeczy: flow, feedback i ciągłe uczenie się, rozumiane nie jako szkolenia raz w roku, tylko jako codzienne poprawianie tego, co boli.

Największe odkrycie, które wraca do mnie do dziś, jest banalnie brutalne. Wąskim gardłem w IT prawie nigdy nie jest technologia. Są nim zależności, ręczne przekazania, silosy i brak wspólnej odpowiedzialności. Jeśli chcesz poprawić jakość, to często nie zaczynasz od narzędzi testowych, tylko od tego, jak praca płynie przez zespół i gdzie stoi w kolejce.

Wpływ na QA był u mnie bardzo konkretny. Zamiast traktować testowanie jako ostatnią bramkę, przestawiliśmy się na współodpowiedzialność. Developerzy brali testy jednostkowe i kontraktowe jako część definicji zrobione, QA koncentrowało się na ryzyku biznesowym, krytycznych ścieżkach i tym, co naprawdę ma potencjał zaboleć klienta. W praktyce oznaczało to mniej spięć, mniej teatralnych odbiorów i mniej „wrzutów na ostatnią chwilę”. To książka, po której łatwiej jest powiedzieć na spotkaniu jedno zdanie, które robi różnicę: nie dyskutujmy, czy dowieziemy, tylko co dziś blokuje przepływ.

Accelerate, kiedy intuicja dostała twarde dane

W świecie IT lubimy opinie. Każdy ma historię, każdy ma doświadczenie, każdy ma swoją wersję prawdy. „Accelerate” zrobiło coś rzadkiego, bo dało liczby tam, gdzie wcześniej była wiara. Po tej książce metryki DORA przestały być u mnie ciekawostką z konferencji, a zaczęły być normalnym językiem rozmowy o tym, czy system dowozi. Częstotliwość wdrożeń, lead time, MTTR, change failure rate, to są wskaźniki, które nie pytają, czy zespół jest zapracowany. One pytają, czy system pracy jest zdrowy.

Najważniejsza lekcja jest prosta, choć nie zawsze wygodna. Elitarne zespoły nie są szybsze dlatego, że mają lepszych ludzi. Są szybsze dlatego, że konsekwentnie optymalizują cały system, a nie tylko fragmenty. I to jest moment, kiedy QA może przestać brzmieć jak „dział od blokowania release’u”, a zacząć brzmieć jak „dział od skracania czasu do prawdy”. To inna narracja, inny poziom szacunku, inny poziom wpływu.

Jeśli miałbym wskazać, co ta książka zmienia najbardziej, to sposób rozmowy z biznesem. Gdy pokazujesz trend, ryzyko i koszt awarii, rozmowa o jakości przestaje być emocją. Staje się decyzją.

The Pragmatic Programmer, QA zaczyna się w kodzie

To jest książka, do której wraca się po latach i nagle uderza mocniej. Nie dlatego, że jest nowa, tylko dlatego, że z czasem zaczynasz widzieć, ile problemów jakościowych wynika z rzemiosła, a nie z braku testów. Dobre praktyki, typu DRY, orthogonality, tracer bullets, wczesne testowanie, nie brzmią sexy, ale one robią dwie rzeczy. Ułatwiają zmianę i zmniejszają prawdopodobieństwo niekontrolowanych efektów ubocznych. A to jest fundament jakości.

Największa zmiana myślenia jest taka, że QA nie jest osobnym etapem. QA jest konsekwencją sposobu wytwarzania. Jeśli kod jest czytelny, przewidywalny i modułowy, testowanie przestaje być walką. Jeśli kod jest chaotyczny, QA może się starać do upadłego, a i tak będzie łapać tylko część problemów.

To jest książka, którą polecam zarówno developerom, jak i QA, bo daje wspólny język. Gdy QA potrafi wskazać ryzyko wynikające z konstrukcji kodu, a nie tylko z zachowania UI, rozmowa nagle staje się partnerska.

Clean Code, brutalna prawda o źródłach bugów

Wokół tej książki narosło sporo sporów. Jedni ją kochają, inni mówią, że jest dogmatyczna. Ja mam prostą obserwację. Niezależnie od kontrowersji, ona świetnie obnaża to, skąd w praktyce biorą się defekty. Zbyt długie funkcje, złe nazwy, ukryta logika, chaos w obsłudze błędów, brak spójnych konwencji, to wszystko jest fabryką bugów, których nie wyłapiesz testami w całości, bo one rodzą się w nieczytelności.

To jest też książka, po której zaczynasz rozumieć, dlaczego testowanie czasem boli. Jeśli system jest skomplikowany w środku, QA dostaje skutki uboczne w postaci niespójnych zachowań, wyjątków bez sensownych komunikatów i zmian, które psują rzeczy „w zupełnie innym miejscu”. Z tej perspektywy clean code to nie estetyka. To inwestycja w przewidywalność.

Warto ją czytać ostrożnie, bez traktowania każdego rozdziału jak prawa fizyki. Ale warto, bo zmienia nawyki, które później zmniejszają defekty zanim w ogóle powstaną.

Designing Data Intensive Applications, jakość w skali, nie w funkcjach

To jest książka, po której zaczynasz inaczej myśleć o jakości, bo przestajesz patrzeć na system jak na zestaw ekranów i API, a zaczynasz patrzeć na niego jak na organizm, w którym dane żyją, migrują, replikują się, spóźniają, czasem kłamią, a czasem tylko wyglądają na prawdę. I nagle QA dostaje nowy poziom pytań. Nie tylko czy działa, ale kiedy działa, w jakich warunkach, przy jakich opóźnieniach, przy jakich awariach części systemu.

Ta książka bardzo mocno ustawia głowę pod scenariusze, których wiele zespołów nie testuje, bo są niewygodne. Co się dzieje, gdy kolejka ma opóźnienie. Co się dzieje, gdy replikacja złapie lag. Co się dzieje, gdy klient widzi dane sprzed minuty, a oczekuje aktualnych. Co się dzieje, gdy jedna część systemu jest dostępna, a druga nie, i musisz podjąć decyzję o degradacji funkcji.

Jeśli pracujesz w środowisku, gdzie skala i niezawodność mają znaczenie, ta książka zmienia sposób definiowania jakości. I nagle testy obciążeniowe, testy odporności i scenariusze awarii przestają być fanaberią. Stają się normalną częścią rozmowy o ryzyku.

Staff Engineer, przywództwo bez stanowiska managera

Ta książka zrobiła dla mnie coś ważnego, bo nazwała zjawisko, które wcześniej było intuicją. Można mieć ogromny wpływ bez bycia managerem. Można budować dźwignię, która zwiększa skuteczność całych zespołów, nawet jeśli nie masz władzy formalnej. I to jest niesamowicie ważne dla dojrzałych ról technicznych, także w QA.

Jeśli jesteś seniorem i czujesz, że nie chcesz people managementu, ale też nie chcesz „tylko robić ticketów”, to ta książka otwiera kilka sensownych ścieżek. Mentoring, strategia, usprawnianie systemu pracy, budowanie standardów, rozwiązywanie najtrudniejszych problemów i przenoszenie wiedzy w organizacji. To jest rola, w której produktywność mierzy się wpływem, a nie liczbą zadań.

W QA to potrafi być game changer. Dobry QA lider techniczny nie „koordynuje testów”. On ustawia standardy ryzyka, pomaga zespołom w automatyzacji tam, gdzie ma to sens, buduje definicje metryk jakości i uczy organizację myślenia o defektach jak o koszcie, nie jak o wstydzie.

The Making of a Manager, kultura zjada procesy na śniadanie

Na koniec książka, która najmniej mówi o technologii, a najbardziej o tym, dlaczego ludzie w IT czasem przestają działać jak ludzie. To lektura, po której łatwiej jest zrozumieć, że procesy QA i procesy delivery nie zadziałają w złej kulturze. Jeśli ludzie boją się mówić o problemach, jeśli nie ma przestrzeni na feedback, jeśli 1 na 1 jest fikcją, to jakość zawsze będzie pozorna, bo prawdziwe ryzyka będą zamiatane pod dywan.

To jest też książka, która porządkuje temat zarządzania jako rzemiosła. W IT często awansuje się kogoś na lidera, bo był świetnym specjalistą, a potem liczy się, że „jakoś to będzie”. Ta książka pokazuje, że to się da zrobić dobrze, ale trzeba to traktować jak umiejętność, a nie jak etykietę.

Dla QA to ma znaczenie szczególne. Jakość wymaga mówienia rzeczy niewygodnych. Jeśli kultura nie pozwala mówić niewygodnych rzeczy, QA będzie albo ignorowane, albo będzie zmuszone do politycznej gry. A to jest prosta droga do frustracji i rotacji.

Dlaczego właśnie te siedem

Wybrałem je według jednego kryterium. Po każdej z nich zmieniłem coś w praktyce. Nie tylko dopisałem wiedzę do głowy, ale inaczej prowadziłem rozmowy, inaczej projektowałem proces, inaczej budowałem odpowiedzialność. To są książki, które działają, jeśli po lekturze zrobisz jeden konkretny ruch. Czasem mały, czasem duży, ale realny.

Jeśli miałbym wskazać jedną na start, wybrałbym The Phoenix Project, bo daje ramę myślenia o IT jako systemie, a nie jako zbiorze ról. A jeśli chcesz podejść do tematu bardziej liczbowo, to Accelerate jest świetnym krokiem drugim, bo daje narzędzia do mierzenia tego, co wcześniej było przeczuciem.

Którą przeczytasz jako pierwszą. Jeśli chcesz, napisz mi w komentarzu, którą już znasz i co Ci w niej zostało w głowie. A jeśli wolisz konkret, mogę dopisać krótką sekcję pod każdą książką z jednym wdrożeniem, które można zrobić w tydzień, bez rewolucji i bez wielkiego projektu.