CONTEÚDO

1. Visão Geral
2. Manutenção
   1. Telas THF
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 bases de datasul: 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. Descritivo do erro/solução detalhado e não genérico (evidência via texto, imagem ou vídeo).
2. Base simulada (se possível em ambiente não corporativo, para não perder a simulação).
3. Base simulada na versão mais atual disponível no mercado.
4. Obrigatório captura das telas do produto relacionadas ao erro (Telas de parametrização, registros, etc).
5. Obrigatório captura dos erros apresentados no console do navegador (F12 - Console), e captura das chamadas dos serviços e seus respectivos retornos JSON (F12 - Network -> Headers/Response).
6. Obrigatório envio dos logs de Appserver e Jboss ou Tomcat.
7. Versão do cliente mencionada (ex. 12.1.28.8-Progress).
8. Extrato de versão dos programas relacionados ao erro do produto.
9. Versão dos serviços chamados no erro (Casca REST e API).

Exemplo de  Capturas de tela para abertura de issue Meu RH Datasul

TELAS THF

Quando o problema for relacionado a telas THF é necessário evidencias todos os passos descritos na documentação Telas THF para aprovações/reprovações por usuário de RH

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.

• Situação estressada internamente na equipe antes de gerar a issue (enviar a base quando houver).
• Descrição dos passos realizados até o momento da criação da issue (histórico).

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.

• Situação estressada internamente na equipe antes de gerar a issue (enviar a base quando houver).
• Descrição dos passos realizados até o momento da criação da issue (histórico).

05. REJEIÇÕES PARA O ATENDIMENTO

Acordos:

• O desenvolvimento tem até 30 dias para fazer o grooming inicial das issues e verificar se a situação é pertinente.
• 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 a líder ([email protected] ou prime [email protected]) e aguardaremos resposta em até 2 dias para prosseguir com a rejeição.
• Quando a issue é aberta no mesmo dia pode ser rejeitada sem alinhamento. (alinhar atendimento)
• Quando o item já foi resolvido no cliente com configurações/entendimento pode ser rejeitada sem alinhamento. (alinhar atendimento)

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.

<!-- esconder o menu --> 


<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}
</style>