MEP PROCESSO DE GESTÃO DE BUGS E SOLICITAÇÕES DE MELHORIAS DE SISTEMA.

Apresentação em tema: "MEP PROCESSO DE GESTÃO DE BUGS E SOLICITAÇÕES DE MELHORIAS DE SISTEMA."— Transcrição da apresentação:

1 MEP PROCESSO DE GESTÃO DE BUGS E SOLICITAÇÕES DE MELHORIAS DE SISTEMA

2 1. PROCESSO: FLUXO DE BUGS / AJUSTES

3 Fluxograma Ínicio Fim Enviar solicitação pelo Slack
Informar finalização para solicitante SETORES COORDENADOR CLIENTDESK Cadastrar solicitação no Monday Informar finalização pelo Slack Fluxograma Informar finalização pelo Monday Executar solicitação CTO

4 Procedimento Operacional
Solicitante - Setor Operacional : 1. Registrar solicitação de Bugs / Ajustes pelo Slack, classificando em [BUG] ou [Ajuste] [BUG] – Defeito, falha ou erro no código que provoca mau funcionamento [Ajuste] – Pequenos ajustes que dependem exclusivamente de dev, tais como: vinculacao de nota, apagar dados de prontuário, etc. Coord. ClientDesk : 2. Verificar solicitação garantindo que o Bug é reproduzido e que os ajustes realmente devem ser feitos por desenvolvimento. 3. Registrar solicitação no board do Monday – “Demandas” CTO - Desenvolvimento 4. Verificar registros no board do Monday – “Demandas” 5. Executar correção ou emitir feedback sobre o caso para Coord. ClientDesk Observação: Se for necessário mais tempo para correção do bug, o CTO deverá informar programação de ajuste. 6. Informar ajuste ou feedback para solicitante do setor operacional Solicitante – Setor Operacional: 7. Informar ajuste ou feedback para solicitante. Procedimento Operacional

5 Situação que pode ocorrer
Todo registro deverá conter, se aplicável : Nome da Empresa (com ID) e Paciente (com ID). Para bugs, é necessário enviar vídeo demonstrativo. Antes do registro de bugs / ajustes, o solicitante (setor operacional) deverá garantir que a solicitação não foi cadastrada anteriormente, checando o board de ”Demandas” Em casos que a correção da solicitação requeira um tempo maior de implantação (mais do que 5 dias úteis), O CTO é responsável por informar a previsão de ajuste. Caso a solicitação exija um desenvolvimento de ”Melhoria do Sistema”, a requisição será tratada como processo de ”Fluxo de Melhorias no Sistema”, devendo ser previamente aprovada em sprint. Se a solicitação tenha origem pelo Cliente, o setor operacional deverá garantir o bom relacionamento (feedbacks periódicos) com o solicitante até a conclusão do pedido – principalmente quando for necessário um maior tempo de desenvolvimento. Quando a solicitação tenha urgência de resolução, o Coord. de ClientDesk poderá entrar em contato diretamente com o CTO sem registro prévio no Monday. Solicitantes (Setor Operacional) que não tenham frequência de uso de slack (setor comercial, por exemplo) poderá notificar a solicitação por meio de comunicação mais conveniente (telefone, por exemplo). Observações Situação que pode ocorrer Ação Solicitante não conseguir contato com Coord. de ClientDesk quando ocorrer bugs que impactam significamente no funcionamento do sistema Solicitante deverá entrar em contato diretamente com o CTO.

6 2. PROCESSO: FLUXO DE MELHORIAS NO SISTEMA

7 Fluxograma Ínicio Fim SETORES CTO
Informar situação da Sprint para Solicitante (Cliente) SETORES Enviar solicitação pelo Slack Até Segunda-feira Cadastrar solicitação no Monday Alinhar prioridades junto com Solicitantes COORDENADOR CLIENTDESK Até Quarta-feira Fluxograma Informar situação da Sprint para Solicitante (Setor Operacional) Enviar Sprint para CTO Montar sprint e obter Aprovação do Owner do Produto Até Segunda-feira CTO Organizar Sprint com equipe Executar Sprint

8 Procedimento Operacional
Solicitante - Setor Operacional : Registrar solicitação de ”Melhoria do Sistema” pelo Slack Coord. ClientDesk : 2. Verificar solicitação enviada, garantindo que o problema só poderá ser resolvido por meio de desenvolvimento. 3. Cadastrar solicitação de desenvolvimento no Monday - Board “Requests: Backlog” Até segunda-feira: 4. Alinhar com os solicitantes as prioridades das requisições Até quarta-feira: 5. Apresentar lista de prioridades para o Owner do Produto, validando os itens que serão devidamente executados ou não em Sprint. 6. Enviar ”Lista de Itens” aprovada pelo Owner do Produto para o CTO CTO: 7. Analisar a ”Lista de Itens” e planejar execução com a equipe 8. Verificar itens ”Concluídos” em Sprint (Monday), testando a solução desenvolvida. 9. Informar para o Solicitante (Setor Responsável) conclusão de Sprint 10. Informar conclusão para solicitante (Clientes) Procedimento Operacional

9 Antes do registro de ”Melhorias no Sistema”, o solicitante (setor operacional) deverá garantir que a solicitação não foi cadastrada anteriormente, checando o board de ”Requests: Backlog” Sempre que possível, o coord. de ClientDesk deverá apresentar soluções já contidas no sistema para os problemas apresentados, minimizando os esforços de desenvolvimento. O alinhamento de prioridades será feito em conjunto com os solicitantes, garantindo que os problemas mais urgentes estejam em tempo hábil na fila de produção. Os itens da “Lista de prioridades” que não forem aprovados para Sprint Semanal pelo Owner do Produto, será devidamente justificado e informado (pelo Coord. ClientDesk) para os solicitantes. Nunca um solicitante (Setor Operacional) deverá informar um prazo de implantação de melhoria sem alinhar previamente com o Coord. de ClientDesk / Owner do Produto. Nunca um solicitante (Setor Operacional) deverá informar para o cliente que não é possível desenvolver a solução, mas também não poderá prometer que será feita. Informar que será cadastrada e analisada pela equipe responsável. Caso um item da Sprint não seja executado em tempo hábil ou conforme solicitado, o CTO deverá alinhar em conjunto com o Coord. de ClientDesk o planejamento correto da task, sendo reportado para os solicitantes (Setor Operacional). Nesse caso, não é necessária aprovação para entrar em Sprint. Em todos os casos (Conclusão, Adiantamento Planejado, Atrasos, etc.), o solicitante deverá comunicar e garantir o bom relacionamento com o cliente. Observações

10