Gestão de Produtos: Processo de Coleta de Requisitos e Priorização de Demandas
Software: Softcom (Processos) | Grupo: PROCESSOS
Solução
Gestão de Produtos | Processo de Coleta de Requisitos e Priorização de Demandas
- Objetivo
Este documento tem como objetivo esclarecer como e em qual momento deve ser realizada a coleta de requisitos de um sistema, destacando a importância da priorização e alinhamento entre as partes (Cliente e Softcom) para que sejam respeitadas as prioridades de acordo com critérios bem definidos.
- Pontos de Contato
| Franquias | Apoio a Franquia: melhoria.continua@softcomtec.com.br (Vanderson (bugs), Santana(melhorias), Flavio (Fechamento) |
|---|---|
| Colaboradores Internos Softcom | Gestão de Produto: gestao.produtos@softcomtec.com.br |
Orientação de fluxo de contato:
Quando Franquia (técnico): BUGS para Vanderson, MELHORIAS ou NOVOS REQUISITOS para Santana
Quando PEV (técnico): Deverão ser reportadas as situações de suporte diretamente a Gestão de produtos
Quando PEV comercial e/ou Franquia comercial: Deverão ser reportadas as situações para os respectivos supervisões e encaminhado para Gestão de produtos
Quando Comercial(geral) para fechamento: Deverão ser encaminhadas as situações para Flávio.
Meios de contato:
O contato deverá ser feito por do discord ou email, o email deverá ter no assunto as tags [BUG] para quando for referentes a bugs, [Melhorias/Requisitos] quando for referente a melhorias ou requisitos novos, e, [Fechamento] para quando for referente a requisitos/critérios de fechamento.
- Exemplo
Sendo o uso do discord para report de bugs e mail para novos requisitos
Sugestão: Criar canal no discord padrão da softcom unificando todos os envolvidos operação e franquia com os gestores e técnicos da franquia, gestão de produto e especialistas, para que seja feito o relatório inicial da situação, e caso sendo necessário, acompanhando individual a partir de um grupo. Objetivo é que todos presentes no canal tenham acesso ao que está sendo reportado e uma possível colaboração.
Report de bugs/falhas/erros:
Da abertura de grupos: Para cada situação/cliente no discord, neste grupo deverão estar presentes obrigatoriamente representantes da Gestão de Produto, técnico que está em contato com o cliente e o gerente de seu setor
Do report ao time responsável pelo produto: Deverão ser reportadas as situações de bug através do canal “Gestão de Produto” por um representante da Gestão de Produto
Report de novos requisitos/melhorias:
Do envio de novos requisitos: Deverá ser encaminhado para os emails dos pontos de contato, contendo evidências da funcionalidade, sendo elas fotos,vídeos, sistema de referência e documento de aparato fiscal quando houver.
Do envio de melhorias: Deverá ser encaminhado para os emails dos pontos de contato, contendo descrição da melhoria proposta, possível fluxo de uso e necessidade que será contemplada.
Dos critérios de report:
Deverá ser informado no momento do report a prioridade/urgência da situação
Caso houver situações anteriores pendentes, identificar qual deverá ser priorizada
Dos critérios de Fechamento:
Deverá ser encaminhado a dúvida para o supervisor responsável antes do fechamento da venda
Quando identificado novos requisitos de fechamento para troca de software, deverão ser encaminhados às evidências e justificativas do fluxo a ser realizado.
Dado encaminhando das informações será feita a análise e respondido com o parecer de contorno ou possível prazo de entrega
Fluxo de Coleta
- Mapa Mental:
- Script em texto
Incidente - Bug:
-Qual o incidente? Envie alguma evidência (Arquivo/Configuração, foto ou vídeo)
-Qual o cliente?
-Tem impacto na operação? Caso sim, qual impacto?
-Existe contorno?
Exemplo de report de bug: Erro ao cadastrar uma conta no
Qual o Incidente? Ao cadastrar uma conta bancária do tipo poupança a partir do módulo financeiro do SOFTCOMSHOP, estão sendo criados dois registros da mesma conta após clicado em salvar.
Como exemplo foi criada a conta chamada Banco BB
Qual o cliente? A situação foi reportada pelo cliente “Qualidade Experience”, de CNPJ 888.888.8888/88 e tem o sistema com a url qualidadeexperience.softcomshop.com.br. Também foram reportados a mesma situação pelos clientes : Cliente /cnpj / sistema-2,Cliente /cnpj / sistema-3,Cliente /cnpj / sistema-4, N-n.
-Tem impacto na operação? Sim, são criados vários registros de uma mesma conta.
-Caso sim, qual impacto? Causa dificuldades no gerenciamento das contas, podendo um lançamento ou retirada ser feito na conta errada e causar diferenças
-Existe contorno? Sim, foi repassada a orientação de contorno que ao criar a conta, observar se a conta foi criada duplicada e excluir o segundo registro gerado.
Melhorias ou Novos Requisitos:
-Qual a melhoria desejada? Envie alguma evidência (Foto ou vídeo)
-Qual o cliente?
-Qual a relevância na operação do cliente?
-Existe contorno?
Exemplo de report de melhoria:
-Qual a melhoria desejada? Possibilitar a entrada de NFe sem que seja movimentado o estoque dos produtos.
Justificativa: Para alguns clientes/segmentos é feito uma nfe de faturamento futuro, ou seja, é emitida uma NFe para indicar que essa NFe será efetuada posteriormente e emitir a nfe de faturamento real, assim para quem está recebendo é importante que haja a possibilidade de importação de NFe de faturamento futuro e que ela não movimente o estoque. Como exemplo o “CFOP 2922 - Lançamento efetuado a título de simples faturamento decorrente de compra para recebimento futuro”
-Qual o cliente? A melhoria foi reportada pelo cliente “Qualidade Experience”, de CNPJ 888.888.8888/88 e tem o sistema com a url qualidadeexperience.softcomshop.com.br. Também foi solicitado pelos clientes : Cliente /cnpj / sistema-2,Cliente /cnpj / sistema-3,Cliente /cnpj / sistema-4, N-n.
-Qual a relevância na operação do cliente? Ajudará no gerenciamento fiscal e físico do estoque
-Existe contorno? Sim, o cadastro da nfe com os itens possuindo quantidade zero.
Segundo exemplo de report de melhoria:
Prazos e SLA de atendimento de Gestão de Produtos
SLA início: Refere à coleta, análise da situação, definição de contorno e/ou encaminhamento para o time responsável pelo produto
SLA Encaminhar SQUAD: Remete ao tempo que deverá ser encaminhada a situação ao squad responsável pelo produto após a finalização da análise e coleta de requisitos da situação.
No recebimento de situações através dos grupos deverá ser indicada como resposta inicial que o reportado será visto
Ao dar início a verificação, deverá ser indicada que a aquela situação será vista naquele momento
Quando encaminhando e quando recebido retorno, deverá ser informado no grupo referente a situação
| Item | SLA Início (Gestão de produtos) | SLA Encaminhar SQUAD | Observação | Prioridade |
|---|---|---|---|---|
| Sistema ou Faturamento parado | 0 a 20min | até 30min | -Em situações bug nas principais telas de faturamento(vendas) e emissão de documentos fiscais( NFCe, NFe e MDFe), início da análise e tratamento teria início imediato e não será sobreposta até sua entrega. | 1 |
| Bugs não críticos | 30m a 1hs | até 2h | -Em caso de situações na qual há um ’bug’ evidente mas poderá ser contornado com um paliativo, que não permitirá a operação travar. | 2 |
| Análise de relatórios | 2hs a 4hs | até 4h | -Situações que dependem de validações em banco e coleta de fluxos/rotinas de alimentação dos relatórios. | 3 |
- Fluxo da Gestão de Produto
- Níveis de Prioridade nas Squads
| Item | SLA Início | SLA Conclusão | Observação | Prioridade |
|---|---|---|---|---|
| Sistema ou Faturamento parado | 0 a 20min | Até 2 horas | -Em situações bug nas principais telas de faturamento(vendas) e emissão de documentos fiscais( NFCe, NFe e MDFe), início da análise e tratamento teria início imediato e não será sobreposta até sua entrega. | 1 |
| Correções com impacto operacional relevante | 2hs a 48hs | De 2hs à 7 dias úteis | -Em caso de situações na qual há um ’bug’ evidente mas poderá ser contornado com um paliativo, que não permitirá a operação travar. | 2 |
Melhorias- Novos Requisitos- Correções com menor impacto ou maior complexidade| 1 a 7 dias | Sob Análise| -Nesses casos as definições de prioridade e prazo dependem de fatores como relevância/complexidade do requisito levantado e nível de serviço do cliente-Se identificado que o requisito levantado não tem relevância suficiente para os clientes ou não cabe na versão atual, pode ser alocado a uma versão seguinte, podendo assim receber um prazo superior ao prazo máximo de uma versão “Release”| 3
- -Níveis de Prioridade na BackOffice
| Item | SLA Início | SLA Conclusão | Observação | Prioridade |
|---|---|---|---|---|
| Sistema ou Faturamento parado | 0 a 20min | Até 2 horas | 1- Para coletar o passo a passo para reproduzir | |
| 2- Informar qual análise e procedimento já foi realizado (muitas vezes as situações chegam sem análise e sem informar o que já foi feito) apenas passando a situação | ||||
| 3- Se for PDV, já coletar o banco de dados, banco de mesas e xml de configuração do PDV, além de passar os demais dados para reproduzir a situação | ||||
| 4- Se for emissão de NFe/MDFe, também coletar o banco, o certificado do cliente, a nota/mdfe de exemplo | ||||
| 5- O ponto de apoio analisar e realizar situações básicas: | ||||
| 5.1- Ao enviar uma NFCe pendente de envio a SEFAZ rejeita com emissor não habilitado para emissão de NFCe, sendo que ao enviar uma nova nota não rejeita. Uma análise básica é comparar os dados dos 2 XMLs de envio (chegou recente a situação do exemplo e não foi feita essa análise e sim já passada para a squad analisar o motivo) | ||||
| 5.2- Houve a questão de em alguns clientes ter a questão do PDV ficar contando vários segundos na hora de emitir NFCe . A equipe de testes acessou o computador do cliente, concedeu permissão total nas pastas (após isso não houve mais reportes do PDV ficar contando vários segundos ao emitir NFCe) e comunicou a equipe de apoio. A mesma situação aconteceu em outra máquina e a equipe de apoio já deveria ter concedido as permissões como foi feito anteriormente, porém resolveu acionar a equipe de testes para verificar (que iria acessar e conceder permissão total nas pastas) | ||||
| 6- Sobre o atendimento imediato: | ||||
| 6.1- Verificar que nem sempre será possível o início imediato do atendimento, uma vez que as pessoas da equipe de testes poderão não ter disponibilidade de verificação no momento atual. exemplos: estarão em call, estarão no meio de um raciocínio, estarão no meio de um teste, estarão em horário de almoço, etc). | 1 | |||
| Correções com impacto operacional relevante | 2hs a 48hs | De 2hs à 7 dias úteis | -Em caso de situações na qual há um ’bug’ evidente mas poderá ser contornado com um paliativo, que não permitirá a operação travar. | |
| 2 |
Melhorias- Novos Requisitos- Correções com menor impacto ou maior complexidade| 1 a 7 dias | Sob Análise| -Nesses casos as definições de prioridade e prazo dependem de fatores como relevância/complexidade do requisito levantado e nível de serviço do cliente-Se identificado que o requisito levantado não tem relevância suficiente para os clientes ou não cabe na versão atual, pode ser alocado a uma versão seguinte, podendo assim receber um prazo superior ao prazo máximo de uma versão “Release”| 3
Observação: Situações relacionadas à última versão release liberada têm prioridade acima de melhorias ou novos requisitos a serem desenvolvidos.
- Prazos Padrões para Liberação de Versões
| Liberação de Versões | O que é contemplado na versão | Prazo |
|---|---|---|
| Hotfix | Correções com impacto operacional relevante (Em casos de sistema parado, a correção será disponibilizada assim que concluído seu desenvolvimento e validação, quando a disponibilização da correção ocorrer antes da liberação da versão, o caso referente a situação possuirá a flag “Entregue” marcada). | Até 7 dias úteis |
| Release | -Melhorias-Novos Requisitos-Correções com menor impacto ou maior complexidade | 30 a 40 dias úteis |
Observação: A data prevista de cada versão de acordo com o prazo estabelecido poderá ser observado a partir registro de liberação, disponível na tela inicial do helptools ou no painel Minha Visão da agenda.
Recomendações de ferramentas:
Para Prints de tela: Recomendamos o uso do Lightshot
Para Filmagens de tela: scre.io
Para criação de GIFs: ScreenToGif
Criação de mapas mentais e fluxogramas: whimsical, helptools ou app.diagrams.net
Criação de documentos: Google Docs, Word office, Writer (Libre Office), ou qualquer outro software que gere arquivos .doc, .docx e PDF
Para saber mais sobre os responsáveis de cada equipe/produto, clique aqui.
Tags: sofcom, faq, processo, fluxo, comunicação, comunicao, prazo, prazos, sla