Kilka pytań do - część 9

Jeśli ktoś śledzi cykl "Kilka pytań do...", zapewne zauważył, że najbardziej doświadczeni spośród naszych dotychczasowych rozmówców siedzą w branży mniej więcej cztery lata (pomijamy Annę, która działa na innym rynku). Mamy świadomość, że te kilka wywiadów zapewne nie odzwierciedla pełnego przekroju społeczności dokumentalistów, ale dają one pewne wyobrażenie, jak młody jest nasz rodzimy rynek tech commu. Naszą ambicją jest nakreślenie pełniejszego obrazu dlatego nieustannie poszukujemy osób, które mogły by go dopełnić. Dzisiaj zapraszamy na wywiad z Jarkiem Orłowskim, który na tle innych przepytywanych jest prawdziwym rekordzistą w kategorii "długość stażu".

Jak długo pracujesz jako Tech Writer?

10 lat.

W jaki sposób zostałeś Tech Writerem?

Zanim zostałem writerem, pracowałem (uwaga, niespodzianka!) jako nauczyciel angielskiego. Zostałem zwerbowany za pomocą „cold-calla” do szkoły, w której pracowałem, przez mojego przyszłego kolegę z zespołu – firma powiększała TechComm o trzy nowe stanowiska i tradycyjna rekrutacja okazała się nieskuteczna w dotarciu do osób biegle posługujących się angielskim z technicznym zacięciem (w tej kolejności). Wcześniej nie miałem pojęcia, że taki zawód istnieje.

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

Pracuję w dużej, międzynarodowej firmie, która jest światowym liderem na rynku oprogramowania do zarządzania wydajnością aplikacji (APM – Application Performance Management). Cała firma zatrudnia około 1700 osób, a we wszystkich liniach produktowych pracuje około 10 osób oficjalnie nazwanych „technical writer”. Content tworzy jednak znacznie większe grono – Product Management, Support, Sales Engineers, a nawet sami użytkownicy za pośrednictwem Community. Mój własny zespół to trzech writerów.

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

W firmie nie ma oddzielnego działu TechComm. Organizacyjnie jesteśmy częścią developmentu. Pracujemy w Agile. Poza taskami dokumentacyjnymi, zajmujemy się także UX copywriting, copy editing i innymi zadaniami według aktualnych potrzeb scrum teamu, do którego jesteśmy przydzieleni. Poza zadaniami scrumowymi, prowadzimy oddzielny board z taskami niewynikającymi bezpośrednio z bieżącego developmentu. Współpracujemy blisko z supportem, jesteśmy zaangażowani w budowanie Community użytkowników, a także dostarczamy pomocy językowej i redakcyjnej innym działom firmy, niezwiązanym z developmentem.

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

Przeszliśmy długą drogę od dokumentacji utrzymanej w Wordzie, którą transformowaliśmy do DocBooka, dla którego opracowaliśmy nasz własny system automatycznej publikacji. W tym samym czasie, w innych liniach produktowych, writerzy pracowali na Adobe FrameMakerze i RoboHelpie. Te wszystkie formaty przeszły w końcu transformację do utrzymywanego wewnętrznie systemu opartego na DITA i dopasowanego do naszych potrzeb Dita Open Toolkita, z prostym CMSem ułatwiającym kontrolę nad referencjami między topikami. Ostatecznie, w wyniku wielu zmian jakie przeszła nasza organizacja i jej wizja, porzuciliśmy wyszukane narzędzia. Obecnie dokumentację utrzymujemy w Confluence. Z jednej strony brakuje nam elastyczności jaką dawała nam DITA, z drugiej, uczymy się oszczędnie gospodarować słowem i możliwie upraszczać strukturę informacji.

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

Wszelkimi znanymi techwriterom kanałami – rozmowy z SMEs, spotkania planistyczne, spotkania demo, Jira, dokumentacja developerska, kod, forum użytkowników, tickety supportowe oraz wszelkie skrawki informacji, które wpadną w nasze ręce – jak w kawale o studentach, którzy kserują kawałek papieru przywianego przez wiatr na ulicy.

Jakie dokumenty dostarczasz, w jakiej postaci, w jakim języku i jak są one publikowane?

Za czasów DITY dostarczaliśmy PDFy, czysty HTML, WebHelp, Windows Help, a także eksportowaliśmy content wprost do Confluence. Dzisiaj, jedyna forma informacji to strony WWW hostowane przez instancję Confluence, która jest wyposażona w zaawansowany plugin pozwalający na eksport do PDF i HTMLa o jakości zbliżonej do plików produkowanych przez DITA Open Toolkit. Całość informacji dostarczamy w języku angielskim.

Jakie produkty opisujesz?

Zaawansowane oprogramowanie do monitorowania wydajności aplikacji sieciowych. Nasi odbiorcy to pełen przekrój, od zwykłych odbiorców raportów, poprzez administratorów systemów, którzy instalują, konfigurują i zarządzają naszym softwarem, aż po DevOps i zaawansowanych użytkowników, którzy używają naszego softu do rozwiązywania problemów w swoich aplikacjach. Ważnym odbiorcą naszej pracy są także pracownicy firmy wykonujący zadania u klientów.

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?

Pracuję także nad UX Copywriting.

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

Wyzwanie jest tak naprawdę jedno i z niego wywodzą się wszystkie inne. Dostęp do informacji. Nasz software jest często używany w środowiskach niedostępnych zwykłym śmiertelnikom, więc nie każdą funkcjonalność jesteśmy w stanie przetestować samodzielnie w realnych warunkach, a tym samym uzyskać perspektywę końcowego użytkownika.

Co najbardziej lubisz w pracy Tech Writera?

Możliwość obcowania z technologią i wszechstronność zadań, z którymi się mierzę. Jestem trochę researcherem, trochę developerem, trochę testerem, trochę grafikiem, no i w końcu trochę pisarzem.

Co byś radził osobom, które chciałyby zacząć swoją przygodę z pisaniem dokumentacji?

Poszukać oferty i odpowiedzieć na nią, nie przejmując się zbytnio brakami w litanii oczekiwań od kandydata. Rekrutując na to stanowisko, sprawdza się przede wszystkim umiejętności komunikacyjne, co poza biegłością w posługiwaniu się wymaganym językiem, oznacza także otwartość, umiejętność konstruowania prostych komunikatów, czy umiejętność wyciągania wniosków. Poza tym, przydaje się zdolność do szybkiego przyswajania wiedzy. Inne wymagania, także te dotyczące narzędzi i znajomości technologii, można spokojnie nadrobić w trakcie pracy. To nie fizyka kwantowa.