Mapeamento do fluxo de entrega e pontos de medição

Mapear o fluxo de entrega é transformar o caminho que uma mudança percorre (da ideia ao uso em produção) em um modelo visual e mensurável. O objetivo não é “desenhar um processo bonito”, e sim identificar onde o trabalho espera, onde há retrabalho, onde o risco aumenta e em quais pontos é possível coletar dados confiáveis para orientar decisões. Um bom mapeamento deixa explícitas as etapas, os responsáveis, as entradas e saídas, os sistemas envolvidos e, principalmente, os eventos que marcam transições de estado (por exemplo: “PR aberto”, “PR aprovado”, “build concluído”, “deploy iniciado”, “deploy finalizado”).

Neste capítulo, você vai aprender a: (1) delimitar o fluxo de entrega que realmente importa para o seu produto, (2) mapear etapas e filas com um nível de detalhe útil, (3) escolher pontos de medição que gerem indicadores acionáveis e (4) padronizar eventos e fontes de dados para reduzir ambiguidade e ruído.

O que é o fluxo de entrega (e o que não é)

Fluxo de entrega é a sequência de atividades e esperas necessárias para transformar uma mudança em valor entregue ao usuário. Ele atravessa áreas e ferramentas: backlog, desenvolvimento, revisão, integração, testes, homologação, deploy, monitoramento e correções. O fluxo real quase nunca é igual ao “processo oficial”, porque inclui filas, dependências, aprovações informais, interrupções e re-triagens.

Não confunda fluxo de entrega com:

• Estrutura organizacional: o fluxo não é um organograma. Ele pode atravessar times e ainda assim ser um único fluxo.

  Continue em nosso aplicativo

  Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

  ou continue lendo abaixo...

  

  Baixar o aplicativo

• Pipeline de CI/CD: o pipeline é uma parte do fluxo. O fluxo inclui decisões humanas, priorização, espera por revisão, validações e incidentes.

• Checklist de qualidade: checklists são controles; o fluxo descreve como o trabalho se move e onde medir.

Por que mapear antes de medir

Métricas sem mapeamento tendem a medir “o que é fácil” (por exemplo, quantidade de commits) em vez de medir “o que importa” (por exemplo, tempo de espera por revisão, taxa de retrabalho após QA, tempo até recuperação após falha). O mapeamento ajuda a responder perguntas essenciais:

• Onde começa e onde termina a medição (qual é o evento de início e qual é o evento de fim)?

• Quais estados intermediários são relevantes para diagnosticar gargalos?

• Quais dados existem e quais precisam ser instrumentados?

• Quais variações do fluxo existem (hotfix, mudança pequena, mudança grande, experimento, migração)?

Tipos de mapa: escolha o nível certo

Mapa macro (end-to-end)

Mostra grandes fases e principais transições. Útil para alinhar times e identificar onde a maior parte do tempo é espera. Exemplo de fases: “Descoberta e priorização” → “Implementação” → “Validação” → “Entrega” → “Operação”.

Mapa de fluxo detalhado (com filas e critérios)

Inclui estados, filas, critérios de entrada/saída e responsáveis. Útil para definir pontos de medição e padronizar eventos. Exemplo: “PR aberto” → “Aguardando revisão” → “Revisão em andamento” → “Aprovado” → “Build” → “Testes automatizados” → “Homologação” → “Deploy”.

Mapa por classe de mudança

Separar classes evita misturar coisas incomparáveis. Um hotfix tem urgência e controles diferentes de uma feature grande. Você pode mapear 2 a 4 classes, como: “mudança padrão”, “hotfix”, “mudança regulatória”, “experimento”.

Passo a passo prático para mapear o fluxo de entrega

1) Defina o escopo: qual “mudança” você está rastreando

Escolha uma unidade rastreável e consistente. Exemplos comuns:

• Pull Request (PR): bom para medir desenvolvimento e revisão, mas pode não representar entrega se o deploy for desacoplado.

• Change/Release: bom para medir entrega em produção, mas pode agrupar muitas mudanças e esconder variações internas.

• Ticket: bom para rastrear do pedido ao deploy, mas depende de disciplina de atualização e vínculo com código.

Recomendação prática: se sua organização usa PR e deploy contínuo, comece com PR + evento de deploy associado (via tag, commit SHA ou referência do PR). Se usa releases em lote, comece com release e complemente com amostragem de PRs internos para entender gargalos.

2) Estabeleça o ponto de início e o ponto de fim

Sem isso, o “tempo de ciclo” vira um número arbitrário. Defina eventos observáveis e registráveis. Exemplos:

• Início: ticket movido para “Em desenvolvimento”, primeiro commit no branch, PR aberto.

• Fim: deploy finalizado em produção, feature flag habilitada para 100%, mudança validada em produção.

Evite pontos subjetivos como “quando o dev começou a pensar” ou “quando o PO aprovou mentalmente”. Prefira eventos com timestamp em sistemas.

3) Liste as etapas reais e as filas (esperas)

Faça uma coleta rápida com quem executa o trabalho. A pergunta-chave é: “O que acontece com uma mudança desde o início até o fim, incluindo esperas?”. Registre etapas e, separadamente, filas. Exemplo:

• Etapa: “Revisar PR” (alguém está trabalhando nisso).

• Fila: “Aguardando revisão” (ninguém está trabalhando nisso).

Essa distinção é crucial porque muitas melhorias vêm de reduzir espera, não de acelerar execução.

4) Para cada etapa, defina entrada, saída e critérios

Para evitar ambiguidade, descreva:

• Entrada: o que precisa existir para a mudança entrar na etapa (ex.: PR aberto com checklist preenchido).

• Saída: o que caracteriza que a etapa terminou (ex.: PR aprovado por 2 revisores e build verde).

• Critérios: regras que impedem avanço (ex.: cobertura mínima, testes obrigatórios, aprovação de segurança).

Isso ajuda a identificar pontos onde a mudança “volta” (rework) e onde há bloqueios recorrentes.

5) Identifique variações do fluxo (ramificações)

Mapeie caminhos alternativos, por exemplo:

• Hotfix: pula homologação? exige aprovação extra? deploy fora da janela?

• Dependência externa: aguarda API de outro time? aguarda fornecedor?

• Reprovação: falha em testes e volta para desenvolvimento.

Se você não registrar ramificações, suas métricas vão misturar fluxos e gerar interpretações erradas (por exemplo, achar que “o time está lento” quando, na verdade, 20% das mudanças entram em um caminho com aprovação regulatória).

6) Desenhe o mapa em formato de estados e transições

Um formato útil para medir é uma máquina de estados: cada mudança está em um estado por vez, e eventos a movem para o próximo estado. Exemplo simplificado:

Backlog selecionado -> Em desenvolvimento -> PR aberto -> Aguardando revisão -> Revisão em andamento -> Aprovado -> Build/Testes -> Pronto para deploy -> Deploy em produção -> Validado

Mesmo que você mantenha um diagrama visual em uma ferramenta, escreva a versão textual com nomes padronizados. Isso facilita instrumentação e consultas.

7) Valide o mapa com dados e com casos reais

Pegue 5 a 10 mudanças recentes e “reproduza” o caminho delas no mapa. Pergunte:

• Alguma etapa não existe na prática?

• Alguma fila está faltando?

• Há estados que ninguém atualiza?

• O evento de fim é sempre observável?

Se o mapa não consegue representar casos reais sem exceções demais, ele está abstrato demais ou detalhado demais no lugar errado.

Como escolher pontos de medição (instrumentação) no fluxo

Pontos de medição são eventos ou estados onde você captura timestamps e atributos para calcular indicadores. Um ponto de medição bom tem três características: (1) é objetivo e registrável, (2) ocorre com frequência suficiente para gerar amostra e (3) está ligado a uma decisão ou ação possível.

Categorias de pontos de medição

• Transições de estado: quando a mudança entra ou sai de um estado (ex.: “PR aberto”, “PR aprovado”).

• Eventos de qualidade: falhas e aprovações (ex.: “teste E2E falhou”, “scan de segurança bloqueou”).

• Eventos operacionais: deploy, rollback, incidentes (ex.: “deploy iniciado”, “rollback executado”).

• Eventos de retrabalho: reabertura, reversão, retorno de etapa (ex.: “ticket voltou para Em desenvolvimento”).

O conjunto mínimo de pontos para começar

Um conjunto inicial costuma equilibrar esforço e valor. Exemplo de pontos mínimos para uma mudança baseada em PR:

• T1: PR aberto (início do trecho “revisão e integração”).

• T2: primeira revisão iniciada (reduz cegueira sobre fila).

• T3: PR aprovado.

• T4: merge realizado.

• T5: build/testes concluídos com sucesso no main.

• T6: deploy em produção finalizado.

Com esses timestamps, você consegue decompor tempos: espera por revisão (T2-T1), duração da revisão (T3-T2), tempo até merge (T4-T3), tempo de integração (T5-T4), tempo até produção (T6-T5).

Pontos adicionais para diagnosticar qualidade e retrabalho

• Falha de pipeline: timestamp e tipo (lint, unit, integração, E2E).

• Reabertura de PR: após aprovação, voltou por falha ou mudança de requisito.

• Rollback: associado ao deploy e ao motivo.

• Bug pós-deploy: criado dentro de uma janela (ex.: 7 dias) e vinculado ao deploy/commit.

Esses pontos permitem separar “demora por fila” de “demora por instabilidade” e “demora por retrabalho”.

Exemplo prático: mapeando um fluxo típico com PR e deploy contínuo

Considere um time que trabalha com trunk-based development, PRs curtos e deploy diário. Um mapa detalhado pode ser:

• Em desenvolvimento: branch criado, commits locais.

• PR aberto: PR criado, checklist preenchido.

• Aguardando revisão: nenhum revisor atribuído ou ninguém iniciou.

• Revisão em andamento: comentários e ajustes.

• Aguardando CI: pipeline em execução ou aguardando agente.

• Pronto para merge: aprovado e CI verde.

• Merge: merge no main.

• CI no main: build/testes pós-merge.

• Pronto para deploy: artefato gerado.

• Deploy em produção: execução do deploy.

• Validação pós-deploy: smoke test, monitoramento inicial.

Pontos de medição recomendados nesse fluxo:

• PR criado (início do trecho revisável).

• Revisor atribuído e primeira revisão iniciada (captura fila).

• PR aprovado (fim da revisão).

• Merge (início da integração no main).

• CI do main concluída (estabilidade do main).

• Deploy iniciado e finalizado (tempo e confiabilidade de deploy).

• Alarme/erro crítico em até X minutos após deploy (sinal de regressão imediata).

Note que “Validação pós-deploy” pode ser automatizada (smoke) ou manual; se for manual e não tiver registro, você terá um buraco de dados. Nesse caso, ou instrumenta (registro de execução) ou redefine o fim para “deploy finalizado” e mede qualidade pós-deploy por outros eventos (incidentes, bugs, rollback).

Como lidar com fontes de dados e rastreabilidade

Mapear o fluxo também é mapear onde os dados vivem. Em geral, você terá pelo menos três fontes: ferramenta de gestão de trabalho (tickets), repositório/PR (código) e CI/CD (pipelines e deploys). O desafio é conectar tudo com um identificador comum.

Estratégias de vínculo

• ID do ticket no título do PR e nas mensagens de commit: facilita correlação automática.

• Tag de release com lista de commits: útil em releases em lote.

• Metadados no deploy: registrar commit SHA, serviço, ambiente, autor, link do PR.

Defina um padrão simples e verificável. Exemplo de convenção:

[PROJ-1234] Descrição curta

Aplicado em: título do PR, commits principais e, quando possível, no registro do deploy. Isso reduz “mudanças órfãs” que não entram nas métricas.

Qualidade do dado: regras mínimas

Sem regras mínimas, os indicadores viram discussão sobre a validade do número. Algumas regras práticas:

• Todo PR deve estar vinculado a um ticket (exceto mudanças triviais documentadas).

• Todo deploy deve registrar commit SHA e serviço/artefato.

• Estados do ticket devem ser atualizados por automação quando possível (ex.: ao abrir PR, mover para “Em revisão”).

• Eventos de falha de pipeline devem ter classificação padronizada (ex.: “unit”, “integration”, “e2e”, “security”).

Identificando gargalos e riscos a partir do mapa

O mapa permite localizar onde medir para encontrar gargalos. Alguns padrões comuns e como instrumentar:

Fila de revisão

Sintoma: muito tempo entre PR aberto e primeira revisão. Medição: timestamp de PR aberto e timestamp da primeira atividade de revisão. Ação típica: políticas de WIP, rotação de revisores, limites de tamanho de PR.

Instabilidade de pipeline

Sintoma: muitas falhas e reexecuções. Medição: taxa de falha por estágio, tempo perdido em reexecuções, principais causas. Ação típica: melhorar testes, reduzir flakiness, cache, paralelismo, isolamento de testes.

Espera por homologação/aprovação

Sintoma: mudanças prontas acumulam antes de deploy. Medição: tempo em “Pronto para deploy” e frequência de janelas. Ação típica: automatizar validações, reduzir dependência de janelas, feature flags.

Retrabalho pós-merge

Sintoma: mudanças voltam após merge por bugs ou requisitos. Medição: reverts, hotfixes associados, bugs criados após deploy vinculados ao commit. Ação típica: melhorar revisão, testes de contrato, validação de requisito antes do merge.

Checklist de implementação: do mapa ao painel de indicadores

Depois de mapear e escolher pontos de medição, transforme isso em um plano executável:

• Defina eventos e nomes padronizados: lista de eventos com descrição e fonte (ex.: “PR_OPENED” vem do repositório; “DEPLOY_FINISHED_PROD” vem do CD).

• Defina campos obrigatórios: ticket_id, pr_id, commit_sha, serviço, ambiente, timestamps.

• Crie um dicionário de dados: significado de cada campo, formato, regras de preenchimento.

• Automatize coleta: webhooks, APIs, logs de pipeline, exportações agendadas.

• Crie validações: detectar PR sem ticket, deploy sem commit, timestamps fora de ordem.

• Comece com um recorte: um serviço ou um time, uma classe de mudança, 4 a 6 pontos de medição.

Modelo de tabela de pontos de medição (para usar no time)

Uma forma prática de operacionalizar é manter uma tabela que conecta etapa, evento e uso do dado:

Etapa: PR aberto | Evento: PR_OPENED | Fonte: Repo | Campos: pr_id, ticket_id, author, created_at | Uso: início do ciclo de revisão/integração
Etapa: Aguardando revisão | Evento: FIRST_REVIEW_STARTED | Fonte: Repo | Campos: pr_id, first_review_at | Uso: medir fila de revisão
Etapa: Revisão concluída | Evento: PR_APPROVED | Fonte: Repo | Campos: pr_id, approved_at, approvals_count | Uso: duração da revisão
Etapa: Merge | Evento: PR_MERGED | Fonte: Repo | Campos: pr_id, merged_at, merge_commit_sha | Uso: início da integração no main
Etapa: CI main | Evento: MAIN_CI_PASSED | Fonte: CI | Campos: commit_sha, finished_at, duration, stage_failures | Uso: estabilidade e tempo de integração
Etapa: Deploy produção | Evento: DEPLOY_FINISHED_PROD | Fonte: CD | Campos: commit_sha, service, finished_at, status | Uso: tempo até produção e confiabilidade

Esse artefato evita que cada pessoa interprete “o que medir” de um jeito. Também facilita auditoria: se um indicador parece estranho, você volta ao evento e verifica a fonte.

Armadilhas comuns ao mapear e medir

Detalhe excessivo no lugar errado

Mapas com dezenas de micro-etapas (ex.: “rodar comando X”, “abrir ferramenta Y”) ficam caros de manter e não geram decisão. Prefira detalhar onde há espera, retrabalho ou risco.

Estados que dependem de atualização manual

Se a métrica depende de alguém “mover o card”, ela tende a ficar inconsistente. Sempre que possível, use eventos automáticos (abertura de PR, merge, execução de pipeline, deploy).

Medir apenas o que está dentro do time

Se aprovações externas ou dependências são parte relevante do tempo total, elas precisam aparecer no mapa como filas/etapas. Caso contrário, você otimiza o que já é rápido e ignora o gargalo real.

Não separar classes de mudança

Hotfix e feature grande no mesmo indicador podem distorcer a leitura. No mapa, registre a classe e use-a como filtro nas análises.

Exercício guiado: crie seu primeiro mapa e seus primeiros pontos

Use este roteiro com seu time (30 a 60 minutos):

• Escolha uma mudança recente que foi para produção (uma feature ou correção).

• Liste os eventos com timestamps que você consegue recuperar hoje (PR aberto, merge, deploy, etc.).

• Desenhe os estados pelos quais ela passou e marque onde houve espera.

• Repita com mais 2 mudanças e ajuste o mapa para cobrir variações.

• Selecione 4 a 6 pontos de medição que existam para todas as mudanças analisadas.

• Defina lacunas de instrumentação: quais eventos não têm registro e como capturá-los.

Ao final, você terá um mapa que representa o fluxo real e um conjunto inicial de pontos de medição que podem ser coletados de forma consistente, servindo de base para indicadores de fluxo, estabilidade e retrabalho.