Technical writer – jak wygląda jego dzień pracy?

Technical writer?  To czym ty się zajmujesz?

Często nazywani jesteśmy pisarzami technicznymi, dokumentalistami, UX writerami, content designerami. Nazw dla tego zawodu jest naprawdę dużo. Jednak za każdym razem, gdy mówię komuś, że pracuję jako technical writer, niemalże natychmiast pojawia się pytanie: „Ale czym ty się tak naprawdę zajmujesz?”. Moja odpowiedź na to z pozoru niewinne pytanie skutkuje… pytającymi spojrzeniami i lawiną kolejnych pytań. „Ale co to jest? Co to znaczy?  Czy to ty piszesz te niejasne instrukcje, które są dołączane do instalacji oprogramowania?”.

Jeśli czytaliście na naszym blogu poprzednie wpisy z tej serii, wiecie już, kim jest i czym zajmuje się technical writer. Pisaliśmy o nim w artykułach Technical Writer, czyli mistrz słowa w IT i “Technical writer – poznaj jego supermoce!”. Jakie obowiązki wiążą się z pracą na tym stanowisku, jakie umiejętności są potrzebne – w tym artykule chcę Wam opowiedzieć, jak to wygląda z mojej perspektywy i zaznajomić Was z codziennymi wyzwaniami tej pracy.

Nie tylko formalna edukacja

Wybór tej ścieżki zawodowej oznacza ciągłą naukę. Nasza praca wymaga jednak znacznie więcej niż tylko zaangażowania w formalną edukację. Stale współpracujemy z ekspertami z wielu dziedzin i często z wielu różnych branż. Wiąże się to z potrzebą poszerzania wiedzy, często samodzielnie, ale również poprzez uczestnictwo w kursach czy webinarach.

Jako pisarz techniczny, potrzebujesz silnych umiejętności organizacyjnych, aby sprawnie zarządzać informacjami, które zbierasz. W wielu przypadkach zdobycie informacji nie jest trudne, ale precyzyjne określenie, które z nich są istotne dla czytelników, może być wyzwaniem. Wielu doświadczonych pisarzy technicznych tworzy każdego roku kilka nowych książek. Muszą oni przyswajać nowe informacje, rozumieć je, organizować, ustalać priorytety i, co najważniejsze, ostatecznie przekazać tę wiedzę w przystępnej formie.

Zanim jednak powstanie konkretny dokument, czyli efekt końcowy naszej pracy, “po drodze” musi sporo się wydarzyć. Nasza codzienność to weryfikacja materiałów, sprawdzanie istniejącej dokumentacji pod względem językowym, wykonywanie tłumaczeń i innych zadań projektowych zgodnie z ustalonymi standardami, dotyczącymi zwięzłości, stylu i terminologii. Niekiedy również delikatnie wcielamy się w rolę analityka biznesowego, a nawet testera! Tworzenie dokumentacji zajmuje około 40-45% czasu w projekcie, z czego dwie trzecie  poświęcamy na planowanie dokumentacji (zrozumienie user stories, współpracę z deweloperami, testerami, Product Managerami, analitykami) oraz samo jej dostarczenie. Cennym źródłem wiedzy jest dla nas współpraca z analitykami, od których nie tylko czerpiemy informacje o projekcie, wspieramy ich również w bieżących zadaniach.

Praca na tym stanowisku wymaga więc czerpania przyjemności z porządkowania niezliczonych stron dokumentów. Niezbędne są umiejętności redakcyjne (takie jak strukturyzacja, edycja, pisanie, korekta) oraz znajomość metodologii i konsekwentne stosowanie ustalonych reguł stylu. Naszym celem jest przede wszystkim dostarczenie tego, czego klient potrzebuje, bez pozostawiania śladu własnego głosu, a co za tym idzie, odcięcie się od swojego ego.

Przychodzi technical writer do guru

Pewien technical writer, który pracuje w zawodzie już ponad 7 lat, opowiedział mi kiedyś ciekawą historię. Dotyczy ona roli pisarzy technicznych w branży IT i tego, jak wiele mogą, niejako “przy okazji”, wnieść do projektu. Każdy technical writer doświadczył tego niezręcznego momentu, kiedy trzeba opisać naprawdę skomplikowaną funkcję systemu. Właśnie wtedy, nasz wewnętrzny perfekcjonista po prostu nie odpuści. Zaczynamy więc bawić się aplikacją, badać ją, spędzamy godziny, by zrozumieć, jak większość użytkowników zastosowałaby daną funkcjonalność, dzięki czemu możemy ją lepiej opisać. Godziny mijają, a my wciąż nie jesteśmy zadowoleni z research’u, chociaż zaczyna się on robić naprawdę długi. Wreszcie podejmujemy decyzję, że nadszedł czas, aby poprosić guru o pomoc. Guru, czyli, oczywiście, dewelopera. Perspektywa tego spotkania spędza nam sen z powiek, boimy się, że zostaniemy wyśmiani. Gdy w końcu zadajemy deweloperowi pytanie i prosimy go o krótki feedback, zamiast odpowiedzi słyszymy: „Nawet nie wiedziałem, że ta funkcja może tak działać. Nie stworzyliśmy tego celowo. Właściwie, to był tylko stary kod, który baliśmy się usunąć, więc… świetna robota!”

Jak widać, technical writing nie polega tylko na pisaniu. Przy wprowadzaniu nowego produktu, po dostarczeniu kodu, tester testuje poszczególne funkcje, robi to również technical writer, wcielając się w użytkownika końcowego. Dlaczego? Ponieważ jest on pierwszym klientem, a testowanie pomaga w tworzeniu dokumentacji z punktu widzenia użytkownika końcowego. I to właśnie w tym momencie mogą przydarzać się sytuacje jak w powyższej historii.

Technical writing, czyli co poeta miał na myśli?

Technical writing znacznie różni się od literackiego stylu pisania. Język, którego używamy, odbiega również od standardów, których uczymy się  w szkole czy podczas studiów. Spójrzmy na wiersz Edgara Allana Poe.

“Do Heleny” (tłumaczenie: Władysław Nawrocki).

Heleno! dla mnie urok twój
Jest, jak te barki, co przed laty
Koiły ciężki drogi znój,
Cicho wędrowca w swoje światy
Niosąc przez wonne mórz bławaty.

By wyrazić sens tej wypowiedzi, jako technical writer powiedziałabym po prostu: “On uważa, że Helena jest piękna”. I to jest właśnie esencja naszej pracy − przekształcanie złożonych i trudnych materiałów w jasną i zwięzłą dokumentację, która będzie zrozumiała dla docelowych odbiorców.

Technical writerzy to ludzie sztuki, ale zdaję sobie sprawę, że na pierwszy rzut oka nazwanie pisarza technicznego “artystą” może wydawać się nieścisłe. Jednak tam, gdzie mamy do czynienia z kunsztem językowym, czy to w wierszu, czy w instrukcji obsługi, mamy do czynienia ze sztuką. Dodatkowo obala to mit, że pisarstwo techniczne jest nudne i nietwórcze.

Pisząc ten tekst, chciałam pokazać Wam pracę pisarzy technicznych od tej mniej znanej, twórczej strony. Zależało mi też na tym, aby przekonać Was, że zaangażowanie technical writera do projektu po prostu się opłaca. Opracowanie instrukcji obsługi produktu końcowego na przykład przez dewelopera może skutkować zbędnymi opisami lub wyolbrzymionymi korzyściami. Chociaż utrzymanie dużego poziomu szczegółowości jest ważne, profesjonalna dokumentacja techniczna powinna być zwięzła, bezstronna i jasno przedstawiająca fakty. Wysokiej jakości, fachowo opracowana dokumentacja i podręczniki użytkowników świadczą o profesjonalizmie organizacji.