Kilka pytań do - część 26

Przed Wami kolejna odsłona cyklu Kilka pytań do... Tym razem na nasze pytania odpowiada Piotr Sroka, który ma już dość spory staż w zawodzie technical writera. Jak to się wszystko zaczęło i czy po czasie warto było obrać taką karierę? Zapraszamy poniżej.

1. Jak długo pracujesz jako technical writer?

W styczniu tego roku świętowałem 10 rocznicę pracy w zawodzie i mieszkania w Krakowie. Aż trudno uwierzyć, że 10 lat minęło tak szybko. Można powiedzieć, że praca na stanowisku technical writer w znaczący sposób zmieniła moje życie i zaprowadziła mnie w miejsce gdzie obecnie jestem. 3 różne firmy i 10 lat w zawodzie to dobry moment na refleksję.

2. W jaki sposób zostałeś technical writerem?

To był przypadek. Szukałem pracy z językiem angielskim w Krakowie i pośród ofert, na które aplikowałem jedna była na stanowisko technical writer. Wtedy też pierwszy raz usłyszałem, że jest taki zawód. Jak dziś pamiętam tamtą rekrutację - proces był bardzo szybki, a jedna z rozmów rekrutacyjnych odbyła się nawet w moje urodziny, z czego rekrutujący nie zdali sobie nawet sprawy. Jeden z nich został później moim przełożonym i przy jakiejś kawie wyszło, że ta praca to taki trochę prezent urodzinowy. Tak jak już mówiłem, niewiele wiedziałem wtedy o stanowisku technical writera, ale praca wydawała mi się ciekawa (i taka była, i jest nadal). Jak teraz o tym wszystkim pomyślę, to całe szukanie pracy mogło się skończyć inaczej, bo na przełomie 2011/2012 potrzebowałem po prostu znaleźć pracę. Mimo iż nie pracuję już w tamtym miejscu, to nadal jestem bardzo wdzięczny tamtej firmie i osobom, które mnie zatrudniły, że dostałem szansę na start w nowym miejscu i dobrej firmie.

3. Czy możesz opowiedzieć coś o swojej firmie i zespole, w którym pracujesz?

To może tak w bardzo dużym skrócie - firma, w której pracuję, Hitachi Energy, jest światowym liderem technologicznym, który obsługuje klientów z sektora użyteczności publicznej, przemysłu i infrastruktury. Mieszczące się w sercu Krakowa Centrum Technologiczne dostarcza innowacyjnych i niezawodnych technologii z zakresu generacji, transmisji oraz dystrybucji energii elektrycznej.

Jeżeli chodzi o sam zespół deweloperski - są to ludzie, z którymi łatwo się dogadać i co najważniejsze i którzy bardzo szanują oraz doceniają pracę technical writera. Przychodząc do pracy w nowym, nieznanym miejscu zawsze czuje się trochę stresu. Nowe firma, nowy produkt, nowi ludzie. W Hitachi Energy, za sprawą zespołów, do których trafiłem to uczucie zniknęło bardzo szybko. To nie jest też tak, że technical writer ma tutaj taryfę ulgową. Zespół dewelopersko-produktowy potrzebował specjalisty, miał pewne wymagania i oczekiwania względem dokumentacji, „zaprosił mnie do wspólnego stołu” i oczekiwał, że w temacie dokumentacji będzie mógł na mnie polegać. Taka postawa bardzo dobrze wpłynęła na naszą współpracę i utwierdziła moją pewność siebie w roli technical writera.

Szerzej o zespole i produkcie pisałem już w artykule tutaj. Oddaje on atmosferę tego co się u nas dzieje i jeśli ktoś ma ochotę, zapraszam do przeczytania.

Po tych 10 latach spędzonych na pisaniu dokumentacji, stwierdzam, że to w dużej mierze od developerów zależy czy polubisz tą pracę czy nie. W zgranym i różnorodnym zespole każdy coś wnosi, każdy jest ekspertem w jakiejś dziedzinie. Jest to bardzo budująca atmosfera, wiesz na czyją pomoc możesz liczyć. To właśnie dzięki takiej współpracy nauczyłem się korzystać z pewnych narzędzi deweloperskich i tego jak zorganizowany jest kod źródłowy produktu, który opisuję. Tutaj podkreślę, że nie znam się na programowaniu, jakoś mnie to specjalnie nie kręci, ale z dobrym zespołem, który mnie otacza wiele rzeczy związanych z IT staje się dla mnie bardziej przystępne.

4. W jaki sposób jest zorganizowana praca Twoja i Twojego zespołu?

Mam jeden główny produkt, który rozwija 5 zespołów deweloperskich pod okiem 3 biznes analityków. Dostarczamy wersję Cloudową i wersję, którą klient może sobie sam instalować u siebie. Wersję Cloudową wydajemy co dwa tygodnie i co za tym idzie pewna część dokumentów w mniejszym lub większym stopniu musi być aktualizowana równolegle z wersjami Cloudowymi. Wersja, którą klient instaluje sobie sam wychodzi 3 razy w roku i wymaga wygenerowania ok 15/20 różnych dokumentów. Na szczęście, większość tych dokumentów wymaga tylko drobnych zmian. Najwięcej pracy jest zawsze przy podręcznikach użytkownika i instalacji. Ok 4 tygodnie przed releasem można poczuć jak wiele elementów ma wpływ na moją pracę i to co czym piszę.

5. Jakich narzędzi używasz i co o nich sądzisz?

MadCap Flare, tego narzędzia używam 6/7 lat, zdążyłem się do niego przyzwyczaić. Jest dość duża międzynarodowa społeczność, która z niego korzysta i internetowe grupy gdzie writerzy nawzajem sobie pomagają. Dla mnie niezwykle wartościowe okazały się konferencje zagraniczne, na które wysyłała mnie firma i możliwość poznania ludzi, którzy od lat korzystają z tego narzędzia, a technical writing tworzą od lat 80/90. Swoje pliki źródłowe przechowuję i wersjonuję przy pomocy Gita, a do tworzenia opisów metod API używam Microsoft Visual Studio. Czasem zdarza mi się współpracować przy tworzeniu/edycji tekstów dla UX Designerów i wówczas robię to np. w programie Figma.

6. W jaki sposób zdobywasz informacje potrzebne do tworzenia dokumentacji?

Przez ponad 3 lata w Hitachi Energy dość dobrze zaprzyjaźniłem się z produktem, który opisuję i staram się jak najwięcej rzeczy robić sam. Monitoruję historyjki w Jirze, aby znać postęp prac nad nowymi funkcjonalnościami, biorę udział w różnych spotkaniach, korzystam z dostępnych środowisk demo. To jest chyba taki idealny model gdzie technical writer poznaje produkt tak jakby to był jego produkt, samodzielnie pisze dokumentację, która gdy jest mniej lub bardziej gotowa, trafia w ręce zespołu deweloperskiego, aby sprawdzić jej techniczną poprawność.

Nie jest jednak tak, że znam cały produkt w 100%. Nadal przytrafia mi się tzw. „Aha! Moment" gdzie dowiaduję się o czymś, co dla niektórych osób było oczywiste i powszechnie znane, a ja trafiam na to pierwszy raz, bo wcześniej nie opisywałem zbyt wiele z danego obszaru produktu.

To co mi znacznie ułatwia pracę to nagrywanie spotkań, podczas których jeden z naszych ekspertów mi coś wyjaśnia. Podczas spotkania mogę skupić się na zagadnieniu i zadawaniu pytań, a nie na robieniu notatek. Jest to szczególnie przydatne jeśli dane zagadnienie jest trudne techniczne lub system, na którym odbywa się demonstracja zawiera zasoby, których w łatwy sposób sam nie jestem w stanie sobie przygotować lub byłoby to zbyt czasochłonne. Zdarza się też, że opisywanie tego co widziałem muszę odłożyć na kilka dni/tygodni i wówczas takie nagranie jest bezcenne.

7. Jakie typy dokumentów tworzysz?

Tworzę wszelkie niezbędne dokumenty. Najbardziej potrzebne i poczytne są noty wydania, podręczniki użytkownika, instalacji i integracji. Ta dokumentacja oddaje w 99% to co się dzieje i zmienia w naszym oprogramowaniu. Dokumenty te dostarczam w formacie pdf. Część produktów Hitachi Energy ma dokumentację w postaci online helpów, natomiast nie mój produkt.

8. W jakich językach piszesz dokumentację i jak jest ona publikowana?

Nie będzie tutaj chyba zaskoczenia. Dokumentację tworzę w języku angielskim. Pod kątem językowym jest to bardziej American English, a ostatnio dodatkowo staram się wdrażać w swojej pracy uproszczony angielski techniczny według wytycznych ASD-STE 100. Jest to ciekawe doświadczenie.

9. Jakie produkty opisujesz?

Moim głównym produktem jest produkt z kategorii asset performance management, co po polsku tłumaczy się jako oprogramowanie do zarządzania wydajnością aktywów. Nasze rozwiązanie Lumada APM (Asset Performance Management) pozwala na optymalizację kosztów utrzymania oraz zarządzania ryzykiem wystąpienia awarii. Mam tu na myśli kluczowe aktywa przedsiębiorstw o znaczeniu strategicznym, takich jak elektrownie czy fabryki. Stabilność i bezpieczeństwo tych urządzeń i systemów zapewnia bezpieczeństwo dostaw dla odbiorcy końcowego.

Poza tym zdarza mi się czasem opisywać inne produkty i/lub urządzenia związane z branżą energetyczną.

10. Czy oprócz tworzenia dokumentacji zajmujesz się czymś jeszcze, np. tworzeniem materiałów marketingowych? Jeśli tak, to czym i jakich narzędzi do tego używasz?

Ostatnimi czasy wróciłem do roli Scrum Mastera i dorywczo wspieram jeden z zespołów deweloperskich w tej roli. Wcześniej byłem Scrum Masterem zespołu dokumentacyjnego, więc to co robię teraz jest czymś trochę nowym. Ten swoisty eksperyment pozwolił mi zbliżyć się do codziennej pracy jednego zespołu i mieć bardzo dobry wgląd w to co się dzieje. Ponieważ na koniec każdego sprintu muszę aktualizować dokumentację produktową, takie zbliżenie do zespołu dostarcza mi niezbędnych informacji. Ciekawym doświadczeniem jest też udział w dyskusjach, które są bardzo techniczne, chwilami trudne dla mnie do zrozumienia, a dotyczące codziennej pracy. Staram się z nich coś wyłuskać, zadawać pytania i wyciągać wnioski. Mam takie wrażenie, że z czasem coraz więcej rozumiem z tego o czym zespół rozmawia i sprawniej „łączę ze sobą kropki”, jeśli wiecie co mam na myśli.

Dodatkowo jestem zaangażowany w tematy EB (Employer Branding) i rekrutacyjne w mojej firmie. Język angielski od zawsze był moim hobby i jeśli tylko mam czas, a ktoś w innym dziale potrzebuje językowej pomocy robię to z przyjemnością.

11. Jakie są największe wyzwania, które napotykasz w swojej pracy?

Brak czasu i chwil skupienia.

Momentami brakuje mi dni kiedy nikt nic ode mnie nie chce i mogę po prostu usiąść spokojnie i pisać. Praca technical writera chwilami przypomina polowanie. Musisz łapać ludzi, którzy mogą dostarczyć ci to co potrzebujesz: dostęp do jakiegoś zasobu, odpowiedź na pytania, informację na temat planowanych funkcjonalności. Kiedy to wszystko już dostaniesz okazuje się, że powoli zbliża się koniec tygodnia, a wypadałoby usiąść i stworzyć przynajmniej pierwsze szkice dokumentu. Jednocześnie też możesz poczuć się jak zwierzyna łowna, bo ktoś chce z Tobą skonsultować jakieś zagadnienie językowe, dopytać czy mamy dokumentację na jakiś dany temat, itp. Stąd bierze się ten brak czasu i chwil skupienia.

Przed pandemią zdecydowana większość osób, z którymi współpracuję była na miejscu w biurze i łatwiej było z nimi porozmawiać. Wówczas brałem jeden dzień w tygodniu pracy z domu, aby ukryć się przed światem i skupić na pisaniu. Teraz ten trend się trochę odwrócił. Staram się zaglądnąć do biura raz lub dwa razy na miesiąc, aby pewne sprawny omówić na żywo. Kiedyś uciekałem z biura, teraz dla komfortu i zmiany otoczenia uciekam czasem do biura.

12. Co najbardziej lubisz w swojej pracy?

Tych argumentów jest sporo. Na początek, szeroki zakres zadań i możliwości. Praca w dużej firmie z dużą ilością projektów i zespołów nie daje czasu na nudę. Przy tym mam pełną elastyczność miejsca pracy. Mam dobrze wyposażone stanowisko do pracy w domu, jak i w biurze i korzystam z nich według potrzeb. Mam dobry produkt, który przyjemnie się opisuje. Jakoś nigdy nie przepadałem za tworzeniem dokumentacji takiej typowo deweloperskiej, technicznej. Lubię tworzyć tutoriale, dokumentację z przykładami, dokumentację, która odpowiada na realne scenariusze, z którymi spotykają się użytkownicy naszego oprogramowania.

Bardzo doceniam budżet szkoleniowy, który możemy wykorzystać we własnym zakresie. Muszę przyznać, że okres pandemii był pod tym względem wyjątkowy. Wiele wydarzeń i szkoleń przeszło na formułę online, a co za tym idzie ich cena była niższa. Dzięki temu udało mi się zgłębić UX writing poprzez udział w 2 warsztatach i konferencji. Dodatkowo zainteresowałem się Simplified Technical English, skończyłem studia online i zdałem egzamin. Nie jest tylko tak, że firma od nas wymaga i nic w zamian nie daje. Mam zbalansowane godziny pracy i dużą elastyczność. Wymagania są na tyle realistyczne, że bardzo, ale to bardzo rzadko zdarza mi się duży nadmiar pracy. Tak naprawdę te 3 wydania produktu, o których mówiłem wcześniej, to czas kiedy przez 2-4 tygodnie musze się bardzo intensywnie skupić i dostarczać dokumenty według określonego harmonogramu, aby nie blokować kroków naszego „release process”. Pracy jest dużo, ale nie czuję żeby mnie ta praca przytłaczała lub ktoś stał mi nad plecami i dopychał zadania na siłę. Bardzo to doceniam.

13. Co możesz poradzić osobom, które chciałyby zacząć swoją przygodę z pisaniem dokumentacji?

Patrząc na rok 2012 i na 2022 bardzo dużo się zmieniło. Zawód technical writera stał się bardziej rozpoznawany w Polce. Zawiązała się społeczność technical writerów, regularnie w Krakowie odbywa się konferencja SOAP, w Warszawie mamy studia podyplomowe z technical writingu, firmy oferują płatne staże, jest dużo specjalistycznych szkoleń, chociażby z UX writingu, jak i darmowych webinarów i meetupów. Jest dużo łatwiej wejść w zawód niż to było jeszcze kilka lat temu. Zawiązała się polska społeczność technical writingu, która zawsze jest w stanie doradzić, czy to językowo, czy w problemach narzędziowych, czy np. na jakie wydarzenie lub szkolenie warto się wybrać.

Uważam, że warto zainteresować się pisaniem dokumentacji i spróbować swoich sił. Nie ma chyba lepszego sposobu żeby poznać ten zawód inaczej niż pisząc. Może się okazać, że taka praca będzie czymś dla Was. Jeśli nie, to praca jako technical writer może otworzyć Wam drzwi do innych ról w świecie IT. Technical writing pozwala poznać dobrze firmę, różne role w organizacji i zachęcić do sprawdzenia różnych ścieżek kariery.

Gdyby ktoś chciał zadać mi jakieś pytanie zapraszam do kontaktu.

Piotrze, bardzo dziękujemy za czas, jaki poświęciłeś na ten wywiad.

Jeśli wśród czytelników znajdzie się ktoś chętny do podzielenia się swoimi doświadczeniami w pracy technical writera niech pisze na nasz adres: kontakt@techwriter.pl