Przejdź do głównej zawartości

Kilka pytań do - część 29

· 6 min aby przeczytać

W ramach naszego znanego i lubianego cyklu "Kilka pytań do..." rozmawiamy dziś z Joanną, która, od prawie półtora roku realizuje się w roli dokumentalisty w dużej korporacji z branży IT, a wcześniej pracowała przez wiele lat jako tłumaczka języka angielskiego.

Joanna zgodziła się podzielić swoimi doświadczeniami i wrażeniami z życia tech writera.

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

Pracę w charakterze technical writera zaczęłam niemal półtora roku temu. Dopiero wtedy przekonałam się, jak dalece rola ta wykracza w praktyce poza potoczne wyobrażenia o „pisaniu dokumentacji”. Tak naprawdę chodzi tu o tworzenie szerokiego spektrum wszelkiego rodzaju pomocy dla użytkownika. Można powiedzieć, że współczesna dokumentacja to raczej „user assistance” oznaczająca różnego typu interakcję z odbiorcą. Warto również podkreślić, że w dużej mierze praca ta polega na gromadzeniu informacji z najróżniejszych źródeł i ich nieustannym tłumaczeniu z „technicznego na ludzki” – choć nie zawsze, gdyż czasem adresatem dokumentacji nie są użytkownicy końcowi, ale na przykład deweloperzy po stronie klienta, dostosowujący oprogramowanie pod jego indywidualne potrzeby.

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

Bardzo długo myślałam o tym, że w moim życiu zawodowym potrzebuję zmiany. Właściwie przez całe życie związana byłam z jednym pracodawcą i jedną branżą. Czułam, że chcę się rozwijać i być nie tyle odtwórcą – a tak wygląda w dużej mierze praca tłumacza – ile autorem. Zastanawiałam się też na ile zgromadzona wiedza i doświadczenie mogą przydać mi się w innym kontekście. W samej zmianie nie było nic wyjątkowego: opracowałam CV i przeglądałam ogólnodostępne oferty. Niestety nie znałam nikogo w branży IT, więc szlaki przecierałam sobie samodzielnie. Na pewno nie jest bardzo łatwo w sytuacji, gdy jest się humanistą aspirującym do stanowiska nieco technicznego, ale po jakimś czasie się udało.

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

Pracuję dla wielkiej korporacji – mój pracodawca to jeden ze światowych liderów w produkcji oprogramowania. Współpracowników nie mam chyba tylko na Grenlandii. Obecnie wspieram jako writer dwa zespoły – jeden w Polsce, drugi w Wielkiej Brytanii; w codziennej pracy potrzebujemy jednak kontaktu z ludźmi z innych miejsc – nie tylko w Europie. Na pewno czasem trudno się „spotkać”, kiedy jedni dopiero wstają, a drudzy chcieliby już pójść spać. Co do systemu pracy, ja sama pracuję w stu procentach zdalnie, a większość moich kolegów hybrydowo. Wszystkie zespoły w firmie pracują zgodnie z metodologią Agile/Scrum – w składzie mamy przede wszystkim programistów, ale są tu również inne osoby: product owner, scrum master, architekt, testerzy, no i oczywiście ktoś taki, jak ja – dokumentalista.

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

Jak już wspomniałam – zespoły pracują w sposób zwinny w dwutygodniowych sprintach. Ze względu na rozproszenie geograficzne i czasowe korzystamy z popularnych i niezbędnych narzędzi do organizacji pracy, takich jak Jira, wszelkiego rodzaju dodatkowe planery czy komunikatory. Przydaje się też firmowa Wiki.

5. Jakie doświadczenia zebrałaś jako technical writer? W jakich projektach brałaś udział?​

Mam wrażenie, że w przypadku branży IT jedyną stałą jest zmiana. Każdy dzień to nowe doświadczenia – w dużym uproszczeniu mogę jednak powiedzieć, że projekty, w których brałam udział koncentrują się na szeroko pojętym oprogramowaniu z obszaru handlu/commerce.

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

Obawiam się, że na wymienienie narzędzi, z których korzystam zabrakłoby nam tu miejsca. W podstawowych obowiązkach posługuję się jednym z edytorów XML sprzężonym z systemem zarządzania treścią opartym o założenia DITA (Darwin Information Typing Architecture). Nieobce mi są GitHub i Markdown, Wiki Confluence oraz programy do pracy z grafiką i wideo - SnagIt, czy Camtasia.

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

Z Internetu. To znaczy między innymi. Głównym źródłem informacji jest codzienna praca z własnym zespołem. Ponadto zapoznaję się z istniejącą już dokumentacją, która w przypadku produktów, z którymi pracuję jest naprawdę olbrzymia i złożona – mówimy tu o tysiącach stron. Ważna jest też tzw. surowa dokumentacja techniczna dostarczana przez programistów. Liczą się też treści przygotowywane przez product ownerów – wszelkiego typu user stories, ale także opisy konkretnych deweloperskich tasków. No i rozmowy, pytania, pytania, rozmowy. Co ważne, proces ten właściwie nigdy się nie kończy – ponieważ nie pracujemy w metodologii waterfall, dokumentacja powstaje równolegle z produktem. Nie opisujemy czegoś gotowego, ale oprogramowanie, które jest nieustannie rozwijane.

8. Jakie typy dokumentów tworzysz?​

Wracając niejako do koncepcji user assistance, współczesna „dokumentacja” to nie tylko standardowe manuale dla użytkownika końcowego czy biznesowego lub przewodniki przygotowywane pod konkretne grupy użytkowników, w tym administratorów, czy integratorów systemów, choć takimi również się zajmuję. Tworzy się także teksty widoczne w obrębie interfejsu, specyficzną dokumentację API, a także grafiki i materiały wideo.

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

Całość dokumentacji tworzę w języku angielskim, gdyż to ona ma najszersze grono odbiorców. Oczywiście część naszych produktów jest lokalizowana, ale w mojej firmie technical writerzy nie zajmują się tym procesem w ogóle. Nasza rola sprowadza się do przygotowywania oryginałów zgodnie ze standardami komunikacji technicznej oraz opracowywania anglojęzycznej terminologii tak, aby jak najbardziej ułatwić życie tłumaczom.

10. Jakie produkty opisujesz?​

Pracuję w obszarze produktów commerce – zarówno od strony backendowej, jak i frontendu, czyli storefrontu, z którym mają do czynienia klienci końcowi. Ze względu na architekturę naszych rozwiązań, dużo tu zagadnień mocno technicznych związanych z integracją i komunikacją pomiędzy składowymi systemu.

11. 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?​

Ze względu na to, jak rozbudowane jest nasze portfolio, komunikacja marketingowa to u nas zupełnie odrębna działka. W mojej pracy najbliższe marketingowi będzie opisywanie biznesowych korzyści danej funkcji, ale chodzi tu raczej o konkrety – bez reklamowych fajerwerków i pełnych ekscytacji sformułowań.

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

W moi przypadku wszystkie największe wyzwania wiążą się z brakiem typowo technicznego backgroundu. Złotą rybkę poprosiłabym o „licencjat z informatyki”.  Bywa bardzo trudno merytorycznie, kiedy brakuje fundamentów. Z drugiej strony zapewnia to świeże podejście – skoro dla mnie coś jest trudne, czy nieoczywiste, to można z dużą dozą pewności założyć, że takie też będzie dla klienta. Łatwiej się zatem wczuć w położenie odbiorcy i wymyślić dobrą strategię objaśnienia zawiłości oprogramowania innym.

13. Co najbardziej lubisz w swojej pracy?​

Zmienność i konieczność ciągłego uczenia się! Oczywiście bywa to też męczące – chętnie by się porobiło jakieś rutynowe zadania. Niemniej jednak to, że właściwie każdy dzień przynosi coś nowego daje poczucie, że się rozwijasz i że jeszcze duuużooo do osiągnięcia. Lubię też interakcję z ludźmi, których wiedza i doświadczenie są całkiem odmienne od mojego. No i oczywiście fakt, że spotykam na zawodowej drodze ludzi z całego świata, a nie tylko – jak wcześniej – humanistów z Polski.

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

Z perspektywy czasu powiedziałabym, że można sobie trochę ułatwić życie próbując zdobyć podstawy wiedzy programistycznej, czy ogólnie „informatycznej”. Naszym atutem jest wiedza językowa, standardy komunikacji technicznej różnią się nieco w zależności od firmy i stosunkowo łatwo je przyswoić. Trudniej zrozumieć o czym mówią współpracownicy, kiedy już zaczną o „merdżu do dewelopa” i „podmianie binarki”.

Joanno, serdeczne dzięki za czas poświęcony na udzielenie wywiadu.

Jeśli chcecie podzielić się z nami swoimi doświadczeniami i wrażeniami z pracy technical writera, piszcie śmiało na adres: kontakt@techwriter.pl.