Os Papéis · Quem ensina

Advogado de desenvolvedores

Escrito a partir de fontes publicadas

O engenheiro empregado por um fabricante cujo trabalho serve a quem usa a tecnologia dele. A advocacia fica dentro de relações com desenvolvedores — e o cargo só funciona enquanto a comunidade acreditar que ele diz a verdade sobre o produto de quem o paga.

Como é o dia

  • Escrever sample code e integrações de referência que mostrem o produto fazendo algo de verdade.
  • Responder em público — fórum, chat, issues — onde a resposta fica disponível para todo mundo que chegar depois.
  • Palestrar e tocar workshops, que é ensinar para uma sala que escolheu estar ali.
  • Abrir o bug report detalhado que um usuário frustrado teria abandonado.
  • Advocacy interno: levar a dificuldade da comunidade para dentro da empresa, em termos sobre os quais produto e engenharia consigam agir.

Pelo que responde

  • Exatidão técnica em público, com o nome da empresa em cima.
  • As dificuldades da comunidade chegarem às pessoas que conseguem resolvê-las.
  • Material que continua funcionando depois da release contra a qual foi escrito.

Como é medido

  • Sinais de adoção: sign-ups, integrações construídas, uso de documentação e samples.
  • Atividade e sentimento da comunidade.
  • Mudanças de produto rastreáveis ao feedback que o papel carregou — a medida honesta, e a mais difícil de atribuir.

De quem recebe

A comunidade de desenvolvedores
Perguntas, reclamações e os contornos (workarounds) que eles inventaram sem ninguém pedir.
Produto e engenharia
O que vem por aí, e o raciocínio por trás do que já existe.
O suporte
O caso recorrente — dificuldade da comunidade já quantificada.

A quem serve

Os desenvolvedores de fora
Uma rota para fazer o produto funcionar, e alguém que responde.
A gestão de produto
Evidência de campo no vocabulário de quem bateu no problema.
A empresa
Adoção construída sobre capacidade, não sobre persuasão.

Quem mais tem interesse

  • A comunidade mais ampla, incluindo quem nunca posta e lê tudo.
  • O marketing, cujas mensagens a credibilidade do advocate sustenta ou contradiz.
  • A engenharia, cujo backlog recebe o que o advocate carrega.

O que exige

  • Capacidade de engenharia, porque a credibilidade vem de construir a coisa, não de descrevê-la.
  • Escrever e falar para uma plateia que vai conferir as afirmações.
  • A disposição de dizer que um produto faz algo pela metade, em público, na conta da empresa.
  • Estar em paz com uma contribuição visível em todo lugar e atribuível em quase nenhum.

Do que o trabalho depende

O papel é pago por um lado e útil ao outro, e o valor depende inteiramente de a comunidade acreditar na segunda parte. Essa crença se constrói na metade sem glamour: abrir o bug, dizer com todas as letras onde o produto fica devendo, e voltar depois com o que mudou. O advocate que faz isso é confiável e a empresa dele colhe; a metade interna do trabalho é o que torna a metade externa verdadeira — e é por isso que medir só a atividade de palco produz uma função que aos poucos para de funcionar.

As fontes publicadas

Para onde leva

O trabalho em si

A Prática cobre como este trabalho é feito — triagem, escalação, evidência, passagem de bastão — em todo o corpus.

Ler A Prática