Mamy dla Was kolejną odsłonę cyklu Kilka pytań do... Kto tym razem odpowiada na nasze pytania? Szczegóły poniżej.
Anna Wójcicka wygrała nasz konkurs o wejściówkę na soap! 2022 i udzieliła wyczerpujących odpowiedzi na nasze pytania. W branży jest od niedawna, a dzięki temu patrzy świeżym okiem na to co się dzieje. Usiądźcie wygodnie i przeczytajcie uważnie, bo naszym zdaniem warto 😉
1. Jak długo pracujesz jako technical writer i na czym właściwie polega Twoja rola?
Tech writerem jestem od marca tego roku. Początkowo, zanim zostałam przypisana do projektu, zajmowałam się tłumaczeniami dla działu marketingu, zrobiłam trochę materiałów na użytek wewnętrzny na Confluence (głównie instrukcje użytkownika), wpadła mi też w ręce reedycja dokumentacji API.
Teraz, w projekcie, jestem śledczym 😊 Mamy dwa systemy zarządzania dokumentacją – stary i nowy – i w związku z tym trzeba przenieść dane do nowego. Znajduję luki i łatam je, wychwytuję niejasności i parafrazuję teksty, zmieniam kolejność budując bardziej logiczne ciągi, poprawiam językowo (operujemy w języku angielskim), szukam ludzi, dokumentów i podstron, gdzie znajdę wiedzę, której brakuje. Dokumentacja, którą się teraz zajmuję, osadzona jest w kontekście prawnym (m. in. ochrona danych wrażliwych), ale czuję się dość pewnie z tym zadaniem dzięki poprzednim doświadczeniom zawodowym. Dalsze zadania stopniowo będą się pojawiać i rozwijać.
2. W jaki sposób zostałeś/aś technical writerem?
Złożyłam CV do mojej organizacji na stanowisko analityka biznesowego. W odpowiedzi na aplikację otrzymałam zapytanie, czy nie byłabym zainteresowana podjęciem współpracy w roli tech writera (ze względu na moje wykształcenie językowe), z planem rozwoju w kierunku analityka. Propozycja wydała mi się rozsądna, bo nie miałam jeszcze doświadczenia na stanowisku analityka, a profile pracowników firmy na Linkedin wskazywały, że taka ścieżka rozwoju faktycznie jest tu możliwa.
3. Czy możesz opowiedzieć coś o swojej firmie i zespole, w którym pracujesz?
Pracuję dla polskiej firmy w branży IT, zatrudnionych mamy ok. pięciuset pracowników. Moja firma jest w sam raz, cenię sobie zwłaszcza sprawną komunikację ze wszystkimi działami. Ogólnie rzecz biorąc, wdrażamy i rozwijamy rozwiązania Salesforce, UiPath oraz Veeva. W ramach tych działań świadczymy również usługi team & body leasing.
Jako tech writerzy tworzymy tu kameralne, czteroosobowe grono. Nasz mały zespół jest połączony z większym, złożonym z analityków (razem jest nas wtedy dwanaścioro). A dwunastoosobowa drużyna z kolei podlega pod większą jednostkę związaną z analizą biznesową. Stąd też wynika (takie mam wrażenie) podwyższony stopień świadomości w zakresie komunikacji technicznej u naszych analityków, a ja rzeczywiście mam możliwości rozwoju w obranym kierunku.
W projekcie u klienta jestem członkiem zespołu dostarczającego rozwiązanie PaaS (Platform as a Service) w ramach usług Salesforce. Pracujemy dla klienta farmaceutycznego, stąd też mam z tyłu głowy fakt, że działamy w ramach branży mocno regulowanej. Organizacja ma zasięg globalny, częściowy podział geograficzny (LATAM, APAC i inne).
4. W jaki sposób jest zorganizowana praca Twoja i Twojego zespołu?
W gronie tech writerskim spotykamy się raz w tygodniu, by wymienić się różnymi odkryciami, wyzwaniami na projektach, zrobić sobie nawzajem review czy w inny sposób wesprzeć merytorycznie. W razie potrzeby jesteśmy też ze sobą w kontakcie na chacie. My ślę, że mam dużo szczęścia w tym względzie. Tech writerzy bywają jednoosobowymi zespołami. Wtedy nie masz kogo poprosić, żeby spojrzał na twój tekst, nie masz też nikogo, kto rozumie, że jest różnica między “real time” i “real-time”. W takim trybie pracy jest zdecydowanie trudniej.
Natomiast w projekcie spotkania dla całego zespołu mamy trzy razy w tygodniu - dwie poranne piętnastominutówki i czterdzieści pięć minut podsumowania tygodnia w piątek. Jako tech writer nie muszę się pojawiać na nich za każdym razem, ale gdy mam sprawę albo chcę kogoś “złapać” – to jest właśnie ten czas. Mam sporo przestrzeni na własną pracę konceptualną, pisanie i, jak to wcześniej określiłam, prowadzenie śledztwa.
5. Jakie doświadczenia zebrałeś/aś jako technical writer? W jakich projektach brałeś/aś udział?
W tym roku po raz pierwszy uczestniczyłam w konferencji Soap!. Co prawda online, a nic nie zastąpi spotkania na żywo (w trybie online nie miałam szans na złapanie poduszki, która powędrowała w stronę publiczności podczas ostatniego wystąpienia, a bardzo chciałam ją złapać), ale poszerzył mi się zdecydowanie horyzont postrzegania tego, co może robić tech writer. Na tego typu spotkaniach lubię też bardzo obserwować w jaki sposób są prezentowane treści, zwłaszcza w warstwie storytellingu. Soap! był więc dla mnie znakomitym obiektem obserwacji.
Mam też za sobą zdany certyfikat ITCQF. Nie tyle ważny jest jednak sam certyfikat, ile zawartość sylabusa, którą przyswoiłam. Pozwoliło mi to na wstępne uporządkowanie wiedzy o komunikacji technicznej, a także dało podstawę do zadawania celnych pytań. Gdy nie znam czegoś z własnego doświadczenia, mam jednak świadomość istnienia danego obszaru oraz dobrych praktyk z nim związanych. Mogę tę wiedzę porównać z rzeczywistością i relacjami moich rozmówców.
Wymieniłabym tu również wiedzę związaną z analizą danych, a w szczególności ich wizualizacją. Wizualizacja danych to także element komunikacji technicznej, więc jako tech writer taką wiedzą nie gardzę, ale póki co raczkuję w temacie, bo bardziej skupiam się na nadrobieniu wiedzy związanej ze statystyką. Jako filologa niestety mnie to ominęło, ale lepiej późno niż później albo wcale.
O projektach nie opowiem zbyt dużo, ponieważ niedawno zaczął się pierwszy z nich, ale dostrzegam ogólne podobieństwa względem pracy w korporacji. Nie mam tu na myśli wyścigu szczurów ani tych wszystkich paskudnych sytuacji, o których powstają memy. Chodzi mi raczej o współpracę z wielofunkcyjnymi zespołami i sekwencję działań. Osobie, która ma za sobą doświadczenie pracy w dużej organizacji o rozbudowanej strukturze na pewno będzie łatwiej się w tym odnaleźć. Jest to doświadczenie zdecydowanie uniwersalne. Poza tym nie czuję się “korporacyjnie” w żadnym z moich zespołów, widzę, że przykładana jest waga do kultury pracy i za to chylę czoła przed głównodowodzącymi.
6. Jakich narzędzi używasz i co o nich sądzisz?
W ramach projektu obecnie używam platformy do zarządzania ryzykiem związanym z informacją. Zgromadzona tam dokumentacja wspiera identyfikację zagrożeń dotyczących danych i systemu, aby zapewnić bezpieczeństwo, prywatność i zgodność danych od samego początku rozwoju danego procesu oraz kontrolować koszty utrzymania z tym związane (aż się prosi, żeby wspomnieć, że sylabus ITCQF obejmuje ten aspekt!). Jako użytkownik czuję, że platforma jest mi przyjazna, ale wiem, że nie wszyscy mają takie wrażenia. Udostępniałam jakiś czas temu ekran deweloperowi z mojego zespołu, przyznał szczerze, że cieszy się nie musi robić tego, co robię ja. Są gusta i guściki.
Moim przyjacielem jest też pakiet Microsoft Office. I Confluence. I Snagit. Jeszcze nie trafiłam na ścianę używając któregokolwiek z nich.
7. W jaki sposób zdobywasz informacje potrzebne do tworzenia dokumentacji?
Poprzez analizę innych dokumentów i załączników. Luki łatam przez spotkania z dedykowanymi specjalistami od danych rozwiązań. Gdy nie jestem pewna, czy dobrze rozumiem dane pojęcie lub proces (a jest złożony), podpytuję o słowa-klucze mojego męża dewelopera. Mogę z nim skonstruować sobie metaforę typu: czy między tymi dwoma systemami lata coś w rodzaju lampek choinkowych, które nie są zapalone (pusta struktura bez danych), czy te lampki są zapalone (czyli jakieś dane w strukturze są), a jeśli są zapalone, to czy zmieniają kolory (jakaś transformacja danych się tu dzieje)? Takie metafory są też moim zasobem, gdy rozmawiam z innymi i chcę w obrazowy, prosty sposób przekazać (osobom technicznym i nietechnicznym) co się dzieje w danym systemie. Umiejętność storytellingu to kompetencja zarówno tech writera, jak i analityka, więc cieszę się tym wspólnym polem i dobrze się na nim bawię.
8. Jakie typy dokumentów tworzysz?
SRA (System Risk Assessment), wiem, że mogą mi się zdarzyć też DCR (Data Classification Report). Wcześniej instrukcje użytkownika i jedno API documentation.
9. W jakich językach piszesz dokumentację i jak jest ona publikowana?
Angielski, do użytku wewnątrz organizacji. Tłumaczenia dla działu marketingu trafiały na bloga firmy.
10. Jakie produkty opisujesz?
Obecnie na ukończeniu mam Publication Database, następne będzie narzędzie do maskowania danych.
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?
Na ten moment skupiam się na projekcie, ale w razie “wolniejszych przebiegów” nadal służę pomocą przy review dokumentów koleżanek (i z wzajemnością). Co dwie, trzy lub cztery pary oczu - to nie jedna.
12. Jakie są największe wyzwania, które napotykasz w swojej pracy?
Przed odkryciem zawodu tech writera byłam przekonana, że na końcu łańcuszka produkcyjnego stoją testerzy. Zmieniłam zdanie; pomijając end usera, na końcu łańcuszka jesteśmy my - tech writerzy. Czekanie na czyjąś odpowiedź czy spotkanie ze specjalistą bywa irytujące. Taki problem to chyba jednak nie problem.
13. Co najbardziej lubisz w swojej pracy?
Po pierwsze - dzielenie się wiedzą i swobodny dostęp do informacji. Mam wrażenie (zbudowane na rozmowach z różnymi ludźmi zanim weszłam do branży IT), że deweloperzy i inne osoby techniczne bardziej “zazdrośnie” strzegą swojej wiedzy, przez co trudniej o rozwój, trzeba więcej szukać samemu i niejako “wyszarpać” tę wiedzę. W środowisku tech writerskim nie widzę tego agresywnego rysu rywalizacyjnego. Być może jest to związane z tym, że nasz zawód nie jest tak szeroko znany jak inne profesje, nie ma więc przysłowiowych “500 CV na jedno stanowisko juniorskie” jak to bywa ze stanowiskami programistycznymi. Nie musimy się bić i drapać.
Druga rzecz - zgodność z moim rysem osobowościowym. Po prostu lubię szperać i zbierać dane, a potem je porządkować. Tym obecnie się zajmuję. Moją drugą naturą jest też bycie nauczycielem, czyli kimś, kto lubi dzielić się wiedzą i tłumaczy w sposób zrozumiały. Na stanowisku tech writera moja nauczycielska dusza jest zdecydowanie ożywiona.
Po trzecie - balans między pracą z ludźmi a pracą własną. Gdy masz za dużo spotkań, nie ma czasu na pracę własną i łatwo zwyczajnie zmęczyć się ludźmi. Gdy z kolei kontaktu z ludźmi brak, łatwo o “zapiwniczenie się” przed komputerem i popadnięcie w społeczną samotność. Jako tech writer mam równowagę w tym zakresie.
14. Co możesz poradzić osobom, które chciałyby zacząć swoją przygodę z pisaniem dokumentacji?
Learn English! Powtarzam to wszystkim, którzy rozważają wejście do branży IT. Fora internetowe i grupy na FB pełne są zapytań typu “jakiego języka uczyć się najpierw?” (w domyśle - języka programowania). Moja odpowiedź wtedy brzmi - angielskiego, bo to jest pierwszy język IT.
Druga rzecz - jeśli boisz się ogólnie branży IT (“bo jestem po studiach humanistycznych”, “bo jestem nietechniczny”), spróbuj osłuchać się ze słownictwem branżowym. Zmywając naczynia, słuchaj podcastów i materiałów z YT. Różnych - o programowaniu, o testach, o analizie biznesowo-systemowej, o Agile/Scrumie. To trochę jak z nauką języka obcego - im więcej słówek rozpoznajesz i rozumiesz, tym pewniej czujesz się z tym co słyszysz i czytasz. Tu jest podobnie. Może ten sposób nauki nie uczynił mnie programistą, ale rozpoznaję po słowach-kluczach rozmowę o back endzie w szumie w kawiarni. Branża jest uroczo memogenna, polecam więc też memy jako materiał edukacyjny. To znakomite połączenie przyjemnego z pożytecznym. Po czasie okazuje się, że język branżowy nie jest tak straszny, jak się na początku wydawał.
Po trzecie - nawet jeśli nie jesteś zainteresowany pisaniem dokumentacji, polecam się jednak profesją tech writera zainteresować; zwłaszcza, jeśli myślisz o przebranżowieniu. Nadal mnóstwo ludzi uważa, że “specjaliści w branży IT = programiści”. Jest w tym tyle racji, na ile racji jest w twierdzeniu, że wszystkie prostokąty to kwadraty. Stanowisko tech writera pozwala na przyjrzenie się od wewnątrz, ale jednak stojąc nieco z boku, jak wygląda praca poszczególnych specjalistów. Wtedy można bardziej świadomie podjąć decyzję o ukierunkowaniu swojego rozwoju w konkretną stronę. Bardzo przykre są historie ludzi, którzy zainwestowali mnóstwo czasu i pieniędzy w bootcampy i certyfikaty, by ostatecznie dojść do wniosku, że dana profesja nie jest dla nich. Tech writing pozwala na celniejsze “mierzenie ciosów” na rynku pracy i nie przeszkadza w rozwoju w innych kierunkach, czego jestem przykładem. Mało tego, uważam, że tech writing to znakomity punkt wyjściowy dla wszystkich, bo wszyscy musimy się komunikować, a im skuteczniej to robimy, tym lepiej dla całego zespołu, klienta i projektu. Rozwijanie kompetencji w zakresie komunikacji technicznej nie jest więc stratą czasu niezależnie od docelowego zawodu. Może się też okazać, że to tech writing okaże się tym obszarem, który kochamy najbardziej, bądź po czasowym “skoku w bok” chcemy do niego wrócić. I to też jest piękne!
Anno, bardzo dziękujemy za poświęcony czas.
Jeśli ktoś z Was miałby ochotę odpowiedzieć na nasze pytania, zapraszamy. Informacje kontaktowe znajdziecie tutaj.