Seu Template de Dados para o Ciclo de Vida de Desenvolvimento de Software

O Horário de Início do Evento registra a data e hora exatas em que uma atividade começou, fornecendo a ordem cronológica necessária para reconstruir o fluxo do processo.

Os timestamps são a base de toda análise de Process Mining temporal. Eles servem para calcular KPIs como tempos de ciclo, de espera e de processamento. Analisar timestamps ajuda a localizar gargalos, medir a eficiência e entender a duração de cada estágio do ciclo de vida. Por exemplo, o intervalo entre o envio do código e o fim da revisão pode revelar lentidões no processo de peer review.

Este timestamp é essencial para ordenar os events corretamente e calcular todas as métricas baseadas em tempo, como cycle time e gargalos.

Disponível em logs de eventos, trilhas de auditoria ou tabelas de histórico que registram alterações nos itens de trabalho de desenvolvimento.

O ID do Item de Desenvolvimento é a chave primária que identifica cada instância de caso no ciclo de vida. Cada ID representa um trabalho distinto — como história, tarefa ou correção de bug — desde sua criação até a resolução final ou deploy.

Na análise de Process Mining, esse atributo é essencial para reconstruir a jornada de cada item. Ele permite que a ferramenta vincule atividades relacionadas, como 'Desenvolvimento Iniciado', 'Peer Review Concluído' e 'Implantado em Produção', em um fluxo coerente. Analisar itens individuais ajuda a identificar variações, atrasos e loops de retrabalho específicos.

Este é o identificador de case fundamental necessário para rastrear o ciclo de vida completo de cada item de trabalho de desenvolvimento, do início ao fim.

Normalmente encontrado nas tabelas principais de itens de trabalho ou de chamados de um sistema de gestão de desenvolvimento de software.

O Nome da Atividade descreve uma etapa específica ou mudança de status no processo de desenvolvimento. Essas atividades formam os nós no mapa do processo, representando marcos como 'Item Aprovado para Desenvolvimento', 'Código Enviado para Revisão' ou 'Testes de QA Concluídos'.

Este atributo é vital para visualizar o fluxo e entender a sequência de eventos. Ao analisar as atividades, os times identificam os caminhos comuns, descobrem desvios e medem o tempo em cada estágio. Ele é a base para análise de gargalos, detecção de retrabalho e checagem de conformidade com o modelo ideal.

Define as etapas do processo, permitindo a visualização e análise do workflow de desenvolvimento.

Geralmente derivado de logs de mudança de status, fluxos de eventos ou tabelas de histórico de auditoria dos itens de desenvolvimento.

O atributo Source System identifica a aplicação ou plataforma de origem onde os dados do ciclo de vida de desenvolvimento foram registrados. Isso é particularmente útil em ambientes onde múltiplas ferramentas são usadas, como o Jira para rastreamento de chamados e o GitLab para gestão de código-fonte.

Na análise, especificar o Source System ajuda na validação dos dados e fornece contexto para os dados do processo. Permite uma análise comparativa entre processos gerenciados em sistemas diferentes e garante que a interpretação dos dados esteja correta, já que nomes de campos e convenções de processo podem variar entre sistemas. Também pode ser usado para filtrar a análise para o conjunto de dados de uma ferramenta específica.

Fornece contexto sobre a origem dos dados, o que é fundamental para a validação dos dados e análises que envolvem múltiplos sistemas integrados.

Geralmente é um valor estático adicionado durante o processo de extração de dados para identificar a origem dos registros.

O atributo Última Atualização de Dados registra quando as informações foram extraídas ou atualizadas do sistema de origem pela última vez, indicando a atualidade e relevância dos dados.

Essa informação é vital para garantir que análises e Dashboards reflitam a realidade atual. Os stakeholders podem ver instantaneamente o quão atualizada está a visão do processo, o que gera confiança nos insights. É um metadado essencial para gerenciar pipelines de dados e agendar atualizações.

Indica o quão recentes são os dados, garantindo que a análise seja oportuna e relevante para a tomada de decisão.

Este valor é geralmente gerado e armazenado pelo pipeline de extração, transformação e carregamento (ETL) de dados.

Este atributo identifica o indivíduo ou grupo responsável por concluir a etapa atual ou o item de trabalho como um todo. O responsável pode mudar várias vezes ao longo do ciclo de vida, refletindo handoffs entre diferentes papéis, como desenvolvedores, testadores de QA e revisores.

Analisar o atributo Assigned To é fundamental para entender a carga de trabalho da equipe, a eficiência dos handoffs e os padrões de colaboração. Permite filtrar o mapa do processo para ver o trabalho de uma pessoa ou equipe específica, ajudando a identificar gargalos de recursos. Análises de redes sociais baseadas em handoffs entre responsáveis podem revelar falhas de comunicação ou estruturas de colaboração excessivamente complexas.

Permite analisar a carga de trabalho, a frequência de passagens de bastão e os padrões de colaboração, ajudando a otimizar a eficiência da equipe.

Encontrado no item de trabalho ou no registro do problema, geralmente rastreado no histórico ou log de auditoria.

O Horário de Término do Evento marca a conclusão de uma atividade. Enquanto muitas etapas são registradas como eventos instantâneos, outras têm duração mensurável, como a 'Revisão de Código'.

Este atributo é essencial para calcular o tempo de processamento ativo de tarefas, diferenciando-o de esperas ou tempos ociosos. Ao comparar o início e o fim do evento, é possível medir o esforço em atividades que agregam valor. Isso permite uma análise granular do uso de recursos e ajuda a identificar quais tarefas consomem mais tempo de trabalho ativo.

Permite calcular o tempo de processamento ativo de cada atividade, separando-o do tempo de espera e oferecendo uma visão mais clara do esforço real.

Pode ser encontrado nos logs de eventos ou derivado pelo timestamp da atividade seguinte na sequência para o mesmo item de trabalho.

Este atributo identifica a equipe, squad ou grupo específico responsável por entregar o item de desenvolvimento. Em organizações maiores, o trabalho costuma ser distribuído entre equipes especializadas como 'Frontend', 'Backend', 'Mobile' ou 'Platform'.

Analisar pelo Team Name permite comparar a performance e compartilhar melhores práticas entre os times. Ajuda a responder perguntas como 'Qual equipe tem o menor cycle time?' ou 'Algum time gera mais retrabalho que os outros?'. Esta análise pode revelar diferenças em workflows, competências ou disponibilidade de recursos que impactam a performance geral de entrega, oferecendo oportunidades para melhorias direcionadas.

Permite o benchmarking de performance entre diferentes equipes, ajudando a identificar boas práticas e áreas que precisam de melhoria.

Frequentemente associado ao usuário atribuído ou como um campo direto no registro do projeto ou item de trabalho.

O Project Name fornece contexto ao agrupar itens de trabalho que pertencem a um produto, iniciativa ou base de código específica. Práticas de desenvolvimento e cycle times podem variar significativamente entre projetos — por exemplo, um sistema legado versus uma nova aplicação greenfield.

Este atributo permite uma agregação de alto nível e a comparação de processos de desenvolvimento em diferentes partes da organização. Ao filtrar a análise por projeto, os gestores podem avaliar a saúde e a eficiência de cada esforço de desenvolvimento. Também é essencial para entender como a performance do processo se relaciona com o contexto específico e o ambiente técnico de um projeto.

Permite que a análise do processo seja segmentada por produto ou iniciativa, revelando diferenças de performance relacionadas ao contexto do projeto.

Um campo padrão no item de trabalho ou no registro do problema, ou o nome do repositório em sistemas como Git.

O atributo Priority indica a urgência técnica ou de negócio de um item de trabalho. Geralmente é definido com valores como 'Alta', 'Média' ou 'Baixa' e ajuda as equipes a decidir o que priorizar.

No Process Mining, a prioridade é uma dimensão poderosa para análise. Permite que as equipes verifiquem se itens de alta prioridade são realmente processados mais rápido que os de baixa prioridade. Comparar os cycle times entre diferentes níveis de prioridade pode revelar se o processo respeita as prioridades de negócio. Se itens de alta prioridade atrasam com frequência, isso pode indicar problemas no planejamento, na alocação de recursos ou no design do workflow.

Ajuda a verificar se o trabalho de alta prioridade flui mais rápido pelo processo e identifica gargalos que afetam desproporcionalmente itens críticos.

Um campo padrão no item de trabalho ou no registro do problema na maioria dos sistemas de gestão de desenvolvimento.

O Status do Item de Desenvolvimento representa o estado de um item em um dado momento. Enquanto o Nome da Atividade registra o evento de mudança, este atributo captura o estado em si, o que é útil para analisar o contexto no momento do evento.

Esse atributo costuma ser usado para gerar o Nome da Atividade, mas traz contexto extra. Por exemplo, permite analisar quanto tempo os itens ficam em estados como 'Bloqueado' ou 'Aguardando Revisão'. Entender o tempo gasto em estados não produtivos é fundamental para identificar atrasos sistêmicos e melhorar a eficiência do fluxo.

Permite analisar o tempo gasto em diferentes estados, ajudando a identificar atrasos e tempos em status que não agregam valor, como 'Bloqueado'.

Disponível como um campo principal no item de trabalho ou no registro do problema, sendo rastreado em seu histórico.

Este atributo categoriza a natureza do trabalho realizado. Diferentes tipos de itens de trabalho geralmente seguem caminhos de processo distintos e têm expectativas de performance diferentes. Por exemplo, um 'Bug' pode exigir um processo de hotfix rápido, enquanto uma 'Feature' segue um ciclo padrão de desenvolvimento e teste.

Com este atributo, analistas podem comparar os fluxos e a performance para diferentes tipos de trabalho. Isso ajuda a responder perguntas como 'Nosso processo de correção de bugs é mais rápido que o de desenvolvimento de funcionalidades?' ou 'Itens de dívida técnica geram mais retrabalho?'. É uma dimensão fundamental para segmentar os dados e obter insights mais específicos e acionáveis.

Permite comparar processos e performance entre diferentes categorias de trabalho, revelando ineficiências específicas de certos tipos de desenvolvimento.

Um campo padrão no item de trabalho ou no registro do problema na maioria dos sistemas de gestão de desenvolvimento.

O atributo Criador identifica quem iniciou o item de trabalho. Pode ser um gerente de produto criando uma história, um QA registrando um bug ou um agente de suporte relatando um problema de cliente.

Analisar quem cria os itens oferece insights sobre a origem das demandas. Por exemplo, muitos bugs relatados por usuários finais podem indicar falhas na qualidade dos lançamentos recentes. Também serve para avaliar a clareza dos requisitos iniciais, correlacionando o criador a retrabalhos ou atrasos posteriores.

Ajuda a identificar os originadores do trabalho, permitindo analisar as fontes de demanda, bugs ou solicitações de funcionalidades.

Um campo padrão como 'Relator' ou 'Autor' no registro de criação inicial de um item de trabalho.

O Rework Indicator é um atributo booleano ou categórico derivado que sinaliza events como parte de um ciclo de retrabalho. Isso é comumente identificado quando o fluxo do processo retrocede, por exemplo, de 'Teste de QA' para 'Desenvolvimento em Andamento', ou quando ocorrem atividades específicas como 'Retrabalho Identificado no QA'.

Este atributo é extremamente valioso para análise de qualidade e eficiência. Permite o cálculo direto das taxas de retrabalho e destaca as partes do processo que mais o geram. Ao filtrar por atividades de retrabalho, as equipes podem realizar análises de causa raiz para entender por que problemas de qualidade não são detectados antes. Reduzir o retrabalho é fundamental para melhorar tanto a velocidade de desenvolvimento quanto a qualidade do produto.

Quantifica o retrabalho diretamente, permitindo que as equipes meçam sua frequência, analisem as causas e acompanhem as melhorias de qualidade ao longo do tempo.

Geralmente derivado durante a transformação de dados, identificando loops de retorno no fluxo do processo ou nomes de atividades específicos relacionados a falhas.

O atributo Planned Release vincula um item de desenvolvimento a um cronograma de entrega ou versão específica. Isso costuma ser usado no planejamento de releases para agrupar funcionalidades e correções para um deploy coordenado.

Analisar por Planned Release ajuda a avaliar a previsibilidade e a confiabilidade do processo de release. Permite acompanhar as taxas de entrega no prazo, comparando a Planned Release com a data real de deploy. Além disso, auxilia na gestão do escopo e na compreensão do fluxo de trabalho destinado a uma release específica, destacando riscos ou atrasos potenciais que podem impactar o cronograma de entrega.

Conecta o trabalho de desenvolvimento aos cronogramas de entrega, permitindo a análise de taxas de entrega no prazo e previsibilidade de releases.

Um campo padrão como 'Versão de Correção', 'Release Alvo' ou 'Caminho de Iteração' em ferramentas de planejamento e desenvolvimento ágeis.

Severidade é diferente de prioridade: ela mede o impacto técnico de um problema, enquanto a prioridade mede a urgência da correção. Um erro de digitação em uma página pouco visitada pode ser de baixa severidade e baixa prioridade, já um erro crítico de corrupção de dados seria de alta severidade e alta prioridade.

Este atributo é vital para a análise de qualidade, permitindo que as equipes avaliem se estão resolvendo os problemas mais graves primeiro. Ao analisar o tempo de ciclo por nível de severidade, as empresas garantem que falhas críticas sejam sanadas rapidamente para minimizar o impacto aos clientes.

Permite analisar a eficácia da equipe na resolução de problemas com base no impacto técnico, garantindo que falhas críticas sejam corrigidas rapidamente.

Um campo padrão, especialmente para itens de trabalho do tipo 'Bug' ou 'Incidente', em sistemas de gestão de desenvolvimento.