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.