Żywot dokumentalisty poczciwego, czyli wyzwanie to pisanie

Bycie Technical Writerem jest fajne. Przynajmniej według nas. Jest to zawód nietuzinkowy, dający satysfakcję i poszerzający wiedzę techniczną, szczególnie dla osób, które ukończyły studia humanistyczne. Jednak nie zawsze jest tak różowo. Dzisiaj chcemy wylać trochę żali i podzielić się z Wami tym, z czym Technical Writer musi się mierzyć. Dla jednych są to problemy, dla innych wyzwania. Bez względu na to, jakiego określenia użyjemy, są to "ciemne strony" tego zawodu, o których też trzeba mówić. Dzięki temu możemy podpowiedzieć innym jak sobie radzić w trudnych sytuacjach. Problemy są różne, dlatego nasza lista w żadnym wypadku nie wyczerpuje tematu. Jest to jedynie zestawienie, które zbudowaliśmy na podstawie własnych doświadczeń. Nie chcemy nikogo zniechęcać do zawodu Technical Writera, a jedynie uświadomić, że to nie zawsze plaża i drinki ze słomką 😉

Edukacyjna pustynia

Kilkukrotnie ubolewaliśmy (np. w tym wpisie) nad brakami w edukacji formalnej i kursach przeznaczonych dla dokumentalistów, dlatego nie będziemy się nad tym po raz kolejny rozwodzić. Wspominamy o tym tylko dla porządku. Łatwo nie jest, ale mamy pewne możliwości zdobywania wiedzy. Przede wszystkim "nie wyważajmy otwartych drzwi". Korzystajmy ile się da z doświadczenia kolegów i koleżanek po fachu. Czytajmy blogi i literaturę branżową. Bierzmy udział w konferencjach. Na szczęście istnieją ludzie, którzy chcą rozkręcić komunikację techniczną w naszym kraju, np. nasi "mydlani" przyjaciele, którzy w tym roku organizują już po raz drugi konferencję soap!.

Miękkie serce i twarda...

W stosunku do użytkowników czytających nasze instrukcje trzeba mieć miękkie serce, rozumieć ich potrzeby, wczuwać się w ich sytuację. Trzeba ich uspokoić i doprowadzic do celu jak najszybciej. Z drugiej strony trzeba też mieć twardą... wiadomo co, bo jak każda praca twórcza, pisanie instrukcji jest obiektem krytyki. Mamy tu na myśli krytykę, która nie dotyczy kwestii merytorycznych, tylko stylu. Tak samo jak w przypadku powieści - jednym styl danego pisarza odpowiada, a innym nie. Instrukcja może być przejrzysta, kompletna i zrozumiała, jednak zawsze znajdzie się ktoś kto będzie miał uwagi do tego jak jest napisana. Przepisze nam parę zdań, bo będzie uważał, że tak lepiej brzmi. Jest to najcięższy rodzaj krytyki, bo słabo mierzalny. Często taka osoba nie jest w stanie jednoznacznie sformułować swoich "zarzutów". Po prostu jakoś się to czyta tak sobie, brakuje płynności. Każdy ma swoje upodobania i sposób pisania, gusta i guściki. Przez to czasami ciężko dyskutować o takich problemach rzeczowo. Jak temu zaradzić? Najlepiej zapytać wprost jakie są oczekiwania, co powinniśmy zmienić, żeby było lepiej. Jeśli nie doczekamy się odpowiedzi na te pytania, można ugryźć temat inaczej. Warto poprosić osobę, która ma zastrzeżenia do naszego stylu o wskazanie instrukcji, które według niej są godne naśladowania. Wtedy będziemy mogli stopniowo wchodzić w styl, którego się od nas oczekuje.

Ostatni będą pierwszymi... albo nie

Brutalna prawda jest taka, że dokumentacja jest gdzieś na dole listy priorytetów. Oczywiście nie zawsze i nie wszędzie, ale niestety takie zjawisko ma miejsce w niektórych firmach. Produkt jest najważniejszy, dlatego oczywiste jest, że w sytuacji gdzie programista ma napięte terminy, wyższy priorytet ma dokończenie jakiejś funkcji systemu niż odpowiadanie na nasze pytania. W żadnym wypadku nie mamy o to pretensji, jest to zrozumiałe, tym bardziej, że jeśli nie będzie produktu to nie będziemy mieli czego opisywać. Żal mamy o coś innego. O to, że często brakuje w tym jakiegoś wyważenia i zdrowego rozsądku. Czasami można odnieść wrażenie, że wszyscy chcieliby "zjeść ciastko i mieć ciastko", czyli mieć dobrą dokumentację na czas, ale bez większego wkładu ze swojej strony. Technical Writer jest zależny od wielu osób, bez których ciężko jest zgromadzić potrzebne informacje. O ile opisując interfejs graficzny wiele rzeczy można sobie "wyklikać" i sprawdzić samemu, o tyle, np. w przypadku konfiguracji serwera nie jesteśmy w stanie wziąć informacji z powietrza. Sytuacji nie polepsza fakt, że często architekci systemu nie prowadzą swojej dokumentacji, która opisuje jak dana funkcja ma wyglądać. Poza tym, nawet jeśli to robią, to zdarza się, że jest ona niezbyt dokładna albo nieaktualna. Co z tym zrobić? Odpowiedź jest prosta - zakasać rękawy i zrobić ile się da samemu. Jednocześnie trzeba obudzić w sobie natręta i pytać dopóki nie uzyskamy informacji, które są nam potrzebne. Jeśli to nie działa, terminy na oddanie dokumentacji są coraz bliższe, a my jesteśmy w martwym punkcie, bo ktoś nas zbywa, trzeba wprost powiedzieć przełożonemu, że bez tych informacji dokumentacja po prostu nie powstanie. Dzięki temu nikt nam nie zarzuci, że widzieliśmy zagrożenia i nic nie zrobiliśmy.

To dawno nieaktualne od wczoraj

Produkt się zmienia, a to jak często zależy od fazy w jakiej się znajduje. Rzadko kiedy dokumentacja zaczyna powstawać w momencie kiedy produkt jest prawie gotowy. Często trzeba zacząć pisać kiedy produkt jest jeszcze w fazie testów, co powoduje zgłaszanie dużej ilości uwag, które rzutują na dokumentację. Najbardziej ekstremalne jest pisanie dokumentacji zaraz po tym jak jakaś funkcja została ukończona i niestety wciąż ma mnóstwo niedoróbek, które trzeba będzie poprawić. Takie sytuacje niestety mają miejsce. Wpadamy wtedy w pętlę ciągłego poprawiania. Rzeczy zmieniają się z dnia na dzień. Taki tryb pracy jest uciążliwy, bo zaczynamy mieć wrażenie kręcenia się w kółko i przekonanie, że to się nigdy nie skończy. Pikanterii dodaje jeszcze fakt, że programiści "siedząc po drugiej stronie barykady" odbierają produkt zupełnie inaczej niż użytkownik. To powoduje, że nie są oni do końca świadomi, że jakaś mała kosmetyczna zmiana, np. nazwy opcji w menu, może pociągnąć za sobą lawinę czasochłonnych poprawek w dokumentacji. Działa to też w drugą stronę - duża poprawka systemu może kompletnie nie mieć wpływu na dokumentację, bo dotyczy ona mechanizmu, którego użytkownik nie widzi. Dlatego, o ile to możliwe, trzymajmy rękę na pulsie. Na przykład możemy śledzić system do zgłaszania problemów pod kątem zgłoszeń, które wpływają na dokumentację. Dodatkowo można też mieć na oku plan ukończenia poszczególnych części systemu przez programistów. Dzięki temu będziemy mogli przewidzieć z grubsza ile pracy nas czeka.

Technical Writer niepotrzebny od zaraz

Nietuzinkowość naszej profesji ma również swoje wady. Najbardziej odczuwalną jest bardzo mała ilość ofert pracy w Polsce. Niestety, do poziomu Stanów Zjednoczonych sporo nam jeszcze brakuje i być może nigdy do niego nawet się nie zbliżymy. Kraków zdecydowanie przoduje w ilości ofert. Z naszych obserwacji wynika, że właśnie tam jest największe zapotrzebowanie na dokumentalistów. Jednak nadal jest to kropla w morzu. Z tego powodu trzeba uzbroić się w cierpliwość. Dla pocieszenia, możemy ten stan rzeczy postrzegać w taki sposób, że jest nas mało, więc pracodawcy mają problem ze znalezieniem właściwego kandydata. Oznacza to, że osoby, które już parają się pisaniem dokumentacji mają spore szanse na bycie tymi właściwymi kandydatami. Jesteśmy pełni nadziei, że z biegiem czasu Technical Writing w naszym kraju będzie nabierał rozpędu. Póki co działajmy. Uświadamiajmy ludzi, że instrukcje to nie jakieś świstki papieru tylko owoc ciężkiej pracy dokumentalistów. Może trochę zbyt górnolotnie to brzmi, ale wiecie o co nam chodzi 😉

Dajcie nam znać w komentarzach lub w inny sposób z czym Wy się mierzycie na co dzień i czy Wasze żale pokrywają się z naszymi.