POIT #114: Technical writer

Witam w sto czternastym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest rola technical writera.

Dziś moimi gośćmi są:

Michał Skowron – przez 8 lat pracował jako Technical Writer, w małych i dużych firmach, zajmujących się wytwarzaniem oprogramowania. Jest dużym zwolennikiem automatyzacji procesu dostarczania treści. W zeszłym roku został developerem narzędzi do dokumentacji. W codziennej pracy skupia się na tworzeniu i wdrażaniu narzędzi oraz rozwiązań, które pomagają wytwarzać dokumentację techniczną zgodnie z najlepszymi praktykami obowiązującymi w branży rozwoju oprogramowania. Jego ulubionym językiem programowania jest Python. Autor przewodnika “Tech Writer koduje w Pythonie. Przewodnik szybkiego startu.”

Paweł Kowaluk – w IT od 2008 roku. Pracował jako architekt informacji, designer, lider projektów, programista i technical writer. Autor książki „Dokumentacja do oprogramowania. Poradnik dla managerów”.

W tym odcinku o roli technical writera rozmawiamy w następujących kontekstach:

  • czym zajmuje się technical writer?
  • co wnosi do zespołu?
  • czym jest documentation as a code?
  • w jaki sposób technical writer współpracuje z innymi członkami zespołu?
  • od jak dawna ten zawód istnieje w Polsce?
  • jakie firmy i branże zatrudniają technical writerów?
  • w jaki sposób zostać technical writerem?
  • czy w Polsce istnieją możliwości kształcenia się w tym zawodzie?
  • na ile ważne w tym zawodzie jest posługiwanie się słowem i copywriting?
  • na ile ważne są umiejętności techniczne?
  • z jakich źródeł można tą wiedzę pozyskiwać?
  • z jakich narzędzi korzysta tech writer?
  • jak wygląda rynek pracy dla tej roli?
  • jakie ma możliwości rozwoju kariery?
  • czy to jest dobra furtka do IT?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 114. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o roli technical writera.

Przypominam, że w poprzednim odcinku rozmawiałem o aplikacjach w chmurze publicznej.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/114.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilka minut.

Sponsorem dzisiejszego odcinka jest platforma rekrutacyjna SOLID.Jobs. Jeśli szukasz pracy w IT, koniecznie odwiedź solid.jobs. Znajdziesz tam tylko oferty z widełkami wynagrodzeń. Jeśli aktualnie nie myślisz o znalezieniu nowej pracy, to koniecznie zapisz się na Job Alert. Otrzymasz regularne wiadomości e-mail z zestawieniem ofert, które mogą Cię zainteresować. Jeśli w swojej pracy dalej korzystasz z SVN-a, to koniecznie odwiedź SOLID.Jobs.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego, jest właśnie ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.

A ja przy okazji bardzo dziękuję moim obecnym patronom.

A teraz życzę Ci już miłego słuchania. 

 

Odpalamy!

 

Cześć, dzisiaj moimi gośćmi są: Michał Skowron, który przez osiem lat pracował jako technical writer w małych, dużych firmach zajmujących się wytwarzaniem oprogramowania. Jest dużym zwolennikiem automatyzacji procesu dostarczania treści. W zeszłym roku został deweloperem narzędzi do dokumentacji. W codziennej pracy skupia się na tworzeniu i wdrażaniu narzędzi oraz rozwiązań, które pomagają wytwarzać dokumentację techniczną zgodnie z najlepszymi praktykami obowiązującymi w branży rozwoju programowania. Jego ulubionym językiem jest Phyton. Autor przewodnika Tech writer koduje w Pythonie, przewodnik szybkiego startu

Oraz Paweł Kowaluk. W IT od 2008 roku. Pracował jako architekt informacji, designer, lider projektów, programista i technical writer. Autor książki Dokumentacja do oprogramowania, poradnik dla managerów.

Panowie razem prowadzą podcast Tech writer koduje, w którym mówią o technicznej stronie tworzenia dokumentacji w IT. Starają się działać w społeczności i występować na konferencjach. A dzisiaj z Michałem i z Pawłem oczywiście będę rozmawiał o technical writerze. Czym ta rola jest? Za co jest odpowiedzialna? Jak może pomóc.

Michał, Paweł, witajcie w podcaście! Bardzo się cieszę na naszą rozmowę.

 

M.S.: Cześć Krzysztof, fajnie się usłyszeć i fajnie się spotkać, żeby porozmawiać o technical writingu.

 

P.K.: Cześć, miło gościć.

 

Super, to zaczniemy wobec tego moim klasycznym pytaniem na wejście, czyli czy słuchacie podcastów? Jeśli tak, to może macie jakieś fajne do polecenia.

 

M.S.: Będziesz żałował tego pytania, bo akurat jestem uzależniony od podcastów. Dzisiaj sprawdzałem w swoim playerze, to mam obecnie ponad sześćdziesiąt subskrypcji, jeśli chodzi o podcasty w różnych kategoriach. Może tak pokrótce przedstawię to, czego słucham regularnie. Z branży komunikacji technicznej, w której pracuję, to podcast Write the Docs Podcast, The Not-Boring Tech Writer albo Content Content. To są takie pozycje, których słucham regularnie z tej dziedziny. Oczywiście w związku z tym, że zajmuję się automatyzacją i programowaniem, to słucham też podcastów programistycznych. Z polskich pozycji, przyznam szczerze i nie jest to zabieg przymilania się, ale słucham właściwie tylko Twojego podcastu: Porozmawiajmy o IT.

 

Dzięki!

 

M.S.: A jeśli chodzi o zagraniczne, to dużo słucham o Phytonie, czyli Python Bytes, Talk Python To Me, Podcast._init_. O Java Skrypcie też trochę, czyli na przykład JS Party, JAMstack Radio albo Syntax ostatnio też odkryłem, bardzo fajny podcast. Jeszcze mam całą masę z pogranicza ciekawostek i nauki, takich jak na przykład polski podcast Wolność w Remoncie, chociaż ostatnio się zawiesił niestety. Freakonomics Radio, do tego mam jeszcze Household Name, Science Rules, bardzo fajny.

Staram się też czasami dokształcać z języka, na przykład z hiszpańskiego ostatnio, więc Espańiolistos albo wiadomości Organizacji Narodów Zjednoczonych po hiszpańsku. Nie mówię, że wszystko rozumiem, ale chcę się przyzwyczaić trochę.

 

Jasne.

 

M.S.: Może żeby nie przedłużać, tyle wystarczy.

 

Niezła lista.

 

M.S.: Jak ktoś chce, to mogę chętnie udostępnić całość. Zapraszam.

 

Super, dzięki. 

 

P.K.: A ja niestety nie słucham podcastów. To może być trochę dziwne, bo prowadzimy podcast, a ja nie słucham. To tak, jakbym był pisarzem, co nie umie czytać albo rybą, co nie umie pływać. Ale tak się złożyło, że to nie jest moja forma przekazu. Nie jestem nigdy w takiej sytuacji, żebym miał tylko kanał audio otwarty i mógł spokojnie się tym zajmować.

 

Pewnie.

 

P.K.: Ale na przykład lubię newslettery reaktowe, subskrybuję dwa takie: React Weekly News i React News. Nazywają się trochę nondescript. Chciałem polecić, jak się do nich zapisać, ale nie pamiętam, jak się do nich zapisałem. Po prostu gdzieś na jakiejś stronie się zapisałem. 

 

Myślę, że można wygooglać. Fajnie, dzięki mimo wszystko za te polecenia. Myślę, że nie jesteś odosobnionym przypadkiem. Znam takie osoby, które tworzą podcasty, a nie mogą zdzierżyć słuchania swojego głosu i to ich odrzuca od słuchania swojego i również innych podcastów. To jest jak najbardziej ok, to nie jest medium dla wszystkich. 

Skoro już porozmawialiśmy o podcastach, to przejdźmy do tematu naszej rozmowy. Na początku chciałbym Was zapytać, kim jest technical writer. Czy jest polski odpowiednik tego zawodu? Gdybyście mogli parę słów powiedzieć o roli i obowiązkach technical writera, żeby przybliżyć ten zawód.

 

M.S.: Nie jest łatwo zdefiniować w krótki sposób, czym zajmuje się technical writer, bo każda definicja spłyca to, co robi technical writer. Postarajmy się może powiedzieć, na czym to polega. Mówiąc w skrócie, jest to osoba, która pisze instrukcje. W tym momencie wiele osób myśli, że to straszna nuda. Siedzi człowiek dziesięć godzin przed maszyną do pisania albo przed komputerem, cały czas stuka i patrzy się w ekran a nic się nie dzieje. Ale to tak nie wygląda. Wydaje mi się, że lepszą definicją jest powiedzenie, że jest to osoba, która znajduje się pomiędzy specjalistą, który się na czymś zna, a odbiorcą i stara się w łatwy sposób przekazać jakieś trudne zagadnienia. 

Ta rola pojawia się w różnych dziedzinach, nie tylko w IT, ale też na przykład w produkcji czy w branży medycznej. W związku z tym, że my pracujemy od zawsze w IT, to najlepiej znamy tę rolę od tej strony.

Czy są polskie odpowiedniki? Są, ale według mnie nie najlepsze, więc głównie mówi się technical writer, ale można też spotkać się z określeniem autor techniczny lub specjalista do spraw dokumentacji technicznej. Czasami też dokumentalista, co nie jest najlepszym określeniem, bo kojarzy się z filmami dokumentalnymi. Paweł ukuł swój termin, którego chyba nikt poza nami nie zna, chociaż padł na antenie TVP2: technoskryba.

 

P.K.: Czasem ktoś napisze na LinkedInie w komentarzu.

 

Technoskryba – trochę nowoczesne, trochę z nutką przeszłości. Podoba mi się, fajne.

 

P.K.: Technical writer jest kimś, kto pisze, ale to rola pomiędzy UX writingiem, czyli pisaniem dla interfejsu, a UX designem, czyli projektowaniem tych aplikacji, trochę twarzą do użytkownika. Głównie musi się wykazywać umiejętnością kontaktu z użytkownikiem, rozumieć jego potrzeby. W ten sposób jest podobny do dziennikarza, który popularyzuje naukę. Czyli mamy fizyków, biologów, naukowców i mamy ludzi, którzy prowadzą blogi o nauce, kanały na YouTubie lub podcasty, zapraszają naukowców do swojego programu i opowiadają o tym. Technical writer jest kimś, kto zna framework, który firma sprzedaje i będzie pisał o tym frameworku. Oprócz instrukcji obsługi czy stron z referencją, może prowadzić bloga technicznego albo nagrywać filmiki instruktażowe.

 

 

Technical writer jest kimś, kto zna framework, który firma sprzedaje i będzie pisał o tym frameworku. Oprócz instrukcji obsługi czy stron z referencją, może prowadzić bloga technicznego albo nagrywać filmiki instruktażowe. 

 

 

To wszystko jest zależne od tego, gdzie się znajdujemy. Czy ten konkretny produkt jest bardzo poważny i jest do niego tylko wydrukowana książeczka złożona na szesnaście części, włożona do pudełka. Czy jest to coś consumer-facing w stałym użytku ze  społecznością na social mediach, kanałem na YouTubie związanym z tym produktem. Technical writer będzie się udzielał w takich miejscach.

 

Rozumiem. Gdy myślę o produkcie, o którym Pawle wspomniałeś, przychodzi mi na myśl, że to product manager czy też programiści, schodząc piętro niżej, to są osoby, które powinny znać ten produkt najlepiej i być w stanie oddać pewne niuanse i w ogóle opisać ten produkt. Dlatego pytanie do Was, skąd wynika potrzeba takiej osobnej roli, która by miała o tym produkcie od strony technicznej pisać. Osoby, która nie jest ściśle techniczną rolą, nie zajmuje się wytwarzaniem tego produktu sensu stricto na co dzień. Co do zespołu wnosi technical writer?

 

M.S.: Zanim zaczniemy od tego, kto powinien tworzyć i dlaczego technical  writer jest potrzebny w zespole, to napomknę o tym, co Paweł mówił. Dobrze jest wspomnieć o tym, że dokumentacja to nie jest tylko instrukcja obsługi, którą mamy czasami przed oczami. Mówiąc słowo dokumentacja widzimy opasłe tomisko, które spada na stół i kurz się podnosi do góry. Z biegiem czasu i z rozwojem technologii to znaczenie słowa dokumentacja bardzo się rozszerzyło. To może być tekst w interfejsie, webhelp lub error message, który pojawia się w programie albo tooltipy, które się wyświetlają. Fajnie, żebyśmy pamiętali w rozmowie, że mówiąc dokumentacja nie mamy na myśli stricte drukowanych instrukcji czy tradycyjnego podejścia, tylko to jest bardzo szerokie określenie. Pomoże nam to lepiej zrozumieć kto pisze i dlaczego powinien pisać daną część.

 

Moje doświadczenie jest takie, że często programiści mają bardzo specjalistyczną wiedzę na temat bardzo wąskiej dziedziny, fragmentu tego co robią, który się spina w całość. A technical writer opisując ten produkt całościowo jest pomostem, który łączy poszczególne jednostki i ma mniej specjalistyczną wiedzę, ale szerszą i jest w stanie połączyć fakty.

 

Jest też kwestia tego, że nie każdą dokumentację będzie pisał technical writer. Większy sens może mieć to, żeby programista pisał wewnętrzną dokumentację dla innych zespołów programistycznych. A technical writer będzie pisał dokumentację zewnętrzną dla klientów, dlatego że on nie ma tak specjalistycznej wiedzy, co może się wydawać negatywną rzeczą, ale jest pozytywem, bo dzięki temu zadaje pytania, które by zadał odbiorca. Ignorancja jest błogosławieństwem, dlatego jest to bardzo przydatna umiejętność i często programiści, którzy są tak blisko produktu i funkcjonalności tracą perspektywę. 

Wydaje im się, że pewne rzeczy są oczywiste, wszyscy wiedzą jak kliknąć, czego używać. Poza tym są emocjonalnie przywiązani do swojego produktu, bo go stworzyli i wydaje im się, że wszystko co powiedzą ma znaczenie dla użytkownika. Tyle wysiłku włożyli, zrobili cudeńko technologiczne, które jest super i trzeba wszystkim o tym powiedzieć. To nie zawsze tak jest, odfiltrowanie informacji jest tu bardzo istotne. Odbiorcę nie zawsze interesuje to, jak to jest zaimplementowane, czasami wystarczy kilka zdań, jak kliknąć tu czy tam. Taka rola jest wartościowa, bo potrafi po pierwsze agregować informacje, po drugie odfiltrowywać te informacje, a po trzecie postawić się w roli użytkownika i z tej perspektywy przedstawić informacje, które są potrzebne.

 

P.K.: Uzupełniając to, co mówisz, Michał, perspektywa technical writera jest bardzo ważna, ale są jeszcze dwie rzeczy poboczne, które też mają znaczenie . Pierwsza to jest najlepsze spożytkowanie czasu. Najlepsze spożytkowanie czasu programme managera, project managera to jest zarządzanie projektem, produkcją. Najlepsze spożytkowanie czasu programisty to pisanie kodu czy inne tego typu zajęcia, podobnie tester, UX designer, każdy ma swoje cele. Jeżeli mamy dużo wiedzy do przekazania, to warto jest wyodrębnić osoby, które będą po prostu pisały o produkcie i ich czas będzie pożytkowany na pisanie.

Poza tym pisanie to też umiejętność, to że ktoś potrafi pisać kod, to nie znaczy, że potrafi pisać do ludzi. Ktoś może pisać za dużo albo za mało. To jest w pewnym sensie kwestia perspektywy. Jeżeli wprowadziłem ulepszenia do tego, jak jest realizowany jakiś protokół, to napisze całą stronę o tym protokole, czego użytkownik w ogóle nie potrzebuje. Ta perspektywa i umiejętności pisania pozwolą tech writerowi zdecydować, żeby nie pisać o tym, napisać o tym mniej albo położyć to w innym miejscu. 

Poza tym samo pisanie to nie wszystko, są inne zdolności związane z technical writingiem, takie jak architektura informacji, czy jak coś ułożyć, w jakiej kolejności, w jakich miejscach, jakie podstrony może mieć nasza strona, jak to sprawdzić, jak sprawdzić czy te strony są odpowiednie, jak porozmawiać z użytkownikami, żeby się dowiedzieć, co ich boli i czego potrzebują. To jest cały wachlarz umiejętności, których inne grupy w IT nie mają, bo nie potrzebują ich. A tym się zajmuje właśnie technical writer.

 

Poza tym samo pisanie to nie wszystko, są inne zdolności związane z technical writingiem, takie jak architektura informacji, czy jak coś ułożyć, w jakiej kolejności, w jakich miejscach, jakie podstrony może mieć nasza strona, jak to sprawdzić, jak sprawdzić czy te strony są odpowiednie, jak porozmawiać z użytkownikami, żeby się dowiedzieć, co ich boli i czego potrzebują. To jest cały wachlarz umiejętności, których inne grupy w IT nie mają, bo nie potrzebują ich. A tym się zajmuje właśnie technical writer. 

 

Rozumiem, czyli technical writer wnosi swoje specyficzne umiejętności do zespołu, wzbogacając cały zestaw umiejętności, który w tym zespole jest. Pawle, powiedziałeś o umiejętności pisania, bardzo ważna umiejętność, myślę, że jeszcze nie raz dzisiaj do niej wrócimy. Ale technical writer, który jest w tym zespole, musi skądś czerpać wiedzę na temat produktu, mniej lub bardziej technologicznych aspektów, zawiłości tego produktu. Musi współpracować z innymi członkami zespołu, nie jest osamotnioną wyspą. Chciałbym Was zapytać, jakie najlepsze praktyki albo jakie zasady współpracy z programistami, testerami, product managerami stosujecie w swojej pracy, które się sprawdzają i pozwalają Wam być na bieżąco z rozwojem produktu?

 

M.S.: Mówiąc z doświadczenia, ja zawsze starałem się przyjąć taką strategię, że jak trafiałem do zespołu, który zajmował się jakimś produktem, starałem się maksymalnie integrować z tym zespołem. Nie stawiałem siebie w sytuacji, gdzie przychodzę jako technical writer i mówię: „Wy zrobiliście swój produkt, teraz mi powiedzcie co zrobiliście, a ja o tym napiszę, żeby użytkownik wiedział, jak tego używać”. Starałem się być rzeczywiście częścią zespołu, gdzie siedzieliśmy razem w jednym miejscu. To jest prosty aspekt, ale wiele ułatwia, bo spędzamy czas razem – kiedy jeszcze biura były pootwierane i można było siedzieć w normalnych warunkach. To bardzo ułatwia pracę, bo widzimy się na co dzień, rozmawiamy nawet o bzdetach, ale to buduje więź, która powoduje, że komunikacja jest łatwiejsza.

Po drugie, starałem się też patrzeć, jak programiści pracują, jakich narzędzi używają albo gdzie trzymają kod źródłowy. I nawet z ciekawości starałem się zawsze kod źródłowy przejrzeć, zobaczyć co tam się dzieje, jaki to język programowania, jakie funkcje ma ten produkt. Starałem się też używać takich narzędzi, jakich oni używają. Oczywiście narzędzia do zgłaszania tak zwanych ticketów czy ich IDE, z którego korzystali. 

Starałem się bardzo mocno integrować, a robiłem to w takim celu, że kiedy trafiała do mnie na przykład prośba o opisanie czegoś, to moim pierwszym ruchem było zajrzenie do kodu, otworzenie tego w IDE i zrozumienie, co się tu zmieniło. Robię wstępny research, takie zadanie domowe i dopiero wtedy, kiedy utknę, mając opis takiego ticketa, co się zmieniło, patrząc w Gicie na zmiany, na kod źródłowy i na Unity Testy jestem w stanie wywnioskować, jaka funkcjonalność została wprowadzona i co ona robi. 

Po takim wstępnym researchu, jeśli mam jakieś pytania albo czegoś nie rozumiem, zaczynam rozmawiać z programistami. Okazuje się, że wtedy ta rozmowa jest dużo łatwiejsza. Oni widzą, że ja szanuję ich czas, bo zrobiłem to co mogłem we własnym zakresie i nie zadaję trywialnych pytań, na które odpowiedź można znaleźć w bardzo łatwy sposób. Po drugie widzą, że ja rozumiem techniczne zagadnienia i staję się równym partnerem do rozmowy. 

To jest część techniczna, ale pozostaje jeszcze część biznesowa, czyli nie jak co działa, ale po co w ogóle to jest. To jest bardzo ważna rzecz, od której często trzeba zacząć, czyli opisać, że ta funkcjonalność pozwala ci zrobić to i to po to, żebyś mógł zrobić to i to. Klienta przede wszystkim interesuje po co tego używać albo po co to jest, a nie jak. Jak, to wiadomo, ale najpierw trzeba wiedzieć po co. Tutaj wchodzi rola product managera, analityka biznesowego, w zależności od firmy czasami może to być jeszcze inna rola, o innej nazwie. 

Staramy się pytać, samemu grzebać, brudzić sobie ręce i rozmawiać, czyli funkcjonować w tej grupie. Jest to proces skomplikowany, nie jest linearny, często trzeba wracać, każdy ma swoje strategie. Według mnie kluczowe jest zbudowanie wspólnej więzi między osobami w projekcie i wzajemnego szacunku oraz pokazania tego, że się chce i nam zależy na tym, żeby też coś dać od siebie.

 

P.K.: Kontynuując wątek więzi i kontaktu z różnymi rolami w projekcie, dodałbym jeszcze, że rolą technical wrtitera może być wskazanie i zbudowanie wartości dokumentacji w produkcie. Produkt można zacząć z takim pomysłem, że musimy mieć dokumentację, bo jest wymagana, w kontrakcie jest napisane, że ma być. Technical writer może popatrzeć na potrzeby użytkownika i doradzić, gdzie ta dokumentacja ma być i na przykład odkryć, że skoro wypuszczamy co miesiąc nową wersję, przydałoby się wysłać maila do użytkowników i wylistować nowe funkcjonalności. Bierze na siebie prowadzenie takiego miesięcznego newslettera. 

Kiedy jest w stanie zbudować wartość dokumentacji, to ma wpływ na product ownerów i project managerów, ludzi, którzy zarządzają projektem. Oni wtedy mają w głowie takie okienko do zapełnienia, guzik do naciśnięcia, że przyda się do tego jeszcze dokumentacja. Wychodzi nowa funkcjonalność i oni myślą o tym, żeby ją udokumentować. Mogą wpadać też na takie pomysły, na jakie wpada technical writer. Skoro piszemy o tym, może dodajmy demo. Technical writer i dowolny inny członek zespołu może to zaproponować, jeżeli dokumentacja jest na widoku i za każdym razem o niej rozmawiamy i myślimy o tym, jak pomóc użytkownikowi.

 

Jasne.

 

P.K.: Dobrym przykładem tutaj jest coś, co się stosuje we frontendowych frameworkach, na przykład Storybook, gdzie mamy te przykłady komponentów. Jak go użyć, jak efektywnie będą te przykłady napisane? To jest częściowo praca technical writera. Nie wystarczy zrenderować wszystkich opcji przycisku, tylko może ten przycisk w jakimś kontekście, w jakimś przykładzie jak ma działać.

 

Ciekawa sprawa, nigdy o tym nie myślałem w ten sposób, ale teraz przyszło mi na myśl, że technical writer może przyczyniać się do utrzymania i podnoszenia jakości produktu poprzez tego typu działania. To jest trochę side effect jego działalności, wartość dodana. Testerzy nieraz mogą się skupiać jedynie na danych ficzerach, czy powiedzmy na jakiejś wąskiej funkcjonalności, natomiast technical writer może mieć wysokopoziomowe spojrzenie z punktu widzenia użytkownika, którego nikt w zespole nie ma. Ciekawy dodatek do działania całego teamu.

 

P.K.: Mam to szczęście, że udało mi się kilka razy być w projekcie, gdzie dało się to tak zrobić, udało się wejść w całą tę tkankę zespołu i zbudować wartość dokumentacji. Niestety, nie ukrywajmy, często rzeczywistość jest taka, że dokumentacja jest na szarym końcu, jako zło konieczne. 

 

Po części może być tak dlatego, że odpowiedzialność za dokumentację spoczywa na osobach, które być może powinny być zaangażowane w inne działania, na przykład na programistach, czy na PM-ach. Osoba tech writera może przejmować te obowiązki, jednocześnie wypełniając je lepiej, niż gdyby to spoczywało na kimś innym. Wtedy ta dokumentacja może być też prowadzona na bieżąco.

Dużo mówimy o IT, bo to jest temat naszego dzisiejszego podcastu, ale Michał na początku powiedział, że tech writer to nie tylko IT, to tylko jedna ze specjalizacji. Może wyjdźmy trochę szerzej wobec tego. Jakie jeszcze firmy zatrudniają tech writerów? Kiedy ten zawód się w Polsce pojawił? Jest to stosunkowo nowa rzecz. Z Waszego doświadczenia, kiedy jest ten moment, w którym firma decyduje, że potrzebuje mieć takie stanowisko? Jakie elementy wpływają na to, że takie stanowisko jest powoływane w firmie?

 

M.S.: Bardzo dużo pytań zapakowałeś w jedno w pytanie. Pytałeś w jakich branżach występuje ten zawód. Poza IT, które jest obecnie najpopularniejszą branżą w jakiej ten zawód się ujawnia albo przynajmniej jest najbardziej widoczny, jest też branża AGD i RTV. Nie wiem, czy mogę tutaj wspomnieć konkretne firmy, ale jest duża firma w Krakowie, która zatrudnia takie osoby do pisania instrukcji do urządzeń gospodarstwa domowego. Często się też pojawia w firmach produkujących autobusy. Mają osoby, które pracują przy linii produkcyjnej i tworzą instrukcje do autobusów lub ich części. Branża militarna też ma takie osoby, branży lotnicza również. 

Zanim sam zostałem technical writerem, miałem taką przygodę jako tłumacz, gdzie tłumaczyłem instrukcję obsługi do samochodu osobowego. I byłem ciekawy, kto pisze instrukcje do takiego samochodu. Kiedyś może bardziej niż teraz, ale byłem dużym fanem branży motoryzacyjnej. Marzyła mi się praca w niej, myślałem, że może mógłbym pisać instrukcje do takich samochodów, ale się nie udało. To są te branże, które mi przychodzą do głowy.

Kolejne pytanie brzmiało, od jak dawna ten zawód istnieje w Polsce. Trzeba by tu wspomnieć o dwóch rzeczach. Pierwsza to jest od jak dawna istnieje, a drugie, od jak dawna ludzie są świadomi tego, że istnieje, nawet ci, którzy pracują w tej branży. Przez ponad pięć lat prowadziłem portal Techwriter.pl wraz z innymi osobami i zdarzało nam się dostawać maile od ludzi, którzy mówili, że są technical writerami, a nie wiedzieli, że to się tak nazywa. Od dziesięciu lat pisali dokumentacje i nie wiedzieli, że ich zawód tak się nazywa. 

Często świadomość tego nazewnictwa, tego że się przynależy do większej grupy zawodowej, jest jaka jest. Ale w ostatnich latach bardzo się to zmieniło w Polsce. Odpowiadając krótko, jest to w miarę młoda branża na tle na przykład Stanów Zjednoczonych czy krajów Europy zachodniej, przez co średnia wieku osób pracujących u nas w zawodzie – przynajmniej z tego, co my zaobserwowaliśmy, nie mamy twardych danych – jest niższa niż osób, które w Stanach pracują w tej branży.

 

Przez ponad pięć lat prowadziłem portal Techwriter.pl wraz z innymi osobami i zdarzało nam się dostawać maile od ludzi, którzy mówili, że są technical writerami, a nie wiedzieli, że to się tak nazywa. Od dziesięciu lat pisali dokumentacje i nie wiedzieli, że ich zawód tak się nazywa. Często świadomość tego nazewnictwa, tego że się przynależy do większej grupy zawodowej, jest jaka jest. Ale w ostatnich latach bardzo się to zmieniło w Polsce. 

 

P.K.: Branża IT czy branża tworzenia oprogramowania, można by powiedzieć, jest taką młodą branżą w ogóle, ale jest też młodą branżą w Polsce i technical writer pojawia się u nas raczej w kontekście tej branży. To określenie po prostu nie było używane odnośnie, tak jak Michał mówił, ludzi pracujących w przemyśle ciężkim czy w produkcji. Takie osoby to byli często technicy utrzymania jakości albo kontroli jakości, czyli osoby, które są w łańcuchu produkcyjnym, ale nie mówimy na to technical writer. 

 

W Niemczech albo w krajach anglojęzycznych podobnie brzmiący termin funkcjonuje od dziesięcioleci, odkąd się wyspecjalizowała produkcja. W krajach zachodnich są kierunki uniwersyteckie, które kształcą ludzi do wykonywania tego zawodu, są certyfikaty. U nas jest tego mniej, certyfikaty istnieją od niedawna, są studia podyplomowe, czasem przedmioty na kierunkach typu lingwistyka stosowana nazywane pisaniem technicznym lub pisaniem biznesowym. Ale jest to stosunkowo młoda branża. 

Kiedy ja zaczynałem w 2008 roku to było nas Polsce, takich ludzi, którzy się nazywali technical writerami, bardzo mało. Pojawiło się takie stowarzyszenie, które przez kilka lat funkcjonowało, i na spotkaniach było dziesięć, dwadzieścia osób maksymalnie. Teraz, jeszcze przed pandemią, jak była konferencja technical writerów, to było na niej około dwustu osób. Takie doroczne konferencje naprawdę zgromadziły dużo uczestników i cieszyły się powodzeniem i zainteresowaniem.

 

M.S.: Chciałbym dodać, a propos tego, że branża jest dosyć młoda, że Techwriter.pl już chyba piąty rok z rzędu będzie przeprowadzał badanie płac wśród technical writerów. Liczba respondentów nie jest bardzo duża, ponad sto osób bierze udział w tym badaniu, ale wyniki z zeszłego roku prezentują się tak, że 14,4 procent osób odpowiedziało, że pracuje dłużej niż dziesięć lat, czyli niewiele. 21,6 procent osób pracuje między sześć a dziesięć lat. Najliczniejsza grupa to trzy do pięciu lat  – 38,7 procenta. I staż od zera do dwóch lat to jest 25,2 procenta. Jak widać, branża relatywnie młoda, jeśli chodzi o staż pracy.

 

Jak całe IT, to jest generalnie młoda branża. Potrafię sobie wyobrazić, że w tradycyjnym przemyśle, o którym trochę powiedzieliście, ta rola już się w miarę umościła i znalazła swoje zastosowanie. Jeśli ktoś otwiera nową fabrykę, firmę, która produkuje na przykład sprzęt AGD, to raczej planuje, że taka rola musi się znaleźć gdzieś w łańcuchu wytwórczym. Ale w IT jest różnie. Jak popatrzymy na przykład na startupy, które powstają, rosną, to jeśli nabierają odpowiedniej masy, być może pojawia się konieczność powołania takiej roli. Jak wynika z Waszego doświadczenia, czy to staż, wiek, zaawansowanie firmy wpływa na to, że takie role są powoływane? Czy są jeszcze inne czynniki, które motywują do tego, żeby zatrudniać tech writerów?

 

M.S.: Powiedziałbym, że są dwa czynniki, które decydują o tym, czy dokumentacja jest potrzebna i czy potrzeba do niej wydzielonej roli. Po pierwsze sam produkt determinuje, czy dokumentacja będzie potrzebna. Nie ma co na siłę pisać rozbudowanej dokumentacji do produktu, który głównie jest przeznaczony dla przeciętnych użytkowników końcowych, nie jest wysoce wyspecjalizowany i interfejs jest bardzo dobrze zaprojektowany. Więc ta dokumentacja może być naprawdę minimalna i programista jest w stanie ją obsłużyć, napisze jakąś krótką specyfikację techniczną na potrzeby wewnętrzne. Na przykład dokumentacja do API, bo to API jest relatywnie niewielkie, a to co widzi użytkownik jest tak proste i intuicyjne, że nie wymaga opisu.

Często jest też tak, będę trochę demonizował, że o dojrzałości organizacji świadczy fakt, czy chce taką dokumentację tworzyć w sposób właściwy, bardziej usystematyzowany. Miałem takie doświadczenia, że często firmy taką potrzebę zgłaszały zdecydowanie za późno. Firma żyła własnym życiem, miała produkt, który wcale nie był prosty. Jakaś dokumentacja sobie hulała po firmie w takiej czy innej formie, na przykład trzystustronicowego PDF-a, do którego ktoś coś dopisywał przy nowym releasie jak znalazł chwilę albo i nie. Nagle przychodził klient z dużymi pieniędzmi i mówił: „Dobra, to ja ten produkt kupię, ale gdzie jest dokumentacja?”. I wtedy się zaczyna panika i szukanie na gwałt osoby, która to ogarnie. A niestety proces kompleksowego ogarnięcia dokumentacji, nie jest procesem krótkim, łatwym i przyjemnym. Wymaga on też czasu i oczekiwania są bardzo wygórowane. Niestety takie sytuacje też mają miejsce. 

Niektóre firmy też rychło w czas decydują się, że trzeba coś z tym zrobić, bo dokumentacja może być postrzegana nie tylko jako produkt posprzedażowy, czyli my już komuś sprzedajemy produkt i ta osoba wymaga, że ta dokumentacja musi być, ale też jest takie podejście, że dokumentacja może mieć wpływ na samo sprzedawanie produktu. Jeśli mamy dobrą dokumentację, którą udostępniamy użytkownikom w sposób otwarty, to potencjalny klient może w niej znaleźć również wiele informacji, które skłonią go do tego, żeby ten produkt kupić, albo stwierdzić, że on jest lepszy od produktu konkurencyjnego, bo znajdzie w nim szczegóły techniczne, które go interesują. Więc jest to bardzo wielowymiarowe pytanie i z takiej strony też można do niego podejść.

 

P.K.: To jest fajne, co mówisz o sprzedaży przy pomocy dokumentacji. Był kiedyś startup, który miał mniej niż dziesięć osób i tuż przed tym, jak wypuścili swój produkt, szef startupu zatrudnił dosłownie trzy osoby – byłem jedną z nich, dlatego opowiadam tę historię – żeby napisać dokumentację, która w dniu publikacji oprogramowania miała być dostępna i miała zachęcać ludzi do używania. Cała idea tego startupu miała być taka, że ten program zastąpi produkt X, który jest znany na świecie. Żeby mógł zastąpić, to musieliśmy odpowiednio szybko, łatwo onboardować nowych użytkowników i wpuścić ich w nasz ekosystem. To było fajne podejście, bo to był startup, który jeszcze nie miał nic na rynku, a już chcieli mieć tę dokumentację zrobioną jak najlepiej. 

Z drugiej strony tego medalu są firmy, które są ogromne i mają na przykład stuosobowe zespoły technical writerów. To jest fantastyczne, bo to jest zawsze dobrze zorganizowane, naoliwiona maszyna, która pompuje dokumentację w świat. Natomiast ma to też swoje wyzwania, na przykład tej dokumentacji jest za dużo, albo dużo jest zastałych rzeczy i ciężko byłoby je poprawić, bo cały czas jest bieżąca praca. Każdy kij ma dwa końce.

Natomiast jeśli chodzi o sprzedawanie za pomocą dokumentacji, to chciałbym podać taki przykład z obecnego rynku oprogramowania, nie chcę reklamować, ale jest taki framework Next.js. Firma Vercel, która to wypuściła, w pewnym sensie sprzedaje swoje usługi hostowania za pomocą tego Next.js-a. Jest to fajne narzędzie, którego każdy może użyć i jest do niego dokumentacja, żeby ludzie mogli zacząć. W sekcji deployment jest napisane najlepsza opcja Vercel hosting, tutaj mamy skrypty już zaszyte w Next.js-ie, trzeba tylko wpisać komendę i się deplojuje. Czyli to jest też super sposób na wprowadzenie ludzi do lejka sprzedaży.

 

Chwilę porozmawiajmy o tym, jak zostać taką osobą. Jest to, mam wrażenie, taka rola interdyscyplinarna, że trzeba wiele różnych umiejętności posiadać. W związku z tym, ciężko mi sobie wyobrazić jakiś kierunek kształcenia, który by bezpośrednio dawał wszystkie skille potrzebne w tym zawodzie. Ale może się mylę. Czy w Polsce mamy jakieś możliwości kształcenia się w zawodzie? Jakbyście mogli powiedzieć ogólnie, co byście polecali na start, w jaki sposób zostać taką osobą w zespole?

 

M.S.: Znowu pytanie napakowane pytaniami. Zacznijmy od tego, jak można zostać technical writerem. Ja znam dwie najbardziej popularne ścieżki, które prowadzą do tego zawodu. Ta bardziej popularna to jest osoba z wykształceniem lingwistycznym, czyli mój przykład. Ukończyłem pięcioletnią magisterską anglistykę ze specjalizacji tłumaczenie, a później trafiłem do firmy na helpdesk i tak już się moje życie potoczyło w kierunku IT. Tak mi się spodobało łączenie języka z IT, że zostałem i byłem przez osiem lat technical writerem. Teraz już więcej koduję niż piszę. To jest taka ścieżka, którą ja znam najlepiej i z którą najczęściej się spotykam.

Druga opcja osoba, która ma wykształcenie techniczne, czyli na przykład studiowała nauki związane z komputerami, informatykę. A później decyduje się tego języka douczyć jako drugą umiejętność i też pisze dokumentacje. Takie przypadki też obserwowaliśmy na zachodzie, gdzie osoby z dużym stażem programistycznym, czy też w pracy technicznej, decydowały się na przejście na stanowisko technical writera. Może żeby coś zmienić albo nie było już tylu programistów potrzebnych w projekcie, więc decydowali się na przebranżowienie. To jest dużo mniej popularna ścieżka, od razu mówię i rzadko się z nią spotykam.

 

P.K.: Ona jest może mniej popularna w Polsce i to jest też ciekawa sprawa, bo technical writer często pisze po angielsku, to jest najczęściej spotykane. Więc jeżeli ktoś w Polsce ma zostać technical writerem, musi znać język na naprawdę wysokim poziomie. Kiedy czytamy dokumentację, nie może być widać, że została ona napisana przez osobę, dla której jest to drugi język. Żeby to nie było takie oczywiste na pierwszy rzut oka. 

Natomiast na zachodzie, tak jak Michał mówiłeś, wszelkie branże nowoczesnych technologii, w tym oprogramowanie i IT, są przesycone. Nie jest to wcale takie dziwne, że człowiek po studiach technicznych mógłby się chcieć zajmować pisaniem o technologii. Może jego pasją jest pisanie, ten język naturalnie już ma, jeszcze tylko kwestia innych umiejętności, które są potrzebne w tej dyscyplinie.

 

M.S.: Dobrze Paweł, że doprecyzowałeś. My mówimy ze swojej perspektywy, czyli osób, które urodziły się i mieszkają w Polsce, które studiowały w Polsce i które pracują w firmach, gdzie językiem urzędowym jest angielski. My patrzymy ze swojej, dość wąskiej, perspektywy. 

Wracając do pytania, jakie umiejętności są potrzebne. Miałem kiedyś taką prezentację na temat zawodu tech writera, którą przeprowadziłem nawet na studiach u koleżanki dla jednej z grup. Podzieliłem to na trzy rzeczy, umiejętności interpersonalne, charakter i wiedza techniczna. Jeśli chodzi o charakter, to na pewno potrzebna jest dociekliwość, dokładność i cierpliwość, to są cechy, które warto mieć. Umiejętności interpersonalne, to oczywiście praca zespołowa i komunikatywność, o tym już mówiliśmy, czyli osoba, która nie jest w stanie dobrze się komunikować z innymi osobami w zespole, będzie miała ciężko, bo chociażby zdobywanie wiedzy staje się trudne. Jeśli chodzi o wiedzę techniczną, to różnie z tym bywa.

Są role, gdzie wymaga się tej wiedzy technicznej na bardzo wysokim poziomie. Widzieliśmy ogłoszenia, gdzie właściwie szukało się programisty z umiejętnością pisania, ja bym to tak podsumował, czyli takiego jednorożca. Chciało się, żeby ta osoba znała języki programowania, świetnie mówiła po angielsku, miała lekkie pióro i wszystko zrobiła. Pojawiają się też takie ogłoszenia. Często wiedza techniczna, jakiej się oczekuje, jest pomiędzy ekspertem a użytkownikiem. Czyli znamy, rozumiemy produkt, umiemy o nim mówić w sposób właściwy, ale nasza wiedza nie jest zbyt duża, żebyśmy nie mieli za dużo założeń. Często jest tak, że osoby rekrutujące bardziej stawiają na umiejętności miękkie plus umiejętności językowe i zakładają, że ten stan wiedzy technicznej da się łatwo uzupełnić. Jako technical writer, ja nie muszę umieć programować, muszę rozumieć, co jest napisane, ale sam kodu nie muszę umieć pisać. Dużo łatwiej jest taką osobę przyzwyczaić, takie umiejętności nadrobić, niż nauczyć jej świetnego angielskiego w ciągu dwóch miesięcy. To jest trudniejsze zadanie. Więc to są takie zestawy umiejętności.

 

Często wiedza techniczna, jakiej się oczekuje, jest pomiędzy ekspertem a użytkownikiem. Czyli znamy, rozumiemy produkt, umiemy o nim mówić w sposób właściwy, ale nasza wiedza nie jest zbyt duża, żebyśmy nie mieli za dużo założeń. Często jest tak, że osoby rekrutujące bardziej stawiają na umiejętności miękkie plus umiejętności językowe i zakładają, że ten stan wiedzy technicznej da się łatwo uzupełnić.

 

I ostatnia część pytania, czyli gdzie taką wiedzę można nabyć, jak chce się zostać technical writerem. Doczekaliśmy się w Polsce po wielu latach pierwszych studiów podyplomowych z komunikacji technicznej, które są dostępne na prywatnej uczelni Vistula i chyba we Wrocławiu był kierunek dostępny, ale nie wiem, jak teraz. Wiem, że dopiero w zeszłym roku wystartowała pierwsza edycja tych studiów podyplomowych. Były dostępne od kilku lat, ale grupa nie mogła się zebrać. Dla osób, które chciałyby uzupełnić swoją edukację w tym kierunku w sposób bardziej oficjalny w Polsce już jest to możliwe.

Drugą opcją jest dwudniowy kurs ITCQF, który kończy się certyfikatem. Tutaj często rysuje się analogię pomiędzy ISTQB. Jeśli ktoś jest zaznajomiony z testerskim certyfikatem, to ten ITCQF został stworzony dla ekspertów z komunikacji technicznej, czyli na przykład technical writerów i jest analogiczny do tamtego, kończy się oficjalnym certyfikatem. Taki kurs można zrobić i na pewno fajnie to w CV może wyglądać. 

Plus wszystkie nieformalnie źródła wiedzy. Mamy książki, jest dużo literatury, przeważnie zagranicznej. Blogi również głównie zagraniczne, po angielsku, jeśli chodzi o komunikację techniczną. W Polsce mamy ten jeden wspomniany portal: Techwriter.pl. Meetupy, na przykład MeetContent w Polsce, gdzie mamy serię meetupów. Co roku odbywa się jedyna polska konferencja techcomowa Soap, dużego kalibru. Bardzo polecamy. Podcasty też głównie zagraniczne, nie chcę za dużej autoreklamy robić, ale nasz to jest jedyny chyba z komunikacji technicznej po polsku. Dużo jest materiałów dostępnych w sieci, oczywiście po angielsku, jeśli chodzi o komunikację techniczną i technical writing.

 

Może możecie się pochwalić albo podzielić z jakich źródeł Wy korzystacie. Powiedziałeś, Michał, o wielu różnych dostępnych materiałach. Natomiast na Waszym już poziomie, z czego korzystacie, żeby poszerzać swoją wiedzę dwukanałowo. Z jednej strony mamy te umiejętności posługiwania się słowem technicznym, a z drugiej strony wiedzę domenową, trochę związanym z technikaliami, z programowaniem, z produktem. Z czego Wy korzystacie na co dzień, żeby poszerzać swoją wiedzę z tych obszarów?

 

M.S.: Ja przyznam się od razu, że w ostatnim roku albo dłużej korzystam głównie z materiałów związanych z programowaniem w Phytonie, Java Scripcie, czy też związanych w ogóle z pracą w roli DevOpsa. Moja rola wymaga ode mnie wiedzy z zakresu technologii chmurowych, na przykład Docker, Kubernetes, Kotlin, JavaScript, Phyton. Więc ja się obracam głównie w materiałach typu szkolenia online na LinkedIn Learning albo artykuły na przykład na Real Phyton, to jest taki super portal. Ale tak jak mówię, to jest wszystko związane bardziej z programowaniem i z tą wiedzą, której przeciętny technical writer nie potrzebuje.

Jest taka książka, którą zawsze bardzo polecałem na początku, ona się nazywała Technical Writing 101 wydana przez Scriptorium Publishing. Była nawet dostępna za darmo w formacie EPUB w Internecie, można było sobie pobrać. To jest świetna według mnie pozycja na sam początek, jak chcemy zacząć, poczytać o technical writingu. To była fajna opcja. Była też bardziej nowoczesna książka The Product Is Docs od firmy Splunk. Jest też bardzo króciutka książka, chyba czterdziestostronicowa, którą napisał technical writer z Amazona w Stanach, nazywa się Modern Technical Writing i on pisze o takim nowocześniejszym podejściu do tematu.

Te wszystkie podcasty, o których wspominałem to też jest źródło wiedzy, a jeśli chodzi o blogi, to nie będę oryginalny, bo jest taki bardzo popularny blog zagraniczny I’d Rather Be Writing Toma Johnson, który jest jedną z najbardziej znanych osób w branży techcomu, przynajmniej tego międzynarodowego. No i portal Techwriter.pl w Polsce, zdecydowanie polecam, żeby tam zaglądać, jeśli chcemy w polskich realiach łyknąć polskiego contentu, to też tam warto zajrzeć.

 

P.K.: Nie mam tutaj dużo do dodania, chciałbym tylko jeszcze raz polecić ten blog I’d Rather Be Writing, bo akurat dla mnie konkretnie, profil autora jest bardzo podobny do mojego, czyli do tego czym się obecnie zajmuję. Prowadzi podobną  dokumentację i zawsze znajdę jakieś fajne rady tam. A jest to blog, który podchodzi też holistycznie do tematu dokumentacji, czyli nie zajmuje się na przykład tylko tworzeniem strony z dokumentacją i deplojowaniem tej strony, ale na przykład pisze o procesie badania efektywności dokumentacji, którą napisaliśmy i to jest coś czym się ostatnio zajmowałem w pracy. Także naprawdę polecam, takie wszechstronne spojrzenie na nowoczesną dokumentację.

 

M.S.: Chciałem jeszcze wspomnieć o takich źródłach jak konferencje, bo w Polsce mamy tylko naszego Soapa, ale normalnie są publikowane nagrania z prezentacji, na YouTube są one otwarte, nie trzeba się nawet logować ani za to płacić. Te prezentacje są do obejrzenia za darmo. Jest też społeczność Write the Docs, która jest międzynarodowa i powstała w Stanach, ale rozszerzyła się na inne kraje Europy. Mamy na przykład konferencję Write the Docs w Pradze, która się odbywała co roku. Świetna konferencja i oni też mają dużo nagrań na YouTubie, jeśli chodzi o prezentacje, które tam miały miejsce. Poza tym oni organizują też meetupy online. Ostatnio był taki meetup, organizowany przez litewski oddział Write the Docs, w którym mój znajomy miał okazję prezentować na temat tego, co się dzieje w komunikacji technicznej w Polsce. Jest bardzo dużo lokalnych grup Write the Docs i one też zrzeszają dużo ludzi z różnych krajów.

Jest na przykład taka inicjatywa API the Docs, to jest jakby rozszerzenie Write the Docs i oni chyba są w Amsterdamie głównie, te osoby, które się tym zajmują. Teraz wystartowała gdzieś seria takich meetupów na temat dokumentacji do API, co jest bardzo gorącym tematem, więc można się zapisać, za darmo uczestniczyć, tam na pewno jest masa cennej wiedzy. Write the Docs też jest dużą społecznością, oni mają swój kanał na Slacku, kanał to złe słowo – workspace, który jest przeogromny, tam jest pięć albo sześć tysięcy ludzi. Sporo osób, więc ciężko nadążyć z tymi wszystkimi kanałami, co tam się dzieje. Polecam w ogóle Write the Docs, jak społeczność.

 

Fajnie, czyli tych materiałów, tych źródeł jest bardzo dużo i myślę, że nikt już nie może mieć wymówek, że nie jest w stanie się tego zawodu, tej roli nauczyć. Mówimy trochę o posługiwaniu się słowem, powiedzieliście, że lekkie pióro to jest jedna z pożądanych umiejętności dla tech writera. Zastanawiam się na ile copywriting też jest ważną umiejętnością. Czy to jest ten sam typ copywritingu, jaki na przykład jest wymagany wśród marketingowców, którzy powinni w jakiś sposób sprzedawać, przyciągać tym językiem, zwięźle opowiedzieć o jakiejś idei, pomyśle, produkcie. Czy w przypadku tech writerów to również jest ten typ copywritingu, którego używacie na co dzień? Czy może korzystacie z nieco innych typów? Mimo wszystko copywrtiting jest ważny w Waszej codziennej roli?

 

M.S.: Moje doświadczenie jest takie, że o wszystkim, czego nauczyli mnie w szkole na temat kreatywnego pisania musiałem zapomnieć, bo wszelkie ozdobniki językowe, upiększenia, albo zasada nie powtarzania tego samego słowa w dwóch zdaniach po sobie – to się nie do końca sprawdza w komunikacji technicznej. Jeśli chodzi o pisanie szeroko pojętej dokumentacji do produktu, to nacisk kładziemy na łatwy, jasny i przejrzysty język, który najlepszy jest na poziomie późnej klasy szkoły podstawowej, można by tak uprościć. 

Musimy założyć jedną rzecz, wiele osób, które korzystają z dokumentacji po angielsku, to są w większości osoby nie urodzone z tym językiem. One nabyły język angielski jako drugi, więc musimy brać pod uwagę, że ich poziom rozumienia tego języka, może odbiegać od poziomu native speakera. Używając wyszukanych słów, czy ozdobników językowych możemy tylko zaciemnić obraz, dlatego jest to trochę taki suchy język. Stawia się na proste, krótkie zdania, obdarte ze wszystkich ozdobników, które nawet czasami dobrze, żeby powtarzały pewne stwierdzenia, żeby była jasność, że mówimy o tym elemencie, a nie o innym. Ja nie mówię o tym, że to ma być kwadratowy język i ciężki do czytania, ale musimy uważać na to, jak piszemy, szczególnie jeśli ta dokumentacja jest później tłumaczona na inne języki, to różne rzeczy później trudno się tłumaczy w innych językach. 

 

Używając wyszukanych słów, czy ozdobników językowych możemy tylko zaciemnić obraz, dlatego jest to trochę taki suchy język. Stawia się na proste, krótkie zdania, obdarte ze wszystkich ozdobników, które nawet czasami dobrze, żeby powtarzały pewne stwierdzenia, żeby była jasność, że mówimy o tym elemencie, a nie o innym. 

 

Dlatego też pisanie jasne i przejrzyste, to jest jeden element, a jak jeszcze dochodzi element, że to jest tłumaczone, to wiele innych zasad dochodzi. Dlatego często tworzy się style guide’y wewnętrzne, Microsoft ma swój style guide, który jest kanonem w tej dziedzinie, inne firmy też mają swoje wskazówki. Często tworzy się swoje rozwinięcia tych standardów, albo jakieś swoje zasady, na przykład, że tutaj nie stawiamy kropki, a tutaj dajemy przecinek. Staramy się, żeby to było jednolite. 

Pytałeś o copywriting, ja osobiście w swojej karierze technical writingu nie miałem potrzeby pisania żadnych materiałów promocyjnych, albo takich z pogranicza marketingu, gdzie copywriting by się przydał, a wręcz moje doświadczenie jest takie, że jest to totalnie oddzielna umiejętność. To są dwie osobne branże, które w moim odczuciu i doświadczeniu się nie zeszły raczej  w jednym miejscu. 

Ale tak jak Paweł wspominał, może się zdarzyć rola, gdzie ktoś będzie wymagał od nas pisania dokumentacji technicznej, ale też wysyłania newsletterów, czy maili promocyjnych, gdzie tutaj już trzeba trochę innego fajnego języka użyć. Tak samo język, którego używamy w samym produkcie, na przykład w interfejsach, też może mieć trochę inny styl, tam trzeba mieć trochę więcej polotu. Ja głównie byłem takim suchym technical writerem, który siedział w tej dokumentacji i miał przekazać tę myśl w jasny sposób.

 

P.K.: Właściwie można by powiedzieć, że część z tych umiejętności pisania technicznego jest takich, jak w copywritingu, jeśli chodzi o ton głosu i sposób przekazywania informacji. Nie krzyczymy na użytkownika, że się pomylił, nie poniżamy, nie mówimy źle o produkcie, który sprzedajemy. Jest cały szereg takich rzeczy, które na tą klarowność i pozytywność przekazu się składają, które może nie są oczywiste, ale one też wchodzą w technical writing. 

Poza tym to zwięzłe pisanie to jest coś dosyć trudnego. Łatwo jest po prostu napisać, to co mam w głowie, ale trudno jest potem to tak zredagować, żeby to było faktycznie przejrzyste i zrozumiałe. W pewnym sensie trochę się to może kłócić z copywritingiem, bo on może mieć na celu wywołanie jakichś konkretnych uczuć, a technical writing zazwyczaj ma na celu wywołanie jednego uczucia, takiego, że wszystko jest w porządku. Przychodzę z jakimś problemem do dokumentacji, straciłem jakieś dane, ok, odzyskam je, spokojnie. Wystarczy zrobić to i to i odzyskałem.

 

Jasne, rozumiem. Dużo powiedzieliśmy o otoczce, o umiejętnościach związanych z tym zawodem. Chciałbym teraz zejść na poziom narzędzi, bo domyślam się, że Word to nie jest jedyne narzędzie, z którego korzystacie na co dzień. Z jakich tooli korzystacie, jak duży jest ten rynek narzędzi dla technical writerów?

 

M.S.: Wspomniałeś o Wordzie, zaraz będziemy mieć tu hordę osób, które będą Cię chciały spalić na stosie za to stwierdzenie.

 

P.K.: Z drugiego obozu.

 

M.S.: Nie no, żartuję oczywiście. Rynek narzędzi dla komunikacji technicznej, czy w ogóle do tworzenia dokumentacji istnieje, jest coś takiego. Są firmy, może nie jest ich wiele, które specjalizują się w tworzeniu stricte produktu pod potrzeby pisania dokumentacji. O ile wspomniany Word w pewnych zastosowaniach może się sprawdzić, czyli potrzebujemy napisać krótką, kilkustronicową instrukcję czy procedurę, to nie musimy od razu inwestować w kombajn do tworzenia super dokumentacji i implementować przez pół roku jakiegoś rozwiązania. Może to się sprawdzi na nasze potrzeby, wygenerujemy sobie tego PDF-a, może to nie będzie szczyt osiągnięcia technologicznego w kwestii dokumentacji, ale spełni swoje potrzeby. Trzeba wyważyć między tym, czego potrzebujemy, a co jest dostępne. 

Mówiąc o firmach, istnieją narzędzia, które się nazywają Help Authoring Tools, to jest taka specyficzna dziedzina i rodzaj narzędzia. Na przykład firma Madcap produkuje, dość fajny produkt Flare, miałem okazję korzystać. Ja go określam jako taką fabrykę. Od momentu kiedy wiemy, co chcemy napisać, tworzymy tą treść, definiujemy w jakich formatach mamy ją dostarczyć i on nam pokrywa ten proces od początku do końca. Czyli my piszemy, używamy jakichś zmiennych, snippetów, rzeczy, dzięki którym możemy wykorzystywać ponownie treść, podstawiać różne wartości w zależności od produktu. Później generujemy sobie output typu Webhelp, HTML5, PDF, co chcemy i na końcu dostajemy gotową dokumentację, którą publikujemy na przykład na serwerze http. Takie produkty istnieją.

Istnieje też taki standard XML-owy, który jest darmowy i otwarty, DITA XML, który ma dla siebie dedykowane narzędzia, na przykład Oxygen XML to jest taki edytor do XML-a, który bardzo fajnie wspiera DITĘ, jeśli w niej piszemy. DITA to już jest standard, który wymaga trochę wiedzy i trzeba jednak wiedzieć, są tam różne zasady. Nie chcę wchodzić w za duże szczegóły. 

Jest jeszcze duży nowy kierunek nazywany Docs as Code, to nie jest konkretne narzędzie, tylko takie podejście do procesu tworzenia dokumentacji, gdzie traktujemy dokumentację tak, jak byśmy traktowali kod. Źródła trzymamy w Gicie, piszemy w Markdownie, reStructuredText, albo Asciidoc, zależnie od potrzeb. Może to też być DITA według mnie, sam format źródłowy nie ma znaczenia. Czyli pliki źródłowe trzymamy w Gicie, później mamy Pull requesty, mamy jakąś automatyzację do tego zapiętą, czyli automatycznie nam się to testuje. Jak się to przetestuje, to można wtedy zmergować, jak się zmerguje, to jest automatyczny deployment na jakieś środowisko. Tak samo jak robimy produkt, tak samo robimy dokumentację. Często też wiąże się to z faktem, że dokumentacja żyje w tym samym miejscu co oprogramowanie.

Jeśli chodzi o narzędzia z tym związane, to używamy często tego, co używają już programiści w firmie, czyli na przykład Jenkins, TeamCity albo Bitbucket czy GitHub, w zależności od tego, co jest w firmie. Mamy VS Code, który wspiera Markdowna i możemy tam pisać tę dokumentację. Mamy klienta do systemu kontroli wersji, więc tutaj te narzędzia się często pokrywają. Mamy też takie wynalazki jak Paweł wspomniał, Next.js czy Docusaurus. Bardzo popularne stały się statyczne generatory stron w świecie IT, jeśli chodzi o nowoczesną dokumentację.

 

P.K.: Nie wspomniałeś jeszcze, Michał, o tytanach rynku narzędzi tech writerskich. Istnieje takie oprogramowanie, które należy do kategorii CCMS.

 

M.S.: Właśnie, wyparłem to chyba z głowy. Żeby nie było, nie chcę tu nikogo obrażać, ale niestety moje osobiste doświadczenie nie jest zbyt dobre z tego typu narzędziami, może trafiłem w zły produkt.

 

P.K.: Tych CCMS-ów jest bardzo dużo. CCMS to znaczy Component Content Management System i to jest coś stricte stworzone na potrzeby dokumentacji, czyli to nie jest taki CMS typu WordPress, ale coś, co jest krok wcześniej. Kontroluje nam dostęp do źródeł i zarządza całym workflow pracy z tymi źródłami i potem prowadzi do różnych kanałów publikacji tych źródeł. Jeżeli użyjemy tego standardu, o którym Michał mówił, DITA, to taki CCMS będzie bazą danych, w których przechowywane są pliki DITA, on sobie zarządza dependencjami między tymi plikami, nie pozwoli nikomu zepsuć tych plików. Zarządza całym workflow, szef zespołu może przydzielać zadania konkretnym autorom, czyli ten CCMS ma w sobie takiego jakby Gita, Girę z ticketami. 

Ten workflow kontroluje, co się z tymi plikami dzieje, one są potem automatycznie tłumaczone czy wysyłane do firmy, która je przetłumaczy i są automatycznie budowane do formatu, który publikujemy. Czyli na przykład przekładana do jakiejś bazy danych online, albo produkowana jako statyczne strony i wrzucana na jakieś web servery. Tego typu kombajny do tech writingu kosztują dziesiątki albo raczej setki tysięcy dolarów rocznie za subskrypcję i są używane przez takie firmy, które mają kilkudziesięcioosobowe zespoły dokumentacji. Często są też używane w wielu pionach, na przykład tech writerzy, copywriterzy i zespół prawny też używają tego narzędzi.

 

Faktycznie wygląda jak wielki kolos, a wiadomo jak to jest z takimi rozwiązaniami, później problem ze zmianami. Paweł, mówiłeś wcześniej, że na przestrzeni Twojego doświadczenia z branżą community rosło, coraz więcej osób na konferencjach można spotkać, coraz większy jest ten rynek. Jak w Waszej opinii wygląda obecnie rynek pracy, ilość ofert, wynagrodzenie, możliwość pracy dla firm z zagranicy? Jak w Waszym subiektywnym odczuciu ten rynek pracy wygląda obecnie dla tech writerów?

 

M.S.: W naszym subiektywnym odczuciu ten rynek zmienia się na lepsze pod tym względem, że pojawia się coraz więcej ofert i wynagrodzenia też idą do góry. Kiedy ja zaczynałem w 2012 roku jako technical writer, moja pierwsza praca, jaką znalazłem była w Katowicach. Wymyśliłem sobie, że zostanę technical writerem, bo to jest zawód, który będzie łączył język z IT. Z jednego się kształciłem, drugie mi się podoba, to jest fajna kombinacja. I zacząłem szukać kogoś, kto zatrudnia w tamtej okolicy i w samych Katowicach znalazłem dosłownie jedną ofertę. Zaaplikowałem i opatrzność boska sprawiła, że dostałem tę pracę i ponad osiem lat pracowałem zanim zmieniłem rolę. Nie było tego dużo, nie było w czym za bardzo wybierać. Zdecydowanie najwięcej ofert było w Krakowie. 

Teraz, jak ostatnio sprawdzałem z ciekawości, jak wyglądają oferty pracy na LinkedInie to jest już dużo więcej firm, które zatrudniają, nawet w samych Katowicach pojawiło się kilka ofert. Znam osobiście przynajmniej dwie kolejne firmy, które w Katowicach zatrudniały. W Warszawie pojawiło się trochę ofert, na przykład Google otworzył nowy oddział w Warszawie i cały zespół technical writerów teraz tam powstaje. Dzieje się. W Krakowie systematycznie pojawiają się oferty, we Wrocławiu jest bardzo dużo. 

Ogólnie rynek zmienił się na lepsze, jeśli chodzi o ilość ofert. I też obserwujemy, że wynagrodzenia potrafią być dobre, czasami znakomite. Wspomniane badanie z Techwriter.pl, może nie będę cytował konkretnych cyfr, ale warto zajrzeć na artykuł, który jest dostępny za darmo bez logowania – Wyniki badania płac z 2020 roku. Jest tam tabela, która pokazuje, jak w kolejnych latach mediana i średnia się zmieniały i można zaobserwować, że z roku na rok ona była troszeczkę wyższa. Według mnie dzieje się dobrze, wiadomo, że to nie jest jeszcze skala choćby ogłoszeń dla testerów czy programistów, daleko nam do tego. Przeważnie jak mamy zespół stu programistów to będziemy mieli trzech, czterech writerów, taką bym proporcję przyjął. Ale jest według mnie lepiej.

 

Jak może wyglądać ścieżka rozwoju tech writera? Jak może swoją karierą pokierować i czy to zawsze musi być tylko drogą dążąca do pisania technicznych tekstów, czy też w pewnym momencie można nieco zboczyć w którymkolwiek kierunku i wystartować z nieco inną specjalizacją? Jak to wynika z Waszego doświadczenia, gdy obserwujecie, analizujecie swoje kariery, swoich kolegów, koleżanek? Z czym się najczęściej spotykacie?

 

M.S.: Ja ma dwie takie ścieżki, czy drogi. Pierwsza, to ścieżki rozwoju w samym rejonie komunikacji technicznej. Może nie doprecyzowaliśmy, ale mówiąc komunikacja techniczna mamy na myśli szerszą dziedzinę, która ma pod sobą technical writing, ale istnieją tam jeszcze inne poddziedziny. Jeśli chodzi o komunikację techniczną, to można się rozwinąć na przykład w kierunku UX writera. Teraz to się robi popularne, czyli osoby, która się specjalizuje w tej treści, która się wyświetla w produkcie. Piszemy komunikaty, piszemy teksty, które użytkownik widzi w produkcie. 

Mamy też rolę API writera, można się wyspecjalizować w dokumentacji stricte do API, która jest trochę innym typem dokumentacji. Mieliśmy nawet cały odcinek o dokumentacji do API, gdzie stwierdziliśmy, że to jest tak jakby produkt. API bez dokumentacji, to tak jakby go trochę nie było, bo nie wiadomo, jak z niego korzystać. To też jest taka fajna dziedzina. Jest architektura informacji, albo content strategy, czyli planowanie tego, jak informacje będę przedstawiane, projektowanie taksonomii i tak dalej. I kierunek w którym ja poszedłem, czyli rozwój narzędzi do dokumentacji, czyli trochę na pograniczu programisty, DevOpsa, technical writera – to jest kierunek mocno techniczny. Mnie to akurat interesowało.

Druga możliwość, czyli wyjście poza komunikację techniczną. Technical writing może być taką furtką do zostania na przykład key way engineerem albo programistą, takie przykłady też znam. Osoby były technical writerami z mocno technicznym zacięciem i zostawały później deweloperami. Może to też być rola we wsparciu technicznym klienta, to też jest pomaganie ludziom w jakiś sposób, tylko forma jest inna, ale idea podobna. Tych możliwości trochę jest.

 

P.K.: Może jeszcze trochę dołożę do tego, co mówiłeś o różnych specjalizacjach w komunikacji technicznej. Ręka w rękę z pisaniem dokumentacji idzie analizowanie tego, czy ona działa i jak ona działa. I tu wyłaniają się dwie działki. Analityk typu Google Analytics lub Web Analytics, można głęboko w to wejść, jeżeli dokumentacji jest dużo, może to być osobna rola. Druga sprawa to jest User Experience Design, znam osoby, które przeszły z technical writingu stricte do User Experience Designu, ale osoba, która stoi okrakiem pomiędzy tymi obszarami też jest przydatną osobą. Osoba współpracująca  z zespołem takich harcore’owo piszących ludzi, a ludzi którzy się zajmują stricte projektowaniem doświadczeń. Są to trochę bardziej egzotyczne przykłady tego co można robić na przykład z architekturą informacji. 

Michał wspomniał o taksonomii, a taksonomie się wpisują w architekturę informacji całej firmy i są też takie działki, gdzie tech writerzy idą w kierunku analizy danych lub rozwiązań sztucznej inteligencji, analizy tekstu i budują grafy semantyczne, które mapują całą infrastrukturę produktów. Jest taka firma Semaphore, która ma całą platformę do tworzenia grafów wiedzy na temat tego, co mamy w przedsiębiorstwie. Osoba z zespołu dokumentacji będąca architektem informacji dokumentacji jest często silnym członkiem zespołu tworzącego tę taksonomię firmową. To może być zaskakujące, ale osoba wracająca z tech writingu może pójść w kierunku analizy danych i zagadnień z dziedziny Machine Learning, które potem wyrastają z tego zarządzania informacją.

 

Ciekawe. Mówi się o tym, że key way czy product manager to są takie role, które fajnie wprowadzają do IT. Czy w Waszej opinii zawód tech writera to też jest dobra furtka do IT? Można później przeskoczyć na bardziej techniczne role?

 

M.S.: Jak najbardziej, mój dobry znajomy powtarza od dłuższego czasu, że dawniej key way był taką dziedziną, która była furtką do IT, kiedy ten zawód jeszcze nie był tak ugruntowany i sprowadzał się do posadzenia człowieka w rogu i kazania mu klikać. Widzimy co się stało parę lat później. Też wtedy mówiło się, że żeby być key way to trzeba umieć klikać i coś tam wiedzieć i można wejść w IT. Oczywiście nie umniejszam, bo uważam, że key way to jest też trudna dziedzina i jak widać rozwinęło się to w takim kierunku, gdzie firmy poważnie podchodzące do tematu widzą wartość w tym. I właśnie dlatego ten mój znajomy zaczął iść w kierunku komunikacji technicznej, chciał to rozwijać analogicznie do tego, co widział w key way. Pracował zarówno w key way jak i w dokumentacji i widział te podobieństwa. Komunikacja techniczna była wątkiem, który miał podobne cechy jak key way. 

W tym momencie komunikacja techniczna czy technical writing stricte stał się taką fajną furtką do IT. To nie chodzi o to, że takich ludzi jest łatwo znaleźć. Żebyśmy się nie wpędzili w przekonanie, że każdy może to robić, bo to tak nie jest. Trzeba mieć zestaw specjalnych umiejętności, żeby dobrze to wykonywać, bo byle jak to można robić. Ale żeby być dobrym technical writerem, trzeba mieć zestaw umiejętności. Jest to furtka o tyle dobra, że często wystarczy mieć umiejętności językowe i odpowiedni zestaw cech i charakter, bo, tak jak mówiłem, tej wiedzy technicznej można się douczyć do takiego stopnia, żeby można było pisać o niej. 

Mamy przykłady z życia wzięte, które ja widziałem osobiście, czyli zatrudnianie osób, które nie miały żadnego doświadczenia w komunikacji technicznej na stanowiska juniorskie i później pod okiem starszych kolegów czy koleżanek nabywały umiejętności i po kilku miesiącach stawały się już właściwie samodzielnymi specjalistami. Albo były to osoby, które były wcześniej nauczycielami angielskiego w szkole, chciały zmienić coś w swoim życiu i nagle stwierdzały, że technical writer to jest to i świetnie się odnajdywały w tej roli.

Sam zresztą byłem po studiach językowych, pracowałem na helpdesku i nagle dostałem pracę technical writera. Przyszedłem do firmy, gdzie nie było ani jednego technical writera, cała dokumentacja to był jeden trzystustronicowy PDF, nie było nawet porządnego narzędzia do pisania dokumentacji. I powiedziano mi, że teraz mam zrobić porządek. Pomalutku da się to zrobić, przy odpowiednim nastawieniu i zestawie umiejętności. Tak, odpowiadając krótko, jest to fajna furtka do IT.

 

P.K.: To może też być furtka w ogóle do biznesu. Znamy przykłady ludzi, którzy z tech writerów stawały się product ownerami, albo wchodzili na taką ogólną ścieżkę managerską i żyją w korporacjach na różnych szczeblach zarządzania. Natomiast chciałbym też zwrócić uwagę, że fajne jest bycie humanistą w IT, bo w takich stricte technicznych rolach nie jest to oczywiste, że ktoś jest humanistą. Z jednej strony jest człowiek, który lubi technologię, on jest programistą, jest testerem, zajmuje się architekturą oprogramowania i tak dalej. Człowiek, który lubi ludzi, jest technical writerem, UX designerem, product ownerem, jest potrzebny do tego interfesju, pomiędzy komputerami a naszymi klientami, którzy będą używać naszego oprogramowania. Jest to ten klej łączący, jest to człowieczeństwo. Jeśli ktoś myśli, że jest zbyt humanistyczny, żeby być w IT, to nie jest tak, możecie być tech writerami, możecie być designerami, możecie pełnić różne role.

 

M.S.: Nie wiem jak Wy odczuwacie, jeśli chodzi o branżę IT, ale moje przekonanie jest takie, że w ostatnim czasie coraz więcej uwagi zwraca się na aspekt ludzki, jeśli chodzi o technologię. Już wszyscy zrozumieli, że sama doskonałość technologiczna jakiegoś rozwiązania nie gwarantuje sukcesu produktu, musimy zwracać uwagę na to, że korzysta z tego człowiek i to człowiek musi być zadowolony z tego, co wyprodukowaliśmy. Zwraca się uwagę na ten element, nie wiem, czy słowo humanistyczny to jest dobre stwierdzenie, ale ten ludzki element w technologii.

 

Już wszyscy zrozumieli, że sama doskonałość technologiczna jakiegoś rozwiązania nie gwarantuje sukcesu produktu, musimy zwracać uwagę na to, że korzysta z tego człowiek i to człowiek musi być zadowolony z tego, co wyprodukowaliśmy. Zwraca się uwagę na ten element, nie wiem, czy słowo humanistyczny to jest dobre stwierdzenie, ale ten ludzki element w technologii. 

 

Wiemy o co chodzi, czujemy to. Fajnie, to jest bardzo dobre podsumowanie naszej rozmowy i tą zachętą do bycia człowiekiem w IT będziemy dzisiaj kończyć. Michał, Paweł, bardzo Wam dziękuję za poświęcony czas, za rozmowę. Sam się bardzo dużo dowiedziałem o tym zawodzie, myślę, że słuchacze też będą mieli teraz lepszy ogląd z czym to się, przysłowiowo, je. Powiedzcie proszę, gdzie Was można znaleźć, jak się z Wami skontaktować?

 

M.S.: Pierwsze miejsce, gdzie możecie zajrzeć, to jest Techwriterkoduje.pl. Tam są nasze podcasty, nasze wystąpienia i nasze, powiedzmy, dzieła pisane, które stworzyliśmy i tam też jest sekcja kontakt, gdzie jesteście w stanie znaleźć maila, możecie do nas napisać, skontaktować się z nami. Jeśli chcecie bardziej prywatnie, to mnie możecie znaleźć na LinkedInie. 

 

P.K.: Też zapraszam na LinkedIn, Paweł Kowaluk, obecnie technical writer w Guidewire.

 

Świetnie, oczywiście wszystkie linki będą dołączone do odcinka, jak zawsze. Ja Wam bardzo jeszcze raz dziękuję, no i do usłyszenia, cześć!

 

M.S.: Dzięki, Krzysztof! Na razie!

 

P.K.: Dzięki, Krzysiek!

 

I to tyle z tego, co przygotowałem dla Ciebie na dzisiaj, rola tech writera może wnieść wiele do zespołu, przyczynić się do podniesienia jakości projektu czy produktu, a jednocześnie być furtką do IT.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o roli technical writera. 

Zapraszam do kolejnego odcinka już za tydzień. Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.