Od stażysty do team leadera. Historia Mai Bieńko

Marzeniem każdego stażysty jest zostać w firmie, która spełnia jego wymagania. Tak było w przypadku Mai Bieńko, która w czasie studiów dostała się na staż w Goyello (dziś Aspire Systems Poland). Przez kilkanaście miesięcy pracowała jako testerka i nie planowała zmiany zawodu. Przełożeni zauważyli jednak, że ma potencjał do zarządzania zespołem. Jaką główną zasadę Maja wyznaje dziś w pracy? — Chcę budować zespoły, gdzie każdy jest zaangażowany i czuje się odpowiedzialny za projekt — mówi.

Zaprosiliśmy Maję Bieńko, Software Testerkę z Aspire Systems Poland, by opowiedziała nam, jak wygląda rzeczywistość studenta, stażysty, a później product ownera i team leadera.

Jak zaczęła się Twoja przygoda z testowaniem i tworzeniem oprogramowania?

Studiowałam informatykę na ETI. Wiązałam z nią przyszłość, ale nie byłam pewna, czy programowanie to coś, co będę chciała robić przez całe życie. Mam to do siebie, że poddaję wiele rzeczy w wątpliwość. Tak się jednak złożyło, że trafiłam do Goyello na staż. Nie miałam określonej ścieżki rozwoju. Nie wiedziałam, czy zostanę programistką, testerką, a może analityczką biznesową. Aplikowałam więc na dwa stanowiska w Goyello — jedno związane z technologią .Net, a drugie z testowaniem. Na drugim wypadłam lepiej (albo z .Neta byli lepsi kandydaci) i podczas rozmowy rekrutacyjnej otrzymałam ofertę stażu na pozycji testera oprogramowania.

Na czym miała polegać Twoja praca?

To był mix. Moje obowiązki obejmowały pisanie testów automatycznych, jak i manualnych. Ale zajmowałam się też analizą systemu. To stanowisko łączyło wszystko to, czego zawsze chciałam spróbować. I tak zaczęła się moja kariera z testowaniem. Długo myślałam, że zawsze będę zajmować się testowaniem, bo bardzo mi się to podobało. Zaletą było także to, że istnieje wiele rodzajów testowania, a z natury jestem ciekawska i lubię wielu rzeczy próbować.

Wróćmy na chwilę do czasów studiów. Powiedz, czy w ogóle poza zajęciami interesowałaś się testowaniem? Czytałaś tutoriale, robiłaś kursy?

Studia i zadania z informatyki zajmowały mi tyle czasu, że nie robiłam wiele poza tym. Na pierwszym roku nie miałam żadnej styczności z programowaniem. Dla mnie była to droga od zera, a poziom na Politechnice był dosyć wysoki, dlatego szybko musiałam nadrobić dużo rzeczy.

Mogłabyś opowiedzieć o zwyczajnym dniu po zajęciach, aby pokazać jak dużo czasu trzeba poświęcać na studia dzienne z informatyki?

Mieliśmy sporo wykładów i ćwiczeń, a jako przykładny student na początku starałam się uczestniczyć we wszystkich. Około osiem godzin dziennie zajmowały nam zajęcia, do tego na bieżąco realizowaliśmy projekty. Póki nie znałam jeszcze ludzi z mojej grupy, zwracałam się o pomoc do mojej siostry, absolwentki tego samego kierunku. Zaraz po zajęciach ruszałam do niej i bywało, że siedziałyśmy nad zadaniami do późnej nocy. Tak wyglądały moje pierwsze miesiące studiów.

Jestem ciekaw, co siostra mówiła Ci o programowaniu, kiedy poszłaś na studia? Jak przedstawiała branżę IT?

Nie wiem, czy odbywałam z nią rozmowy na temat tego, jak wygląda ten świat. Widziałam co ona robi, pamiętam jak pisała swoją pracę dyplomową. Wtedy mieszkałyśmy w jednym pokoju i ona też rozpoczęła pracę, będąc na studiach. Wiedziałam, że te studia lekkie nie są, że czeka mnie sporo nauki.

Na studiach więcej było przedmiotów dotyczących samego programowania, niż testowania?

Większość dotyczyła programowania, poznawania nowych języków, frameworków. Mieliśmy jeden przedmiot dotyczący jakości oprogramowania, który traktował o testowaniu. Większość mojej początkowej wiedzy testerskiej bazowała na tym przedmiocie. Były jeszcze pojedyncze przedmioty czy bloki, które zawierały temat testowania.

Wiedza, którą zdobyłaś na studiach, jeżeli chodzi o testowanie, wystarczyła, by dostać się na staż do Goyello. Powiedz, proszę, jak wyglądał pierwszy dzień stażu, pierwsze dni, pierwsze poważne zadanie?

Wszystko było nowe, co mnie trochę stresowało, dlatego niesamowicie doceniałam wszelką życzliwość ze strony starszych kolegów. Na staż dostali się też moi znajomi ze studiów, co dodawało mi otuchy. Byłam jednak jedynym testerem w moim projekcie, a pierwszym zadaniem było poznanie, jak działa aplikacja, jakie są zasady biznesowe. Dostałam dokumentację, która została stworzona na samym początku, i miałam stworzyć na jej podstawie aktualizację po angielsku. Trochę mi to zajęło, bo w międzyczasie poznawałam tę aplikację, wysyłałam zgłoszenia bugów czy poprawek. Na początku było ich bardzo dużo. Dopiero z czasem nauczyłam się priorytetyzacji — co warto zgłaszać, a na co można przymknąć oko.

Po dokumentacji przyszedł czas na kolejne zadanie. Pamiętasz jakie?

Później zajęłam się pisaniem testów automatycznych. Otrzymałam pomoc w postaci linków do różnych artykułów, podpowiadali mi też testerzy z innych projektów, ale sporo czasu błądziłam po omacku. Manager przejrzał jeden z moich testów, który nie spełnił jego oczekiwań. To było jak kubeł zimnej wody na głowę. Z początku czułam, że jest to niesprawiedliwe, bo musiałam radzić sobie sama. Jednak w późniejszej pracy również niejednokrotnie musiałam samodzielnie eksplorować nowe dla mnie tematy. Dlatego z perspektywy czasu uważam, że była to ważna lekcja wykonywania swoich zadań na 150%, żeby trafić w potrzeby odbiorcy.

Byłaś jedyną testerką w projekcie. Miałaś mentora?

Wtedy jeszcze proces z mentorami nie był tak dopracowany, jak dzisiaj. To były moje główne zastrzeżenia, jeśli chodzi o staż. Zostały one jednak wysłuchane i w kolejnych edycjach poprawione. W rozwiązywaniu problemów pomagał mi mój kolega z zespołu, programista. Robił code review, ale tylko pod kątem programowania. Już wtedy uważałam, że dobrze by było, gdyby tester rzucił na to okiem. Przy następnych zadaniach prosiłam testerów z innych projektów o review.

Ile osób pracowało wtedy w firmie? Ile mieliście projektów?

Wydaje mi się, że zespół liczył wtedy siedemdziesiąt osób. Na staż przyjęto dziewięć osób i od tego czasu coraz częściej dołączali do nas kolejni programiści i testerzy.

Jak to się stało, że z początkującej testerki dosyć szybko zostałaś product ownerem?

Na początku byłam testerką naszej wewnętrznej aplikacji związanej z grywalizacją. Polega ona na tym, że mamy zdefiniowanych pięć głównych umiejętności. Na przykład za napisanie blog posta dostajesz punkty w umiejętności “Writing”, za poprowadzenie prezentacji dostajesz punkty do “Knowledge sharing”. Każda aktywność ma swoją punktację, za co później zdobywasz kolejne poziomy. Swoje uwagi i propozycje zmian przesyłałam do ówczesnego product ownera, którym był Paweł Bejger, pomysłodawca aplikacji. W pewnym momencie zaproponował, że skoro widzę tyle poprawek, to może chciałabym zaopiekować się całym projektem. Najpierw objęłam pozycję “Product Owner Support”, bo dalej Paweł miał być PO, a ja miałam opiekować się projektem i konsultować zmiany. Potem zostałam product ownerem. Z początku dbałam o to, co możemy poprawić, reagowałam na zmiany, a jeśli oddelegowano developera do pracy nad projektem, to z nim współpracowałam.

Dzisiaj masz zespół dedykowany aplikacji?

Do dziś, ze względu na to, że jest to wewnętrzna aplikacja Aspire, pracują przy niej różni developerzy, którzy nie realizują projektu dla klienta. Klient ma zawsze pierwszeństwo, dlatego skład zespołu ciągle się zmienia, co było dla mnie sporym wyzwaniem.

Jak udaje się Tobie zapanować nad takim zespołem?

Stawiam na to, żeby wiedza nie pozostawała tylko w głowach developerów, dlatego spisuję ważne rzeczy i prowadzę dokumentację. Staram się selekcjonować, co jest wartościowe, warte udokumentowania. Staram się też, aby osoby, które odchodzą z projektu były zawsze pod ręką, w razie czego pomogły np. przekazać informacje kolejnej osobie. Aktualnie jestem w procesie przekształcania całej naszej poprzedniej dokumentacji, aktualizowania jej, oraz pracy nad długiem technologicznym.

Wielu seniorów, z którymi rozmawiałem, mówiło, że projekty realizowane dla klientów są bardziej rozwojowe, bo każdy jest inny i każdy klient ma inne wymagania. Ty pracujesz cały czas w jednym projekcie i w dodatku wewnętrznym. Czy uważasz, że przez to wolniej się rozwijasz?

To nie do końca prawda. Od samego początku ten projekt i bycie w nim PO było zadaniem pobocznym i dopiero niedawno wywalczyłam, że będę poświęcać na niego więcej czasu. Pracowałam dotąd w około dwunastu różnych projektach. Kiedy zostałam mianowana na PO League of Geeks (tak się nazywa nasza platforma grywalizacyjna), pracowałam jako tester nad projektem dla klienta na pełen etat. W związku z tym opiekowałam się League of Geeks w tzw. “międzyczasie”. Na początku było głównie reagowanie na problemy, zmiany, od czasu do czasu spotkania z użytkownikami i zbieranie informacji. Później poświęcałam jeszcze więcej czasu w ramach regularnego etatu, ale cały czas byłam w jakimś projekcie z klientem.

Nad czym ostatnio pracowałaś?

Ostatnio pracowałam w trzech projektach. Dwa i pół dnia w bardzo dużym projekcie związanym z lotnictwem. Cały mój zespół testerski był w Belgii, co było dużym wyzwaniem i dało mi bardzo dużo pod względem rozwoju. Dwa dni zajmowałam się innym projektem, w którym byłam nie tylko testerem, ale też scrum masterem. Jak się domyślasz, z całego tygodnia pracy tylko pół dnia zajmowałam się pracą product ownera.

Jestem ciekaw, co zmieniło się w Twojej codziennej pracy, odkąd nie jesteś stażystką. Możesz porównać jak wyglądał dzień, kiedy pracowałaś w jednym projekcie, a jak wygląda, gdy pracujesz w kilku jednocześnie?

Kiedy byłam wyłącznie testerem w jednym projekcie, miałam listę zadań, funkcjonalności, które muszę sprawdzić, przetestować i skonsultować z innymi developerami. Dzisiaj, pracując w kilku projektach naraz, dbam o wywiązywanie się z godzin spędzonych odpowiednio w każdym projekcie. Nieraz okazywało się, że jest coś pilnego do sprawdzenia w projekcie, co blokowało pracę jakiegoś developera. Na bieżąco spisuję sobie, co robiłam dzisiaj, ile godzin i w jakim projekcie, bo inaczej pogubiłabym się.

Musiałam też nauczyć się wyczucia, co jest w danej chwili ważniejsze, wartościowe, co mogę odłożyć na później, kiedy tych zadań jest dużo. Musiałam nauczyć się organizacji pracy. Kiedyś w jednym projekcie po prostu siedziałam osiem godzin, czasem brałam udział w spotkaniu. Teraz bywają dni, że mam spotkanie po spotkaniu, przez co później ciężko zrealizować własne zadania. Dlatego trzeba umieć wybrać, w którym spotkaniu muszę uczestniczyć, a co można załatwić na przykład mailowo.

Jesteś team leaderem, a jednym z Twoich zadań jest dbanie o rozwój zespołu. Co to znaczy?

Jestem dla nich takim punktem kontaktowym, osobą do której zwracają się z problemami. Dbam także o to, by rozwijali się w Aspire, realizowali swoje ambicje i mogli rozwinąć skrzydła. Mamy takie podejście, że ustanawiamy roczne cele, o których później rozmawiamy. Pytam, czy mogę pomóc, czy coś ich blokuje i czy mogłabym jakoś ich wesprzeć.

Co chciałabyś przekazać początkującym koleżankom i kolegom z branży?

Najważniejsze to oswoić strach oraz niepewność i nie pozwalać, aby powstrzymywał przed podejmowaniem ambitnych zadań. Miałam to szczęście, że manager zachęcał mnie do pójścia w kierunku tematów, które wydawały mi się poza moim zasięgiem i umiejętnościami. Dzięki temu samodzielnie podejmuję kolejne wyzwania, które teraz stoją przede mną.


Maja Bieńko. Absolwentka Politechniki Gdańskiej. Tester oprogramowania z 4-letnim doświadczeniem, również w automatyzacji testów. Scrum Master i Product Owner w Aspire Systems. Posiadaczka certyfikatu Professional Scrum Master oraz ISTQB Foundation. Zajęła drugie miejsce w Ogólnopolskim Hackatonie Testerskim (2017). Zawsze wnosi pozytywne nastawienie do zespołu, w którym pracuje.

Patronujemy

 
 
Polecamy
HRakterna środa – W turkusowej organizacji lider może przyznać się do słabości