Kilka pytań do - część 4

W dzisiejszym odcinku pod gradobiciem pytań znalazła się Agnieszka, która od dłuższego czasu zajmuje się tworzeniem dokumentacji w międzynarodowej korporacji. W wolnym czasie czyta techwriter.pl i dba o to, żebyśmy się nie nudzili. Zapraszamy do lektury.

Jak długo pracujesz jako Tech Writer?

W marcu mijają 3 lata.

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

Tech writerem zostałam trochę z przypadku. Na piątym roku studiów zaczęłam rozglądać się za jakimś stałym zajęciem. Szukałam stanowiska, na którym mogłabym wykorzystać znajomość języka angielskiego. Przeglądałam oferty praktyk i staży, chodziłam na rozmowy kwalifikacyjne. W końcu trafiłam na ofertę praktyk jako Technical Writer w IBM. Wcześniej nie brałam pod uwagę takiej ścieżki zawodowej. W ogóle nie wiedziałam, że istnieje coś takiego jak technical writing! Na uczelni mówiono tylko o standardach typu tłumacz, nauczyciel, ewentualnie księgowy.

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

IBM to korporacja o ugruntowanej pozycji rynkowej. Nawet jeżeli ktoś nigdy nie miał okazji używać naszego oprogramowania ani nie słyszał o Watsonie, na pewno styka się z innymi naszymi produktami, jak chociażby kasy fiskalne, w życiu codziennym. Jak w wielu przypadkach, nasz zespół jest międzynarodowy, ale spora jego część znajduje się w Krakowie. Mamy osoby o różnym wykształceniu, od fizyków, przez programistów (co oczywiste), po absolwentów filologii angielskiej. Przyczynia się to do różnorodności opinii, co moim zdaniem ma dobry wpływ zarówno na środowisko pracy jak i jakość naszych produktów.

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

Technical writerzy nie tworzą osobnego zespołu, tylko przynależą do poszczególnych zespołów produktowych. Dokumentację do naszego produktu piszą cztery osoby. Trzy znajdują sie w Krakowie, jedna w Wielkiej Brytanii. Każdy z nas jest odpowiedzialny za jakaś część, na przykład instalację, ale nie jest to sztywny podział. Wynika raczej z naturalnych zainteresowań niż z narzuconej biurokracji. Często śmieję się, że tworzymy „dream team”, bo każdemu udało się znaleźć coś dla siebie. Mimo że każdy z nas ma swoją domenę, staramy się być zorientowani w tym, co robią pozostałe osoby. W ten sposób, kiedy jedno z nas idzie na urlop lub zwolnienie, ktoś inny jest w stanie przejąć jego pracę bez większego problemu.

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

Do tej pory moim głównym narzędzniem był Arbortext Editor. Miałam też styczność z Oxygen XML Author i Adobe FrameMaker. Pewnie jest to kwestia przyzwyczajenia, ale Arbortext jest moim faworytem. Było to pierwsze narzędzie do tworzenia dokumentacji technicznej, jakie poznałam i pewnie dlatego wydaje mi się najbardziej intuicyjne i przyjazne dla użytkownika. Oxygen nie przypadł mi do gustu głównie ze względu na interfejs. Kiedy po raz pierwszy otworzyłam plik w Oxygenie, połowę okna zajmowały dodatkowe panele. Wiem, że można je dostosować do swoich potrzeb, ale pierwsze wrażenie skutecznie mnie zniechęciło. FrameMaker z kolei kompletnie nie jest dla mnie. Jestem przyzwyczajona do narzędzi do tworzenia dokumentacji on-line. Przyszło mi jednak pracować nad jedną publikacją, która miała formę książki. Przestawienie się z Arbortexta na FrameMakera było trudną sprawą. Odetchnęłam z ulga, kiedy projekt się skończył 😉

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

Założenie jest takie, że wszystkie potrzebne informacje znajdują się w systemie do zarządzania projektem. Scrum master przypisuje mi jakieś zadanie, czytam opis, loguję się do aplikacji i powinnam być w stanie udokumentować daną funkcjonalność lub procedurę. Rzeczywistość wygląda jednak nieco inaczej 😉. Jeżeli dokumentuję prostą funkcjonalność, którą łatwo wywnioskować z interfejsu, to po prostu loguję się do aplikacji, sama próbuję przejść daną procedurę, a potem ją opisuję. Taki dokument daję do przeczytania deweloperowi, który implementował funkcjonalność oraz testerowi. Oni dostaraczają komentarzy odnośnie szczegółów, których nie byłam w stanie sama się domyślić, na przykład, na temat ograniczeń danej funkcjonalności. Jeżeli do udokumentowania mam coś innego niż procedurę do wyklikania na interfejsie, na przykład parametry, których można użyć z komendą albo wymagania sprzętowe, zaczynam od przejrzenia opisu story implementującego daną funkcjonalność. Można tam zazwyczaj znaleźć sporo przydatnych informacji. Uzbrojona w podstawy, kartkę i długopis udaję się po szczegóły do właściwej osoby. Reszta pracy wygląda tak samo: piszę, wysyłam do sprawdzenia, dostaję komentarze i uzupełniam na ich podstawie dokumentację.

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

Nasz zespół dostarcza dokumentację w postaci pomocy on-line. Używamy standardu DITA (stworzonego zresztą przez IBM), dlatego nasza dokumentacja jest podzielona na trzy rodzaje tematów: zadania (ang. tasks), pojęcia (ang. concepts) i materiały zależne (ang. reference). Piszemy po angielsku, ale nasza dokumentacja jest później tłumaczona na inne języki.

Jakie produkty opisujesz?

Opisuję dwa produkty, które służą do zarządzania licencjami oprogramowania. Ogólnie chodzi o to, żeby klient mógł sprawdzić, jakie programy są zainstalowane na komputerach w jego firmie, ile ich jest oraz jak często są używane. Na podstawie tych informacji powinien być w stanie stwierdzić, czy spełnia wymogi licencyjne dla danego oprogramowania, czy musi coś uregulować.

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?

Poza pisaniem dokumentacji tworzę też infografiki oraz filmy instruktażowe. Do tych pierwszych używam CorelDraw, do tych drugich Camtasia Studio. Oprócz tego, wspólnie z kolegą z zespołu przygotowujemy wewnętrzne prezentacje nowych wersji produktu.

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

Wyzwań jest sporo. Po pierwsze, przeskok z poziomu przeciętnego użytkownika komputera do poziomu osoby, która tłumaczy użytkownikom, jak wykonać skomplikowaną procedurę na AIXie. Na początku pracy mocno odczuwałam braki w wiedzy technicznej, co często sprawiało, że czułam się jak przedszkolak, którego przez pomyłkę zapisano na studia doktoranckie. Musiałam też przełamać wewnętrzną blokadę przed zadawniem pytań, które wydawały mi się głupie lub oczywiste z punktu widzenia osób, z którymi rozmawiałam. Teraz się tym nie przejmuję, tylko drążę temat do skutku 😉 Innym problemem jest to, że dokumentacja ma niższy priorytet niż tworzenie aplikacji. Jest to oczywiście zrozumiałe, bo co komu po najlepszej dokumentacji świata, kiedy nie ma działającej aplikacji. Jednak każdy chce, żeby jego praca była traktowana poważnie. Nikt nie lubi, kiedy się go spycha na koniec kolejki. Na szczęście takie sytuacje są rzadkie i wynikają z realnego braku czasu i naglących terminów, a nie z niechęci lub lekceważenia pracy technical writerów.

Co najbardziej lubisz w pracy Tech Writera?

To, że każdy dzień jest inny. To, że oprócz pisania dokumentacji mogę rozwijać się także na innych płaszczyznach, jak choćby tworzenie infografik czy user experience, którym zainteresowałam się właśnie dzięki pracy technical writera. Przede wszystkim jednak cenię sobie to, że miałam okazję poznać zupełnie inny świat i świetnych ludzi, z którymi mogę pracować na co dzień.

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

Jeżeli ktoś obawia się, że nie zna się na programowaniu albo nie ma wykształcenia technicznego, to radziłabym się tym nie przejmować. Technical writer powinien bardzo dobrze znać angielski. Jeśli tylko ma trochę determinacji i ciekawości, to wszystkiego innego dowie się „po drodze” przy okazji pisania dokumentacji. Natomiast osobom, które już wiedzą, że to jest ich praca marzeń, radziłabym uzbroić się w cierpliwość i sporą dawkę asertywności. Początki mogą być trudne, bo na studiach technicznych nie mówi się o dokumentacji (ewentualnie o dokumentacji kodu, ale to zupełnie inna bajka). Można trafić do firmy, w której deweloperzy nie rozumieją, jaka jest rola technical writera. Nie należy się zniechęcać, kiedy współpraca na początku się nie układa. Trzeba zacisnąć zęby, pokazać wartość tego, co się robi i nie dać się odprawiać z kwitkiem. Potem jest już z górki 😉

Jeśli chcecie skontakować się z Agnieszką albo sami macie ochotę podzielić się swoimi doświadczeniami, nie zwlekajcie dłużej tylko piszcie na adres kontakt@techwriter.pl.