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?