Kilka pytań do — część 19

Serwujemy kolejny wywiad w ramach cyklu „Kilka pytań do…”. Tym razem rozmawiamy z Michałem Hylińskim, który pełni funkcję Information Architecta w krakowskim oddziale Motorola Solutions Systems Polska.

Jak długo pracujesz jako Information Architect i na czym właściwie polega Twoja rola?

W październiku miną trzy lata. Information Architect [dalej IA — przyp. red.] w Motoroli to osoba, która wspiera project managera skupiając się nie na priorytetach i ludziach, ale na pakiecie dokumentów należących do danego portfolio. Są trzy główne zadania IA — orientować się w tym, co znajduje się w naszych podręcznikach, rozumieć na czym polegają wszystkie nowości, które mamy za zadanie opisać i w końcu łączyć te dwa filary w taki sposób, żeby ułatwić pracę technical writerom pracującym w moim zespole. Do tego dochodzi jeszcze całe multum pomocy wszystkim, których praca w jakiś sposób może skorzystać na tych czynnikach i drugie tyle pracy, nazwijmy to, biurokratycznej.

W jaki sposób zostałeś Information Architectem?

Kiedy zacząłem pracować jako technical writer, bardzo szybko zacząłem interesować się tym, jak lepiej wykorzystać moje umiejętności. Samo pisanie i, nazwijmy to, dbałość o szczegóły, nigdy nie były moją najmocniejszą stroną, za to dobrze radzę sobie w czytaniu ze zrozumieniem i przekazywaniu skomplikowanych informacji w uproszczony sposób. Dlatego gdy tylko była taka możliwość, zostałem scrum masterem, a potem IA. Wiem, że samo stanowisko nie jest w korporacjach zbyt powszechne, ale przypuszczam, że wszędzie występują role zawierające podobne elementy — często jako dodatkowe obowiązki team leadera czy po prostu senior technical writera.

Tak jak to było u mnie, żeby zostać IA, najważniejsze są dwa warunki — obycie w pokrewnych technologiach oraz umiejętność przekazania tego innym w taki sposób, żeby ułatwiać pracę, a nie dodatkowo ją komplikować.

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

Pracuję w Motorola Solutions. Firma zajmuje się tworzeniem systemów komunikacji radiowej używanych głównie przez służby publiczne i firmy. Dla przeciętnego Kowalskiego — takie bardziej zaawansowane walkie-talkie, połączone z siecią serwerów i stacji bazowych, które pracują na to, żeby komunikacja odbywała się nieprzerwanie i niezawodnie.  Zespół zajmuje się infrastrukturą dla systemów DIMETRA, czyli tych certyfikowanych na terenie Unii Europejskiej.

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

Moimi ulubionymi narzędziami jest zeszyt i długopis, a oprócz tego wspomagam się pakietem biurowym Google i Acrobatem, w którym można wygodnie analizować i komentować PDF-y. Koniecznością jest również praca z Jirą i Confluencem, oraz oprogramowaniem własnym Motoroli. Ciągle szukam sposobu, żeby skutecznie i bezboleśnie połączyć to wszystko. Jeśli zachodzi potrzeba, żebym zobaczył coś w kodzie naszej dokumentacji, to wtedy do akcji wkracza easyDITA i Oxygen XML Authoring.

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

Każdy [doświadczony techwriter — przyp. red.] wie, że w tej pracy najważniejsza jest bezpośrednia współpraca z SME. Kiedy tylko się da, najlepiej zdobywać informacje bezpośrednio od źródła i budować relację. Oprócz tego są dokumenty businessowe i designowe, specyfikacje, opisy zadań i inicjatyw w Jirze i wszystko, co jestem w stanie znaleźć w naszych zasobach.

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

Główna część mojej pracy kończy się tam, gdzie zaczyna się praca technical writera. Rzeczy, które dostarczam to opisy zadań w Jirze, zestawienia dotyczące ogółu pracy w danej iteracji, plany miesięczne i kwartalne, opisy wymaganych zmian na brudno, namiary na odpowiednich ekspertów i ogólne informacje czy wytyczne dotyczące danej funkcji dokumentu. Kiedy te rzeczy są gotowe, pałeczkę przejmuje tech writer, a ja… zaczynam przygotowywać się do kolejnego rzutu, a w międzyczasie służę writerom jako pomocnik i konsultant. Na sam koniec stawiam jeszcze kropkę nad i, upewniając się, że dokumenty, które publikujemy są ok. Sam posługuję się mieszkanką angielskiego i polskiego, a finalny efekt pracy naszego zespołu jest zawsze po angielsku, publikowany jako podręczniki wewnątrz aplikacji, PDF-y na naszym portalu, a wreszcie, w zależności od klienta, tłumaczone lub drukowane dokumenty.

Jakie produkty opisujesz?

Tak jak wspominałem, zajmujemy się infrastrukturą sieci, więc głównie fizycznymi lub wirtualnymi serwerami, konsolami dyspozytorskimi, stacjami bazowymi i różnymi urządzeniami sieciowymi. Systemy, które stawia Motorola można porównać do alternatywnej sieci komórkowej, która pokrywa całe kraje, dając pewność służbom takim jak policja, wojsko czy straż pożarna, że będą mogły komunikować się ze sobą nawet jeśli konwencjonalna sieć komórkowa czy internetowa zostanie uszkodzona lub wyłączona z powodu przeciążenia, kataklizmu czy po prostu nieprzewidzianego wypadku.

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

Często nie wiadomo w co włożyć ręce i zawsze pojawia się ryzyko, że coś na mnie utknie. Oprócz tego nie każdemu będzie odpowiadał fakt, że trzeba oddać nieskończoną pracę writerowi i pogodzić z tym, że IA nie ma bezpośredniego wpływu na efekt końcowy pracy, którą sam zaczął. Czasami nawet nie widzę jak wygląda efekt końcowy naszej pracy. A czasami widzę, i wiem, że gdybym to ja pisał, dokonałbym innych wyborów, niekoniecznie lepszych.

Co najbardziej lubisz zatem w pracy Information Architecta?

Najbardziej podoba mi się to, że pomagam swoją pracą innym pracownikom, co jest bardzo satysfakcjonujące. Poza tym, te najfajniejsze elementy mojej pracy to taki technical writing w pigułce, a w zasadzie to, co w nim najfajniejsze — ale gdy ja kończę pracę i przekazuję moje materiały kolejnej osobie, niekoniecznie muszę przejmować się zasadami konkretnego styleguide’a. Pod tym kątem treści szlifuje już technical writer.

Co możesz poradzić osobom, które chciałyby zacząć swoją przygodę z pisaniem dokumentacji?

Najważniejsze umiejętności to tak zwane czytanie ze zrozumieniem, komunikacja, rozwiązywanie problemów i pisany angielski. Jeśli masz wątpliwości, czy się nadajesz, spróbuj przeczytać jakiś skomplikowany wpis na Wikipedii, a potem przekazać komuś najważniejsze fakty. Jeśli czujesz, że robisz to nieźle i dostaniesz odpowiedni feedback, raczej będzie ok. Idź na staż albo zgłoś się do rekrutacji na stanowisko entry level. Pokaż entuzjazm i te cztery umiejętności. I już masz pierwszy krok za sobą! 😊

Serdecznie dziękujemy Michałowi Hylińskiemu za to obszerne wprowadzenie w specyfikę jego zawodu. A chętnych po więcej wrażeń zza biurka techwriterskiego, zapraszamy do lektury pozostałych materiałów powstałych pod szyldem jak to robią inni.