Kilka pytań do - część 24

Po dość długiej przerwie wracamy do cyklu: Kilka pytań do. Tym razem poznacie pracę technical writera z punktu widzenia stażystek.

Patrycja Pyrek i Klaudia Wilk to stażystki firmy Hitachi ABB Power Grids. Gdyby trzeba było ją podsumować jednym zdaniem, to najlepiej obrazuje to angielskie „we keep the light on”. Hitachi ABB Power Grids wnosi pionierskie rozwiązania, dzięki którym światowe sieci energetyczne są mocniejsze, bardziej inteligentne, ekologiczne i niezawodne. Firma rozwija wiodące technologie zasilania, technologie cyfrowe, zaawansowane systemy automatyzacji i otwarte platformy cyfrowe.

Patrycja i Klaudia rozpoczęły staż kilka miesięcy temu i zgodziły się podzielić z Wami swoimi wrażeniami. Rozmowę z nimi polecamy w szczególności osobom, które rozpoczynają swoją karierę zawodową w technical writingu.

Jak długo pracujesz jako technical writer i na czym właściwie polega Twoja rola?

Patrycja: Technical writingiem zajmuję się od około roku. Jestem stażystką, której zadaniem jest tworzenie i aktualizowanie dokumentacji technicznej. W głównej mierze zajmuję się pisaniem User Guide’a i dokumentacji API.

Klaudia: Jako technical writer pracuję niemal rok, obecnie jestem na stażu. Moje główne zadania opierają się na przygotowaniu Release Notes i aktualizowaniu User Guide’a. Dodatkowo piszę dokumentację API oraz pomagam developerom przy wewnętrznej dokumentacji.

W jaki sposób zostałaś technical writerem?

Patrycja: Można powiedzieć, że Technical Writerem zostałam trochę przez przypadek. Jako studentka rozpoczęłam poszukiwania stażu i między dostępnymi ofertami trafiłam na tą związaną z technical writingiem. Na początku niewiele wiedziałam na ten temat, ale po zrobieniu małych poszukiwań i zapoznaniu się z tematyką, uznałam, że może to być ciekawe zajęcie. W pewnym sensie łączy dwie rzeczy, które mnie interesują, czyli języki obce i technologie.

Klaudia: Szerzej o technical writingu dowiedziałam się na spotkaniu organizowanym przez firmę, w której obecnie pracuję. Zdałam sobie sprawę, że pisanie dokumentacji to naprawdę ważny aspekt tworzenia produktu i zaczęłam zgłębiać temat. Zaskoczyło mnie to, jak dużo jest możliwości, jeśli chodzi o techniczne aspekty tworzenia dokumentacji. Po kilku miesiącach okazało się, że moja obecna firma szuka stażysty. Postanowiłam wysłać CV i zobaczyć, jak w praktyce wygląda technical writing.

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

Patrycja: Firma jest wiodącym na świecie pionierem technologii, które pozwalają na zaspokojenie rosnącego zapotrzebowania na energię elektryczną przy jednoczesnym zmniejszeniu wpływu na środowisko. Zespół z którym pracuję pracuje nad aplikacją związaną z rynkiem energii. Wpiera ona operatorów rynków detalicznych energii, firmy dystrybucyjne. Aplikacja jest wykorzystywana do tworzenia prognoz, raportów i rozliczeń związanych z rynkiem energii. Praca zespołu oparta jest o metodykę Scrum.

Klaudia: Firma, w której pracuję, jest pionierem w dziedzinie nowych technologii i zaawansowanych systemów automatyzacji, dotyczącej branży energetycznej. Mój zespół odpowiada za produkt, który ma prognozować i informować o potencjalnych zagrożeniach różnych urządzeń energetycznych. Praca zespołu opiera się na zasadach Scrum, więc niezbędna jest cykliczna aktualizacja dokumentów.

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

Patrycja: Do pisania dokumentacji User Guide’a używam programu Microsoft Word. Myślę, że jest to program dobrze wszystkim znany. Ma przyjazny interfejs użytkownika, jest dosyć prosty w obsłudze. Natomiast do dokumentowania API korzystam z zestawu narzędzi - Swagger. Swagger jest również wygodnym narzędziem, które z początku może przerażać, gdyż wiąże się z zaglądaniem w kod aplikacji. Jednak po zapoznaniu się z działaniem już nie jest taki straszny.

Klaudia: Podczas pisania dokumentacji używam głównie MadCap Flare oraz Microsoft Word. Jeśli chodzi o dokumentowanie metod API, to korzystam ze Swaggera. Uważam, że wszystkie narzędzia po bliższym poznaniu, są naprawdę przyjemne w użytkowaniu, a przede wszystkim pomocne w procesie dokumentowania.

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

Patrycja: Najwięcej informacji zyskuję dzięki spotkaniom z zespołem, ciągłym śledzeniem tego co się właśnie dzieje z aplikacją. Biorę też udział w spotkaniach z biznes analitykiem zespołu, gdzie poznaję produkt nie tylko od strony technicznej, ale też biznesowej. Poznaję na tych spotkaniach również wymagania użytkownika względem aplikacji. Na pewno ułatwia mi to opisywanie produktu i poszerza wiedzę na temat procesów jakie w nim zachodzą.

Klaudia: Informacje, które są mi niezbędne do tworzenia dokumentacji produktu, zazwyczaj zdobywam podczas spotkań zespołowych. Developerzy, z którymi współpracuję, zawsze chętnie pomagają mi zrozumieć aspekt, który muszę opisać. Dodatkowo zespół organizuje spotkania w formie szkolenia, na których są wyjaśniane pewne aspekty funkcjonowania aplikacji. Zdecydowanie jest to pomocne przy tworzeniu dokumentacji.

Jakie typy dokumentów tworzysz?

Patrycja: Tworzę User Guide’a, gdzie dokumentuję działanie aplikacji pod użytkownika. Zapisuję przydatne instrukcje i porady, które mają ułatwić poruszanie się po aplikacji. Zajmuję się też dokumentowaniem API, które bardziej skierowane jest do programistów.

Klaudia: Dokumenty, jakie tworzę, to w głównej mierze User Guide i Release Notes. User Guide jest już gotowym produktem, którego tylko aktualizuję o najnowsze zmiany. Natomiast w Release Notes piszę o wszelkich zmianach, które wydarzyły się od poprzedniej wydanej wersji. Dodatkowo zajmuję się pisaniem dokumentacji API, z której korzystają również klienci.

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

Patrycja: Dokumentację piszę w języku angielskim. Dostarczana jest klientom wraz z produktem. W głównej mierze współpracuję z jednym zespołem, gdzie opisuję aplikację związaną z rynkiem energii. Aplikacja wykorzystywana jest do tworzenia rozliczeń na podstawie danych energetycznych, do zarządzania złożonymi umowami i kontraktami, a także jest wykorzystywana do tworzenia raportów z tym związanych.

Klaudia: Dokumentację piszę w języku angielskim. Jest ona cyklicznie przekazywana do klientów przy każdej aktualizacji produktu. Produkt, który opisuję, związany jest z predykcją stanu działania i sprawności urządzeń, wykorzystywanych w branży energetycznej. Głównym zadaniem jest prognozowanie i przedstawianie zagrożeń, które zaburzają ich prawidłowe funkcjonowanie.

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?

Patrycja: Nie zajmuję się marketingiem, ale też pracuję nad contentem. Pomagam biznes analitykowi przygotowywać specyfikacje do widoków w aplikacji. Miałam też okazję wcielić się w rolę testera. Wykonywałam zarówno testy manualne, jak i czasem pisałam testy automatyczne. Nieraz takie testy trzeba też udokumentować, więc tym też się zajmowałam. Zdarza się też, że dostarczam tłumaczenia w języku japońskim.

Klaudia: Zdarzyło mi się pomagać innym zespołom przy opisywaniu nowej funkcjonalności produktu czy konsultowaniu treści, dotyczących UX writingu. Również miałam okazję pomagać przy tworzeniu materiałów, służących do promocji firmy, na przykład w social mediach. Często wspieram developerów przy tworzeniu wewnętrznej dokumentacji, jeśli tylko jest taka potrzeba.

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

Patrycja: Największym wyzwaniem, szczególnie na początku, była tematyka produktu, który jest ściśle związany z rynkiem energii. Mimo, że jest to temat techniczny, to jednak jest to dla mnie coś nowego, nieraz muszę poświęcić więcej czasu, by zapoznać się lepiej z tą tematyką. W końcu ciężko byłoby pisać o czymś o czym się nie ma za dużego pojęcia. Teraz, dzięki lepszemu poznaniu produktu i pomocy zespołu, nie stanowi to dla mnie takiego problemu, ale zawsze znajdą się nowe rzeczy do poznania.

Klaudia: Na samym początku największym wyzwaniem, który zajął mi trochę czasu, było zrozumienie produktu i jego działania. Miałam jednak możliwość przetestowania aplikacji, jej instalacji oraz funkcjonowania. Na podstawie istniejącej dokumentacji, licznych spotkań i pomocy developerów, nie jest już to dla mnie aż tak dużym wyzwaniem, ale wciąż staram się poszerzać wiedzę w tym zakresie.

Co najbardziej lubisz w swojej pracy?

Patrycja: Różnorodność zadań. To, że zawsze są jakieś nowe wyzwania, nowe tematy. Dużą satysfakcję również dają pozytywne opinie zwrotne po udanym releasie produktu. Cieszy mnie fakt, że praca nie jest monotonna i to, że łączy moje pasje.

Klaudia: Zdecydowanie jest dużo możliwości do nauki, a zadania są różnorodne. Często w pracy analizujemy dokumentację pod względem językowym, zastanawiamy się nad odpowiednim słownictwem oraz staramy się tworzyć dokumentację zgodną z zasadami „Simplified Technical English”. Również pojawiają się wyzwania techniczne, na przykład w czasie pisania API. Praca technical writera łączy ze sobą aspekty językowe i techniczne, co zdecydowanie jest częścią moich zainteresowań.

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

Patrycja: Czasem prostota jest kluczem. Nie trzeba tworzyć długich zawiłych zdań, aby przekazać coś w równie profesjonalny sposób. Polecałabym zapoznać się z frazą ‘Simplified Technical English’, jeżeli ktoś planuje tworzyć taką dokumentację w języku angielskim. Coś co może być poprawne w mowie codziennej, może nie do końca spełniać wymagania dokumentacji technicznej, dlatego warto zapoznać się z panującymi zasadami, aby nie nabrać złych nawyków na wstępie.

Klaudia: Przede wszystkim polecam zaznajomienie się z podstawowymi zasadami pisania dokumentacji, na przykład podczas kursu online. Kolejnym ważnym krokiem jest zorientowanie na rynek i poszerzanie wiedzy. Zdecydowanie polecam czytać strony lub blogi związane z technical writingiem, żeby być na bieżąco z aktualnymi trendami. Również świetnym źródłem wiedzy są konferencje, poświęcone tematyce pisania dokumentacji.

Patrycjo, Klaudio - bardzo dziękujemy za udzielone nam odpowiedzi.

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