Kilka pytań do – część 12

Witajcie, znamy już dobrze tuzin Technical Writerów. Kiedy zakładaliśmy tę stronę przez myśl nam nie przeszło, że może nas być aż tylu… Szczęśliwą dwunastkę zamyka Kasia Kołodziej, z którą wywiad publikujemy poniżej. I to od razu w dwóch językach!

Click here for English version and enjoy!

Jak długo pracujesz jako Tech Writer?

Komunikacją Techniczną zajmuję się od ponad 5 lat.

W jaki sposób zostałaś Tech Writerem?

Zaraz po studiach na Uniwersytecie Illinois w Chicago, zdobyłam tytuł Bachelor of Science w
Marketingu i postanowiłam wrócić do Polski. To był trudny okres na rynku pracy i pozycja jakiej
szukałam po prostu wtedy nie istniała. Po pewnym czasie, kiedy zrozumiałam, że na Śląsku
prawdopodobnie nigdy nie znajdę anglojęzycznej pracy w Marketingu spełniającej moje kryteria,
natknęłam się na ofertę “specjalista ds. treści technicznych”. A że byłam zainteresowana
technologią informacyjną i praca znajdowała się 5min. ode mnie, postanowiłam zaryzykować – i
tak to się wszystko zaczęło!

Czy możesz opowiedzieć coś o swojej firmie i zespole, w którym
pracujesz?

Pracuję w amerykańskiej firmie Jamf, która zajmuje się zarządzaniem urządzeniami Apple w
przedsiębiorstwach, instytucjach edukacyjnych i organizacjach rządowych. W ostatnich latach
nasza organizacja powiększyła się z 165 do ponad 500 pracowników, znacznie został też
zwiększony zespól inżynierów oprogramowania. Pod koniec 2015 roku zostało otwarte biuro
rozwoju oprogramowania w Katowicach i aktualnie jest nas 30+ osób. Biuro w Polsce nadal się
rozwija i cały czas dołączają nowe osoby. Póki co, jestem jedynym Tech Writerem, reszta znajduje
się w USA.

W jaki sposób jest zorganizowana praca Twoja i Twojego zespołu?

Jamf bardzo stawia na współpracę, transparentność i kulturę DevOps. Pracujemy Agile’owo w
zespołach 4-9 osobowych. Na co dzień jestem częścią cross-funkcjonalnego Scrum teamu, gdzie
dostarczamy konkretną wartość biznesową pod koniec dwutygodniowego sprintu. Współpracuję
też z innymi działami w organizacji, szczególnie z działem UX, Product Management, Marketing
oraz z Subject Matter Experts.
Jestem też częścią zespołu Komunikacji Technicznej. Naszą misją jest wypełnienie luki pomiędzy
naszym oprogramowaniem a potencjalnym użytkownikiem poprzez zapewnianie niezbędnych
informacji do efektywnego korzystania z naszych produktów. Poza tym, jako zespól
profesjonalistów od komunikacji technicznej zależy nam na rozwoju najlepszych praktyk oraz na tym, aby
nadal edukować siebie i organizację w tym temacie. Regularnie automatyzujemy nowe procesy
związane z dostarczaniem treści i pracujemy nad poprawą ogólnej skuteczności naszych treści.

Jakich narzędzi używasz i co o nich sądzisz?

W dużej mierze polegam na narzędziach od firmy Atlassian (JIRA, Confluence, Bitbucket, HipChat,
SourceTree, Bamboo itp.) i nie wyobrażam sobie pracy bez nich. Do spotkań zwykle korzystam z
WebEx – idealnie nadaje się do komunikacji grupowej, współdzielenia ekranu i nagrywania
spotkań. Często też korzystam z przewodników stylu. Myślę, że są to mało wykorzystywane
narzędzia, a bardzo się przydają jeśli zależy nam na jakości. Poza naszymi wewnętrznymi
przewodnikami, używam m.in. Chicago Manual of Style oraz Apple Style Guide.
Narzędzie, które bardzo mi się przydaje to nasze w pełni zautomatyzowane środowisko testowe,
dzięki któremu mogę samodzielnie zbudować wybraną wersję naszego systemu z opcjonalnymi
danymi testowymi. Wszystko w około 2 minuty. Oczywiście używam dużo więcej narzędzi, ale w
sumie wszystko zależy od projektu.

W jaki sposób zdobywasz informacje potrzebne do tworzenia
dokumentacji?

Jako że jestem częścią zespołu Scrumowego, dokładnie wiem co się dzieje i mam dostęp do całej
komunikacji związanej z projektem. Informacje zdobywam również poprzez kontakt z klientem.
Często przeglądam SalesForce, Confluence, Jira lub nasze forum w celu zdobycia dodatkowych
szczegółów. Mamy bardzo przejrzystą organizację, więc uzyskanie informacji nie jest problemem.
Myślę, że najlepszym sposobem aby uzyskać niezbędne informacje to zachowywać się jak
reporter, czyli robić wywiady z ludźmi i zadawać pytania – wiele pytań. Bardzo często Tech
Writerzy w zespołach zwinnych są bombardowani informacjami z każdej strony. Jeśli kiedykolwiek
Cię taka sytuacja spotka, najpierw sobie pomyśl „Jak to ma pomóc użytkownikowi?”, A następnie
zadecyduj, które informacje zwrotne należy zaimplementować.

Jakie dokumenty dostarczasz, w jakiej postaci, w jakim języku/językach
i jak są one publikowane?

Dostarczam różnego typu treści, które mają za zadanie jak najlepiej pomóc naszym
użytkownikom (np. user guides, release notes lub artykuły techniczne). Tworzę wszystko w
języku angielskim, a zespół od lokalizacji produktu przygotowuje je do tłumaczenia. Aby
zapewnić wysoką jakość, współpracuję z edytorem, który dodatkowo sprawdza czy mój materiał
jest gotowy do publikacji. Często tworzę treści bezpośrednio w Confluence, skąd można łatwo
eksportować do formatu PDF lub HTML.

Czy oprócz tworzenia dokumentacji zajmujesz się czymś jeszcze, np.
tworzeniem materiałów marketingowych? Jeśli tak, to czym i jakich
narzędzi do tego używasz?

W kontekście zespołów Scrum nie ma rozgraniczenia na “testerów”, “dokumentalistów” czy też
“programistów”. Dlatego nie tylko tworzę dokumentację, ale też np. testuję nasze
oprogramowanie. Szczególnie przydatne są testy ścieżki czynności, którą może przebyć użytkownik.
Uważam, że jest to świetny sposób na dodatkową perspektywę, przy okazji wychwycenia błędów.

Jakie są największe wyzwania, które napotykasz w swojej pracy?

Tworzenie dokumentacji równolegle z pracą programistyczną, zwłaszcza na początku projektu,
kiedy funkcjonalności nie zostały jeszcze zaimplementowane i mogą się zmienić. Trudno pisać
fikcje :).

Co najbardziej lubisz w pracy Tech Writera?

Podoba mi się to, że w przeciwieństwie do Marketingu, Tech Writer tworzy content wyłącznie
informacyjny. To z kolei, stanowi realną wartość dla użytkownika – i to najbardziej lubię.
Plus, ta rola oferuje szerokie spektrum zadań, więc codziennie uczę się czegoś nowego.

Co byś radziła osobom, które chciałyby zacząć swoją przygodę z
pisaniem dokumentacji?

Myślę że techwriter.pl to pierwszy przystanek dla każdego, kto chce rozpocząć pisanie
dokumentacji technicznej w Polsce – i nie tylko. Można znaleźć wiele informacji i wskazówek dla
obecnych lub przyszłych specjalistów z tej branży. Ale najważniejsze to nie bać się technicznych
tematów!

Czy masz dyplom lub certyfikat z obszaru komunikacji technicznej? Jeśli tak, to jak
pomógł Ci w karierze?

Nie do końca :). Sądzę, że bardzo pomogła mi wiedza zdobyta na studiach marketingowych. W
końcu efektywna komunikacja i trafienie wiadomością do danej grupy docelowej jest podstawą
w obu dyscyplinach. Jestem też w trakcie uzyskania certyfikacji z Komunikacji Technicznej
wydawanej przez ITCQF®.

Serdecznie dziękujemy za wywiad, jeżeli chcielibyście się skontaktować z Kasią, dajcie nam znać!


English version:

How long have you been working as a Tech Writer?

I have been involved with Technical Communications for over 5 years.

How did you become a Tech Writer?

After graduating from the University of Illinois at Chicago, I got a Bachelor of Science in
Marketing and decided to move back to Poland. This was a difficult time on the job market and
the position I was looking for didn’t even exist yet. After a while, when I finally realized that
most likely I will never get an English-speaking job in Marketing in the Silesia region, I came
across a “technical content specialist” offer. As I was always interested in information
technology and the job was close to where I lived, I decided to apply. And that’s how it all
started!

Can you say something about the company you work for and your
team?

I work at Jamf, where we help commercial, education, and government organizations succeed
with the Apple platform. In the recent years the firm grew from 165 employees to over 500,
greatly expanding the engineering team. By the end of 2015 we opened a software
development office in Katowice and right now there are 30+ software engineers. Our Katowice
office is still growing and we are constantly hiring new people. Currently, I am the only Technical
Writer here, the rest of the team is located in the US.

How is your and your team’s work organized?

Jamf embraces the DevOps culture and puts a big emphasis on collaboration and transparency.
We work in an Agile environment with teams consisting of 4-9 members. On a daily basis I am
part of a Scrum team, where we work cross-functionally to deliver specific business value at the
end of our two-week sprint. I often collaborate with other departments, most often with UX,
Product Management, Marketing or Subject Matter Experts.
I am also a part of the Technical Communications team where our mission is to bridge the gap
between our software and the user by making sure users have information they need to use our
products effectively. We also develop best practices for technical writing and continue to
educate ourselves and the organization on this topic. Whenever we can, we try to automate
manual processes associated with content delivery and work on improving overall content
effectiveness.

What tools do you use and what do you think about them?

I heavily rely on Atlassian tools (JIRA, Confluence, Bitbucket, HipChat, SourceTree, Bamboo etc.)
and can’t imagine my work without them. For meetings I usually take advantage of WebEx, as
it’s great for group communication, sharing screens and recording meetings. I also find style
guides to come in very handy. I think it’s a bit forgotten tool and not used as much. And that’s a
shame, as it’s very useful, especially in terms of quality. Besides our internal style guides, I use
The Chicago Manual of Style and the Apple Style Guide.
The tool I like the most is our self-service testing environment which allows me to choose any
local branch build of our software and have a running environment with optional test data in
around 2 minutes. Of course I use a lot more tools but they all depend on the project.

How do you get the information you need to prepare/create
documentation?

Since I work with my Scrum team on a daily basis, I have access to most of the necessary
information, plus I am included in all communication. I also gather and incorporate feedback
from our customers. A lot of times I will look through SalesForce, Confluence, Jira or our
community forum to find additional details. We have a very transparent company, so getting
info is not a problem.
I think the best way to get information you need is by acting like a reporter, meaning
investigating and asking questions – a lot of questions. It is common for Technical Writers on
agile teams to get too much feedback and information. But if you ever encounter a situation like
that, first think to yourself “How does this help the user?” and then decide which feedback to
incorporate.

What documents do you deliver, in what form, in which
language/languages and how are they published?

I deliver any content that is needed in order to best assist our users. These may include: admin
guides, knowledge base articles, release notes, or technical papers. I write everything in English
and our product localization team prepares it for translation. I work with an editor to ensure my
content is ready for publishing. Often I will create my content on Confluence as from there it
can be easily exported to PDF or HTML.

Do you participate in any other activities besides documentation
writing (e.g. creation of marketing materials)? If yes, what is it and
what tools do you use?

Scrum teams do not contain sub-teams dedicated to particular domains, such as “tester”,
“programmer” or “technical writer”. That’s why besides documentation writing, I’d for example
test our software. Especially useful is testing user workflows. I think it’s great to gain another
perspective, besides catching any errors.

What are the biggest challenges at your work?

Working in parallel with development, especially in the beginning of the project when features
are not yet developed and functionalities might change. It’s hard to write fiction :).

What do you like the most in technical writing?

I like that technical writing is purely informational and provides real value to the user, in
comparison to marketing content. I also enjoy talking with people and like the wide spectrum of
work it offers – I learn so much everyday!

What is your advice for those who want to begin their adventure with
writing documentation?

I think techwriter.pl is a great first stop for anyone who wants to begin writing technical
documentation in Poland. You can find a lot of information and tips for current or future tech
writers plus jobs offers. Most importantly, don’t be afraid of technical writing if you don’t have a
technical background!

Do you have any diploma or certificate in technical writing? If yes, did
it help you in your career?

Not really :). But I do think that my education background in marketing helped me quite a bit.
After all, effective communication and reaching your target audience is the basis in both fields.
Also, I am currently in the process of getting a certification in Technical Communication by
ITCQF®.