Skip to main content

Gerar Card de Melhoria

Objetivo desta página

Esta página define como registrar melhorias de forma clara, testável e orientada ao negócio na DBSeller.
O foco não é apenas “pedir algo novo”, mas descrever uma mudança de comportamento do sistema de forma que desenvolvimento, QA, UX e negócio tenham o mesmo entendimento.

Uma melhoria bem escrita:

  • reduz retrabalho

  • evita interpretações divergentes

  • acelera desenvolvimento

  • facilita validação e tomada de decisão

Diferença entre Bug e Melhoria

Antes de abrir um card, é fundamental entender o que está sendo registrado.

Bug

  • o sistema se comporta diferente do esperado

  • existe regra clara sendo violada

  • algo que funcionava quebrou ou nunca funcionou

Melhoria

  • o sistema funciona conforme definido hoje

  • existe uma limitação, oportunidade ou evolução desejada

  • envolve mudança de comportamento, regra ou experiência

Pergunta-chave:

O sistema está errado ou queremos que ele faça algo diferente?

Se está errado, é bug.
Se queremos mudar o comportamento, é melhoria.

Papel do QA na criação de melhorias

O QA não atua apenas na validação final. Em melhorias, o QA:

  • ajuda a estruturar a história

  • identifica impactos e riscos

  • questiona ambiguidades

  • contribui para critérios de aceite claros

  • garante que a melhoria seja testável

Aqui, todo o conhecimento de:

  • critérios de aceite

  • severidade x prioridade

  • tipos de teste

  • risco
    é aplicado desde o início.

Estrutura do Card de Melhoria (User Story)

A DBSeller adota o seguinte padrão oficial de User Story, que deve ser seguido para todas as melhorias.

🧾 Título da User Story

O que é

Identificação clara e objetiva da melhoria.

Formato

[Nome da aplicação] - [Módulo/Tela] - [Descrição objetiva da mudança]

Boas práticas

  • usar verbo de ação claro

  • ser curto e direto

  • indicar exatamente onde ocorre a mudança

Exemplo
E-Cidade – Escola – Permitir exibir apenas cursos ativos no relatório

Evitar

  • títulos genéricos

  • termos subjetivos

  • frases vagas

📝 Descrição

O que é

Contextualiza a melhoria, explicando o problema atual e o comportamento desejado.

Deve responder claramente

  • o que acontece hoje

  • qual é a limitação atual

  • o que será alterado

  • como o sistema deve se comportar após a mudança

Boas práticas

  • linguagem objetiva e técnica

  • foco em comportamento do sistema

  • descrever fluxo atual e fluxo esperado

Exemplo de estrutura
Hoje, o sistema exibe cursos ativos e inativos no relatório de dados da escola, o que gera divergência com a tela principal.
Com esta melhoria, o relatório deve exibir apenas cursos ativos, seguindo a mesma regra aplicada na tela.

🔎 Pré-requisitos

O que é

Condições necessárias para execução e validação da melhoria.

Quando usar

Sempre que a melhoria não for genérica.

Exemplos

  • usuário com perfil específico

  • cadastro previamente existente

  • parâmetro ativo

  • ambiente mínimo configurado

Pré-requisitos ajudam QA e dev a testar no mesmo cenário.

🎨 Protótipo / Wireframes

O que é

Referência visual da alteração, quando houver impacto em UI.

Opções válidas

  • link para protótipo

  • lista de telas afetadas

  • informar claramente quando não se aplica

Evitar deixar o campo vazio. A ausência de impacto visual também é informação.

✅ Critérios de Aceitação

O que são

Condições objetivas e verificáveis que definem quando a melhoria pode ser considerada concluída.

São usados por:

  • dev como guia de implementação

  • QA como base de validação

Formatos recomendados

  • O sistema deve

  • O sistema não deve

  • Dado X, quando Y, então Z

Boas práticas

  • cada critério deve ser testável

  • evitar múltiplas regras em um único item

  • escrever pensando em cenários reais

Exemplo

  • O sistema deve exibir apenas cursos ativos no relatório.

  • O sistema não deve listar cursos inativos, mesmo que estejam vinculados anteriormente.

📏 Regras de Negócio

O que são

Regras fixas que orientam o comportamento do sistema.

Se uma regra for violada, vira bug.

Exemplos

  • validações obrigatórias

  • exceções permitidas

  • limites e restrições

Boas práticas

  • separar regra de critério de aceite

  • escrever como regra permanente do sistema

  • não misturar com sugestão

Severidade e Prioridade em melhorias

Embora melhorias não sejam bugs, elas também possuem impacto e urgência.

Severidade em melhorias

Avalia o impacto da limitação atual:

  • impacto operacional

  • impacto no usuário

  • impacto em dados

Prioridade em melhorias

Avalia urgência considerando:

  • cliente

  • prazo

  • risco

  • dependências

Isso ajuda a ordenar o backlog de forma racional.

Clareza e valor para o negócio

Uma boa melhoria sempre deixa claro:

  • qual problema resolve

  • quem é impactado

  • qual ganho será obtido

Evitar melhorias sem propósito definido.
Se não há valor claro, a chance de retrabalho é alta.

Resultado esperado deste padrão

Ao seguir este padrão, a DBSeller garante:

  • histórias claras e testáveis

  • menos dúvidas durante desenvolvimento

  • QA atuando desde o início

  • melhorias que não mudam de significado no meio do caminho

Gerar um card de melhoria bem escrito é qualidade aplicada antes do código existir.

Back to top