Kilka pytań do - część 6

Marek napisał do nas mail z tematem "Okazuje się, że w sieci w końcu nie jestem sam"... a my od razu poprosiliśmy go o wywiad. Zgodził się! Dzięki temu wszyscy możemy się dowiedzieć paru ciekawych rzeczy. Dziękujemy Ci Marku!

Jak długo pracujesz jako Tech Writer?

Z różna intensywnością od ponad 4 lat.

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

Skończyłem studia humanistyczne i szukałem pracy wszystkimi możliwymi sposobami. Jednym z ogłoszeń jakie otrzymałem od znajomych było właśnie ogłoszenie dotyczące stanowiska “edytora tekstów”. Długo się nie zastanawiałem i wysłałem dokumenty aplikacyjne. Tak się zaczęła moja przygoda z tech writingiem.

Jako ciekawostkę dodam, że jednym z trzech dokumentów jaki musiałem przedłożyć pracodawcy podczas procesu rekrutacji była samodzielnie sporządzona instrukcja do sapera. Jeśli ktoś nie kojarzy to jest to gra dostępna w starszych systemach operacyjnych Windows 😉

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

Firma w której pracuję oferuje usługi w zakresie szeroko rozumianego zaplecza inżynieryjnego dużych projektów infrastrukturalnych i budowlanych np. automatyki przemysłowej, elektroenergetyki, klimatyzacji, itd. Z kolei pion w którym pracuję to pion systemów informatycznych zajmujący się tworzeniem oprogramowania. Oprogramowanie które wytwarzamy przeznaczone jest dla sektora przemysłowego z nastawieniem na gazownictwo, przemysł wydobywczy, elektroenergetykę, ciepłownictwo oraz gospodarkę wodno-kanalizacyjną. Dwa flagowe produkty firmy to:

• system paszportyzacji - system atrybutowego i przestrzennego opisu elementów stanowiących infrastrukturę i majątek przedsiębiorstwa,
• system telemetrii - system klasy SCADA z mechanizmami kolekcji i dystrybucji danych, raportowania i wielowymiarowej analizy danych.

Zespół do którego należę składa się z wdrożeniowców, a ja pełnie w nim funkcję tech writera - odpowiadam za dostarczanie klientom różnego rodzaju dokumentacji. Przez pierwsze 3 lata pracy zajmowałem się głównie rozwijaniem oraz utrzymywaniem dokumentacji systemu ewidencyjnego (system paszportyzacji). Aktualnie moja praca skupia się przede wszystkim na systemach telemetrycznych.

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

Pracujemy w metodyce Scrum, gdzie rozpiętość czasowa sprintów to z reguły 2 tygodnie. Pod koniec sprintu przeprowadzamy podsumowanie zadań, które zaplanowaliśmy na sprint (wraz z retrospektywą) oraz planujemy zadania na kolejne 2 tygodnie. Naszej pracy towarzyszą codzienne spotkania scrum’owe, na których krótko omawiamy to co udało się zrealizować dnia poprzedniego oraz to jakimi zadaniami będziemy się zajmowali. Stan sprintu jest codziennie aktualizowany podczas spotkania na tablicy z zadaniami - poszczególny karty zadań są przesuwane na tablicy zgodnie z aktualnymi postępami każdego zadania (To do / In progress / Done).

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

Do pisania dokumentacji wykorzystuje przede wszystkim Adobe InDesign CS4 PL. Sporadycznie popełnię coś w Wordzie. InDesigna uczyłem się od zera, z kolei podstawy Worda znałem już wcześniej. Każde narzędzie ma swoje plusy i minusy. InDesign jest dla mnie przede wszystkich szybszy w obsłudze, zarówno biorąc pod uwagę formatowanie tekstu jak dołączanie grafik / zrzutów do dokumentów. Umożliwia też import gotowych plików PDF do dokumentacji. O wadach i zaletach aplikacji Microsoftu nie ma się co rozpisywać 😉 Dodatkowo używam także innych prostych narzędzi:

• Paint.Net - podstawowa i szybka obróbka grafik / zrzutów ekranowych.
• Gadwin PrintScreen - przechwytywanie obrazu i zapis do pliku.
• Gios PDF Splitter and Merger - praca z plikami PDF (dzielenie / łączenie).

Do zarządzania zadaniami (backlogi projektów) oraz rozliczania czasu pracy jaki został przeznaczony na poszczególne zadania wykorzystujemy Jirę. Oprócz tego korzystamy również z Confluence'a.

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

Jeżeli chodzi o systemy i narzędzia początkowo poznawałem je samodzielnie. Oczywiście mogłem liczyć na wsparcie merytoryczne kolegów i koleżanek ale większość pracy musiałem wykonać samodzielnie. Aktualnie współpracuje głównie z wdrożeniowcami (łatwiej się z nimi dogadać 😉 ), a mniej z programistami (czasami jednak trzeba "uderzyć do źródła"). Informacje zdobywam w różny sposób. Najczęściej jest to rozmowa, podczas której poznaję specyfikę działania określonych funkcjonalności i modułów aplikacji. Moim zdaniem jest to najlepszy sposób na zdobywanie wiedzy ale wymaga też dużo uporu i konsekwencji. Mówiąc wprost - czasami jeśli ktoś próbuje wysłać cię na drzewo, trzeba zacisnąć zęby i drążyć temat do skutku. Innymi sposobami na zdobywanie wiedzy są różnego rodzaju dokumenty, które stanowią tzw. dokumentację procesu. Dokumenty te są tworzone przez programistów lub wdrożeniowców w trakcie realizacji określonych zdań lub projektów.

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

Są to publikacje małe (do kilku / kilkunastu stron) i duże (do kilku tysięcy stron): począwszy od opisu pojedynczych funkcjonalności systemu, poprzez opis poszczególnych modułów, na opisie całego systemu kończąc, tzw. "klopsy". Tworzę też dokumentację powykonawczą dla mniejszych i większych projektów - czyli co zostało zmodyfikowane w systemie po zmianach, które popełnili wdrożeniowcy. Dokumenty dostarczam bezpośrednio klientowi w postaci PDFa lub w postaci edytowalnej (w zależności od wymagań klienta). Cześć dokumentacji jest dostarczana klientowi wraz z wdrożeniem nowej wersji systemu w środowisku produkcyjnym. Piszę w języku polskim z uwagi na to, że realizujemy projekty głównie dla klientów z Polski.

Jakie produkty opisujesz?

Jeżeli chodzi to tematykę opracowań to aktualnie działam przede wszystkim w obszarze systemów telemetrii (SCADA). Wcześniej zajmowałem się systemem paszportyzacji z modułem GIS’owym - System Informacji Geograficznej (nie mylić z “Główny Inspektorat Sanitarny” 😉 ). Gdzieś po drodze popełniłem też jakąś DTR’kę (dokumentację techniczno-ruchową) dla fizycznego urządzenia (Multiplekser portu szeregowego), dokumentację BMS'a (System zarządzania budynkiem) oraz inną tzw. "drobnicę".

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?

Oprócz tworzenia samej dokumentacji często uczestniczę też w procesie jej składu - kiedy "wkład" dostarczają mi inni, a moim zadaniem jest poskładanie wszystkiego w jedną “zgrabną” całość. Ma to miejsce np. w sytuacji kiedy jako firma realizujemy duży projekt, w który zaangażowane są inne piony i działy.

Aktualnie nie poświęcam tematom związanym z dokumentacją tyle czasu co jeszcze rok temu ale nadal mam w sprintach zadania związane z pracą "twórczą". Od ponad roku wspieram dział wdrożeń, a teraz na tapecie wylądował u mnie temat testów.

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

Największym wyzwaniem zawsze było i jest zdobywanie wiedzy branżowej oraz poznawanie zagadnień technicznych związanych z działaniem systemów. Jako humanista z wykształcenia “nie czuję” od razu wszystkich zagadnień technicznych więc wymaga to ode mnie sporej ilości pytań do osób bardziej zorientowanych technicznie. Z czasem jednak łapie się pewien “zmysł” techniczny, który ułatwia zrozumienie wszystkich zawiłości i “myków”. Tak naprawdę nigdy nie przestałem się uczyć i realizując wraz z zespołem kolejne projekty cały czas poznaje nowe zagadnienia.

Co najbardziej lubisz w pracy Tech Writera?

Samodzielność oraz to, że mam swój obszar działalności za który jestem w pełni odpowiedzialny. Oczywiście pewne standardy mojej pracy zostały wypracowane w drodze rozmów i konsultacji z przełożonymi ale dużo zależy ode mnie.

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

Ważne aby się nie zniechęcać i nie bać się pytać. Aby dobrze coś opisać trzeba to dobrze poznać i zrozumieć, a kluczem do tego jest zdobyta wiedza. Jeżeli masz wątpliwości lepiej zapytać dwa, a nawet trzy razy niż stworzyć dokumentację która będzie zawierała błędy merytoryczne lub będzie niepełna. Powiedzenie “kto pyta nie błądzi” znajduje w naszej pracy pełne zastosowanie 😊