Padrão de abertura de issues para Meu RH - RM

CONTEÚDO

1. Visão Geral
2. Manutenção
3. Apoio
   
4. Apoio ao cliente
   
5. Rejeições para o atendimento
6. Rejeições para o desenvolvimento

01. VISÃO GERAL

O objetivo deste documento é criar um modelo de abertura de issues com o detalhamento necessário para uma atuação mais efetiva do desenvolvimento.

Documentações base: https://tdn.totvs.com/x/6dEWHg | https://tdn.totvs.com/x/H0xYGw

02. MANUTENÇÃO

Todos os passos devem ser evidenciados e anexados na issue:

1. Seguir modelo de abertura de issue (Zaira vai achar e colocar aqui) - não copiar/colar com estilo.
2. Anexar arquivo HAR. (Como obter HAR)
3. Versão do patch do cliente mencionada (Ex.: 12.1.28.246).
4. Base simulada no patch mais atual na versão/release do cliente.
5. Quando for base exemplo compartilhar backup no drive (compartilhar com o domínio TOTVS) ou passar a base em algum servidor.
6. Simular situação no portal antigo (corpore.net), caso o mesmo problema que ocorre no Meu RH aconteça, então a issue deve ser direcionada aos projetos do produto: RHU, PTO, FOP e SMT.
7. Em versões expiradas é necessário fazer o alinhamento com o PO para abertura.

03. APOIO

O apoio deve ser aberto quando todos os passos da manutenção já foram realizados, evidenciados e anexados na issue, porém o atendimento precisa de algum apoio.

• Entrar em contato com o atendimento para agendar call com cliente

04. APOIO AO CLIENTE

O Apoio - Cliente deve ser aberto quando todos os passos da manutenção já foram realizados, evidenciados e anexados na issue, porém a partir da análise de todas as evidência o desenvolvimento precisa analisar diretamente a base do cliente.

• Quando enviar artefato para o cliente manter backup do original do e o próprio analista deve deletar o artefato enviado mesmo que resolva o problema.
• Verificar IIS e anexar na issue.
• Back-end utilizar o Dnspy (verificar se o cliente permite utilizar).
• Front-end gerar dist para debug e enviar para o cliente (ng build).

05. REJEIÇÕES PARA O ATENDIMENTO

Acordos:

• Quando alguma dessas informações estiverem faltando nas issues o analista do atendimento deve ser acionado para envia-las em até 2 dias.
• Todas as rejeições devem alinhadas com o analista e aguardaremos resposta em até 2 dias para prosseguir com a rejeição.

06. REJEIÇÕES PARA O DESENVOLVIMENTO

Quando o cliente retornar que a correção não foi efetiva:

• O atendimento deverá conferir se o aplicou as correções corretamente.
• Caso o problema ainda ocorra no ambiente do cliente, as correções enviadas deve ser aplicada em ambiente atualizado. Sendo o problema simulado deverá abrir uma issue do tipo Rejeição - Manutenção.
• Todos os passos da manutenção devem ser realizados, evidenciados e anexados na issue.