Jak programista może wejść w nową rolę. Historia Moniki Wolak i Pawła Miry

Wbrew pozorom ścieżka kariery programisty czy testera nie jest prosta. Wszyscy znamy jej przykładowy przebieg, czyli od juniora do seniora. Warto wiedzieć, że wielu programistów dochodząc do etapu regulara czy seniora odczuwa potrzebę zmiany, bycia kimś innym. Tak było w przypadku Moniki Wolak i Pawła Miry, z którymi porozmawialiśmy o rozwijaniu swoich ścieżek w firmie Ericsson.

Dlaczego zdecydowali się na zmianę? Jak wyglądały pierwsze dni w nowych rolach i komu polecają tę ścieżkę kariery? Tego dowiecie się z rozmowy z Moniką, która jest Track & Flow Managerem oraz Pawłem – pełniącym rolę Operative Product Ownera.

Zanim przejdziemy do tego, jaką ścieżkę kariery przebyliście, opowiedzcie czym zajmujecie się dzisiaj?

Monika: Od ponad dwóch lat jestem Track & Flow Managerem. Zakres moich obowiązków ewoluuje od momentu ich przejęcia i zależy od zmian, które cały czas zachodzą w naszym projekcie i organizacji. Moje obowiązki są ściśle związane z pracą zespołu, który czuwa nad pętlami testowymi naszej części produktu, w celu szybkiego i poprawnego połączenia wszystkich modułów w końcowy produkt. Moim zadaniem jest wspieranie zespołu w realizacji zadań, wprowadzanie usprawnień w sposobie pracy, podejmowanie decyzji w problematycznych momentach, decydowanie o zmianach, reprezentowanie zespołu podczas spotkań z innymi modułami, jak również przedstawicielami zespołów developerskich.

Paweł: Jestem świeżo po objęciu stanowiska Operative Product Ownera, co wydarzyło się dość naturalnie – po prostu nadszedł odpowiedni moment i okazja na awans. W naszym dziale jest to rola bliska klasycznemu Product Ownerowi w Scrumie, z pewnymi dodatkowymi obowiązkami menedżerskimi, ale nie jest to rola kierownicza, nie jestem “nad” kolegami. Nasz dział odpowiada za utrzymanie i ulepszanie skryptów dla środowiska Continuous Integration. Odpowiadamy za przebieg i wizualizację procesów testowych. Jak to w takim żywym środowisku bywa, czasami coś nie działa tak, jak użytkownik by sobie tego życzył, czasami trzeba coś usprawnić, zautomatyzować lub dodać nowe funkcjonalności.

Zajmuję się m.in. akceptacją zgłaszanych zleceń, priorytetyzacją zadań, współdecydowaniem o używanych technologiach i rozwiązaniach, koordynacją rozwoju podproduktów, a także wdrażaniem nowych osób w dziale. W praktyce jest to praca bardziej z ludźmi niż z produktem, gdyż każdy podprodukt ma swoją grupę developerów nad nim pracujących. Często też zgłaszający prośby zmian potrzebują najpierw porozmawiać, zapytać o szczegóły techniczne, oszacować szanse na wdrożenie i ryzyko z nim związane, więc jest to też funkcja typu SPOC – single point of contact.

Z pełnionymi przez Was rolami związane są umiejętności miękkie. W jaki sposób je rozwijacie?

Monika: Bardzo ważna jest praktyka: każdego dnia dowiaduję się czegoś nowego, co potem przydaje się w pracy. Obserwowanie innych, praca z różnymi zespołami, każda retrospektywa lub spotkanie, w którym uczestniczyłam, a nawet zwykłe rozmowy przy kawie – to świetne sposoby na rozwijanie umiejętności miękkich. Teoria jest podstawą, dlatego byłam na zewnętrznych szkoleniach scrumowych zakończonych certyfikatami, np. Professional Scrum Master I, Professional Scrum Product Owner I. Dodatkowo, w wolnych chwilach, czytam artykuły oraz książki o typach osobowości i o tym, jak należy z nimi współpracować.

Paweł: Zadania organizacyjne wymagają sprawności, odwagi, przełamywania barier, nawet zwykłego mówienia konkretów czy podejmowania trudnych decyzji – uważam, że te umiejętności rozwinąłem przede wszystkim podczas studiów działając w różnych organizacjach. W pracy natomiast warto było uczestniczyć czynnie w spotkaniach: zadawać pytania, dyskutować, argumentować. Poświęciłem też trochę czasu po pracy na budowanie relacji z ludźmi – kiedy wiesz, że możesz wyjść ze współpracownikami na przysłowiowe piwo i polegać na nich także w sprawach prywatnych, znacznie łatwiej się potem pracuje – można udzielać sobie feedbacku z mniejszym ryzykiem, że ktoś się obrazi.

Monika, przez pół roku łączyłaś stanowisko Scrum Mastera i testera. To znaczy, że wahałaś się nad zmianą i nie byłaś przekonana o rezygnacji z pracy testera?

Monika: Swoją pracę rozpoczęłam jako tester w dziale Agile Development. Rozwijaliśmy projekty w procesach zwinnych, w przypadku mojego był to Scrum. W tamtym czasie w dziale przyjęte było łączenie roli Scrum Mastera z rolą techniczną oraz powierzanie mu prowadzenia większości spotkań z project i product managerami ze Sztokholmu. Znalezienie równowagi pomiędzy tymi dwoma rolami jest niezwykle złożone. Stąd bycie Scrum Masterem było dodatkiem i wyzwaniem dla osoby technicznej. Uwielbiam wyzwania i uczenie się nowych rzeczy, dlatego skorzystałam z nadarzającej się okazji. Dzięki temu mogłam pomagać w zmianach w zespole, jak również rozwinąć umiejętności miękkie oraz podnieść zdolności komunikacyjne w języku angielskim.

Dlaczego zainteresowałaś się Scrumem?

Monika: Na studiach informatycznych poznałam podstawowe modele procesów produkcji oprogramowania, takie jak: kaskadowy, iteracyjny, równoległy czy spiralny, ale niczego nie dowiedziałam się o procesach zwinnych. W pracy poznałam: Kanban, Scrum a nawet Lean. Po poznaniu podstaw Scruma postanowiłam poszerzyć swoje doświadczenie, gdyż chciałam nie tylko być jednym z developerów, ale kimś innym. I akurat w tym momencie pojawiła się możliwość zostania Scrum Masterem, więc z niej skorzystałam.

Paweł, do jakiego etapu doszedłeś jako programista? Wejście w nową rolę spowodowało, że przestałeś rozwijać się w tym zawodzie?

Paweł: Absolutnie nie przestałem się rozwijać w tym kierunku! Szkoda by było tych wszystkich poświęconych na to lat. Przestała to być moja główna odpowiedzialność w pracy, ale wciąż koduję w wolnym czasie – nie chcę wypaść z obiegu. Po trzech latach bycia juniorem i regularem zostałem senior developerem, awans zbiegł się w czasie z przejęciem funkcji Operative Product Ownera. Natomiast rozszerzanie obowiązków i odpowiedzialności następowało raczej w sposób ciągły, niezależnie od ówczesnej nazwy stanowiska.

Wbrew pozorom ścieżka kariery programisty czy testera nie jest prosta. Wszyscy znamy jej przykładowy przebieg, czyli od juniora do seniora. Warto wiedzieć, że wielu programistów dochodząc do etapu regulara czy seniora odczuwa potrzebę zmiany, bycia kimś innym. Tak było w przypadku Moniki Wolak i Pawła Miry, z którymi porozmawialiśmy o rozwijaniu swoich ścieżek w firmie Ericsson.

Byłeś w podobnej sytuacji, co Monika, czyli łączyłeś naraz dwie funkcje – programisty i kogoś, kto zajmuje się sprawami organizacyjnymi. Pamiętasz moment, w którym zdecydowałeś, że jednak skupisz się na rolach organizacyjnych?

Paweł: Nie wiem, czy był konkretny moment, ale decyzja o skupieniu się na pracy organizacyjnej narastała mniej więcej od momentu, kiedy zostałem opiekunem naszych praktykantów i wcieliłem się podczas wakacyjnego projektu w rolę kogoś w rodzaju Product Ownera i Scrum Mastera. Minizespół, który stworzyliśmy z praktykantami, był za mały, żeby realnie wdrożyć prawdziwego Scruma, ale pracowaliśmy w sprintach, odbywały się wszystkie zalecane spotkania, powstawały przyrosty, które trzeba było zaprezentować większej grupie – skupiłem się na koordynowaniu tych działań, nie wtrącając się nadmiernie do kodu. Z biegiem czasu taka koordynacja była potrzebna też na poziomie pracy naszych zespołów i tak wyewoluowało zapotrzebowanie na moją obecną rolę.

Powiedziałeś przed chwilą, że nie chcesz wypaść z obiegu jako programista. To znaczy, że powrót do programowania to Twój backup plan?

Paweł: Nie zakładam z góry, że sobie nie poradzę, więc nie nazywałbym tego backup planem. Może po prostu w pewnym momencie dojdę do wniosku, że chciałbym robić coś innego i wrócić pełnoetatowo do programowania, na to nigdy nie jest za późno. Nie chciałbym też na razie “odpłynąć” całkowicie w kierunku czystego zarządzania, wolę cały czas rozumieć, co mówią do mnie koledzy z biurek dookoła i wesprzeć ich również technicznie.

Obydwoje mieliście wcześniej doświadczenia programistyczne lub testerskie. Przydają się one w pracy?

Monika: Doświadczenie testerskie ułatwia zrozumienie problemów i pomaga przy estymacji czasu potrzebnego na dostarczenie rozwiązania. Zdarza się również, że w krytycznych sytuacjach pomagam przy troubleshootingu. W moim przypadku doświadczenie testerskie i wiedza techniczna ułatwiają wiele, ale to nie znaczy, że osoba nietechniczna nie sprawdziłaby się na moim stanowisku.

Paweł: Wiedza o programowaniu z pewnością jest przydatna. Część mojej pracy polega na byciu pośrednikiem pomiędzy naszymi interesariuszami a programistami, którzy dane rozwiązania będą wdrażać. Dobrze jest rozumieć jednych i drugich oraz nie być tylko przekaźnikiem informacji, ale aktywnie uczestniczyć w dyskusjach, czasem też coś doradzić, dorzucić swój punkt widzenia. Ryzyko głuchego telefonu jest wtedy na pewno mniejsze. Bywa to też czasem małą pułapką, kiedy przy niektórych zadaniach pojawia się pokusa, żeby zrobić je samodzielnie – teraz nie zawsze znajduję na to czas, trzeba polegać na „pełnoetatowych” developerach i technicznych ekspertach. Przydaje się też wiedza i doświadczenie z zakresu szeroko pojętej inżynierii oprogramowania – projektowanie rozwiązań, podział zadań na mniejsze, określanie wymagań, które musi spełnić dobry kod, aby zapobiec błędom, proponowanie ulepszeń.

Opowiedzieliście już o swojej przygodzie z testowaniem i programowaniem, która na tę chwilę zakończyła się wejściem w nowe role. Nie macie wrażenia, że jako testerka i programista mielibyście większy wpływ na produkt?

Monika: Uważam, że każda osoba pracująca w Ericsson ma wpływ na produkty. Czasem jest on pośredni, a czasem bezpośredni, ale nie da się go zmierzyć. Tym bardziej porównać, przy tak dużych projektach jakimi się zajmujemy. Wiem, że jako testerka miałabym inny wpływ na produkt niż obecnie, ale na pewno nie miałabym takich wyzwań jakie mam pracując w CI.

Paweł: Jako programiście ciężko było mi zaproponować coś, czego nie potrafiłem samemu zrobić, występowało pewne ograniczenie własną wiedzą i doświadczeniem. Oczywiście kilka pomysłów udało się wdrożyć, ale były to raczej rozwiązania konkretnych problemów. Jedną z zalet funkcji OPO jest to, że może składać więcej propozycji rozwiązań dla dobra produktu, które będą wdrażać inni – na zasadzie umowy z programistami: „Chciałbym, żeby działało to w taki sposób i dawało takie efekty. Nie wtrącam się w szczegóły techniczne i kod, czy dacie radę to wdrożyć?”. Skala pomysłów jest szersza i nie zamyka się na konkretnym rozwiązaniu.

Oferty pracy z

Kto Waszym zdaniem sprawdzi się idealnie w takiej roli, jaką pełnicie teraz, czyli w roli Track and Flow Managera i Operative Product Ownera?

Monika: W tej roli najlepiej poradzi sobie osoba otwarta, pełna zapału, potrafiąca słuchać, szybko reagować na potrzeby oraz podejmować konkretne decyzje, potrafiąca słuchać ze zrozumieniem i sprawnie odpowiadająca na zadane pytania. Dynamiczna i elokwentna, pozytywnie nastawiona do zmian, lubiąca nowości. Nie musi mieć zaplecza technicznego – widziałam, jak osoba na podobnym stanowisku, nietechniczna, potrafiła bez problemów prowadzić techniczne dyskusje i podejmować właściwe decyzje.

Paweł: Osoba otwarta na nową wiedzę, ciągłe zmiany dookoła, reagująca szybko i sprawnie na problemy, lubiąca pracę z ludźmi i akceptująca fakt, że czasem więcej rozmawiamy niż kodujemy. Choćby podstawowy background techniczny na pewno jest też potrzebny, nie umiem sobie wyobrazić, że rozmawiam o czymś, o czym zupełnie nie mam pojęcia. Na pewno przyspiesza to podejmowanie decyzji. Dlatego w mojej opinii osoba zupełnie nietechniczna mogłaby sobie nie poradzić dobrze na tym stanowisku.

Potraficie z perspektywy czasu określić, że mogliście szybciej albo później zmienić stanowisko? A może dziś zrobilibyście to w zupełnie inny sposób?

Monika: Wyzwania, które podejmowałam oraz związane z nimi doświadczenia: te pozytywne i te negatywne, doprowadziły do tego, że teraz pełnię taką, a nie inną rolę w Ericsson. Wiem, że jeśli nie podjęłabym ryzyka związanego z przejściem w nową rolę albo podjęcia nowych zadań, na pewno nie byłabym Track and Flow Managerem. Może byłabym Product Ownerem albo nadal testerem.

Paweł: Na początku pracy w obecnym dziale trochę przytłaczała mnie ilość nowej wiedzy i umiejętności, jakie trzeba było zdobyć, aby stanowić realne programistyczne wzmocnienie zespołu. Jako junior chciałem po prostu programować, tworzyć tysiące linijek kodu, najlepiej jeszcze szybko zobaczyć efekt zmian. To była właśnie moja wiedza ze studiów nieinformatycznych, gdzie nie uczyło się inżynierii programowania czy projektowania architektury, a jedynie szczegółów składni poszczególnych języków. Mój ówczesny kierownik przekonywał mnie, że wcale nie na tym polega praca developera i z perspektywy czasu widzę, że miał rację.

Dojrzały programista musi poświęcić dużo więcej czasu na zastanowienie się jak coś działa, a efektem wielodniowej pracy bywa czasami poprawka jednej linijki kodu. Odpowiadając na pytanie: chyba nie mogłem tego zrobić wcześniej, bo musiałem nabrać odpowiedniego doświadczenia. A czy później? Mam nadzieję, że stało się to w odpowiednim momencie, czas pokaże.

Co sprawia, że czerpiecie satysfakcję ze swojej roli?

Monika: Nowe wyzwania i ludzie, z którymi pracuję, to moja siła napędowa. Jeśli coś jest stałe, znane i przewidywalne, dla mnie jest równoznaczne z nudą. Nie lubię stać w miejscu. Do czasu, gdy zaczęłam pracę jako Track and Flow Manager, prawie co pół roku coś zmieniło się w mojej pracy: zaczynałam jako tester, potem podjęłam wyzwanie bycia Scrum Masterem i testerem jednocześnie, następnie wyjechałam na pół roku do Sztokholmu pracować z nieznanymi mi ludźmi. Po powrocie do kraju pracowałam w zespole zajmującym się frameworkiem testerskim, jednocześnie przygotowując i prowadząc szkolenia o nowej platformie, na którą nasz projekt miał być przenoszony. Następne pół roku znów spędziłam w Sztokholmie, ale już jako proxy-Product Owner zespołu zajmującego się wdrażaniem Continuous Integration do mojego ówczesnego projektu.

Po powrocie do Krakowa nadal kierowałam tym zespołem, którego członkami byli developerzy z Polski, Szwecji i Węgier, aż do czasu, gdy zmieniło się moje życie, czyli do urodzenia synka. Po powrocie z macierzyńskiego i oswojeniu się ze zmianami, które nastały wraz z przejęciem Ericpola przez Ericsson, rozpoczęłam pracę na obecnym stanowisku. Dostarcza ona wielu wyzwań, mam do czynienia nie tylko z ludźmi o różnych charakterach, doświadczeniach i wieku, ale również narodowości czy strefy czasowej. To bardzo ekscytujące.

Paweł: Wyznaję zasadę i dla nikogo nie powinno być to tajemnicą, że pracujemy dla pieniędzy, jak i że ważny jest work-life balance. Ale przecież nic nie stoi na przeszkodzie, aby praca dawała też satysfakcję. Na obecnym stanowisku daje ją przede wszystkim praca z ludźmi, realny wpływ na decyzje dotyczące naszych produktów, zwiększone obowiązki czy odpowiedzialność. Zauważyłem też, że trochę więcej chodzę i rozmawiam zamiast siedzieć przy biurku, więc ma to też aspekt zdrowotny. Najważniejsza jest świadomość tego, że nie stoi się w miejscu i cały czas uczy się nowych rzeczy, nawet jeśli czasami nie jest to łatwe. Nudna i monotonna praca jest pewnie wygodna, ale to chyba nie dla mnie.

---

Monika Wolak. Track and Flow Manager w Ericsson. Magister inżynier Informatyki Stosowanej na Wydziale Fizyki i Informatyki Stosowanej AGH. Posiada doświadczenie testerskie, scrumowe i związane z prowadzeniem szkoleń. Obecnie pracuje przy Continuous Integration. Prywatnie żona Tomasza i mama trzyletniego Mikołaja.

Paweł Miry. Operative Product Owner w Ericsson. Magister inżynier Fizyki Technicznej na Wydziale Fizyki i Informatyki Stosowanej AGH i były działacz w organizacjach studenckich. Programista języków skryptowych (Python, Perl, Bash). W pracy przez pewien czas łączył pracę developera z rolą Scrum Mastera i obowiązkami Team Leadera, podejmuje się dodatkowych zadań organizacyjnych. W wolnym czasie dba o żonę Marzenę, wspiera młodzież w pierwszych krokach programistycznych, kolekcjonuje kasety magnetofonowe i rzuca siekierami w drewniane tarcze.