A matriz é um mapa, não uma nota
Equipes costumam criar matrizes quando a contratação fica inconsistente ou promoções se tornam subjetivas. Dar notas de um a cinco parece rigoroso, mas não ajuda se ninguém consegue apontar evidências que separam um nível do outro.
Comece por capacidades observáveis: pesquisa, escrita e edição, arquitetura da informação, APIs, ferramentas, coordenação de releases, automação de qualidade e trabalho com stakeholders.
Descreva escopo e autonomia
Para cada capacidade, diga que tipo de problema a pessoa consegue resolver e quanta supervisão precisa. Um iniciante pode atualizar um procedimento existente com revisão. Alguém mais experiente pode descobrir o fluxo, validá-lo com engenharia, desenhar a estrutura e criar o processo de review.
Isso é mais útil do que adjetivos como “ótimo comunicador”, porque se apoia em artefatos reais.
Separe ofício de conhecimento de domínio
Não transforme a stack de um produto em definição de senioridade. Kubernetes pode ser crítico para uma vaga e irrelevante para outra. Mantenha habilidades duráveis de documentação separadas do conhecimento local.
O mesmo vale para ferramentas: Git pode ser obrigatório, mas conhecer um gerador específico não define sozinho um nível de carreira.
Use a matriz nos dois sentidos
Ela deve ajudar gestores a explicar expectativas e writers a escolher o que praticar. Inclua exemplos de evidência: uma nova navegação, uma referência de API com exemplos testados, uma migração terminológica ou um quality gate no CI.
Atualize quando o trabalho mudar
IA, conteúdo estruturado e documentation engineering mudam a distribuição do trabalho. Atualize a matriz quando o trabalho real mudar, não quando surgir uma buzzword.
A pergunta durável é: que problema valioso de documentação esta pessoa consegue assumir de forma confiável?
Exemplo aplicado
Use “Uma matriz de competências de technical writer que mede trabalho útil” como exercício de equipe, não como lista de cargos. Pegue uma tarefa recente e reconstrua quem identificou a necessidade do usuário, encontrou os fatos técnicos, definiu a estrutura, revisou o texto e será responsável pela próxima revisão.
Descreva capacidades observáveis:
- que problema a pessoa consegue assumir sem supervisão passo a passo;
- com quais especialistas consegue trabalhar e discordar de forma construtiva;
- que riscos de qualidade detecta antes da publicação;
- que processo de documentação consegue melhorar, e não apenas usar.
Um bom modelo profissional indica qual problema difícil deve ser praticado em seguida. Se produz apenas rótulos como “junior”, “senior” ou “boa comunicação”, é vago demais para orientar crescimento ou contratação.
Checklist editorial rápido
- A matriz é um mapa, não uma nota. Equipes costumam criar matrizes quando a contratação fica inconsistente ou promoções se tornam subjetivas.
- Descreva escopo e autonomia. Para cada capacidade, diga que tipo de problema a pessoa consegue resolver e quanta supervisão precisa.
- Separe ofício de conhecimento de domínio. Não transforme a stack de um produto em definição de senioridade.
- Use a matriz nos dois sentidos. Ela deve ajudar gestores a explicar expectativas e writers a escolher o que praticar.
