Requisitos do rastreador de problemas

Question

Eu não faço isso há um bom tempo, mas, na verdade, vou passar pelo processo de avaliação de vários rastreadores de problemas.

Começando com esses requisitos:

• precisa ser personalizável (campos personalizados, fluxos de trabalho personalizados)
• email & gateways da web
• manipulação de metadados por e-mail (por exemplo, fechar via e-mail, etc ...)
• notificações de email (sob demanda)
• capacidade de atribuir "observador (es)" padrão para novos problemas
• suporte para classificação de problemas (categorias, projetos, etc.)
• relações de problema (subitens, problemas vinculados, problemas duplicados, problemas de mesclagem)
• Integração do AD
• Segurança (por exemplo, só permite que os usuários vejam seus próprios problemas)
• API
• interface CLI (não ligo, mas outros irão sugerir)

Quais os requisitos que estão faltando aqui?

    

Answer 1

Eu poderia adicionar:

• Plataforma (sistema operacional e linguagem de programação) , dependendo do que você está confortável em manter, ou de quem quer que seja o dono, uma vez que esteja em casa.
• Integração IDE se você for usá-lo para fluxos de trabalho de problemas de aplicativos (ou seja, ele faz interface com o Eclipse ou o Visual Studio de uma maneira útil).
• Integração SCM , mais uma vez, se você estiver acompanhando os problemas do aplicativo. É legal amarrar erros ou recursos nos check-ins em seu repositório de código-fonte. Não é tão útil para o trabalho de tipo de ingresso de helpdesk.

Além disso, se isso for servir uma função de suporte técnico, talvez rastreamento de inventário ou rastreamento de licenças.

ATUALIZAÇÕES

• Capacidade de atribuir recursos padrão (por exemplo, técnicos / programadores) à medida que novos problemas surgem (triagem automatizada de nível 1), dependendo do tipo de problema ou aplicativo em que o ticket entra

Answer 2

Possibilidade de anexar arquivo.
Possibilidade de usar template: como criar um novo tipo de caso com uma lista predefinida de subcasas.
Possibilidade de registrar o tempo de trabalho no caso.

    

Answer 3

Ao longo das linhas de segurança, a criptografia entre os pontos de extremidade é importante, mas nem sempre é oferecida.

O recurso de usuário virtual no FogBugz é muito bom. Eu gosto disso melhor que os grupos padrão. Eu consideraria isso um requisito tê-lo usado por alguns anos agora.

    

Answer 4

Sempre que se olha para uma plataforma / pacote de software, também vale a pena olhar para o suporte do próprio produto. Com que rapidez os bugs podem ser corrigidos? É de código aberto para que você possa corrigir os problemas sozinho ou dependerá de outra empresa?

    

Answer 5

Uma pequena coisa - personalização de tema / modelo / logotipo. Algumas empresas preferem uma solução que possam ser personalizadas de acordo com sua imagem corporativa.

    

Answer 6

1. Seção de soluções Whitepapers ou , permitindo que a equipe de suporte pesquise um problema conhecido ou HOWTO .
2. Criação de ticket na ação de monitoramento
3. Anexando arquivos / registros
4. Interface amigável para smartphone para acesso externo
5. Escalonamento automático para problemas não resolvidos

Answer 7

Um fluxo do sistema de gerenciamento de processos com base no status do ticket (como o Jira faz)