Demandas de Desenvolvimento usando o Jira

Registrando demandas nos sistemas para implementação pelo setor de Desenvolvimento usando o Jira.

O sistema Jira é utilizado internamente para operacionalizarmos e gerirmos todas as demandas de implementações nas aplicações desenvolvidas na Rumo. 

Introdução: O Propósito do Formulário

Este formulário no Jira é o canal oficial para solicitar melhorias, ajustes e atualizações em funcionalidades já existentes no sistema SIPROV. Ou seja, não se trata de reportar um defeito (bug), mas de propor uma evolução.

Campos do Formulário: Preencha com Precisão

Cada campo tem uma função crítica no fluxo. Seguir estas orientações evita retrabalho e garante que sua demanda seja processada com a máxima agilidade.

2.1. Sistema: SIPROV

Este campo já deve estar predefinido. Confirme se a solicitação realmente se refere ao ecossistema SIPROV.

2.2. Resumo (Título)

O que é: O título da sua demanda.

Como preencher:

Seja claro e objetivo.

Use uma frase de até 80 caracteres que descreva a essência do pedido.

Dica prática: Em caso de dúvida para sintetizar, utilize uma ferramenta de IA como auxílio para gerar um título conciso.

2.3. Descrição (A Parte Mais Importante)

Este campo é fundamental para o entendimento completo da solicitação. Divida-o em duas partes estruturadas:

A) Descrição Detalhada do Pedido:

Descreva com máximo de detalhes a melhoria desejada.

Inclua exemplos práticos e casos de uso reais (ex: "Atualmente o usuário precisa clicar em 3 telas para gerar o relatório X. Com a melhoria, ele poderá gerar a partir da tela inicial").

Sempre anexe prints de tela inteira da área do sistema em questão, garantindo que a URL completa da página esteja visível no print ou seja informada no texto. Isso agiliza drasticamente a análise.

B) Justificativa (Use este subtítulo):

Contextualize o "porquê" desta solicitação.

Explique qual problema operacional será resolvido, qual ganho de eficiência será obtido ou qual necessidade do cliente está sendo atendida.

Atenção: A falta de uma justificativa clara pode resultar em falha de contextualização e, consequentemente, na não aprovação do ticket pela análise de produto.

2.4. Componentes

Selecione o componente que melhor categoriza a natureza técnica da demanda:

Administrativo: Demandas internas de operação (ex.: cancelamento de uma base de testes).

Aplicação: O mais comum. Refere-se a alterações no código-fonte do sistema em si.

Banco de Dados: Atualizações ou consultas massivas de dados que precisam ser executadas diretamente no banco.

Design: Solicitações relacionadas a interface (UI/UX), como criação de protótipos ou ajustes visuais.

Documento: Criação ou modificação de modelos de documentos (contratos, relatórios padrão, etc.).

Observação: Outros componentes mais específicos são de uso primário do setor de #desenvolvimento.

2.5. Prioridade (Um Campo Crítico)

A definição incorreta aqui impacta diretamente o planejamento da equipe.

Crítico: Uma ocorrência que impacta todos ou vários clientes, geralmente muita demande de atendimento. 

Alta: Impacta diretamente a operação de um cliente ou da empresa, com prejuízo iminente.

Média: Melhoria importante para eficiência, mas sem caráter de urgência extrema.

Baixa: Incrementos ou ajustes pontuais que podem ser agendados com mais flexibilidade. 

Menor: O menor nível de prioridade, geralmente para demandas internamente de pouquíssimo impacto. 

Lembrete: Se houver um chamado no Freshdesk vinculado, a prioridade definida nele será sincronizada com este campo. Mantenha ambos consistentes.

2.6. Clientes

Informe sempre o cliente final solicitante da melhoria.

Cliente não encontrado na lista? Não perca a solicitação. Adicione uma nota na Descrição (ex: "ATENÇÃO: O cliente [Nome do Cliente] não consta na lista. Favor cadastrar.") e marque o @Tulho no Slack ou Jira para o cadastro imediato.

Demanda interna: Se a percepção da melhoria partiu da equipe Rumo, selecione o cliente #1 - Rumo Tecnologia.

3. Boas Práticas e Fluxo Pós-Abertura

Revisão: Antes de salvar, revise todos os campos, especialmente Resumo, Descrição/Justificativa e Prioridade.

Acompanhamento: Após a abertura, o ticket entrará no fluxo padrão (ex: status como "Aberto", "Analisado", "Em Andamento" - conforme seu diagrama). Acompanhe pelas notificações.

Comunicação: Para dúvidas sobre o andamento, utilize os canais combinados (como o Slack no canal #desenvolvimento), sempre mencionando a chave do ticket (ex: SIP-123).

Conclusão: Seguir este guia garante que suas solicitações de melhoria para o SIPROV sejam claras, completas e priorizadas corretamente, resultando em um desenvolvimento mais ágil e alinhado com as necessidades dos clientes e da empresa.

Glossário de Status no Jira da Rumo

Entender o significado de cada status no Jira é essencial para saber em que etapa sua demanda está e quais ações são esperadas. Este glossário explica o fluxo principal, da abertura até a conclusão.

O Fluxo Principal em Etapas:

ABERTO

O que é: O ticket acaba de ser criado e ainda não foi revisado por ninguém.

Ação esperada: O analista de produto ou líder técnico deve fazer a triagem inicial.

ANALISADO

O que é: A demanda foi revisada. Sua descrição e justificativa foram validadas, e agora ela aguarda ser priorizada e colocada na fila de desenvolvimento.

Próximo passo: Planejamento da sprint pelo time de desenvolvimento.

EM ANDAMENTO

O que é: Um desenvolvedor pegou o ticket para trabalhar. A solução está sendo codificada.

Ação esperada: O desenvolvedor atualiza o ticket com comentários em caso de dúvidas ou ao concluir a tarefa.

TESTAR / TESTAR EM HOMOLOGAÇÃO

O que é: O desenvolvimento foi concluído e a alteração foi publicada no ambiente de homologação (uma cópia segura do sistema para testes).

Ação esperada: Quem abriu o ticket ou o cliente solicitante deve acessar a homoloção, testar a funcionalidade e aprovar ou reportar problemas. Esta é uma etapa crítica de qualidade.

PUBLICAR EM HOMOLOGAÇÃO / PUBLICAR

O que é: Status técnico que indica que o código está pronto e disponível para ir para o ambiente de produção. Geralmente é uma transição rápida feita pelo desenvolvimento.

REVISAR EM PRODUÇÃO

O que é: A alteração já está ao vivo no sistema principal (produção). É a verificação final para garantir que tudo está funcionando perfeitamente no ambiente real.

Ação esperada: Uma checagem rápida e final pela equipe de atendimento ou pelo solicitante.

CONCLUÍDO / FECHADO

O que é: O ciclo da demanda terminou com sucesso. A melhoria foi implementada, testada e está em produção.

Importante: Tickets só devem ser fechados após confirmação de que está tudo ok em produção.

Status de Controle e Exceção

REAVALIAR

O que é: Durante a análise ou desenvolvimento, surgiram dúvidas ou informações faltantes. O ticket precisa de mais detalhes ou uma nova decisão de quem o abriu.

Ação esperada urgente: Quem abriu o ticket deve fornecer as informações solicitadas nos comentários. É a ação mais importante para destravar a demanda.

AGUARDAR LIBERAÇÃO

O que é: A funcionalidade está pronta, mas sua ativação depende de um fator externo (ex.: aprovação do cliente, uma data específica para go-live).

Ação esperada: O responsável pelo fator externo deve sinalizar quando for a hora de prosseguir.

CANCELADO

O que é: A demanda foi analisada e decidiu-se não implementá-la. Pode ser por falta de alinhamento com a estratégia do produto, justificativa insuficiente ou mudança de contexto.

Importante: Tickets cancelados devem sempre ter um comentário claro explicando o motivo, servindo de aprendizado para todos.

Conclusão: Dominar esses status transforma o Jira de uma simples lista de tarefas em uma ferramenta poderosa de comunicação e acompanhamento transparente, garantindo que todos na equipe Rumo estejam sempre alinhados sobre o andamento de cada demanda.