Lista 11 porażek i 5 wygranych. Moje subiektywne podsumowanie 2 lat jako lider i tester oprogramowania.
Dzisiejszy wpis będzie niejako podsumowaniem pewnego etapu. Jednym z nich będą dwa lata w testach, a drugim lider zespołu – dużo, mało, średnio — to subiektywne odczucie.
Dwa lata w IT minęły mi ekstremalnie szybko. Dziś chcę się podzielić z Wami przemyśleniami. Co poszło bardzo dobrze, co bym zmienił, jakie mam plany na najbliższe lata.
Dwa lata to czas, podczas którego popełniłem masę błędów, z których wyciągnąłem lekcje i wnioski, a także kilka zwycięstw, którymi chce się z Wami podzielić. Mam nadzieję, że dzięki mojej historii zarówno bycie dobrym QA, jak i liderem przyjdzie Wam łatwiej, ucząc się na moich błędach.
Wpis będzie uniwersalny i nie będzie się odnosił do konkretnych technologii, frameworków czy podejść testowych.
Porażki i wyciągnięte lekcje:
1. Wszystko zrobisz najlepiej sam
Tak, tak — wszyscy znamy to powiedzenie, dzielmy kompetencje, oddawajmy pracę innym, którzy możliwe, że wykonają ją nawet lepiej niż my sami.
Znając to hasło, skończyłem ze wszystkimi możliwymi rodzajami testów UI, API, automatyzacją, scopey projektu, release’y, zarządzaniem zespołem, budowaniem zespołu i wiele pomniejszych czynności. Czemu tak się stało? Bo tkwiłem w przekonaniu, że nikt nie zrobi tego tak dobrze, jak ja.
Fakty są jednak brutalne, zajmując się 30 tematami, nie ma szans, aby każdą z aktywności wykonać perfekcyjnie. Czas ma swoje limity, nasze możliwości też.
Zmieniłem to podejście na rozdysponowywanie kompetencji zespołowi. Staram się to robić w taki sposób, aby każde z zajęć było dla członków teamu nowym wyzwaniem, które pozwoli nauczyć się nowych rzeczy. Tak więc zadania stawiane lekko ponad aktualny stan wiedzy czy możliwości okazały się idealną decyzją.
2. Wiedzę trzymaj tylko i wyłącznie dla siebie. Nie rób tak.
Spotkałem się ze zwolennikami tej teorii i przeciwnikami. Jedni twierdzili, że mając unikatową wiedzę, stajesz się niezastąpiony i odgrywasz większą rolę oraz masz lepszą pozycję negocjacyjną. Również wykazywałem się takim myśleniem jednak dość szybko mi przeszło. I uważam to za podejście, które nie buduje wartości zespołu.
Stałem się zwolennikiem dzielenia wiedzą i doświadczeniami. Dziś nie mam problemu z przekazywaniem wiedzy i doświadczeń jakie zdobyłem często kończąc z głową wbitą w biurko i zadając pytanie czemu to nie działa mimo że powinno.
Moje godziny spędzone nad poszukiwaniem rozwiązania problemu, często mogę przekazać jako gotową receptę przyspieszając rozwój członków zespołu.
Moje doświadczenie pozwala zaoszczędzić dużo innym osobom, które mogą ten czas spożytkować na jeszcze szybszy rozwój co jest moim małym zwycięstwem z perspektywy lidera.
Staram się również przekazać zespołowi, że nawet najmniejsza informacja, która usprawni pracę innych, jest na wagę złota.
Mocno wierzę, że dzielenie się doświadczeniami i wiedzą w zespole to najlepszy sposób na potęgowanie jego wartości.
3. Nabranie się na rollercoaster wiedzy
Zapewne wielu z Was przeżywało ten etap w karierze, kiedy myślało, że wie już praktycznie wszystko. Również się na to nabrałem. Każdego dnia zdaje sobie sprawę jak jeszcze wiele dziedzin, zagadnień jest do odkrycia.
Dodając do tego „równania” tempo zmieniających się technologii raczej wiem, że nie będę miał nigdy możliwości użycia sformułowania, że wiem wszystko.
Mimo mojej ekstremalnej pewności siebie dziś mam większą pokorę od wiedzy.
4. Zaburzenie work life balance
Praca jest ważna, nie mam co do tego najmniejszych wątpliwości. Jednak nie przesadzaj w każdą ze stron. Mimo, że stan równowagi jest ciężki do osiągnięcia – staraj się. Moją wizję o najlepszym zespole QA, jaki chce zbudować przypłaciłem 14 kilogramami. Ups…
Na szczęście mam tego świadomość i jestem w trakcie wracania do formy.
Dlatego staraj się zachować balans pomiędzy sportem, przyjaciółmi, pracą, rozwojem i Twoimi pasjami.
5. Najważniejszy język IT
Java, Python, PHP — zdecydowanie nie. Angielski. Pamiętaj, że pierwszym językiem jest angielski. Sam długo zwlekałem ze szlifowaniem angielskiego, jednak teraz zamieniłem to w proces, który przynosi mi dużo radości. Obecnie proces szlifowania języka angielskiego zajmuje tyle samo czasu co nauka Javy.
Oczywiście proporcje się zmienią, jednak obecnie jednym z głównych celów jest przygotowanie języka do takiego poziomu, aby móc wygłosić płynnie publiczną prezentację w języku angielskim.
6. Cierpliwość. – Pamiętaj, że to długoterminowa gra.
W pierwszym akapicie stwierdziłem, że ciężko mi określić obiektywnie dwa lata jako dystans. Mam jednak świadomość, że budowanie dobrze działających zespołów oraz procesów, kultury jakości nie jest procesem, który można osiągnąć w szybkim tempie.
7. Czym jest jakość — zmiana optyki
Wraz z dojrzałością produktu, nad którym pracuję oraz doświadczeniem, zmieniła się też optyka patrzenia na samą jakość. Jakością nie są już same testy, jakością nie jest tylko i wyłącznie zgłaszanie błędów.
Jakością są również procesy, kultura, podejście do jakości całych zespołów, wybór optymalnych i dobrze dopasowanych rozwiązań. Jakość nie jest procesem lokalnym w zespołach QA, jakość jest procesem globalnym w firmach, za którą odpowiedzialny jest każdy pracownik.
8. Oddziel czas na deep work żeby nie stracić dnia
Przypuszczam, że to uczucie, które poznało wiele osób w branży IT. Dzień, w którym masz spotkania, chodzisz po biurze, pomagasz zespołowi osiągnąć cele i załatwiasz dużo drobnych spraw. Na następny dzień na daily pytany o to co robiłeś, ciężko wymienić Ci duże rzeczy, które robiłeś dzień wcześniej.
Nauczony tym doświadczeniem postawiłem na kilka godzin głębokiej pracy w skupieniu, podczas której wykonuję kluczowe zadania zaplanowane rano na konkretny dzień. Zazwyczaj lista ta leży na kartce zaraz obok macbooka i jest regularnie wykreślana.
W moim przypadku takie okna wypadają dwa w ciągu dnia od 8 do 10 oraz od 17 do 19.
Uważam, jednak że są to godziny, w których wykonuje najwięcej kluczowych zadań pozwalających osiągnąć postawione cele i zadania.
Eliminacja „szumu” jest kluczowa.
9. Spędzanie za dużo czasu nad wyborem narzędzi.
Selenium czy Cypress, BDD warto czy nie, allure czy portal report, Java — Python.
Przez długi czas za bardzo skupiałem się na narzędziach zamiast samym celu, który miałem osiągnąć. Zrozumiałem, że narzędzia nie są celem samym w sobie. Trochę to zajęło zanim doszedłem do tego wniosku. Zapytany więc czego używać, odpowiem — to, co znajdzie lepsze zastosowanie w Twoim projekcie i da mu wartość.
10. Za dużo teorii. – Działaj, 200% praktyki!
Podejść do nauki i zdobywania wiedzy jest wiele. Zawsze jednak będę lobbował za praktyką. Nie zawsze tak było. Początkowy okres, w którym bardzo dużo wiedzy pochłaniałem pasywnie. Teraz jestem na drugim końcu skali i uważam, że praktyczna nauka na realnych przykładach i projektach da dużo więcej wartości niż suche książkowe fakty często pokazywane w idealnym odizolowanym środowisku.
Praktyka pozwala zderzyć się również z problemami których nie znajdziesz w książkach a każde wymyślone rozwiązanie to krok ku byciu lepszym ekspertem jakości.
11. Nauka jak cieszyć się procesem
“Ciesz się procesem” – Usłyszałem to na przełomie 2019/2020 roku. Jako osobie ekstremalnie niecierpliwej, która ciągle kieruje się w stronę osiągnięcia celu, ciężko było to początkowo zrozumieć.
Naszym celem jest osiągnięcie efektu w najszybszy możliwy sposób. Po zrealizowaniu go wyznaczamy kolejny. Bez cieszenia się samym procesem i ignorowaniem składnika, jakim jest czas, szybko można dotrzeć do ekstremalnej frustracji (tak, przerobiłem to).
Zwycięstwa:
1. Atmosfera w zespole
Zdecydowanym sukcesem, jaki udało mi się osiągnąć z zespołem, jest atmosfera. Jest praca, są żarty, jest również czas na skupienie. Kultura dzielenia się wiedzą i doświadczeniami czyni zespół naprawdę wyjątkowym.
2. Wartości, na jakich operuje zespół
Zbudowanie zespołu na takich wartościach jak ciągły rozwój, chęci pogłębiania wiedzy, pomoc członkom zespołu i wspólne rozwiązywanie problemów, podejście do jakości i pasja, z jaką wykonujemy pracę. Mimo codziennych wyzwań pozwoliło to zbudować zespół, który ma to w swoim DNA.
3. Metoda opracowywania strategii rozwoju dla każdego członka zespołu indywidualnie i szybkość nauki zespołu.
Czy zespół może się rozwijać bez postawionych przed nim celów? Patrząc na inne zespoły, myślę, że tak – jednak jest to bardzo powolny proces, niezauważalny w codziennej pracy.
Postawienie jasnych celów dla całego zespołu, wyznaczenie kierunku rozwoju, a następnie w zgodzie z tym kierunkiem wyznaczenie ścieżki rozwoju dla każdej osoby pojedynczo sprawiło, że każda z osób w zespole zdecydowanie przyspieszyła swój rozwój.
Rutyna używania tego rozwiązania spowodowała, że zespół rozwija się naprawdę bardzo szybko. Trzeba zaznaczyć, że jest to też praca włożona w rozwój przez poszczególne osoby, brawa dla nich!
4. Potęgowanie ważniejsze niż dodawania
Staram się, aby w codziennej pracy przez procesy, wymianę wiedzy, zdobywanie doświadczeń budować elementy, które potęgują wartość zespołu, zamiast tylko dodawać wartości. Przekazywanie swojej wiedzy całemu zespołowi, przenoszenie zespołu na wyższy poziom kompetencji. To jest moja definicja potęgowania.
5. Ciągła nauka i nieustanne zdobywanie nowych doświadczeń
Cecha, którą uważam za moje osobiste zwycięstwo. Nieustanny rozwój jest czymś, co pomogło mi dostać się do miejsca, w którym obecnie jestem oraz zbudować fantastyczny zespół QA. Mimo to wiem, że to dopiero początek drogi.
Wiedza techniczna, kompetencje miękkie, wiedza managerska jak podejmować jak najlepsze decyzje wpływające na zespół. To nie sprint a maraton.
Co dalej?
Kilka porażek oraz zwycięstw. Mam nadzieje że wpis ten dał Ci wartość i pozwoli uniknąć kilku błędów na które natknąłem się podczas moich ostatnich dwóch lat. Najbliższa przyszłość to nabywanie kompetencji technicznych, mam również cel w roku 2020 zostać prelegentem. Co pokaże rok 2020 i początek 2021 pokaże podsumowujący wpis trzeciego roku pracy.
Teraz czas wrócić do technicznych artykułów. 😉
Jeśli wpis Ci się spodobał udostępnij go proszę znajomemu, któremu może pomóc. Dzięki! 5!
