Experiência do desenvolvedor

Experiência do desenvolvedor não é sobre conforto: é sobre atrito, e atrito é tempo e energia gastos em coisas que não entregam valor. Um build de 25 minutos, um ambiente local que quebra toda semana, um acesso que depende de ticket — cada um custa pouco por vez e muito por trimestre, e o custo aparece como prazo estourado e gente indo embora.

Onde o atrito mora

Os suspeitos de sempre, em ordem de frequência:

• Espera: build lento, teste instável (flaky), fila de revisão, ambiente compartilhado disputado.
• Setup: dias para configurar a máquina; ambiente local que “só funciona na máquina do fulano”.
• Ticket para tudo: acesso, ambiente, banco, domínio — coisas que poderiam ser autoatendimento.
• Contexto perdido: não saber onde está o log, qual é o painel, quem é o dono do serviço vizinho.
• Depurar a plataforma em vez do próprio código: erro de pipeline sem mensagem útil.

Teste instável merece destaque: ele destrói a confiança na suíte inteira. A regra saudável é tratar teste intermitente como bug de prioridade alta — quarentena imediata, correção com prazo — porque o custo real é as pessoas ignorarem falhas legítimas.

Métricas de experiência

Combine dados de sistema com percepção, como manda o SPACE:

Métrica	Alvo saudável
Tempo até o primeiro deploy (pessoa nova)	1 a 2 dias
Tempo até o primeiro deploy (serviço novo)	menos de 1 dia
Duração do CI no pull request	menos de 10 minutos
Taxa de falha intermitente	perto de zero
Tempo até primeira revisão	poucas horas
Tickets manuais por semana	tendendo a zero
Satisfação com a plataforma	pesquisa trimestral

A primeira delas é o melhor termômetro isolado que existe: onboarding lento revela toda a dívida de plataforma de uma vez.

Tempo até o primeiro deploy

Faça o exercício com a próxima pessoa que entrar. Cronometre, anote cada bloqueio, e não ajude antes de registrar onde ela travou.

09h00  clone do repositório
09h40  falta acesso ao registry (ticket)          ← 6h de espera
16h10  build local falha: versão do runtime
17h00  primeiro teste rodando
D+1    primeiro PR
D+2    deploy em produção

Cada bloqueio é um item de backlog da plataforma, com dono. Repita a cada trimestre — é a forma mais barata de auditar a própria plataforma.

Ambiente local e ambiente efêmero

O ambiente local ideal sobe com um comando e não depende de configuração manual:

make dev        # ou devcontainer / docker compose / tilt / nix
# sobe dependências, aplica migrations, carrega dados de exemplo e inicia com hot reload

Quando reproduzir tudo localmente for inviável (dezenas de serviços, dependência gerenciada de nuvem), o caminho é o ambiente efêmero por pull request: cada PR ganha um ambiente real, com URL própria, destruído no merge. Isso resolve fila de homologação, elimina o “na minha máquina funciona” e permite revisão do comportamento, não só do diff.

Para funcionar sem quebrar o orçamento: TTL curto com destruição automática, dados sintéticos (nunca dado pessoal de produção — veja compliance), e dimensionamento mínimo.

Ouvindo os usuários internos

Dados mostram o quê; conversa mostra por quê. Três práticas simples e eficazes:

• Pesquisa trimestral curta, com uma pergunta aberta (“qual é o maior atrito hoje?”).
• Observar alguém trabalhando por uma hora, sem interferir. Você vai ver contornos que ninguém relata porque já se acostumou.
• Canal de suporte da plataforma com métrica: as perguntas repetidas são um mapa do que falta em documentação ou automação.

Feche o ciclo publicamente: escolha um ou dois itens por trimestre, resolva e conte o que mudou. Pesquisa sem ação visível para de ser respondida — e aí você perde o instrumento.

Um alerta final: DX não é conforto sem limite. Reduzir atrito não pode significar remover guarda-corpo de segurança ou de qualidade. O objetivo é que o caminho seguro seja também o caminho fácil — quando os dois coincidem, ninguém precisa escolher.

Próximo passo: você fechou a trilha de Plataforma. Ligue o investimento ao resultado em Métricas DORA e ao custo em FinOps.