Czy techwriter to z definicji autor i to w dodatku bestsellerów?

W dzisiejszym poście staramy się dowieść, że zawód techwritera i pisarza, pomimo wielu stycznych, to jednak zupełnie odmienne zawody.

A gdyby tak był plebiscyt na najlepszą dokumentację techniczną?

Wydawać by się mogło, że skoro żaden produkt nie może obyć się bez najdrobniejszego kawałka papieru z treścią techniczną, to w każdym plebiscycie na najbardziej poczytne dzieło literackie swe chlubne miejsce powinna zajmować również pozycja z tego obszaru literatury. Literatury technicznej rzecz jasna.

Wyobraźcie sobie, że jako techwriterzy odbywacie spotkanie literackie, na przykład w sklepie z urządzeniami RTV i AGD, i rozdajecie autografy, bo wasza instrukcja do pralki zdobyła prestiżowe wyróżnienie! Czyż nie brzmi pięknie? Aż trudno tutaj powstrzymać wyobraźnię i nie nakreślić sytuacji, w której podchodząca z prośbą o autograf osoba wspomina nam ze wzruszeniem i łzami w oczach, że procedura dotycząca ustawiania programu wyłącznego wirowania zmieniła totalnie życie calej rodziny.

Dokumentalista i pisarz to nie to samo?

Postrzeganie zawodu techwritera przez osoby postronne czasami jest takie, że dokumentalista to osoba, która, podobnie jak autor/ka książek, wpada w wir kreatywnego wytwarzania treści, którą potem, pięknie opakowaną w okładkę z ilustracją opisywanego produktu, wydaje na świat, by literacko-edukacyjną wartość nieść narodom. Zaś w tym całym twórczym procesie odbywa się walka o wybieranie słów spośród tych najdobitniejszych, wyrażeń tylko najpiękniejszych i konstrukcji wyłącznie najbardziej eleganckich.

Cóż - trochę tak, trochę nie.

Zdecydowanie technical writing jest zawodem skupiającym się na wykorzystywaniu umiejętności pisarskich, lecz daleko mu do zawodu pisarza/rki. A im bardziej się zagłębić w to co zazwyczaj zalicza się do wachlarza obowiązków osoby zajmującej się techwritingiem, tym to pokrewieństwo okaże się jeszcze bardziej odległe.

Trzeba wiedzieć, że o ile firma nie potrzebuje zbudować produktu (w tym dokumentacji) od zupełnego zera, to w większości przypadków tworzona dokumentacja techniczna będzie powstawać na bazie już dotychczas wydanych treści. Nowa treść to swego rodzaju udoskonalone i poszerzone wydawnictwo z zeszłego roku. Sami przyznacie, że książki tak się pisać nie da. W praktyce oznacza to, że zdarzyć się może, że cała praca związana z opisaniem nowej funkcjonalności może polegać na dodaniu paru zdań, poprawieniu jakiejś procedury lub dodaniu kilku akapitów tekstu.

Nie ma zatem tej całej traumy wpatrywania się w migający kursor na białej przestrzeni dokumentu i rozmyślania od czego by tu zacząć, bo nawet zupełnie nowy podręcznik użytkowania do nieistniejącego jeszcze rozwiązania będzie opierać się o wypracowany już schemat i strukturę treści powielane przy poprzednio wydawanych treściach technicznych. Niemniej jednak, faktycznie typowych językowych rozmyślań jest tu wciąż co nie miara i aż prosi się, aby przytoczyć wiersz Mirona Białoszewskiego "Mironczarnia", z drobną tylko alteracją w tekście:

mę­czy się czło­wiek techwriter mę­czy znów jest zeń słów nie­po­traf nie­pew­ny co­zro­bień yeń

Bo jak łatwo się domyślić, wcale tak łatwo nie jest. W tej pracy sięga się często nie tylko po słownik języka angielskiego, lecz także po ściągawki dotyczące użycia znaczników (np. tagów DITA), szuka się opisu danej funkcji użytej we fragmencie kodu lub terminologii fachowej, żeby później nie ośmieszyć się swoim tekstem najpierw - to jeszcze pół biedy - przed Subject Matter Expertem (SME, korp. to ta osoba, co wie wszystko w temacie, w którym techwriter/ka chciałby wiedzieć więcej, np. programista lub inżynier), a później już przed odbiorcą docelowym.

Nie ma w tym wad, jeśli tylko mózg ma się chłonny jak gąbka, a codziennie rano budzi się z poczuciem bycia osobą skazaną na sukces. Niestety trzeba tutaj odbyć niemałą walkę między oczekiwaniami architektów zarówno treści, jak i produktu, a sztywnymi ramami języka technicznego, uproszczonego języka angielskiego, wytycznych wobec pisania treści technicznej w danej firmie, no i wreszcie, możliwościami, jakie oferuje dane narzędzie do tworzenia dokumentacji. Do tego wszystkiego dochodzi też tłumaczenie sobie inputu od SME (korp. informacja od SME dotycząca potrzebnej zmiany, biały kruk wśród korespondencji dotyczącej aktualnej pracy).

Cóż - do odważnych techwriting należy.

Praca techwritera bywa przy tym nieprzewidywalna jak pogoda. Czasami nowy tydzień zaczynający się zupełną ciszą na morzu może zakończyć się sztormem zadań, które na początku napływały nieśmiało niewielkimi falami i wydawało się, że niedługo będzie po wszystkim. Jak to często bywa, nasz piękny plan to zbudowany zamek z piasku, który zaraz znika pod powodzią requestów (korp. prośba o zmiany do wprowadzenia).

Naraz okazuje się, że w fazie developmentu (korp. fazie rozwoju, opracowywania) rzeczywistość skrzeczy najgłośniej - faktyczne potrzeby nakładu pracy przekraczają wcześniejsze założenia dotyczące obciążenia zespołu dokumentacyjnego. Trzeba zatem mieć świadomość, że wprawdzie nikt nie zobowiąże nas do napisania podręcznika użytkownika o grubości stu stron na już, ale okresy mniejszego obładowania przeplatane są często okresami, kiedy dosłownie nie wiadomo w co ręce włożyć. I tutaj właśnie dochodzimy do tej części przytoczonego wiersza, kiedy techwriter/ka jest niepewny/a cozrobień.

Lecz pod płaszczykiem tych wszystkich trudów i znoju kryją się momenty naprawdę ogromnej satysfakcji. Najczęściej pojawia się ona, kiedy po tygodniach rozmów ze SME otrzymuje się, w odpowiedzi na którąś z kolei prośbę o aprobatę wprowadzonych zmian, komunikat: "jest ok". Zapewniamy was, drodzy czytelnicy i czytelniczki, że w tych dwóch słowach kryje się największe szczęście. A po kilku takich właśnie fazach i litrach wypitej kawy oraz wyspecjalizowaniu się w produkcie, który już niedługo ma zmienić życie klientów, przychodzi moment releasu (korp. wydanie na świat naszego dzieła).

Kiedy tylko faza wydawania nowego dziecka na świat się zakończy, w głowie techwritera/ki grzmią fajerwerki, na skrzynkę odbiorczą przychodzą podziękowania i gratulacje, przy kawie opowiada się, już teraz z uśmiechem na twarzy, najbardziej nerwowe momenty jako anegdoty. Można na nowo planować porządki na pulpicie, a liderowi zespołu opowiedzieć o nowych planach na przyszłość.

I w tym krótkim przerywniku międzyreleasowym techwriter/ka współdzieli splendor i radość z pisania z najbardziej poczytnym/ą autorem/ką. A na dopiero co napisany podręcznik użytkowania - mimo, że to treść techniczna - spogląda z ufnością, że komuś ułatwi życie lub wybawi z opresji. I że w chwili potrzeby, ktoś powróci do lektury tego dzieła, jak do najukochańszej książki wynalezionej na liście najbardziej poczytnych tytułów ostatniego roku. To najprzyjemniejszy okres w pracy techwritera.

Cóż - przynajmniej do czasu, kiedy nie zostaną zgłoszone przez klienta defekty.