W pracy każdego Technical Writera przychodzi co jakiś czas moment wytchnienia. Możemy złapać spokojnie oddech i zwolnić tempo. Pojawia się trochę wolnego czasu. Jedni chcą wtedy po prostu cieszyć się chwilą, ale inni wolą ten czas spożytkować na naukę obsługi nowych narzędzi do tworzenia dokumentacji Help Authoring Tools.
Pierwszym, najbardziej oczywistym pytaniem, które nam się nasuwa to: "Które narzędzie warto poznać?". Jednak, według nas, drugim pytaniem jakie powinniśmy zadać jest: "Czy w ogóle warto inwestować swój czas w poznawanie narzędzi do tworzenia dokumentacji?". Odpowiedź nie jest prosta, tym bardziej, że różni się ona w zależności od celu jaki nam przyświeca. Pomimo tych przeszkód postaramy się do jakiegoś stopnia na nie odpowiedzieć przedstawiając swój punkt widzenia.
Założenie
Zacznijmy od stworzenia kontekstu. Przyjmijmy stanowisko, że pracujemy już jako Technical Writer i że chcemy nauczyć się jakiegoś narzędzia do tworzenia dokumentacji po to, aby zwiększyć swoje szanse na znalezienie pracy jako Technical Writer w innej firmie na lepszych warunkach.
Od czego zacząć?
Jak wiemy narzędzi do tworzenia dokumentacji jest całkiem sporo. Dlatego, żeby cały nasz wysiłek nie poszedł na marne, najrozsądniej byłoby zacząć od przeanalizowania ofert pracy w celu rozpoznania, czego najczęściej wymagają pracodawcy w kwestii znajomości oprogramowania. Tak też zrobiliśmy. Co prawda liczba ofert pracy dla Technical Writerów w Polsce nie powala, ale powinno to nam dać jakiś obraz sytuacji. Przejrzeliśmy 12 ofert pracy z ostatniego kwartału. To czego dowiedzieliśmy się jest dość zaskakujące. Trzy oferty nie zawierały żadnych wymagań dotyczących narzędzi do tworzenia dokumentacji. W sześciu ogłoszeniach w wymaganiach pojawił się Microsoft Office. Niektóre z nich mówiły ogólnie o całym pakiecie, w innych na przykład kładziono nacisk na zaawansowaną znajomość Worda. W dwóch ogłoszeniach pojawił się Sharepoint. W trzech ogłoszeniach wymagana była znajomość Wiki. Tylko w jednym ogłoszeniu wspomniano o narzędziu do tworzenia dokumentacji, podając jako przykład Adobe RoboHelp , MadCap Flare lub JustSystems XMetaL. Co ciekawe nie była to wymagana wiedza, a jedynie mile widziana.
Nie ukrywamy naszego zdziwienia takim stanem rzeczy, ponieważ śledząc zagraniczne blogi dotyczące komunikacji technicznej, dowiadujemy się, że mało kto, o ile ktokolwiek, uważa Worda za dobre narzędzie do tworzenia dokumentacji. Jest on raczej traktowany jako ewentualna opcja do tworzenia małej ilości, prostych dokumentów i to głównie dlatego, że w każdej firmie Word po prostu jest 😊 Jednak kiedy dokumentacja jest obszerna, wymaga kilku formatów i możliwości ponownego wykorzystania treści, wtedy nie jest to najlepszy wybór. Publisher i PowerPoint mogą być pomocne przy tworzeniu treningów, prezentacji czy krótkich przewodników, ale nie są to kompletne narzędzia do tworzenia dokumentacji.
Wniosek?
Nasuwa się sam. Wygląda na to, że znajomość obsługi narzędzi do tworzenia dokumentacji nie jest kluczową umiejętnością Technical Writera, dlatego inwestowanie czasu w naukę takich narzędzi może nie być opłacalne. Tym bardziej, że proces uczenia się takiego oprogramowania jest z natury obarczony pewnymi trudnościami. Po pierwsze nie oszukujmy się, od klikania po programie, czytania instrukcji i oglądania filmików instruktażowych nie poznamy programu dogłębnie. Jak wiadomo "praktyka czyni mistrza", dlatego najlepiej poznawać program przygotowując w nim realny projekt. Dopiero wtedy widzimy jego prawdziwe możliwości. Zaczynają się schody i kombinowanie jak ustawić taki czy inny parametr. Taki sposób uczenia się jest czasochłonny, więc czy naprawdę chcemy poświęcić czas na naukę narzędzia, którego możemy nigdy nie użyć w swojej pracy? Oczywiście jeśli wiemy z góry, do jakiej firmy chcemy aplikować, wtedy opanowanie narzędzia używanego u przyszłego pracodawcy, nawet w stopniu podstawowym, zwiększa nasze szanse na podjęcie współpracy, ale jeśli nie mamy tak sprecyzowanego celu, nasz wysiłek może być po prostu daremny. Dodatkowo nie od wczoraj wiadomo, że "organ nieużywany zanika". Jeśli po opanowaniu obsługi narzędzia nie zaczniemy go regularnie używać, to możemy być pewni, że bardzo szybko zapomnimy jak to robić. No dobrze, w takim razie przyjmijmy, że wiemy, w której firmie chcemy pracować i jakiego narzędzia ona używa oraz że w najbliższej przyszłości chcemy tam aplikować. W takiej sytuacji, w świetle powyższego wywodu, warto zainwestować swój czas i energię w solidne opanowanie narzędzia. Otóż nie do końca. Pozostaje jeszcze kwestia różnić pomiędzy poszczególnymi wersjami oprogramowania. Zdarza się, że zmiana głównej wersji oprogramowania, pociąga za sobą drastyczne zmiany w funkcjonalności programu. Dlatego też, dopiero jeśli wiemy konkretnie jaka wersja jest używana, wtedy cały proces uczenia się zaczyna mieć sens. Oczywiście pod warunkiem, że producent danego narzędzia udostępnia w pełni funkcjonalną wersję próbną, tak jak np. Help and Manual. Narzędzia do tworzenia dokumentacji są zazwyczaj dość kosztowne, dlatego nie podejrzewamy, że ktokolwiek wyciągnie z kieszeni, ot tak, 3000 lub 5000 zł po to tylko, żeby sobie poklikać dla sportu. Ale nie bądźmy już tacy czepialscy, zdobycie wersji demo raczej nie powinno być problemem. Co najwyżej będzie troszkę okrojona w stosunku do licencjonowanej kopii.
W takim razie lepiej nic nie robić?
Oczywiście, że nie. Ale może lepiej skupić się na czymś bardziej uniwersalnym niż narzędzia typowo przeznaczone do tworzenia dokumentacji? Może lepiej jest nauczyć się podstaw programowania w Pythonie lub Javie albo nauczyć się obsługi programu graficznego? Szczególnie znajomość programu graficznego może nam się przydać zarówno do tworzenia dokumentacji (ulepszenie szablonu, poprawa jakości diagramów lub zrzutów ekranu) jak i do innych celów. Z doświadczenia wiemy, że Technical Writer czasami zajmuje się również tworzeniem różnego rodzaju materiałów promocyjnych, jak ulotki, kalendarze czy banery. Dlatego też umiejętność obsługi programu graficznego na pewno zaprocentuje. A jeśli dodatkowo jest to darmowe i wieloplatformowe narzędzie, takie jak np. GIMP czy Inkscape, wtedy mamy jeszcze jedno ułatwienie - nie musimy przekonywać przełożonego, żeby wyłożył pieniądze na zakup licencji. Dlatego jeśli nauczymy się raz obsługi takiego programu, to możemy z niego korzystać w różnych sytuacjach, czy to w obecnej, czy w nowej firmie. Nawet jeśli ktoś nie korzysta akurat z tego narzędzia, nie oznacza, że my nie możemy, skoro to nikogo nic nie kosztuje. Na pewno jest to wiedza bardziej uniwersalna, która ma większe szanse na zastosowanie niż znajomość konkretnego HATa.
Ale ja jednak chcę się nauczyć jakiegoś narzędzia do dokumentacji...
Jeśli już koniecznie chcemy poznać takie narzędzie, może lepiej przyjąć trochę inną strategię. Zamiast starać się poznać dobrze jeden program, lepszym rozwiązaniem może okazać się zdobycie przekrojowej wiedzy na temat dostępnego oprogramowania do tworzenia dokumentacji. Znajomość nazw, producentów, możliwości poszczególnych narzędzi oraz orientacyjnej ceny licencji pozwoli nam na podjęcie tematu w trakcie ewentualnej rekrutacji, jeśli padną pytania o znajomość tego typu oprogramowania. Ponadto, jeśli trafimy do firmy, która jest dopiero na początku budowania swojej dokumentacji, istnieje duża szansa, że naszym zadaniem będzie wybranie najbardziej optymalnego narzędzia, które spełni jej potrzeby. Taka wiedza przekrojowa będzie w takim momencie nieoceniona. Inną opcją jest nadrobienie braków z Worda, bo jak widać takie umiejętności są ciągle w cenie. I nie dajcie się oszukać. Pomimo tego, że wiele osób twierdzi, że zna ten program, tak naprawdę nieliczni znają go naprawdę dobrze.
Nasze argumenty nie mają na celu zniechęcenia nikogo do poznawania narzędzi do dokumentacji. Chcemy tylko zasygnalizować, że taka wiedza jest mile widziana, ale niekoniecznie krytyczna jeśli chodzi o pracę Technical Writera, bo Dokumentalista musi umieć przede wszystkim pisać dobrze, a czy będzie to rycie instrukcji dłutem w kamieniu czy klepanie w RoboHelpie to jest już kwestia drugorzędna 😉 Dlatego zachowajmy zdrowy rozsądek i nie dajmy się zwariować.