Processo de atendimento para projetos em sustentação¶
Objetivo: Estabelecer o processo padrão que abrange o recebimento, a classificação, o tratamento e a conclusão das solicitações relacionadas a sistemas e projetos que estão em fase de Sustentação, garantindo qualidade, acompanhamento e cumprimento de prazos.
Definições¶
- Demandas de sustentação: solicitações relacionadas a manutenção corretiva, evolutiva ou atendimento a incidentes recorrentes;
- Card: registros das demandas na ferramenta de gestão contendo dados necessários para atendimento;
- SLA: prazo para cumprimento do atendimento e resolução da demanda;
- Prioridade:
- P1:: Crítico - Incidente com indisponibilidade total de serviço crítico e sem workaround, exigindo resposta imediata (major incident – padrão de mercado/ITIL);
- P2:: Alto - Incidente com impacto significativo em funcionalidade crítica, com workaround limitado, exigindo tratamento prioritário;
- P3:: Médio - Incidente com impacto moderado e workaround disponível, podendo ser tratado dentro do fluxo normal de atendimento;
- P4:: Baixo - Incidente de baixo impacto ou melhoria, sem urgência, tratável de forma planejada ou oportunística.
Etapas do processo¶
Abertura da demanda - Open¶
Início do atendimento das solicitações relacionadas a sistemas e projetos em fase de Sustentação. Essa etapa consiste no registro da demanda com as informações necessárias para o atendimento.
- Gerente do projeto;
- Analista de negócio / requisitos;
- Cliente.
- Cards registrados na ferramenta de gestão.
-
Solicitante registra em um card ou chamado contendo:
- Descrição detalhada;
- Evidências (prints, logs, vídeos, etc);
- Ambiente;
- Classificação de Impacto e Urgência;
- Contado do solicitante.
-
Registro do card na ferramenta de gestão e notifica a equipe de Sustentação.
Importante: O processo de abertura das demandas de sustentação vai depender do acesso que o cliente possui. Caso ele possua acesso à ferramenta de gestão (Git, Redmine, etc), deverá seguir a estrutura citada acima detalhando as informações. No caso de não possuir acesso e as solicitações chegarem via, chat, e-mail, reuniões, etc, a equipe deverá replicar na ferramenta de gestão as informações passadas pelo solicitante seguindo a mesma estrutura.
O processo de abertura deverá ser formalizado no Contrato Social do projeto.
- Backlog do produto com as demandas solicitadas.
Refinamento¶
Etapa em que a equipe necessita refinar as informações recebidas pelo solicitante.
- Gerente do projeto;
- Analista de negócio / requisitos.
- Cards registrados na ferramenta de gestão.
Os registros (cards) devem ser registrados na ferramenta de gestão com as seguintes labels classificativas:
-
Tipo:
- Incidente;
- Melhoria;
- Manutenção;
- Outros;
-
Prioridade:
- P1:: Crítico - Incidente com indisponibilidade total de serviço crítico e sem workaround, exigindo resposta imediata (major incident – padrão de mercado/ITIL);
- P2:: Alto - Incidente com impacto significativo em funcionalidade crítica, com workaround limitado, exigindo tratamento prioritário;
- P3:: Médio - Incidente com impacto moderado e workaround disponível, podendo ser tratado dentro do fluxo normal de atendimento;
- P4:: Baixo - Incidente de baixo impacto ou melhoria, sem urgência, tratável de forma planejada ou oportunística.
-
Complexidade inicial: a estimativa da complexidade dos cards deverá seguir o padrão estabelecido no processo de desenvolvimento, sendo:
- Estimar complexidade / tamanho / esforço: O time pode, neste momento, estimar a complexidade/tamanho/esforço para cada atividade que será desenvolvida. Nesta etapa, o time poderá usar a técnica de Planning Poker (Story Points) e o resultado deve ser registrado em cada card.
- Exemplo: STP::1
Importante: as classificações via labels serão utilizada para extrair métricas no respectivo Painel de Métricas.
- Caso necessite de mais informações, o card deverá retornar ao solicitante
- Backlog com itens priorizados;
- Itens disponibilizados no estado Planejamento no board.
Planejamento¶
Etapa em que é realizado o planejamento do atendimento às solicitações recebidas.
- Gerente do projeto;
- Analista de negócio / requisitos.
- Cards refinados.
- Definição da equipe responsável (dev/ops/infra);
- Previsão inicial de atendimento;
- Alocação do card ao ciclo/milestone (se aplicável).
- Atualização do card para Fazendo.
Fazendo¶
Etapa na qual as demandas planejadas para o ciclo de atendimento começam a serem desenvolvidas pelo time.
- Analista de negócio / requisitos;
- Time de desenvolvimento.
- Itens refinados e pronto para desenvolvimento;
- Itens priorizados e com responsável definido.
- A equipe executa:
- Análise técnica;
- Implementação;
- Testes unitários.
-
Cards atualizados com:
- Descrição da solução;
- Commits vinculados;
- Evidências.
-
Atualização do card para Testes.
Execução de testes¶
Etapa de validação e testes ao final do desenvolvimento.
- Analista de negócio / requisitos;
- Time de desenvolvimento.
- Cards com desenvolvimento finalizado;
- Política para registro de testes.
-
A equipe de testes executa:
- Testes funcionais, integrações e regressão quando necessário.
-
Registra o resultado dos testes no card, conforme template padrão disponibilizado no PPA.
-
Após execução dos testes, caso o card for reprovado:
- Manter a tarefa aberta;
- Criar um novo card do tipo "Bug" (priorizar o bug para correção no mesmo ciclo), associado ao card original;
-
Após correção e aprovação do Bug:
- Re-testar o card original, adicionando novas evidências e, se aprovado, atualizar o estado para "Closed".
Homologação pelo solicitante¶
Após a conclusão dos testes, as solicitações devem ser disponibilizadas para validação do solicitante.
- Gerente do projeto;
- Analista de negócio / requisitos;
- Time de desenvolvimento;
- Cliente.
- Evidências dos testes realizados no ambiente de homologação.
-
Em caso de reprovação na homologação:
- Manter a tarefa aberta;
- Criar novo card do tipo "Erro" (priorizar o Erro para correção no mesmo ciclo), associado ao card original;
-
Após correção e aprovação do erro:
- Encerrar a tarefa do Erro e atualizá-la para "Closed";
- Revalidar o card original, adicionando novas evidências e, se aprovado na homologação, atualizar o estado para "Closed".
- Card disponibilizado para Implantação.
Implantação¶
Etapa onde são feitas as implementações finais após a validação dos testes e homologado pelo solicitante.
- Gerente do projeto;
- Analista de negócio / requisitos;
- Time de desenvolvimento.
- Itens desenvolvidos e com testes aprovados.
- Equipe executa o deploy conforme processo padrão - PPA;
- Registra no card as evidências dos testes do ambiente de produção.
- Card disponibilizado para "Encerramento" após validação dos testes em produção.
Encerramento - Closed¶
Etapa final do atendimento à solicitação do demandante.
- Gerente do projeto;
- Analista de negócio / requisitos;
- Time de desenvolvimento;
- Cliente.
- Evidências da realização bem sucedida do deploy no ambiente de produção.
- A equipe verifica:
- SLA cumprido?
- Evidências completas no card?
- Documentações atualizadas?
- Encerramento do card com comentário final.
- Card encerrado - Closed.