A mudança não acontece só com a chegada do(a) Tech Writer: a importância de uma cultura de documentação na empresa
Desde o ano passado, o mercado de Technical Writing, ou Redação Técnica, acompanhou uma “virada de chave” que se tornou um divisor de águas: deixamos de ser uma área que a maior parte das pessoas “nunca ouviu falar” e, assim, ganhamos uma certa visibilidade, o que nos possibilitou despertar a curiosidade e o interesse das pessoas. E, claro, das empresas.
Muito disso se deve aos passos que demos nos últimos tempos:
- Criamos a nossa primeira comunidade brasileira, a Tech Writing Brasil, e realizamos cerca de 5 eventos abertos ao público;
- Fomos tema em lives, webinars e eventos importantes na área de comunicação e tecnologia, como o Workshop do Bem da FIAP;
- Tivemos o primeiro curso online lançado 100% em português, criado pelo Breno Barreto, e mais recentemente, o primeiro curso em uma universidade brasileira (no caso, a ESPM), o “Fundamentos de Technical Writing”.
(Inclusive, as inscrições para primeira turma do curso estão abertas, você pode saber mais no link acima 😉 ).
Essa maior visibilidade que Tech Writers passaram a ter gerou um resultado esperado, que foi o aumento da procura de profissionais no mercado, ou seja, abertura de vagas:
Prova disso é que, só nos últimos meses, empresas como PicPay e Loggi realizaram seu primeiro processo seletivo para contratar Tech Writers, além de empresas que já possuíam time de documentação.
Com certeza, é um momento interessante para ser Tech Writer ou cogitar uma transição de carreira para área.
Só que tem um porém importante nessa história…
O primeiro passo até pode ser contratar um profissional de Tech Writing para empresa. Mas não adianta esperar que todos os seus problemas de documentação se resolvam só com o(a) TW.
E é essa discussão que gostaria de ter contigo hoje. 😉
Entendendo o X da questão
Por ser uma das administradoras da nossa comunidade, tive a oportunidade de conversar com algumas empresas que estavam em processo de contratar TWs.
Para além da dificuldade esperada em criar uma vaga, listar as devidas competências e mapear potenciais perfis — ou seja, os pontos para saber como contratar Technical Writers -, noto que a dor de quem recruta vai além de só encontrar a pessoa ideal para o cargo: existe a expectativa de que a pessoa que vai chegar seja a figura chave que irá resolver todos os problemas.
“Quais problemas, Mari?”
Bom, todos relacionados à documentação: o que documentar, onde e como documentar, como desenhar os processos de documentação e por aí vai.
Tenho uma boa e má notícia, qual quer primeiro? Vou começar pela boa, vai: contratar um(a) TW é um passo fundamental para “arrumar essa casa”, mas só isso não é o suficiente pra resolver todos os problemas.
E aí entra a má notícia: ou você fomenta uma cultura de documentação na empresa, ou os esforços do TW serão em vão ou irão demorar mais para surtir efeito.
Isso significa que o(a) Tech Writer não resolve o problema? Não, significa que ele(a) resolve sozinho(a). E, nesse sentido, ter essa ideia de cultura de documentação comprada pelos stakeholders é fundamental para que o projeto, de fato, vá para frente.
Caso contrário, a documentação se torna mais um daqueles projetos que, depois de tempo e dinheiro investidos e sem resultados palpáveis, é descontinuado com o falso argumento de que não funcionou. Ué, mas como vai funcionar sem o esforço coletivo, não é mesmo?
Como criar uma cultura de documentação?
Cada empresa tem seu próprio fluxo de trabalho, portanto criar e consolidar uma cultura de documentação passa por entender como estão hoje os times e de que maneira a doc se encaixa a essa estrutura, realizando claro as adaptações necessárias.
Aliás, existem dois conceitos bem importantes quando estamos falando de criar toda uma cultura que dê protagonismo à documentação: o primeiro deles é o DDLC, ou Ciclo de Vida de um Documento. De forma bem resumida, é o fluxo contínuo de criar, revisar, editar e manter uma documentação rolando, assim como acontece com o Ciclo de Vida do Software.
Dia desses, fiz um post só explicando DDLC (no caso, a imagem ao lado), vale a pena conferir depois ;)
O outro conceito muito importante é DocOps, isto é, quando se existe um método de trabalho no qual a documentação é vista como uma entregável de todo o time. O André Sato escreveu um artigo só sobre o assunto e vale muito a pena a leitura :)
Algumas estratégias que podem ajudar você, e sua empresa, a “preparar a casa para receber o(a) TW” ou a construir as bases de trabalho para o(a) redator(a) técnico(a):
1. Estabeleça a doc como critério de aceite para entrega das tasks
A regra é clara: aquela sua funcionalidade só vai para coluna de “done” quando a documentação dela estiver concluída. Dessa forma, garantimos que a documentação, de fato, acompanhe o desenvolvimento do produto ;)
2. Aposte em templates de documentação para otimizar o trabalho
A primeira etapa, que era entender a importância da documentação, você já concluiu. Você também compreendeu o porquê de ter um(a) TW — ou mais TWs — no time.
3. Eduque os times
É bem provável que, logo que o(a) TW chegar à empresa, ele(a) encontre uma certa resistência por parte do time. Se este for o caso da empresa em que você está, é muito importante que as pessoas entendam o porquê da documentação precisar da mesma atenção que o código, por exemplo.
Isso passa, necessariamente, por um processo de conscientização, de explicar o que é Technical Writing, os benefícios de uma boa documentação e os ganhos para o time, como por exemplo maior autonomia e maior adoção do produto pelos clientes.
No entanto, é necessário ter recursos para escalonar e padronizar seu trabalho de documentação. Por isso, uma boa estratégia é a de criar templates de documentação a partir dos modelos de documento que mais são usados nos seus projetos.
Inclusive, existe um projeto open source chamado The Good Docs, que dispõe de uma série de templates para te ajudar nessa missão ;)
4. Realize testes periódicos com a doc, ou colete feedbacks direto do cliente
Além da prova social sobre a qualidade da documentação, realizar testes periódicos pode auxiliar em insights para melhorias no seu produto/serviço. Afinal, se existe toda uma área focada em Qualidade de Software (QA), por que não termos esforços relacionados à qualidade do conteúdo técnico?
Justificar esses esforços de documentação não é uma tarefa fácil — e longe de mim romantizar isso neste texto.
Ainda assim, vale a tentativa. E sabe por quê? É como gosto de dizer: “em um cenário cujas tecnologias têm se tornado, cada vez mais, complexas, é no mínimo ingênuo acharmos que nossos produtos, por eles mesmos, são suficientes para garantir a melhor experiência de uso”.
Em outras palavras: a documentação é um ponto de contato estratégico da sua empresa com cliente. Desperdiçar essa oportunidade, em um mercado tão competitivo como o de tecnologia, não é de bom tom (sim, citando diretamente da decoradora digital Keila Mellman).
Caso não tenho pegado a referência, vou deixar este vídeo da Keila que é uma pérola à parte.
— — -
Sobre mim :)
Eu sou jornalista, com especialização em Comunicação e Marketing Digital, que migrou, em 2019, para área de tecnologia. Ano passado, mergulhei no mundo da redação técnica (Technical Writing) e me apaixonei pela área. Escrevo sobre tecnologia, technical writing e reflexões de carreira e vida no LinkedIn e no Instagram (@maritechwriter), além de ser uma das administradoras da comunidade Tech Writing BR.
Recentemente, fui convidada para ser professora — junto com o Charlley Luz e o Magerson Bilibio — da primeira turma do curso Fundamentos de Technical Writing, o primeiro sobre a área de redação técnica feito em uma universidade brasileira, a ESPM.
