Como diagnosticar equipes de Tecnologia em 2027?

Requisitos

1. Acesso de leitura ao repositório e à esteira de deploy (CI/CD).
2. Saber exatamente qual evento da esteira marca o deploy em produção.
3. Registro de incidentes. Se não tiver, hotfix e revert funcionam como substituto.

Como fazer

1. Defina uma janela de 3 a 6 meses e liste todos os deploys em produção.
2. Frequência: divida o total de deploys pelas semanas da janela.
3. Tempo até produção: meça do primeiro commit ao deploy. Use a mediana, não a média.
4. Taxa de falha: quantos deploys geraram incidente, hotfix ou revert, dividido pelo total. Recuperação: tempo da falha até o próximo deploy que resolveu.
5. Compare cada número com as faixas do DORA. O pulo do gato: leia velocidade e estabilidade juntas, nunca separadas.

Cuidados

1. Só produção conta. Deploy em staging ou teste fica de fora.
2. Poucos deploys fazem o número oscilar muito. Sempre declare o volume da janela.
3. Nunca leia uma métrica isolada. Velocidade boa com falha alta quer dizer que o time entrega mais rápido do que consegue verificar.

Requisitos

1. Um formulário anônimo que leva uns 10 minutos por pessoa.
2. O time precisa saber que o resultado avalia o processo, nunca as pessoas.
3. Os números do DORA e do Value Stream Mapping, para cruzar.

Como fazer

1. Escolha de 6 a 8 dimensões: deploy, revisão, monitoramento, foco, saúde do código, feedback local, clareza de requisitos.
2. Faça uma pergunta por dimensão, com nota de 1 a 10. Nota alta sempre significa melhor.
3. Busque no mínimo 80% de resposta.
4. Olhe a mediana e a distância entre a maior e a menor nota. Mais de 5 pontos de diferença indica time dividido (convenção deste guia).
5. Cruze cada dimensão com um número concreto: revisão com a fila de revisão, deploy com o DORA.

Cuidados

1. Amostra pequena. Com 9 respostas, declare a amostra e trate a mediana como sinal, não como verdade absoluta.
2. Não avalia pessoas. Se for usado para avaliar alguém, o questionário para de funcionar.
3. Nota e dado podem divergir. Quando divergem, os dois entram na investigação.

Requisitos

1. Acesso de leitura a todos os repositórios da organização.
2. A lista dos sistemas que vivem fora de repositório (ERP, ferramentas contratadas) e de quem cuida de cada um.
3. Uma conversa de uns 30 minutos com quem conhece a arquitetura.

Como fazer

1. Classifique cada repositório pela última mudança: ativo (até 90 dias), em manutenção (até 180), dormente (até 540) ou abandonado (mais de 540).
2. Mapeie as conexões: dependências declaradas no código e pares que mudam juntos. Acima de 0,5 de co-mudança sem dependência declarada é uma ligação que ninguém desenhou.
3. Para cada sistema, conte quantas pessoas fizeram 80% das mudanças. Se foi uma só, é ponto único de falha.
4. Classifique a prontidão com três perguntas: tem dono claro? Tem teste no caminho crítico? Tem interface documentada? Três sim = pronto. Um não = com trabalho. Dois ou mais nãos, ou ponto único de falha = bloqueado.
5. Analise a fundo só os sistemas do recorte e valide o mapa com o time.

Cuidados

1. Abandonado não é desligado. Confirme se ainda roda algo em produção.
2. Escopo largo dilui o sinal. Inventarie tudo, mas vá fundo só no recorte.
3. Os limiares são convenção deste guia. Ajuste ao ritmo da sua operação e deixe claro.

Requisitos

1. Os resultados das outras seis análises. Cinco dos sete eixos saem de lá.
2. Um questionário curto sobre como o time usa AI e se existe alguma política.
3. Uma conversa sobre governança de dados com quem cuida dessa parte.

Como fazer

1. Avalie cada eixo em três níveis. L1: não existe ou cobre até um terço da operação. L2: existe, mas não é padrão. L3: é o jeito padrão de fazer as coisas.
2. Use evidência direta quando tiver. Nos outros eixos, derive das análises anteriores, mas deixe claro de onde veio.
3. Ordene os eixos pelo que trava os demais. A sequência natural: dado e infraestrutura primeiro, depois verificação e observabilidade, por último uso de AI.
4. Não calcule média nem nota única. O que importa são as combinações entre os eixos.
5. Escreva a política de AI do time, se ainda não existir. O pior caso é “sai usando”.

Cuidados

1. Adoção não é prontidão. Todo mundo usando Copilot não diz nada sobre se a base está pronta.
2. Eixo derivado herda a precisão da análise que alimentou ele. Nada de casas decimais.
3. O nível serve para localizar, não para dar nota. A conversa que importa é sobre o que trava.

O que amplifica a AI

Em 2025, o DORA publicou sete capacidades que amplificam o efeito da AI. Nenhuma delas se compra pronta.

1. Posição clara sobre AI, comunicada para o time inteiro.
2. Ecossistema de dados organizado e saudável.
3. Dados internos acessíveis para a AI consumir.
4. Controle de versão sólido.
5. Trabalho em lotes pequenos.
6. Foco no usuário.
7. Plataforma interna de qualidade.