Kilka pytań do - część 10

Redukcja zatrudnienia nie zawsze jest czymś negatywnym. Czasami jest to szansa na zmianę kierunku swojej kariery zawodowej. Tak właśnie stało się w przypadku Piotra, który nauczanie języka angielskiego postanowił zamienić na tworzenie dokumentacji. Obecnie na swoim koncie ma już kilka lat doświadczenia w branży, dlatego postanowiliśmy go namówić, żeby opowiedział nam trochę o swojej przygodzie z komunikacją techniczną. Zapraszamy na kolejny odcinek z cyklu "Kilka pytań do..".

Jak długo pracujesz jako Tech Writer?

Prawie 5 lat.

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

Trochę w tym szczęścia, trochę przypadku. Pierwsze lata po studiach pracowałem jako nauczyciel języka angielskiego, jednak redukcja zatrudnienia w szkole zmusiła mnie do szukania innego zajęcia. Traf chciał, że w firmie gdzie pracował mój przyjaciel rozpoczęła się duża rekrutacja do zespołu dokumentacyjnego. Do końca nie zdawałem sobie sprawy o co w tej pracy chodzi, ale wydawało mi się to ciekawe. Wziąłem udział w rekrutacji, zostałem zatrudniony z innymi 8-10 osobami i tak zaczęła się moja przygoda z technical writingiem. Było to duże wyzwanie i zmiana w moim życiu, gdyż musiałem się także przeprowadzić do Krakowa.

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

Firma, pod której logiem obecnie pracuję obchodziła w tamtym roku 10. urodziny. Trzy lata temu zostaliśmy przejęci przez globalnego potentata zajmującego się tworzeniem oprogramowania do zarządzania procesami biznesowymi. Część osób pracuje w firmie od samego początku, co bardzo pozytywnie wpływa na budowanie dobrej atmosfery w pracy i miłych relacji. Zespół writerski tworzy obecnie 10 osób z czego 2 pracują od samego początku. Warto podkreślić że 6 osób znalazło zatrudnienie w ostatnim roku. W skrócie: rozrastamy się jak cała branża IT w Krakowie, i nie powiedzieliśmy jeszcze ostatniego słowa.

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

Jesteśmy podzieleni na kilkuosobowe zespoły, w których każdy z dokumentalistów opisuje element platformy do zarządzania procesami biznesowymi (główny produkt naszej firmy). Kilkumiesięczny okres kiedy tworzy się nowa wersja produktu i dokumentacja mamy podzielony na dwutygodniowe sprinty. W tym czasie, systematycznie opisujemy te funkcjonalności, które zostały już zaimplementowane. Nasza dokumentacja jest sprawdzana pod kątem poprawności technicznej i językowej, a ostatecznie musi zyskać aprobatę edytora i głównego menedżera odpowiedzialnego za całokształt naszej pracy. Chwilami jest to proces powolny, ale jesteśmy pewni, że końcowy produkt jest bardzo dobrej jakości. Jest to nawet po części naszym mottem, aby w procesie tworzenia dokumentacji jakość stawiać przed ilością.

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

MadCap Flare i Subversion. Produkty MadCap są dość drogie, a ich niezawodność niestety jest odwrotnie proporcjonalna do ceny. Z sentymentem i łezką w oku wspominam edytor Oxygen i gitowe repozytorium, które po zapamiętaniu (czytaj spisaniu w notesiku) kilku komend było moim sprawdzonym orężem pisarskim.

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

Odpowiadając krótko: w różny. Najczęściej biorę udział w demowaniu oprogramowania lub oglądam nagrania, na których zespoły developerskie przedstawiają nowe funkcjonalności produktu. Zdarza mi się umawiać na sesje ‘one on one’, aby dokładnie dopytać o zmiany w produkcie i poznać lepiej nowe funkcjonalności. Mam dostęp do gotowego produktu jak i do produktu w fazie developerskiej. Mogę się zalogować, przetestować funkcjonalność samemu. Bardzo często korzystam z projektów jakie tworzą UX designerzy dla zespołów developerskich. Jest to dobry moment aby wyłapać wszelkie nieścisłości i podzielić się tym z zespołem developerskim. Robię duży research, planuję swoją pracę, a najwięcej czasu spędzam na „zabawie” z produktem: klikam, ustawiam parametry, przechodzę wizardy, szukam bugów, a najczęściej generuję errory i alerty. Nieodzownym elementem mojej pracy jest zadawanie dużej ilości pytań. Są to, jakże by inaczej, ‘oczywiste pytania’ (przynajmniej w mniemaniu zespołów developerskich).

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

Główny dokument to on-line help, który dołączamy do naszego sztandarowego produktu z każdą jego nową wersją. Help jest też dostępny na stronie internetowej, którą firma udostępnia swoim klientom. Dodatkowo, strona ta zawiera różnego rodzaju dokumenty w formie artykułów i pdfów. Są to ‘walkthroughs’, ‘procedury troubleshooting’, ‘release notes’, itp. Dokumentacja pisana jest w American English.

Jakie produkty opisujesz?

Jeden z elementów platformy do zarządzania procesami biznesowymi.

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?

Zdarza mi się testować szkolenia na temat naszego produktu. Nim takie e-learningowe szkolenie trafi do naszych klientów, jestem ‘pierwszym użytkownikiem’. Dodatkowo zdarza mi się robić mini prezentacje na temat tych funkcjonalności, które opisuję. Jest to często niezbędne, aby przybliżyć innym tech writerom mój komponent platformy i ułatwić im peer review tego, co napisałem. W ostatnim czasie, co raz częściej zdarza się, że nowe funkcjonalności wpływają na więcej niż jeden element platformy co wymaga współpracy dwóch lub kilku tech writerów z różnych stref czasowych.

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

W wielu rozmowach z innymi kolegami z branży, a także chwilami u siebie w pracy, mam wrażenie, że dokumentacja zawsze traktowana jest po macoszemu i nikt (inżynierowie, czy produkt ownerzy) nie mają czasu, aby poświęcić tech writerom trochę więcej uwagi. Później, gdy użytkownicy zaczynają używać produkt to bardzo szybko wynajdują braki lub nieścisłości w dokumentacji i taka dokumentacja wraca na stół kreślarski. Jako tech writerzy, chyba każdy z nas spotyka się z sytuacją że rozwiązaniem na braki produktowe lub nie do końca dobrze działające funkcjonalności jest opisanie tego w dokumentacji w taki sposób, aby użytkownik produktu był zadowolony z tego co jest. No cóż, nie zawsze udaje się dopiąć wszystko na ostatni guzik w produkcie i trzeba z czegoś zrezygnować, lub dostarczyć w późniejszym terminie.

Co najbardziej lubisz w pracy Tech Writera?

Lubię ten moment kiedy zrozumiem nową funkcjonalność produktu, mam wszystkie dostępne materiały, nie mam więcej spotkań w kalendarzu i na spokojnie mogę sobie pisać dokumentację do mojej ulubionej muzyki. Czuję wówczas, że dobrze spędziłem dzień. Szybko mija tydzień, a artykułów w helpie przybywa. Do tego dochodzą elastyczne godziny pracy i organizowanie pracy na własną rękę. Bardzo lubię kiedy podczas rozmów i prezentacji nowych funkcjonalności produktu jest chwila, aby porozmawiać o tym co słychać w Indiach, Amsterdamie lub Bostonie. Lubię tą różnorodność kultur w pracy i łatwo dostrzegam, że ludzie z Azji, Europy i Ameryki, z którymi mam przyjemność współpracować oglądają te sam seriale, mają podobne poczucie humoru i starają się sobie nawzajem pomóc.

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

Dodać stronkę techwriter.pl do ulubionych i wpaść na konferencję SOAP na dobry początek. Zaczynając przygodę z pisaniem dokumentacji nie należy się zrażać na samym początku. Pierwszy rok, dwa dają już dużą perspektywę. Patrząc na pierwsze inwencje twórcze, można by się pod nosem uśmiechnąć jak to się człowiek nieraz ‘popisał’. Co więcej w tym temacie? Warto spróbować swoich sił w dwóch, trzech firmach, aby wyrobić sobie pogląd na pracę tech writera. Dobrze jest znaleźć firmę, która umożliwia wyjazdy i pracę z zespołami, które zlokalizowane są poza Polską. Firmę, która chętnie wysyła pracowników na szkolenia i konferencje.

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