Czy w IT warto być zołzą?

Bądź… ZOŁZĄ?

Dzisiaj przypada Dzień Zołzy.

Z zołzą nie żyje się zbyt dobrze. Nawet jeśli same tłumaczą, że Z.O.Ł.Z.A to skrótowiec od Zgrabna, Obrotna, Ładna, Zaradna, Ambitna, to jednak słowo zołza się nie kojarzy pozytywnie. Wg słownikowej definicji: "Zołza to określenie obraźliwie, pejoratywnie określające kobietę/dziewczynę, która jest kłótliwa i nieuprzejma, lubi robić na przekór, sprawiające tym samym przykrość innym".

Skąd więc tytuł „Bądź ZOŁZĄ”? Pytajnik i wielokropek trochę tu zdają się poddawać w wątpliwość moc tego tytułu, ale my wątpliwości nie mamy – chcesz być testerem? Bądź zołzą. Albo zołzem (skoro od wiedźmy powstał wiedźmin to czemu od zołzy nie może powstać ten zołz?).

Tester – bez względu na płeć powinien być zołzą (albo zołzem) pełną gębą.

Dla osób spoza branży bycie testerem może wydawać się prostym – ot taki lub taka sobie poklika, poklika, stwierdzi, że coś działa albo nie działa i po robocie, a kilkanaście tysięcy złotych na konto wpadnie.

Ale bycie testerem, nawet na poziomie juniorskim, to nie tylko klikanie, to nie tylko znajomość podstawowych pojęć w stylu teksty czarno i białoskrzynkowe, piramida testów czy przypadki testowe. Nie. To nawet – nie tylko umiejętność wskazania dziury w całym, włącznie z dokładnym umiejscowieniem tej dziury, jej opisem i udowodnieniem, że ona rzeczywiście jest (patrz – tu się w nią wpada! Jak to nie widzisz?). To również – a wręcz przede wszystkim – umiejętność obrony swoich racji, dbanie o jakość za wszelką cenę, sygnalizowanie z uporem krytycznych problemów. I umiejętność przebicia się z tym przekazem. Czyli – bycie taką uciążliwą zołzą, która mówi: tu jest zrąbane, nie, to nie przejdzie. I to na wielu etapach. Im wcześniej – tym lepiej. Dobry tester potrafi wskazać, że coś nie ma prawda działać ZANIM to coś zostanie wykonane – jeszcze w fazie, gdy projekt jest dopiero „na papierze”

Wiele katastrof nastąpiło przez zignorowanie sygnałów, płynących z dołu.

Do katastrofy Challengera nie doszłoby gdyby posłuchano Rogera Boisjoly'ego, inżyniera, który ostrzegał o skutkach wpływu niskich temperatur na uszczelki O-ring, do katastrofy smoleńskiej nie doszłoby gdyby posłuchano prognoz pogody, do zestrzelenia lotu 17 linii Malaysia Aislines nie doszłoby, gdyby nie zignorowano notatki ukraińskich służb, do katastrofy Airbusa linii Germanwings nie doszłoby gdyby wzięto pod uwagę ostrzegający przed takim niebezpieczeństwem artykuł kapitana Jana Cochereta i tak dalej. To co łączy te przypadki to to, że osoby, które miały słuszne podejrzenia o niebezpieczeństwie - z przyczyn formalnych lub nieformalnych - nie przebiły się ze swoim przekazem do świadomości osób decyzyjnych.

W IT - na szczęście - jeśli nie robisz oprogramowania dla pojazdów, systemów kontroli lotnisk, szpitali itp. - katastrofy nie wiążą się przeważnie z utratą ludzkiego życia. Ale najczęściej - wiążą się z utratą pieniędzy, prestiżu, zaufania, czasu.

Wiele razy zdarzało mi się być osobą decyzyjną w sprawie wdrożenia mniejszych lub większych zmian w produkcie.

I wiecie co? W takich sytuacjach - lubię mieć przy sobie zołzę. Kogoś, kto głośno będzie krzyczał, że coś nie działa i co może wybuchnąć. Oczywiście - mogę ten krzyk zignorować - decyzja należy do mnie, czasem analiza ryzyka wskazuje, że trzeba zrobić swego rodzaju YOLO - ale chcę to usłyszeć. Chcę to wiedzieć.

A jeśli zignoruję i dojdzie do katastrofy, to ja będę za to odpowiedzialny.

A nie ktoś, kto wiedział ale milczał. Albo szeptał pod nosem.

Widzisz, że pociąg jedzie ku przepaści? Szarpnij za hamulec bezpieczeństwa.

Dlatego - jeszcze raz - apeluję - testerzy - bądźcie zołzami!