Komunikacja techniczna - jak upłynął drugi semestr studiów?

Pod koniec maja pierwsi absolwenci studiów podyplomowych na kierunku Komunikacja Techniczna mogli z dumą odebrać swoje dyplomy. Oto podsumowanie drugiego semestru (i całego roku akademickiego).

Tu znowu Magda, do niedawna studentka, a dziś już absolwentka studiów podyplomowych kierunku Komunikacja Techniczna na Akademii Finansów i Biznesu Vistula. Musiał minąć nieco ponad miesiąc, abym była w stanie w pełni obiektywnie napisać, jak minął nam drugi semestr. Zaczerpnięcie oddechu było niezbędne - również dlatego, że druga połówka studiów była znacznie intensywniejsza pod każdym względem. Zero ściemy, roboty po kokardę - oto najkrótsze podsumowanie. Uwaga, w artykule pojawiają się pojęcia oznaczone gwiazdką - wyjaśniam je pod koniec, w mini glosariuszu.

A jednak techniczna

Po pierwszym tekście, w którym opisywałam wrażenia  z pierwszego semestru, dostałam na priv sporo pytań. Dotyczyły one specyfiki zawodu technical writera, programu zajęć, tego, na ile niezbędna jest znajomość branży IT, a także minimalnego wymaganego stopnia “techniczności”, której zresztą sama na początku się bałam. Dziś, już po ukończeniu studiów, mogę zupełnie szczerze powiedzieć - możesz wchodzić na ten kierunek bez doświadczenia w IT, z całkowicie czystą kartą, ale jeśli nie masz choćby odrobiny zacięcia do pracy z narzędziami typowymi dla branży (takimi jak systemy kontroli wersji, podstawy technologii frontendowych, oprogramowanie, w którym czasem łatwiej zrobić coś w kodzie niż w panelu WYSIWYG*), będzie ci ciężko. Zresztą, co tu dużo kryć, pierwszy semestr uśpił naszą czujność - przez pierwszych kilka tygodni mierzyliśmy się głównie z teorią, a potem nastał czas praktyki. Jej efekty lądowały zazwyczaj w repozytoriach* na GitHubie.

Oto, co opanowaliśmy stopniowo od końca stycznia do końca maja:

• podstawy html + css (naprawdę totalne podstawy - w tej dziedzinie czuję zresztą niedosyt i chętnie dorzuciłabym dodatkowe godziny, zwłaszcza na css, których słaba znajomość mściła się później)
• składnia Markdowna
• Git* + GitHub* + GitHub Desktop - tworzenie repozytoriów, commitowanie zmian, upublicznianie niektórych repozytoriów poprzez stworzenie GitHub Pages
• narzędzia IDE*, niezbędne do pracy z kodem - Brackets oraz Visual Studio Code
• MadCap Flare, gigantyczny “kombajn” do tworzenia i składu dokumentacji wszelkiego rodzaju
• DITA XML* + edytor Oxygene
• podstawy wiedzy o narzędziach CAT* + praca z MemoQ
• JIRA, tym razem używana na bieżąco do estymacji i tworzenia sprintów projektu zaliczeniowego

Sporo. I właściwie żadnego z narzędzi / języków nie dało się odpuścić. Ze znajomości każdego rozliczano nas w ramach pracy domowej. Potem używaliśmy ich jeszcze raz, tworząc pracę zaliczeniową - zwieńczenie naszej edukacji. Prace domowe oraz praca zaliczeniowa złożyły się na nasze pierwsze techwriterskie portfolio. Odrobina prywaty: moje portfolio możecie obejrzeć tutaj.

Tu refleksja: być może podczas kolejnej edycji studiów warto rozważyć lepsze zbalansowanie teorii i praktyki na przestrzeni obu semestrów. W naszym przypadku, jak już wspomniałam, semestr pierwszy był niemal wyłącznie teoretyczny, a drugi niemal wyłącznie praktyczny, ze wspólnym poznawaniem narzędzi na zajęciach i mnóstwem projektów klikanych po godzinach. Na pocieszenie mogę jednak dodać, że za spóźnienie z dostarczeniem pracy domowej nikt nikomu nie urywał głowy.

Listy z Ameryki

I jeszcze ciekawostka - podczas drugiego semestru chętne osoby mogły wziąć udział w wirtualnej wymianie studenckiej, prowadzonej przez dr Lance’a Cummingsa z University of North Carolina Wilmington. Razem z kolegami i koleżankami z USA realizowaliśmy mini projekty w ramach kierunku „Writing in Intercultural and Global Contexts”. Uczestników i uczestniczki skojarzono w mniejsze grupki (zwykle dwu-, trzyosobowe) i wspólnie pisaliśmy, wymienialiśmy się informacjami, dawaliśmy sobie feedback. Tutaj możecie znaleźć wszystkie szczegóły na temat wymiany.

Muszę jednak uczciwie przyznać, że - choć wzięłam udział w projekcie - to pod koniec zszedł on na drugi plan i toczył się gdzieś w tle. To dlatego, że na przełomie marca i kwietnia wszystkie zasoby mojego procesora zżerała już praca zaliczeniowa.

Le grand finale

Prace tworzyliśmy etapami. Od wykładowców dostaliśmy kilkanaście tematów do wyboru - mogliśmy zdecydować się na jeden z nich lub zaproponować inny. Musieliśmy także podjąć decyzję, z jakiej technologii chcemy skorzystać - czy będzie to MadCap Flare, Markdown czy DITA, a może kilka? W kolejnym etapie tworzyliśmy plan dokumentacji i ustalaliśmy jej typowego odbiorcę (czyli personę) oraz styleguide (np. od Google, Microsoft czy Atlassian). Uzbrojeni w tę wiedzę, zaczynaliśmy pisać. Oczywiście dodatkowo męczyliśmy też wykładowców na Teamsach. Postępy relacjonowaliśmy podczas zajęć oraz w Jirze. Oj, działo się: technologie płatały figle, css-y we Flare dawały do zrozumienia, że nic z tego nie będzie,  brzydkie słowa latały gęsto, pierwsze szkice wybuchały, a tematy ulegały modyfikacji. Czas gonił, bo finalny draft musiał być gotowy na początku maja. Od tego momentu zaczynał się czas na review dla opiekunów projektów - dokładnie tak, jak dzieje się to w przedsięwzięciach komercyjnych. W międzyczasie na zajęciach z Tomkiem Prusem pilnie przygotowywaliśmy się do egzaminu ITCQF - nie jest on wprawdzie obowiązkowy, ale grzechem byłoby nie skorzystać z możliwości szkolenia u specjalisty.

Aż w końcu nadszedł TEN dzień: publiczna prezentacja projektu zaliczeniowego. Każdy dostawał do dyspozycji 10 minut, każdy miał też szansę zadawania pytań kolegom i koleżankom. Był stres, oczywiście - ale były również przerywniki muzyczne (na przykład takie) i czas na podsumowanie studiów. Wymieniliśmy się mailami, numerami telefonów, kontaktami na LinkedIn. Byliśmy niewielką grupą i zdążyliśmy się ze sobą zżyć, jestem więc pewna, że nasz kontakt się nie urwie i jeszcze nieraz się spotkamy - już nie na studiach, ale w pracy. Świat, jak wiadomo, jest mały. Pierwsze spotkanie absolwentów i absolwentek już się zresztą odbyło - grupka integrowała się w jednym z krakowskich pubów.

Tak to ja mogę studiować

Jeśli z powyższego artykułu wyszło wam, że podyplomówka z komunikacji technicznej to pot, krew i łzy, spieszę wyprowadzić was z błędu. Tak, roboty jest dużo. Tak, mózg chrzęści i trzeba opanować wiele umiejętności, o których wcześniej miało się mgliste pojęcie. Ale na każdym etapie tego bolesnego procesu mieliśmy wsparcie wykładowców i wykładowczyń. Przyznam, że stało to dla mnie w ogromnym kontraście do tego, co zapamiętałam ze swoich studiów magisterskich na jednej z renomowanych państwowych uczelni: oprócz rzeczy pozytywnych doświadczyłam tam także konserwatyzmu i ściśle ustalonej hierarchii środowiska akademickiego, kontakty z wykładowcami i promotorami z reguły były sformalizowane, a wizyta w dziekanacie zawsze oznaczała stoczenie jakiejś bitwy. Tutaj zupełnie się z tym nie spotkacie. Organizacja od początku do końca była perfekcyjna, a relacje z wykładowcami przyjazne i partnerskie. Po prostu żal było się z nimi rozstawać - pożegnaliśmy się nie jak wykładowcy ze studentami, ale jak dobrzy znajomi. I wiem, że w toku dalszej kariery możemy liczyć na wsparcie Darka, Marty, Tomka, Daniela i Piotra. Dzięki za wszystko! To co, odpalamy kolejną edycję dla zaawansowanych?

Bonus: ściąga dla humanistów, czyli glosariusz

• CAT - akronim od Computer Aided Translation, czyli narzędzia usprawniające pracę tłumacza (np. Trados, MemoQ). Dzięki nowoczesnemu i rozbudowanemu systemowi tzw. pamięci tłumaczeniowych programy CAT przyspieszają i ujednolicają proces przekładu.
• DITA XML - czyli Darwin Information Typing Architecture. Język formatowania dokumentu, który pozwala nadać mu strukturę - dzięki temu zarówno ludzie, jak i maszyny będą rozumiały, jaka jest rola danego fragmentu tekstu. DITA to obok Markdowna jedna z podstawowych technologii tworzenia dokumentacji.
• git - najpopularniejszy (ale nie jedyny) system kontroli wersji, czyli narzędzie do sprawdzania, kto odpowiada za bugi w kodzie 😉 Jeśli zaczynasz przygodę z gitem, używaj na początek programu z interfejsem graficznym (np. TortoiseGit, GitHub Desktop). Prawdziwym hardkorom polecam oczywiście pracę z gitem w konsoli tekstowej.
• GitHub - serwis służący do przechowywania repozytoriów gitowych i zarządzania nimi.
• IDE - czyli Integrated Development Environment. To po prostu narzędzia do tworzenia kodu. Możesz oczywiście pisać kod w zwykłym edytorze tekstu z możliwością podświetlania składni, ale IDE oferują  sporo dodatkowych udogodnień. Niektóre z nich mają na przykład opcje do "wypychania" jednym klikiem twojej pracy na zewnątrz (na serwer, do repozytorium na GitHubie itd).
• Repozytorium - miejsce, gdzie trzymamy kod źródłowy projektu.
• WYSIWYG - to akronim od What You See Is What You Get. Typowym narzędziem WYSIWYG są CMS-y, czyli Content Management Systems - dzięki nim można tworzyć stronę www mając niewielkie lub żadne pojęcie o html, css i JavaScripcie. Komponenty WYSIWYG znajdziecie także w MadCap Flare, czyli jednym z typowych narzędzi dokumentalisty.