Por que é tão difícil conseguir que os funcionários atualizem o rastreador de problemas?

Eu sempre tive essa luta para que as pessoas atualizassem seus problemas, tanto na minha empresa quanto no trabalho. Eu tive alguns casos em que as pessoas realmente fazem isso pela bondade de seus corações, mas ~ 70% do tempo eu tenho que estar perseguindo as pessoas.

Sendo aquele que geralmente faz alguma ou outra forma de gerenciamento (primeiro sou desenvolvedor), a principal razão pela qual tento explicar é que não quero perseguir as pessoas e interromper para consultar o progresso, mas não No fim das contas, as pessoas não se importam muito com isso. Em alguns casos raros e extremos, acabo atualizando seus tickets (quando preciso criar relatórios).

Então, você já enfrentou esse problema? Como incentivou os desenvolvedores a atualizar o rastreador de problemas com frequência? Que grau de sucesso você teve?

O motivo é que eles não entendem por que devem atualizar o rastreador de problemas, além do fato de que você diz isso.

Por que é que? Meu palpite é que a atualização do rastreador não afeta seu trabalho de maneira significativa, portanto a solução é provavelmente implementar um sistema de rastreamento que realmente os ajude a fazer seu trabalho melhor.

É difícil, porque os funcionários sentem claramente que a atualização do rastreador de problemas não é importante. Você tem que mudar isso, mas há um problema. A comunicação é difícil. A comunicação eficaz é realmente difícil - muito mais difícil do que você imagina. Tão difícil que a comunicação geralmente falha, exceto por acidente .

Show, não conte. Por exemplo. não diga que você (ou seu chefe) precisa dos dados para um relatório. Mostre do ponto de vista dos funcionários como o rastreador de problemas atualizado os afeta e ajuda.

Lidere pelo exemplo.

Sou desenvolvedor e luto para usar o rastreador de problemas que temos no trabalho. Isso é lamentável, porque sou a favor deles manterem as coisas organizadas. Minha solução no momento é usar uma ferramenta de rastreamento pessoal e referenciá-la para falar sobre o progresso em nossas reuniões diárias.

Aqui está o que me faria usar o rastreador o tempo todo:

• Integração perfeita com o IDE e o controle de origem. Usamos algumas aplicações web desajeitadas porque as licenças já foram adquiridas. Demora uma eternidade para criar / atualizar tarefas e possui alguns recursos confusos da interface do usuário. Infelizmente, usar isso está fora do controle da nossa equipe.

• Simplicidade. Com isso, quero dizer não usar 10 campos preenchidos manualmente apenas para adicionar uma tarefa. Estimativas por hora x tempo de conclusão, inserindo manualmente o projeto / componente / etc. em vários campos, etc., apenas aumente a quantidade de tempo.

• Apenas um. Não tenho certeza do quanto isso é comum, mas o gerenciamento de projetos usa uma ferramenta, o suporte usa outra e o desenvolvimento usa uma terceira. Se um não é atualizado, três certamente não são e é improvável que a sincronização entre eles seja automatizada.

Primeiro de tudo: o que você quer dizer com "pessoas atualizando seu progresso"?

Você quer dizer "desenvolvedores atualizando a estimativa atual", "desenvolvedores que não estão definindo um problema como resolvido" ou "clientes / testadores que não estão fechando um problema resolvido" ou todos juntos?

Do ponto de vista de um desenvolvedor, é uma mistura de mentalidade e cultura.

• mentalidade: quando você define um problema como resolvido, significa que está pronto e responsável se for um buggy
• cultura: se a empresa inteira não estiver muito interessada em usar essas ferramentas, mas preferir outras estratégias da organização

Minha experiência é: você precisa que a cultura aponte na direção certa, pelo menos. O que ajuda a seguir é definir um DoD (definição de 'pronto') - se um desenvolvedor (também trabalha para outras funções) pode dizer que cumpriu toda a lista que está aliviando ao marcar o problema como resolvido e seguir em frente sem necessidade olhar para trás.

Pare de perguntar sobre o progresso da codificação (geralmente é uma porcentagem arbitrária retirada do nada) até que o ticket seja fechado, não dá crédito. Se a principal medida que você medir for o número de tickets fechados, ela melhorará.

Observe, no entanto, que todas as métricas podem ser combinadas e tendem a funcionar melhor quando combinadas com métricas complementares.

Como apontado por outras respostas, a pergunta correta aqui é provavelmente: por que você tem um rastreador de problemas. Uma boa resposta para essa pergunta (não apenas da perspectiva do gerenciamento, mas também da perspectiva do desenvolvedor) é imprescindível se você deseja que um sistema de rastreamento de problemas realmente funcione e seja atualizado regularmente.

Em muitas empresas, o sistema de rastreamento de problemas é usado principalmente como uma ferramenta de relatório de gerenciamento. Fazer com que os programadores atualizem os problemas apenas para que o gerenciamento possa executar um relatório não funciona bem. Forçar os programadores a atualizar problemas também não funciona - você pode ter problemas atualizados, mas deve questionar os dados.

Na minha experiência, a única maneira de realmente fazer com que desenvolvedores (e testadores, gerenciamento etc.) efetivamente usem um sistema de rastreamento de problemas é integrá-lo ao processo de desenvolvimento. Isso significa que a saída de uma parte do processo se torna a entrada para a próxima parte do processo.

Para dar autoridade ao sistema de rastreamento de erros, sugiro o seguinte:

• Os desenvolvedores trabalham apenas com bugs / recursos registrados no rastreador de problemas e nenhum trabalho é feito fora dele. Todas as idéias, projetos de refatoração, novos recursos, ferramentas personalizadas a serem desenvolvidas etc. também devem ser registradas.
• Os problemas são trabalhados em ordem de prioridade. A prioridade deve ser parcialmente determinada pela gerência, mas os desenvolvedores também devem ter uma influência na determinação de prioridades. Isso é especialmente verdadeiro quando se trata de problemas de manutenção e refatoração.

Quanto ao processo, você pode usar algo como o seguinte:

• status 'novo' indica que um problema ainda não foi detectado por um desenvolvedor e ainda está na fila de problemas priorizados
• status 'atribuído' indica que foi atribuído a um desenvolvedor. Isso pode ser feito pelo desenvolvedor ou por outra pessoa, como o líder da equipe. Acho que funciona bem ter alguns problemas atribuídos a cada desenvolvedor e, geralmente, uma mistura de 'trabalho pesado', como novos recursos e escolhas fáceis, como bugs simples ou algum trabalho simples de manutenção. Isso permite que os desenvolvedores escolham o trabalho, dependendo do seu humor.
• status 'em andamento' significa que um desenvolvedor está trabalhando em um problema. Apenas um ou dois problemas por desenvolvedor devem estar "em andamento" a qualquer momento.
• Depois que um problema é resolvido, o desenvolvedor pode alterar o status do problema para 'precisa de teste' e alterar o proprietário para o testador. Esta é uma etapa importante, pois também é a fila de trabalho dos testadores.
• os testadores podem alterar o status para 'falha no teste' e alterar a propriedade de volta para o desenvolvedor, o que significa que ele vai para o topo da fila do desenvolvedor, ou pode alterar o status para 'pronto para implantação'.
• problemas com o status de 'pronto para implantar' podem ser mesclados e liberados de acordo com o ciclo de lançamento por quem for responsável pelos lançamentos.

Resumindo: torne o sistema de rastreamento de problemas uma parte essencial do processo de desenvolvimento e você não precisará se preocupar com a atualização dos problemas.

Talvez eles considerem muito trabalhoso abrir um navegador, fazer login, encontrar o ticket e preenchê-lo. Talvez você possa tentar encorajá-los com ganchos . Hoje em dia é comum que na mensagem git / hg [eu assumo que você use um destes], você pode digitar algo como o FIXO 123 curtido e o ticket mudará automaticamente quando você pressionar seu commit. Dessa forma, quase não funciona para o desenvolvedor [se ele trabalha em cada problema em uma ramificação separada - ele já tem o ID do ticket] e provavelmente ele adicionará esses dois caracteres na mensagem de confirmação. Se essa solução não for suficiente, talvez isso signifique que o escopo dos tickets é muito grande e deve ser dividido em muitos tickets menores?

Isso parece mais um problema de cultura da empresa do que qualquer outra coisa. Quem instituiu a necessidade de usar o rastreador? Se isso é algo que uma pessoa ou grupo jogou por aí e espera que todos aceitem e usem, boa sorte. A menos que as pessoas entendam o que é, saibam usá-lo e aceitem que ele realmente facilita suas vidas (suas vidas, NÃO a sua), elas não o usarão, a menos que sejam coagidas pela gerência. Dito isto, se o uso do rastreador for uma decisão da empresa, deve ser de responsabilidade da gerência aplicá-lo. A menos que sua função inclua a responsabilidade e autoridade para obter / fazer com que as pessoas usem o rastreador (soa como não, como você indicou que é desenvolvedor), você não vai muito longe, independentemente do que faz (realisticamente, IMHO )

Provavelmente é semelhante ao motivo pelo qual é tão difícil fazer com que as pessoas entrem no seu horário regularmente. É um trabalho tedioso ...

Muitos rastreadores de problemas se integram ao IDE. Por exemplo, o Rastreador de itens de trabalho do TFS permite marcar uma tarefa como resolvida ao realizar um check-in. Existe até uma opção para exigir que um check-in esteja associado a uma tarefa. Tornar a atualização de um item de trabalho parte do processo de check-in simplifica as coisas. A alternativa é abrir o rastreador de problemas em uma interface separada para executar a alteração.

Outra opção é ter uma reunião de status (ou durante a espera diária) em que alguém abre o rastreador e atualiza tarefas à medida que as pessoas fornecem status.

Uma coisa a considerar é que a própria GUI é um impedimento. Por exemplo, alguns obstáculos podem incluir:

• Demasiados cliques
• Servidor de aplicativos Rastreador de problemas não otimizado ou com pouca potência
• Má usabilidade ou acessibilidade

A exposição de uma API permitirá que o rastreador de problemas seja atualizado via script, da mesma forma que os artefatos técnicos (cobertura de código, relatórios de teste de unidade, status de criação, etc.).

Referências

• Scrumwise - API

• Referência da API REST JIRA Cloud

• API REST do Alfresco Content Services