Problemas comerciais no rastreador de problemas?

5

A maioria dos rastreadores de problemas é direcionada aos desenvolvedores. Mas quando se trabalha em uma pequena equipe que inclui pessoas de negócios: faz sentido que eles coloquem problemas não-dev no rastreador?

Devo dizer que nunca ouvi falar dessa combinação. No meu trabalho em tempo integral, as coisas do negócio são feitas em outro lugar. Mas em uma startup onde você tem dinheiro limitado, por que não colocar todos os negócios e dev todos no mesmo rastreador?

    
por Philip 17.06.2013 / 22:34
fonte

3 respostas

2

Para mim, desde que existam filtros e filas apropriados (para que os desenvolvedores não fiquem sobrecarregados com tickets sobre "chame Bob sobre novo contrato") combiná-los faz sentido.

Na minha linha de trabalho (software financeiro para clientes externos), a maioria dos problemas de desenvolvimento exigirá a priorização da empresa de qualquer maneira. No final do dia, eles são todos problemas com o relacionamento com o cliente (o software faz o que o cliente quer ou há um bug? Descobrimos um problema no código que tornará o código menos sustentável e afetará nossa capacidade de manter os clientes felizes no futuro? o cliente precisa de um novo contrato?)

A abordagem combinada também pode ajudar a encontrar soluções não técnicas para erros técnicos

    
por 18.06.2013 / 10:31
fonte
0

porque não. Redmine (por exemplo) vem com 3 rastreadores fora da caixa e permite que você crie mais. Os 3 são bug, recurso e suporte.

bug é óbvio, mas é recurso solicitar uma coisa de desenvolvedor, ou mais um problema de design / gerenciamento? O que de suporte - pode não ser um bug, mas um problema de configuração.

Você pode adicionar facilmente o Requisito à lista.

O benefício de adicionar tudo isso à mesma ferramenta de acompanhamento é que você pode vinculá-los. Imagine que alguém crie uma solicitação de recurso que passe por várias modificações por meio de discussões com arquitetos ou designers. Quando o gerenciamento decide implementá-lo, ele pode ser associado a um item de acompanhamento de 'trabalho' para você verificar sua origem e associá-lo a um rastreador de 'teste' à medida que passa pelo controle de qualidade e pode ser associado a suporte ou itens de bug no futuro.

Isso é chamado de "rastreabilidade" e é algo enorme com projetos de software em larga escala ou muito controlados. Contanto que você não adicione fluxos de trabalho onerosos a ele (ou seja, somente um líder de equipe pode criar um item de trabalho, etc.), então é uma coisa muito boa.

    
por 18.06.2013 / 14:12
fonte
-1

Eu manteria um rastreador para manter os problemas levantados pelos usuários corporativos. Isso é especialmente útil ao fazer a coleta de requisitos. Você pode querer usar o mesmo rastreador quando fizer testes de aceitação do usuário para marcar os problemas existentes ou coletar feedback dos usuários. Eu usei principalmente várias planilhas de excel no mesmo grupo de trabalho para manter vários problemas (problemas de desenvolvedor em uma planilha, problemas de negócios em outra).

    
por 18.06.2013 / 09:42
fonte