Przed Wami kolejna odsłona cyklu Kilka pytań do... Tym razem na nasze pytania odpowiada Julia Dąbrowska, który niedawno dołączyła do grona towarzystwa ludzi piśmiennych technicznie 😉 Jak to się wszystko zaczęło i co może poradzić osobom stawiającym pierwsze kroki w tej roli? Zapraszamy poniżej.
1. Jak długo pracujesz jako technical writer?
W obecnej firmie, Hitachi Energy, pracuję od 4 lat a w tej konkretnej roli od ok. 4 miesięcy. Moja praca polega na tworzeniu dokumentacji zmian w oprogramowaniu w postaci przyjaznej dla użytkowników tego oprogramowania.
2. W jaki sposób zostałaś technical writerem?
Przez wiele lat pracowałam we wsparciu technicznym klienta i długo zastanawiałam się nad zmianą roli, ale tak, aby jednak pozostać w branży IT, a najlepiej w tej samej firmie. Rolą technical writera zainteresowała mnie koleżanka z poprzedniej firmy, która właśnie tym się zajmuje od wielu lat. Niedługo po rozmowie z nią zapisałam się na szkolenie z normy Simplified Technical English (ASD STE-100). Wzięłam w nim udział z ciekawości, a w trakcie szkolenia poznałam obecnego szefa zespołu technical writerów, w którym pracuję. Opowiedział mi trochę o swojej pracy, a kiedy ja wyraziłam chęć „przebranżowienia się” do tej roli, pozostaliśmy w kontakcie i niecały rok później nadarzyła się okazja dołączenia do zespołu. Na tym etapie już się nie zastanawiałam, tylko aplikowałam na to stanowisko i udało się.
3. Czy możesz opowiedzieć coś o swojej firmie i zespole, w którym pracujesz?
Dział, w którym pracuję, zajmuje się produkcją oprogramowania dla Hitachi Energy, która to firma jest jednym z liderów sektora energetycznego. Zespół technical writerów w Krakowie obsługuje obecnie kilka różnych produktów z oferty oprogramowania dla dużych przedsiębiorstw. Jest nas razem cztery osoby i dopiero się poznajemy, ale współpraca układa się bardzo dobrze. To samo mogę powiedzieć o zespołach tworzących produkt. Jest dużo życzliwości, chęci pomocy i dzielenia się wiedzą. Ludzie tutaj lubią ze sobą pracować i traktują się nawzajem z szacunkiem.
4. W jaki sposób jest zorganizowana praca Twoja i Twojego zespołu?
Produkt, do którego tworzę dokumentację, ma swój rytm wydawniczy wyznaczany tzw. sprintami o długości dwóch tygodni, i to on decyduje o czasie i kolejności moich prac. Podobnie jest w innych produktach, choć są one na różnych etapach rozwoju. W zespole writerów spotykamy się formalnie co dwa tygodnie na planowaniu prac, a nieformalnie konsultujemy przy różnych okazjach. Wszyscy oprócz mnie pracują w trybie zdalnym, więc komunikacja odbywa się głównie przez komunikator firmowy. Staramy się jednak regularnie integrować poza pracą.
5. Jakie doświadczenia zebrałaś jako technical writer? W jakich projektach brałaś udział?
Obecnie uczę się tej roli jako tzw. „junior”, a więc wdrażam się w produkt, który opisuję, i w cykl tworzenia oprogramowania w sposób „zwinny”. W praktyce tworzę lub modyfikuję dokumenty w dwutygodniowych cyklach dopasowanych do cykli wydawania oprogramowania przez zespół programistów. Dopasowuję się do ich terminów tak aby nie powodować przestojów. Uczę się też narzędzi pomocnych przy pracy tech writera.
6. Jaką masz super moc?
Umiem się dogadywać z ludźmi 😊 co w mojej roli ma ogromne znaczenie, bo dokumentacji nie tworzy się samemu. Zawsze jest potrzebna czyjaś pomoc, czy to na etapie zbierania informacji, czy feedbacku dotyczącego mojej pracy.
7. Jakich narzędzi używasz i co o nich sądzisz?
Do pisania dokumentów używam MS Worda i MadCap Flare. Do kontroli wersji i przesyłania zmian - aplikacji Git i git-extensions. Z kolei do tworzenia i edycji zrzutów ekranu z aplikacji używam programu Snagit. Muszę przyznać, że zanim poznałam Flare, Word wydawał mi się bardzo zaawansowanym narzędziem do edycji tekstu. Dalej go doceniam, jednak Flare otwiera zupełnie inne możliwości, zwłaszcza przy zmianach drobnych i powtarzalnych (np. numer wersji, korekta linków, itp.) ale też przy wykorzystywaniu części już utworzonego tekstu do tworzenia na jego podstawie nowych dokumentów. Dopiero poznaję jego pełny zakres możliwości, w tym różne mechanizmy analizy pomocne w wykrywaniu błędów, czy świadomym projektowaniu treści. Jeśli chodzi o Snagita, to od początku pozytywnie mnie zaskoczył intuicyjną obsługą, a możliwości, które daje, nie spotkałam dotąd w żadnym innym edytorze zrzutów ekranu.
8. W jaki sposób zdobywasz informacje potrzebne do tworzenia dokumentacji?
Moim podstawowym źródłem informacji są tzw. historyjki pisane przez Product Ownerów i programistów, przechowywane w narzędziu Jira. Biorę też udział w niektórych spotkaniach zespołów tworzących produkt, a także konsultuję szczegóły z autorami poszczególnych zmian. Dodatkowo, zarówno warstwę językową jak i merytoryczną konsultuję z szefem zespołu, który ma kilkuletnie doświadczenie w opisywaniu tego produktu, i ponad 10-letnie w roli technical writera. Jest on moim głównym recenzentem, ale też mentorem w nowym zawodzie.
9. Jakie typy dokumentów tworzysz?
Są to głównie noty wydawnicze (release notes) i aktualizacje podręcznika użytkownika, a w mniejszym zakresie podręczniki instalacji, aktualizacji, dokumenty referencyjne czy specyfikacje konkretnych funkcjonalności.
10. Czym się interesujesz oprócz dokumentacji i technologii?
Psychologią, medycyną, socjologią, urbanistyką i wszystkim co ma dziś wpływ na człowieka i na jakość jego życia. Dla relaksu gram w planszówki i czytam kryminały.
11. W jakich językach piszesz dokumentację i jak jest ona publikowana?
Piszę wyłącznie w języku angielskim. Dokumentacja jest dostępna dla klientów poprzez aplikację, z której korzystają, a także poprzez zewnętrzne repozytorium.
12. Jakie produkty opisujesz?
Obecnie jest to jeden produkt, który służy do zarządzania stanem technicznym elementów stacji transformatorowych, a także przewidywania ryzyka ich zużycia i/lub awarii.
13. Czy kiedy kupisz nowy sprzęt AGD to idziesz na żywioł i spontanicznie zaczynasz użytkowanie, czy też rozpoczynasz od przeczytania całej instrukcji?
Zawsze najpierw zaglądam do instrukcji, ale nie czytam całej tylko koncentruję się na sposobie uruchomienia urządzenia i szybko przeglądam komunikaty typu „Uwaga”.
14. 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?
Obecnie uczę się pisać dokumentację i to pochłania całą moją uwagę.
15. Jak zachować spokój ducha i szeroki uśmiech? Powiedz, jak być szczęśliwą tech writerką?
Nauczyć się wcześnie prosić o pomoc i zawsze mieć na uwadze, że jest to praca zespołowa i zależymy od pracy wielu innych ludzi. To tyle ode mnie na ten moment, bo wciąż mam wiele do opanowania (w tym opanowanie 😉)
16. Jakie są największe wyzwania, które napotykasz w swojej pracy?
Moje główne wyzwanie to obecnie poziom skomplikowania produktu, który opisuję, a także przestawienie się z wyuczonego sposobu pisania (głównie komunikacja z klientem, a wcześniej język literacki, akademicki i potoczny) na ten techniczny, związany z obsługą programowania. Pisanie w sposób jasny, czytelny, pomocny, niebudzący wątpliwości przeciętnego użytkownika jest zaskakująco trudne 😊
17. Co najbardziej lubisz w swojej pracy?
Pracę z językiem angielskim, który uwielbiam od dziecka, a także współpracę z ludźmi „technicznymi”. Lubię też to poczucie, że moja praca przynosi konkretne, namacalne owoce.
18. Co możesz poradzić osobom, które chciałyby zacząć swoją przygodę z pisaniem dokumentacji?
Na moim przykładzie: jeśli czujecie się swobodnie ze znajomością języka angielskiego i chcecie spróbować w tej roli, to najłatwiej jest na początek dostać się do firmy z sektora IT/software development na stanowisko w dziale wsparcia technicznego klienta. Po zapoznaniu się z produktem i cyklem życia oprogramowania, warto rozejrzeć się wewnątrz firmy za stażami czy stanowiskami typu junior technical writer.
Julio, bardzo dziękujemy za czas, jaki poświęciłaś na ten wywiad.
Jeśli wśród czytelników znajdzie się ktoś chętny do podzielenia się swoimi doświadczeniami w pracy technical writera niech pisze na nasz adres: kontakt@techwriter.pl