Deploy para decisão executiva · Capítulo 4 de 20 · 60 min
Quatro métricas de entrega e a armadilha do volume
Nosso time está entregando mais rápido ou apenas quebrando mais rápido, e como eu distingo os dois no mesmo painel?
Este capítulo faz parte do curso gratuito Deploy para decisão executiva.
Estabelecer a linha de base das quatro métricas de entrega com data, fonte e denominador, e a régua acordada antes de ver o dado.
- Ler as quatro métricas de entrega como um par de velocidade e um par de estabilidade.
- Exigir data, fonte e denominador de cada número antes de aceitar comparação.
- Declarar a contrapartida de custo da frequência de publicação.
Em linguagem simples
Existem quatro números que descrevem como um time entrega software. Dois medem velocidade: com que frequência a empresa publica e quanto tempo uma mudança leva desde que foi escrita até chegar ao cliente. Dois medem estabilidade: que proporção das publicações causa problema e quanto tempo leva para voltar ao normal quando causa.
O erro caro é acompanhar apenas os dois primeiros. Frequência subindo, isolada, parece saúde e pode ser o contrário. A pesquisa de referência do setor, de 23 de setembro de 2025, encontrou relação positiva entre adoção de inteligência artificial e volume de entrega, e relação negativa entre a mesma adoção e estabilidade de entrega. Os dois pares precisam aparecer no mesmo painel, sempre.
- 01Duas métricas de velocidade, duas de estabilidade. Frequência de publicação e tempo até produção medem ritmo. Taxa de falha de mudança e tempo de restauração medem consequência. Sozinhas, as duas primeiras enganam.
- 02Todo percentual precisa do denominador ao lado. Taxa de falha de 6% significa coisa diferente em vinte publicações e em duzentas. Sem denominador, o número serve para qualquer narrativa.
- 03A régua vem antes do resultado. Materialidade combinada depois de ver o número vira justificativa. Combinada antes, tira de todo mundo a liberdade de escolher qual variação merece reunião.
- 04Frequência tem preço unitário. Na Vercel, o build é cobrado por CPU-minuto a partir de US$ 0,0035, verificado em 24 de julho de 2026 em documentação com atualização de 24 de junho de 2026. Publicar mais vezes é decisão com contrapartida orçamentária mensurável.
Glossário rápido
Frequência de publicação
Quantas vezes, num período, uma mudança chega ao cliente. Mede ritmo e, sozinha, não diz nada sobre saúde.
Taxa de falha de mudança
Proporção das publicações que causa degradação e exige correção. É a métrica que impede a frequência de virar propaganda.
Tempo de restauração
Quanto tempo leva para voltar ao estado normal depois de uma falha. Mede a capacidade de reverter, não a de evitar.
Confusão mais comum: Confundir tempo até produção com tempo de build. O build leva minutos. O tempo até produção conta desde que a mudança foi escrita até o cliente vê-la, incluindo espera por revisão, por aprovação e por janela de publicação. Quase sempre o gargalo está na espera, e otimizar o build não move o indicador.
Explique em voz alta: Traduza para o conselho, em dois números, por que um time que publica trinta vezes por semana pode estar em pior situação do que um time que publica cinco.
Entregar mais rápido e quebrar mais rápido produzem o mesmo gráfico
A frase chega em tom de boa notícia: o time dobrou a velocidade de entrega. O painel que a acompanha mostra publicações por semana subindo. É um gráfico verdadeiro e é metade da informação, porque exatamente o mesmo desenho aparece quando o time passou a publicar mais vezes para corrigir o que quebrou na publicação anterior.
A pesquisa de referência do setor tornou isso mensurável, e o primeiro cuidado é citá-la corretamente. Não existe State of DevOps 2026. O relatório anual do DORA foi renomeado para State of AI-assisted Software Development, e a edição vigente é a de 23 de setembro de 2025, com quase cinco mil profissionais pesquisados: 90% usam inteligência artificial no trabalho, mais de 80% relatam ganho de produtividade e 30% declaram pouca ou nenhuma confiança no código gerado. A relação entre adoção de IA e volume de entrega é positiva; com estabilidade de entrega, é negativa.
Existe também um modelo econômico com números publicados. O relatório de retorno sobre investimento do DORA, identificado como edição 2026.01 e com a página institucional atualizada em 22 de abril de 2026, modela para uma organização de quinhentas pessoas cerca de US$ 11,6 milhões de valor contra US$ 8,4 milhões de investimento no primeiro ano, com retorno de 39% e payback em cerca de oito meses; no mesmo cálculo a taxa de falha de mudança sobe de 5% para 6%, com US$ 344 mil de impacto negativo de indisponibilidade. Estes números foram lidos em cobertura especializada de 11 de maio de 2026, e não no documento original, e devem ser tratados como ordem de grandeza. O relatório descreve a curva em J: queda temporária de produtividade antes do ganho.
Quatro métricas, portanto, e não duas. Duas de velocidade e duas de estabilidade, sempre no mesmo painel, cada uma com data, fonte e denominador. Este módulo produz a linha de base delas e a régua que decide, antes de o dado aparecer, qual variação convoca reunião.
Modelo operacional
As quatro métricas e o que cada uma impede a outra de esconder
Elas funcionam em pares. Ler uma sozinha é o erro que transforma painel em propaganda, e é o erro mais frequente em apresentação de tecnologia para conselho.
- Frequência de publicação: Quantas vezes uma mudança chega ao cliente num período. Mede ritmo e é a mais fácil de subir artificialmente, porque fatiar a mesma entrega em dez publicações multiplica o número sem mudar nada. Exemplo: Da API da plataforma, contando apenas publicações de produção concluídas, com o período e o denominador declarados ao lado.
- Tempo até produção: Da mudança escrita até o cliente vê-la. Inclui espera por revisão e por aprovação, que é onde o tempo costuma morar, e não no build. Exemplo: Mediana da diferença entre a data do registro de alteração do código (commit) e a data da publicação que o contém, calculada sobre o trimestre e não sobre a média, que uma única espera longa distorce.
- Taxa de falha de mudança: Proporção das publicações que causa degradação e exige correção. É a métrica que impede a frequência de virar propaganda, e a que mais depende de disciplina de registro. Exemplo: Publicações que geraram incidente ou correção urgente sobre o total de publicações do período, com a definição de incidente escrita e acordada antes.
- Tempo de restauração: Quanto tempo leva para voltar ao normal depois de uma falha. Mede capacidade de reverter, e não de evitar. É a métrica que conversa diretamente com o cartão de incidente. Exemplo: Mediana entre o momento em que a degradação foi percebida e o momento em que o serviço voltou, medida em minutos e não em horas.
As quatro dependem de registro. Empresa que não registra incidente pequeno vai exibir taxa de falha excelente pelo motivo errado, e a primeira medição vira base de comparação enganosa para o ano inteiro. Essa ressalva mora ao lado do número, não em nota de rodapé.
O velocímetro sem o marcador de temperatura
Um caminhão de frota faz o trajeto em menos tempo do que no mês anterior. O painel do gestor mostra velocidade média e nada mais. O motorista pode ter encontrado um trecho novo de rodovia ou pode estar rodando com o motor acima da faixa recomendada, o que produz exatamente o mesmo número no velocímetro e uma manutenção não programada em oito semanas.
Velocidade sem temperatura é meia informação. As duas métricas de estabilidade são o marcador de temperatura da entrega, e a decisão de exibir apenas as de velocidade costuma ser tomada por quem apresenta, não por quem lê.
Evidência pública
Caso documentado: adoção de IA sobe o volume e derruba a estabilidade
DORA, programa de pesquisa do Google Cloud
O relatório anual foi renomeado para State of AI-assisted Software Development e a edição vigente é a de 23 de setembro de 2025, com quase cinco mil profissionais pesquisados e mais de cem horas de dados qualitativos. Ele mede simultaneamente adoção de IA, volume de entrega e estabilidade.
- 90% dos respondentes usam inteligência artificial no trabalho, alta de 14,1% sobre o ano anterior.
- Mais de 80% relatam ganho de produtividade e 30% declaram pouca ou nenhuma confiança no código gerado.
- A relação entre adoção de IA e volume de entrega é positiva; entre a mesma adoção e estabilidade de entrega, é negativa.
Citar State of DevOps 2026 em material executivo é erro factual verificável, e ele aparece com frequência em apresentação de fornecedor. Mais importante que o nome: frequência de publicação subindo sem taxa de falha de mudança sob observação é indicador falso de saúde, e agora existe pesquisa datada para sustentar essa exigência em comitê.
Pesquisa autorreportada com amostra global. Serve para direção do efeito e para ordem de grandeza, e não para prever o resultado de uma operação específica.
Como cada métrica é inflada, e o que pedir junto
Nenhuma das quatro é difícil de melhorar no papel. Esta tabela lista a forma mais comum de inflar cada uma e o dado que precisa vir junto para tornar o número honesto.
| Métrica | Como é inflada sem má-fé | O que pedir junto | Denominador obrigatório |
|---|---|---|---|
| Frequência de publicação | Fatiar a mesma entrega em várias publicações pequenas, ou contar prévias como publicação | Somente publicações de produção concluídas, com o período declarado | Publicações por semana, sobre semanas úteis do período |
| Tempo até produção | Medir a partir da abertura do pedido de mudança, e não da escrita, o que apaga a espera por revisão | Mediana em vez de média, e o ponto exato em que o relógio começa | Número de mudanças consideradas no cálculo |
| Taxa de falha de mudança | Não registrar incidente pequeno, o que zera o numerador sem mudar a realidade | A definição escrita de incidente, acordada antes do período de medição | Publicações com incidente sobre total de publicações |
| Tempo de restauração | Contar a partir do momento em que o time soube, e não do momento em que o cliente sentiu | O instante de início declarado e como a degradação foi detectada | Número de incidentes no período, por severidade |
Conexão com o portal
Da gestão de projetos para a mesa: régua acordada antes do dado
Materialidade definida depois de ver o resultado deixa de ser critério e vira justificativa. Combinada antes, ela retira de todos, inclusive de quem manda, a liberdade de escolher qual variação merece atenção.
Tradução executiva: Nas quatro métricas de entrega, isso significa acordar por escrito, antes do primeiro fechamento, qual variação convoca ação em cada uma delas, e valer nos dois sentidos. Sem a régua, taxa de falha subindo é chamada de amadurecimento do registro e taxa de falha caindo é chamada de mérito do time, na mesma reunião.
Use quando: for estabelecida a linha de base, e sempre que alguém propuser mudar o método de cálculo depois de ver um resultado ruim.
Fronteira: A régua disciplina a leitura e não melhora a coleta. Se o registro de incidente é incompleto, a régua vai ser aplicada a um número enviesado com toda a formalidade do mundo. Corrigir a coleta é trabalho anterior, com dono e prazo, e precisa estar declarado ao lado da primeira medição.
Guardrail
O que precisa estar escrito ao lado de cada número
A linha de base vale pelo rigor do cabeçalho, não pelo valor. Estas cinco exigências transformam quatro números soltos em documento auditável, e todas cabem em uma linha de texto cada.
- Data de corte da medição e período coberto, com a informação de que os últimos dias podem estar incompletos.
- Fonte de cada número, com preferência por sistema que registra automaticamente sobre planilha preenchida à mão.
- Denominador explícito em todo percentual: quantas publicações, quantos incidentes, sobre qual total.
- A definição escrita de incidente, acordada antes do período, com o nome de quem pode alterá-la.
- A régua de materialidade das quatro métricas, datada, valendo nos dois sentidos e com o fórum em que ela é revisada.
Rotina real
A linha de base apresentada ao comitê pela primeira vez
CTO e gerente de engenharia apresentando a Marina e ao CFO · Medição mensal, com linha de base estabelecida uma vez e revisão da régua a cada semestre.
Situação: A afirmação de que a velocidade dobrou precisa virar número. O time nunca mediu taxa de falha de mudança e registra apenas incidentes que geraram acionamento fora do horário.
Entradas: Histórico de publicações da API da plataforma, histórico do repositório, registro de incidentes existente e a fatura de build do último ciclo.
Processo: Calcular as quatro métricas sobre o mesmo trimestre fechado, com denominador explícito. Onde a coleta for incompleta, declarar a lacuna no próprio painel em vez de estimar. Acordar a régua antes de o painel ser aberto na reunião seguinte.
Saída: Uma página com quatro números, data de corte, fonte e denominador de cada um, a lacuna de registro declarada e a régua assinada com data.
Verificação humana: Marina pergunta, para cada número, de onde ele saiu e o que aconteceria se a definição mudasse. Número que muda muito com pequena mudança de definição é marcado como frágil no próprio painel, e não é usado para decidir naquele ciclo.
Como se mede: As quatro métricas, e uma quinta de processo: proporção de incidentes registrados sobre incidentes percebidos, que mede a qualidade da própria medição.
De onde saem os quatro números sem depender do slide do time
Para quem decide
Camada de execução · Para quem vai coletar. Quem decide pode pular: o que interessa à reunião é a exigência de data, fonte e denominador, já descrita acima. · opcional para quem só decide
Duas das quatro métricas saem de sistema que registra sozinho e não admite discussão: a plataforma sabe quantas publicações de produção houve, e o repositório sabe quando cada mudança foi escrita. As outras duas dependem de processo humano de registro, e é justamente por isso que precisam ser declaradas como mais frágeis no painel.
Para quem executa
- 01Frequência de publicação sai da API de deployments do fornecedor, filtrando apenas produção e estado concluído. É o número menos contestável dos quatro.
- 02Tempo até produção cruza a data do registro de alteração com a data da publicação que o contém. Use mediana, porque uma única espera longa distorce a média e o gargalo costuma estar na espera por revisão.
- 03Taxa de falha de mudança exige a definição escrita de incidente antes do período. Sem ela, o numerador muda conforme quem preenche.
- 04Tempo de restauração conta do instante em que a degradação começou, e não do instante em que o time soube. A diferença entre os dois é, por si só, um indicador de detecção.
- 05Custo de build sai da fatura e dá a contrapartida orçamentária da frequência: na Vercel, a partir de US$ 0,0035 por CPU-minuto, verificado em 24 de julho de 2026 em documentação com atualização de 24 de junho de 2026, com teto de 45 minutos por publicação.
Coleta das duas métricas de velocidade a partir de fontes que registram sozinhas. Endpoints e formato conferidos em 24 de julho de 2026.
# Frequência: publicações de produção concluídas nos últimos 100 registros
curl -s -H "Authorization: Bearer $VERCEL_TOKEN" \
"https://api.vercel.com/v6/deployments?target=production&limit=100&state=READY" \
| jq '.deployments | length'
# Mesma lista com data, para contar por semana e declarar o denominador
curl -s -H "Authorization: Bearer $VERCEL_TOKEN" \
"https://api.vercel.com/v6/deployments?target=production&limit=100&state=READY" \
| jq -r '.deployments[] | [.uid, (.created/1000 | todate)] | @tsv'
# Tempo até produção: data de escrita de cada mudança que entrou em produção.
# Cruze com a data da publicação correspondente e use a MEDIANA, não a média.
git log --first-parent --pretty=format:"%h%x09%cI%x09%s" origin/main
# Contrapartida de custo da frequência: minutos de build do ciclo,
# lidos na fatura. Build na Vercel a partir de US$ 0,0035 por CPU-minuto,
# verificado em 24/07/2026 (documentação de 24/06/2026), teto de 45 min por publicação.Contar prévias como publicação. O número triplica sem que nenhuma mudança a mais tenha chegado ao cliente, e o painel passa a medir atividade do time em vez de entrega ao cliente. O filtro de destino produção precisa estar explícito na consulta e escrito no cabeçalho do painel.
Laboratório de decisão
O comitê quer dobrar a frequência de publicação no próximo trimestre
Com a linha de base na mesa, o CTO propõe dobrar a frequência de publicação no trimestre. A taxa de falha de mudança da Nortis ainda não é confiável, porque incidente pequeno não é registrado, e a fatura mostra que build já é uma linha visível do ciclo.
O comitê aprova a meta de frequência agora, adia ou muda o alvo?
- A. Aprovar a meta de dobrar a frequência e acompanhar as demais métricas em paralelo.: Coloca em movimento o único par que o time sabe medir bem e deixa o par de estabilidade sem linha de base confiável durante justamente o trimestre em que ele mais importa. No fim, não haverá como distinguir ganho de degradação.
- B. Adiar qualquer meta até que a taxa de falha esteja medida com confiança.: É rigoroso e paralisante. O registro de incidente leva um trimestre para amadurecer, e nesse intervalo o time fica sem alvo, o que costuma significar que a frequência sobe assim mesmo, sem meta e sem observação.
- C. Aprovar meta de estabilidade primeiro: definição escrita de incidente, registro de todos os incidentes e tempo de restauração medido, com a frequência acompanhada sem meta durante o trimestre e o custo de build declarado no orçamento.: Custa um trimestre de meta de velocidade e entrega a capacidade de saber, no trimestre seguinte, se acelerar foi ganho ou dano. Também coloca a contrapartida de custo da frequência dentro do orçamento antes de ela aparecer na fatura.
Recomendação: A terceira opção, com a definição de incidente escrita e assinada antes do início do trimestre e o custo de build provisionado no orçamento.
Metas mudam comportamento, e é exatamente por isso que a ordem importa. Aprovar frequência com estabilidade sem linha de base confiável instala um incentivo que ninguém consegue auditar: se a taxa de falha subir, será atribuída ao amadurecimento do registro; se cair, ao mérito do time. As duas leituras estarão disponíveis, e a que prevalecer vai depender de quem falar mais alto. Adiar tudo tem o efeito de deixar a frequência subir sem meta e sem observação, que é o pior dos dois mundos. Estabilizar a medição primeiro custa um trimestre e devolve algo que não se compra depois: um ponto de partida em que os dois pares são comparáveis. A contrapartida de custo entra junto porque frequência tem preço unitário de build, e provisionar antes evita a discussão de fatura no meio do trimestre.
Guia prático · Guia de marketing 3 · Medição e SEO
Meça visita, origem e Core Web Vitals da landing sem pagar pelo que ninguém lê
Caso de uso: SEO e mídia paga · página de campanha com meta de conversão
No fim deste guia a landing reporta visitas, origem do tráfego e a experiência real de carregamento, com o custo de cada medição conhecido antes de ligar, e o time sabe qual número leva para a reunião de SEO.
Onde fica: Vercel: projeto > Analytics e projeto > Speed Insights. Cloudflare: Analytics & Logs > Web Analytics.
Passo a passo
Passo 1: Ligue o Web Analytics e confira o preço por evento
Instale o pacote de analytics no projeto e ative a aba Analytics. No Hobby entram 50 mil eventos por mês; no Pro cada mil eventos custam US$ 0,03. Cada visualização de página e cada evento personalizado, como envio de formulário, conta como evento.
Passo 2: Decida se precisa de UTM dentro da Vercel
A leitura por parâmetro UTM no Web Analytics exige o complemento Web Analytics Plus, de US$ 10 por mês por time. Se a empresa já atribui campanha no GA4 ou no CRM, não pague duas vezes: use a Vercel para tráfego e desempenho e deixe a atribuição onde ela já mora.
Passo 3: Ligue o Speed Insights na camada certa
Desde 25 de agosto de 2026 o Speed Insights tem camada gratuita em todos os planos: 10.000 eventos por time a cada 30 dias, só com a nota geral de experiência. As cinco métricas (FCP, LCP, INP, CLS e TTFB), com quebra por rota e país, estão no Speed Insights Plus, a US$ 10 por projeto por mês mais US$ 0,65 a cada 10.000 eventos no Pro.
Passo 4: Reduza a amostra antes de pagar mais
Landing com muito tráfego não precisa medir todas as visitas. Ajuste a taxa de amostragem do pacote do Speed Insights e filtre rotas internas. Verificação: compare o volume de eventos da semana anterior com o da seguinte e confira que a nota não mudou de faixa.
Passo 5: Se a página está na Cloudflare, confira a mudança na contagem
O Web Analytics da Cloudflare passou a medir navegações internas de aplicações de página única com a API de soft navigation do Chrome, mudança concluída em 4 de setembro de 2026. Visitas, visualizações e LCP podem ter mudado de patamar. Não compare agosto com setembro sem anotar essa quebra de série.
| Ajuste | Valor recomendado |
|---|---|
| Web Analytics (Pro) | US$ 0,03 por mil eventos; UTM só com Web Analytics Plus (US$ 10 por mês por time) |
| Speed Insights | Camada gratuita para a nota geral; Plus por projeto só nas landings que pesam na receita |
| Amostragem | Reduzir em páginas de alto tráfego antes de contratar mais eventos |
Ao passar de 10.000 eventos em 30 dias, a camada gratuita do Speed Insights pausa a coleta por ao menos 14 dias. A página continua no ar, mas o relatório fica vazio justamente no pico da campanha.
Nota de laboratório de uma ferramenta de auditoria não substitui dado de visitante real. Para SEO, o que conta é a experiência medida em campo.
Critério de pronto e como medir
- Critério de pronto: a landing aparece no Web Analytics com visitas do dia, o Speed Insights mostra a nota da rota principal e o custo mensal estimado de cada medição está anotado.
- LCP da rota principal abaixo de 2,5 segundos no percentil 75, conferido no Speed Insights Plus ou no relatório de Core Web Vitals do Search Console.
Imagem: Documentação da Vercel.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Imagem: Documentação da Vercel.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Caso Nortis · Semana 2, sexta-feira
O CTO afirma que o time dobrou a velocidade de entrega depois de adotar assistência de IA. O painel mostra número de publicações por semana, e nada mais.
Frequência de publicação subindo sem taxa de falha de mudança sob observação é indicador falso de saúde, e o relatório de referência do setor, de 23 de setembro de 2025, mostra relação positiva entre adoção de IA e throughput e relação negativa com estabilidade.
Estabelecer a linha de base das quatro métricas de entrega com data, fonte e denominador, e registrar a régua de materialidade antes de olhar o resultado.
Exemplo trabalhado
O painel que só tinha metade das métricas
Marina, CEO da Nortis, na sexta-feira depois do comitê
O CTO afirma que o time dobrou a velocidade de entrega depois de adotar assistência de inteligência artificial. O painel mostra número de publicações por semana, e nada mais. Não há data de corte declarada, não há denominador e não há fonte além da própria ferramenta de publicação.
Passo a passo do exemplo
Passo 1: Pedir o par que falta antes de discutir o par que existe
Marina não questiona a frequência. Pede a taxa de falha de mudança e o tempo de restauração no mesmo intervalo. Sem os dois, a afirmação de velocidade é incompleta por construção e não admite verificação.
Passo 2: Exigir denominador e data em cada número
Quantas publicações no período, quantas causaram degradação, medido como e por quem, com data de corte. O número de publicações vem da API da plataforma; a taxa de falha depende de alguém ter registrado incidente, e é aí que aparece a primeira lacuna de processo da Nortis.
Passo 3: Confrontar com a referência do setor, citada corretamente
Não existe relatório State of DevOps 2026. O relatório anual foi renomeado para State of AI-assisted Software Development e a edição vigente é a de 23 de setembro de 2025, com quase cinco mil profissionais pesquisados. Ela registra relação positiva entre adoção de IA e volume de entrega, e negativa entre a mesma adoção e estabilidade.
Passo 4: Declarar a contrapartida de custo e fixar a régua
Publicar mais vezes consome build, cobrado por CPU-minuto a partir de US$ 0,0035, verificado em 24 de julho de 2026 em documentação com atualização de 24 de junho de 2026. A régua de materialidade das quatro métricas é acordada ali, antes de o próximo dado aparecer, e registrada com data e nome de quem pode alterá-la.
Resultado: A afirmação de que a velocidade dobrou continua de pé para uma das quatro métricas e perde a generalidade. O comitê descobre que a taxa de falha não é medida porque incidente pequeno não é registrado, e isso vira o primeiro item de trabalho, com dono.
Continua sob responsabilidade humana: A linha de base mede o que o processo registra, não o que aconteceu. Enquanto incidente pequeno não for registrado, a taxa de falha da Nortis vai parecer excelente pelo motivo errado. Isso precisa estar escrito ao lado do número, com a data em que a lacuna foi identificada, ou a primeira medição vira base de comparação enganosa para o ano inteiro.
Exercício: a linha de base das quatro métricas
Exercício · 30 min
Passo 1: Escolha um trimestre fechado e calcule as quatro métricas sobre ele, sem misturar períodos.
Passo 2: Ao lado de cada número, escreva a fonte, a data de corte e o denominador. Onde a fonte for planilha preenchida à mão, marque o número como frágil.
Passo 3: Escreva a definição de incidente que a empresa vai usar e leve-a para acordo antes do próximo período de medição.
Passo 4: Combine a régua de materialidade das quatro métricas, valendo nos dois sentidos, e registre a data do acordo e quem pode alterá-la.
Passo 5: Some o custo de build do ciclo e escreva-o no mesmo documento, como contrapartida declarada da frequência.
No fim você tem: Entregável: Uma página com as quatro métricas, fonte, data e denominador de cada uma, a definição de incidente acordada, a régua datada e o custo de build do ciclo declarado ao lado.
Entregável do módulo: Linha de base das quatro métricas de entrega (frequência de publicação, tempo até produção, taxa de falha de mudança e tempo de restauração), com data da medição, fonte e denominador de cada número, régua de materialidade acordada antes de ver o dado e a contrapartida de custo da frequência declarada.
- O painel que eu recebo hoje traz as quatro métricas, e eu sei dizer em que data exigi a inclusão do par de estabilidade e quem respondeu por ela.
- Eu exijo data, fonte e denominador antes de aceitar qualquer comparação de entrega entre períodos.
- Eu sei dizer quanto custa, em build, a frequência de publicação que o time propõe para o próximo trimestre.
Com a entrega medida, o comitê volta ao ponto que abriu o curso: por que a conta subiu 41%.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- Destrave o que impede o robô de ler o sitesugerido pelo grafoApresenta os conceitos “LCP” e “Core Web Vitals”, usados em “Quatro métricas de entrega e a armadilha do volume”.
- CursoNode.js: JavaScript no Servidorsugerido pelo grafo4 capítulos de “Deploy para decisão executiva” usam conceitos apresentados em “Node.js: JavaScript no Servidor”.
- CursoGitHub: Controle de Versão do Zerosugerido pelo grafo3 capítulos de “Deploy para decisão executiva” usam conceitos apresentados em “GitHub: Controle de Versão do Zero”.
Depois, siga para
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Software e IA para executivosLer o painel de engenharia pelas cinco métricas juntasExaminar conexões de Ler o painel de engenharia pelas cinco métricas juntas
- Do Agile ao Agentic Operating ModelParar de aprovar esforço e passar a aprovar entrega provadaExaminar conexões de Parar de aprovar esforço e passar a aprovar entrega provada
- Engenharia de Software para ExecutivosDescobrir a falha antes que o cliente ligueExaminar conexões de Descobrir a falha antes que o cliente ligue
- Autoridade Temática e SEO de EntidadesComo parar de reportar ruído como resultadoExaminar conexões de Como parar de reportar ruído como resultado
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.