Technical Writer – człowiek renesansu

Ludzie dzielą się na tych, którzy są Tech Writerami i na tych, którzy nimi nie są. Proste. Tą drugą, liczniejszą grupę możemy z kolei podzielić na tych, którzy nie wiedzą czym się zajmuje Tech Writer i na tych, którym się wydaje, że wiedzą.

Najlepiej świadczą o tym sytuacje, w których ktoś nas pyta czym się zajmujemy. Kiedy słyszą „Jestem Technical Writerem” to albo pytają co to oznacza albo stwierdzają krótko „Aha! Piszesz instrukcje”, mając w głowie obraz smutnego osobnika, który całymi dniami siedzi sam, zamknięty w najbardziej odległym pokoju w biurze i w pocie czoła pisze, pisze i pisze coraz to grubsze księgi, które potem lądują w koszu lub służą do podpierania stołu.
Jednak rzeczywistość jest inna (przynajmniej u nas 🙂 ). Oczywiście, pisanie to duża część naszej pracy, jednak tworzenie dokumentacji nie sprowadza się do bezmyślnego klepania linijek tekstu. Jest to wielowymiarowy proces składający się z różnorodnych zadań. Oprócz tego, nasza praca ma również jeden bardzo istotny „efekt uboczny” – znajdowanie problemów w produkcie, który opisujemy. Dzięki temu stajemy się nie tylko testerami, ale też po części architektami, ponieważ możemy kształtować produkt poprzez proponowanie rozwiązań znalezionych problemów oraz zgłaszanie usprawnień. Przez to z kolei wpływamy na główny element naszej pracy, czyli tworzenie dokumentacji. Niejednokrotnie usunięcie problemu w produkcie powoduje też zredukowanie liczby zagadnień, które musimy opisać. I kółko się zamyka. Podsumowując, dobry Tech Writer powinien być mieszanką pisarza, testera, analityka, architekta i developera w proporcjach właściwych dla struktury zespołu i firmy w jakiej pracuje.
W celu lepszego zobrazowania naszego wywodu, posłużymy się krótką historią, którą przysłała do nas czytelniczka. Autorce serdecznie dziękujemy, a Wam życzymy przyjemnej lektury.

Krótka opowieść o instrukcji, której nie powinno być

Technical writer tworzy opis do czegoś, co już istnieje (produktu/aplikacji/organizacji). To, co opisuje jest dobrze przemyślane na etapie projektu. Wykonanie nie pozostawia nic do życzenia. Technical writer siada i pisze. Ale jak wiadomo istnieją również sytuacje nieidealne.

Jak znaleźć cukier:
1. Otwórz szafkę z napisem „Ręczniki”.
2. Poszukaj w niej puszki z napisem „Kawa”.
3. Otwórz puszkę z napisem „Kawa”. Znajdziesz w niej cukier.

Teraz wybierz odpowiedź, która wg Ciebie jest właściwa:

A. Technical writer powinien napisać instrukcję „Jak znaleźć cukier”.
B. Technical writer powinien wpłynąć na właściwą osobę, która może pozmieniać opisy na szafkach i puszkach. Kiedy cukier będzie w puszce z napisem „Cukier”, nie będzie potrzebna instrukcja szukania cukru.

My od siebie dodamy jeszcze opcję C – czyli opcję B rozbudowaną o sprawdzenie dlaczego szafki i puszki były tak opisane, dlaczego cukier znalazł się tam gdzie się znalazł i czy można uniknąć podobnych sytuacji w przyszłości. Która z nich jest według Was najlepsza?