Kilka pytań do – część 25: Od tech writera do scrum mastera

W najnowszej odsłonie cyklu Kilka pytań do... rozmowa z człowiekiem, którego techwriterska kariera otworzyła możliwość rozwoju w nieco innym kierunku. Szczegóły poniżej.

Ostatnimi czasy coraz więcej osób planuje spróbować sił w pisarstwie technicznym. Znamy też wiele osób, które już podążają tą ścieżką, spełniają się w niej i nie planują zmieniać kursu. Tech writing nie musi być jednak ostatecznym celem podróży, bo możliwa jest zmiana kierunku i realizowanie się w innej roli. Tak było w przypadku Piotra Jrethi, który z powodzeniem odnalazł się zarówno jako tech writer jak i scrum master. Gorąco zapraszamy do zapoznania się z relacją przedstawiającą obie te perspektywy.

Witaj. Powiedz kilka słów o sobie.

Dzień dobry. Nazywam się Piotr Jrethi, jestem byłym tech writerem, a od roku - scrum masterem dla dwóch zespołów scrumowych w duńskiej firmie Omada.

Jakie doświadczenia zebrałeś jako technical writer? W jakich projektach brałeś udział?

Najdłuższy etap mojej techwriterskiej kariery to prawie sześć lat w zespole dokumentalistów w jednym ze skandynawskich gigantów telekomunikacji. Pracowałem tam nad dokumentowaniem software’u związanego z radiową siecią dostępową - najpierw jako “szeregowy” technical writer, a później jako system manager, co w praktyce oznaczało odpowiedzialność za jakość i spójność dokumentacji, architekturę informacji, projektowanie i wprowadzanie usprawnień, czy wreszcie “współudział” we wdrożeniu standardu DITA w organizacji. Później trafiłem do mniejszej firmy, która zajmuje się rozwijaniem własnego softu. Jest to rozwiązanie z branży IGA (Identity and Governance Administration), czyli, w bardzo dużym skrócie, zarządzania kontami użytkowników i ich dostępem do zasobów w organizacji. Tam również pracowałem jako tech writer, tym razem jednak nie w ramach odrębnego doc teamu, a jako pełnoprawny członek zespołów scrumowych. To właśnie tutaj zmieniłem ścieżkę kariery z dokumentalisty na tzw. mistrza młyna, pomimo absolutnego braku umiejętności sportowych. :-)

Z jakich korzystałeś narzędzi?

Jeśli chodzi o narzędzia, których używałem, to były to przede wszystkim edytory i środowiska do zarządzania dokumentacją XML, a więc: Oxygen, Ixiasoft CCMS, Madcap Flare, a z takich bardziej oldschoolowych - Arbortext. Oczywiście pisania w Wordzie też było sporo po drodze. Natomiast teraz spędzam czas głównie wlepiając wzrok w narzędzia do zarządzania projektami zwinnymi pokroju Jiry czy Azure DevOps.

Piotr dyskutuje z użytkownikiem końcowym o usability, simplicity i user experience.

Co sprawiło, że zacząłeś interesować się rolą scrum mastera?

Już jakiś czas temu postanowiłem znaleźć sobie dodatkowe zajęcie, w którym mógłbym się rozwijać. Nie to, żebym w dziedzinie dokumentacji osiągnął już wszystkie szczyty, ale uznałem, że warto mieć też nieco bardziej uniwersalne umiejętności, ponieważ dokumentacja techniczna jest - mam przynajmniej takie wrażenie - nadal dosyć niszową branżą w tym kraju. Mój wybór padł na zarządzanie projektami, a to przerodziło się w chęć mocniejszego spoufalenia się z Agilem, tym bardziej, że pracowałem wcześniej w zespole dokumentacyjnym, który działał na zasadzie wsparcia dla scrum teamów, natomiast sam nie był zespołem zwinnym sensu stricto. To spowodowało, że miałem już pewną perspektywę na to, jak Scrum, czy ogólnie metodyki zwinne, sprawdzają się w naszym dość nietypowym zespole i zapragnąłem mocniej drążyć temat. Była więc to wypadkowa potrzeby rozwoju, dbania o tzw. “job security” oraz faktycznej chęci głębszego poznania tematu, który już wcześniej udało mi się napocząć.

Jak wspominasz pierwsze kroki w nowej roli?

Początki wspominam dobrze, zwłaszcza dlatego, że udało mi się płynnie zmienić rolę. Wsparcie mojego bezpośredniego przełożonego dało mi możliwość pomagania dotychczasowym scrum masterom, przypatrywania się ich pracy, a także brania czynnego udziału w spotkaniach, na których omawiali oni różne scrumowe zagadnienia - dzięki temu mogłem nie tylko obserwować, ale także zacząć dzielić się swoimi opiniami na różne tematy, czy brać na siebie jakieś pierwsze drobne usprawnienia czy analizy. Jeśli chodzi o obowiązki bardziej praktyczne, zacząłem od pomagania naszemu wcześniejszemu scrum masterowi w prowadzeniu wydarzeń scrumowych (a właściwie ich FACYLITOWANIU - bo przecież scrum master nie ma przewodniczyć spotkaniom, tylko wspomagać ich płynne przeprowadzenie). Oczywiście im dalej w las, tym więcej drzew. I kiedy dostałem “swoje” zespoły i przestałem być tylko wsparciem, pojawiła się większa odpowiedzialność i konieczność wyrobienia w sobie umiejętności pozwalających stać się sprawnym “ułatwiaczem”. Zaczęły pojawiać się też kolejne obowiązki, więc nie było już aż tak łatwo. Natomiast bardzo mnie ucieszyło to, że zyskuję pełniejszy obraz i poznaję projekt nie tylko z punktu widzenia swojego teamu, ale również z perspektywy całego R&D.

Powiedz coś więcej na temat projektów w jakich byłeś aktywny.

Moje dwa zespoły, wraz z kilkoma innymi, pracują nad jednym głównym produktem. Pracujemy w dwutygodniowych sprintach. Wcześniej mieliśmy duże (i rzadkie) wydania produktu, natomiast jakiś czas temu przeszliśmy w tryb mniejszych, miesięcznych releasów. Jak wspomniałem wcześniej, staramy się dbać o interdyscyplinarność zespołów, dlatego też tech writerzy są ich integralną częścią.

Jakie umiejętności technical writera pomagają w byciu scrum masterem?

Na pewno dociekliwość i chęć “drążenia” różnych tematów pomaga w jednym z głównych obowiązków scrum mastera - a więc usuwaniu impedimentów, które blokują zespół. Kluczowe są umiejętności związane z komunikacją, zadawaniem pytań, są to więc tematy bliskie dokumentalistom. Tylko pyta się o trochę inne rzeczy. 😊 Na pewno dokładność, dbałość o szczegóły, samoorganizacja również pomagają - skoro stajemy się odpowiedzialni za proces scrumowy, warto upewniać się, że w backlogu panuje porządek, zadania na sprint są przypisane i wycenione, zapytania są skonfigurowane poprawnie, a wszelkie “kontrakty” między członkami zespołu, decyzje, czy problemy są spisane i uwidocznione tak, by osoby zainteresowane miały do nich łatwy dostęp. Z kolei pewnym wyzwaniem, które widzę jest to, że trzeba nagle stać się dużo bardziej widocznym na różnej maści spotkaniach. Często jest tak, że rzeczy, które omawia się na forum zespołu to przede wszystkim kwestie developerskie i QA, tech writer nie zawsze więc jest bardzo aktywny. Scrum master nie ma tego komfortu, a poza spotkaniami zespołowymi pojawia się sporo innych, trzeba więc pracować nad warsztatem związanym z prowadzeniem spotkań, komunikacją, facylitacją, itd.

W jakim zakresie potrzebowałeś się doszkolić?

Choć “papier” nie jest wymagany by pracować jako scrum master, jednym z celów, jakie sobie postawiłem było doszkolenie się i uzyskanie certyfikatu Professional Scrum Master Level I, wydawanego przez Scrum.org - a więc organizację, która wymyśliła cały ten scrumowy interes. Aby ułatwić sobie zdanie egzaminu, wziąłem udział w szkoleniu “Professional Scrum Master”, które systematyzuje wiedzę o Scrumie i pokazuje jego realne zastosowania na podstawie różnych ciekawych i niestandardowych case’ów z prawdziwego życia. Jako że Scrum Guide to tylko paręnaście stron teorii, warto wziąć udział w szkoleniach, które pozwalają lepiej zrozumieć jak te dosłownie kilka akapitów stosuje się w praktyce, jak rozumieć poszczególne opisy i definicje, i wreszcie jakie pułapki na nas czekają - nie tylko w życiu, ale również na teście PSM 1.

Co lubisz w byciu scrum masterem?

Wgląd w to, co się dzieje w organizacji, a nawet możliwość wywierania realnego wpływu na nią. Dostarczanie wartości, jaką jest wspieranie zespołu i usuwanie przeszkód stojących mu na drodze. Równowaga między pewną przewidywalnością “standardowych” obowiązków narzuconych przez ramy Scruma (co pozwala usprawniać pracę nad nimi w systematyczny sposób), a niespodziankami związanymi z coraz to nowymi wyzwaniami i impedimentami (co daje odrobinkę adrenaliny). “Mistrz” w nazwie stanowiska.

Co poradzisz innym technical writerom rozważającym tę ścieżkę?

Jak wspominałem wcześniej, sam próg wejścia nie wydaje mi się wysoki, zwłaszcza jeśli popracowało się już trochę w scrumowym frameworku. Choć nie mam wątpliwości, że od początkującego scrum mastera do starego wygi jest długa droga. Jeżeli ma się taką możliwość, można zacząć od pomagania zespołowi w efektywnym “odbywaniu” wydarzeń scrumowych i powoli wdrażać się w inne obowiązki. Tu na pewno przydadzą się kursy, szkolenia, artykuły, a najlepiej inny scrum master, chętny by podzielić się doświadczeniem - ale przecież zdobywanie wiedzy to chleb powszedni tech writera, więc nie powinno to stanowić dużego problemu. :-)

Czy masz coś jeszcze do dodania?

Korzystając z okazji, chciałbym pozdrowić moją obecną ekipę, a także wszystkich technical writerów, z którymi miałem przyjemność i zaszczyt pracować. To naprawdę fantastyczna zgraja ludzi o bardzo zróżnicowanym (a nawet niespodziewanym) doświadczeniu i skillsecie. I oczywiście pozdrawiam redakcję techwriter.pl i życzę dalszych sukcesów!