Ferramentas de gestão de projetos: como escolher e usar bem

Quase todo time que já reclamou da sua ferramenta de acompanhamento estava, na verdade, reclamando do seu processo. A ferramenta tornou algo visível (uma fila de trabalho pela metade, uma etapa de aprovação confusa, um backlog que ninguém prioriza) e essa visibilidade incomodou. Trocar de produto não resolve isso, e é por isso que migrações de ferramenta tantas vezes entregam um ano de esforço e os mesmos problemas com outra cara.

Dito isso, a escolha faz diferença nas margens, porque as ferramentas têm opiniões. Algumas pressupõem um único time com um quadro; outras, um portfólio com dependências e datas; outras, que o trabalho é inseparável do código. Este guia trata de casar essa opinião com a sua situação e, depois, configurar a ferramenta para que ela ajude em vez de atrapalhar.

O que uma ferramenta deve ou não deve decidir

Uma ferramenta de acompanhamento é um registro compartilhado. Suas funções legítimas são manter uma lista única e oficial do trabalho, mostrar o estado atual com honestidade, preservar o histórico do que foi decidido e quando, ligar o trabalho ao código e aos deploys que o implementaram e responder a perguntas sobre o fluxo que ninguém consegue responder de memória.

O que ela não deve fazer é decidir o processo. Se o workflow tem sete estados porque o template da ferramenta tinha sete, o time adotou por acidente o processo de um estranho. Se os itens não podem ir para "em andamento" sem estimativa porque um campo é obrigatório, uma política de estimativa foi definida pela configuração, e não por acordo. A ordem é sempre a mesma: combinar como vocês querem trabalhar, configurar a ferramenta para refletir isso e depois revisitar as duas coisas.

O corolário é que uma ferramenta não resolve a questão da responsabilidade. Um backlog só está priorizado se alguém o prioriza, não importa o que o software permita; veja product owner e gestão do backlog para entender o que isso envolve.

As principais opções, por adequação

Listas de funcionalidades quase não servem para escolher, porque os produtos mais usados convergiram. O que muda é a situação em que cada um se sente à vontade.

Duas observações honestas. Primeiro, a maioria dos times conseguiria trabalhar bem com qualquer uma delas: a diferença de resultado entre duas ferramentas bem configuradas é muito menor que a diferença entre uma instância bem configurada e uma mal configurada da mesma ferramenta. Segundo, o custo que domina não é a licença, e sim a administração e a migração; por isso, trocar de ferramenta por causa de uma funcionalidade quase nunca se justifica, enquanto trocar porque ninguém mantém a instância atual muitas vezes se justifica.

Produtos dedicados a cronogramas continuam sendo uma categoria à parte. Quando uma entrega realmente precisa de uma rede de dependências, de um histograma de recursos e de um caminho crítico, a visão de linha do tempo de uma ferramenta de acompanhamento é um gráfico de barras, não um modelo de cronograma, e a distinção importa pelos motivos explicados em gerenciamento do cronograma.

As visões e a pergunta que cada uma responde

A maioria das ferramentas oferece o mesmo punhado de visões, e a confusão sobre o propósito de cada uma causa mais problemas do que qualquer funcionalidade ausente.

Um quadro responde a "qual é o estado do trabalho em andamento agora?". As colunas são estados, os cartões são itens, e o valor está em limitar quantos cartões podem ficar em cada coluna: é o limite de trabalho em andamento (WIP) que transforma um quadro de status em um controle de fluxo. Um quadro sem limites e com quarenta cartões em andamento é um mural de boas intenções.

Um backlog responde a "o que devemos fazer em seguida?". É uma lista ordenada, e a ordem é o conteúdo; um backlog exibido como uma pilha plana e sem ordem de centenas de tickets não é um backlog.

Uma visão de linha do tempo ou Gantt responde a "quando cada coisa vai chegar em relação às outras?". Ela serve para datas externas fixas, prazos de entrega de hardware e dependências entre vários times, e se torna enganosa quando é desenhada à mão e não se recalcula quando uma barra se move.

Uma visão de roadmap responde a "aonde queremos chegar nos próximos horizontes?" e funciona melhor quando mostra objetivos, e não funcionalidades com data.

Um relatório ou dashboard responde a "como estamos indo?", uma pergunta que só é útil se a resposta muda alguma decisão.

Escolha a visão pela pergunta, não pela preferência de cada pessoa, e desconfie de qualquer pedido de visão cujo propósito não possa ser formulado como pergunta.

Armadilhas de customização

É na configuração que as ferramentas dão errado, e os modos de falha são consistentes o bastante para serem listados.

• Workflow inchado. Dez estados, seis transições cada, três delas exigindo aprovação. Cada estado a mais é um lugar onde o trabalho fica parado e uma decisão que alguém precisa tomar. De três a cinco estados atendem à maioria dos times; acrescente um só quando existir uma passagem de bastão real e a falta dele já tiver causado problema.
• Acúmulo de campos obrigatórios. Cada campo pareceu razoável para quem o pediu. Juntos, eles transformam a criação de um item em uma tarefa chata de cinco minutos, então as pessoas colam texto de enchimento em campos que não entendem e os dados ficam piores do que nenhum dado.
• Divergência entre times. Oito times, oito workflows e tipos de issue diferentes, e nenhuma possibilidade de uma visão consolidada que faça sentido. Combinem um núcleo comum e permitam acréscimos locais.
• Configuração guiada por relatórios. Campos que existem só para alimentar um gráfico gerencial. O time não ganha nada em mantê-los, então não os mantém com precisão.
• Automações que pegam as pessoas de surpresa. Regras que reatribuem, mudam o estado ou fecham itens de forma invisível. Automação é excelente para etapas mecânicas e corrosiva quando o quadro muda por motivos que ninguém sabe explicar.
• Permissões travadas. Configurações em que os desenvolvedores não podem editar os próprios itens e precisam pedir a um administrador. Cada restrição desse tipo tira o trabalho da ferramenta e o leva para o chat, onde não fica registro nenhum.

O princípio geral: o custo da configuração é pago em cada interação, para sempre, enquanto o benefício costuma ser um relatório que alguém pediu uma vez.

Conectando ao pipeline de entrega

A integração mais valiosa é também a mais barata: coloque a chave do item no nome da branch e na mensagem de commit, e a ferramenta liga o trabalho ao código automaticamente. A partir daí, o sistema de build consegue informar quais commits, e portanto quais itens, estão em um determinado deploy, e o item pode mostrar se chegou a staging ou à produção. O guia de workflows de branches cobre as convenções de nomes que tornam isso confiável.

Outras três conexões compensam o esforço. Transições automáticas no merge (mover um item para "em revisão" ou "concluído" quando o merge request é aprovado) eliminam uma atualização de status que ninguém quer fazer à mão. Um link de um deploy para os seus itens gera release notes de graça. E ligar os tickets de incidente à mudança que os causou constrói os dados necessários para medir com honestidade a taxa de falha de mudanças; é aí que o acompanhamento encontra o pipeline de entrega como ciclo de feedback, e não como sistema administrativo.

Resista à tentação de automatizar transições que representam um julgamento humano. "Concluído" geralmente significa que alguém verificou alguma coisa; uma regra que marca isso no merge redefine silenciosamente a definition of done do time.

Relatórios que valem a pena e higiene dos dados

Toda ferramenta vem com mais gráficos do que alguém precisa. Um pequeno conjunto realmente orienta decisões.

Repare que os gráficos de velocidade não estão na lista. Eles são aceitáveis como insumo interno de um time, como discutido no guia do framework Scrum, e prejudiciais no momento em que aparecem em um dashboard que compara times.

Todos esses relatórios dependem da higiene dos dados, que é pouco glamorosa e decisiva. Os estados precisam ser atualizados quando mudam, e não reconstruídos na sexta-feira antes de um relatório. Os itens precisam ser fechados quando concluídos, e itens obsoletos precisam ser excluídos em vez de se acumularem: um backlog com três anos de tickets intocados é um backlog em que ninguém confia. Duplicatas precisam ser mescladas. E a estimativa ou o tamanho registrado deve ser o que o time realmente combinou, nunca um valor editado depois para deixar um gráfico mais bonito.

Seleção e implantação

1. Escreva as perguntas que você precisa responder

   Não funcionalidades: perguntas. "Quais itens estão bloqueados?", "quando esta release vai sair?", "quanto da nossa capacidade vai para defeitos?". Uma ferramenta que não responde às suas perguntas está desclassificada, seja qual for a lista de funcionalidades.

2. Modele primeiro o seu processo real

   Desenhe os estados pelos quais o trabalho realmente passa hoje, incluindo os informais. Se o processo não estiver claro, resolva isso antes de ir às compras; uma ferramenta vai codificar qualquer confusão que você levar para ela.

3. Faça um piloto com um time real em trabalho real

   De duas a quatro semanas, com trabalho de verdade, não em um sandbox. Avalie a rapidez das ações do dia a dia, a qualidade do quadro e quanta administração ela exigiu.

4. Configure o mínimo

   Workflow padrão, poucos campos, poucos tipos de issue. Acrescente configuração só em resposta a um problema comprovado, e registre por que cada acréscimo existe para que possa ser removido depois.

5. Defina quem é dono da configuração

   Um administrador nomeado, com tempo reservado para isso. Instâncias sem dono acumulam campos customizados e projetos abandonados até que ninguém confie nos dados.

6. Migre de forma seletiva, não completa

   Leve o trabalho em aberto e o histórico recente; arquive o resto como somente leitura. Migrar com fidelidade total anos de tickets fechados custa muito mais do que compensa.

7. Revise depois de um trimestre

   Quais campos estão vazios, quais estados nunca são usados, quais relatórios ninguém abre. Excluir configuração vale tanto quanto adicionar, e acontece com muito menos frequência.

Principais pontos

• Uma ferramenta registra decisões e torna o estado visível; ela não fornece responsabilidade, priorização nem um processo que o time não tenha combinado.
• Os produtos mais usados convergiram em funcionalidades, então escolha pela situação em que cada um fica à vontade e por quem vai administrá-lo, não por tabelas comparativas.
• Case a visão com a pergunta: quadros com limites para o trabalho em andamento, backlogs para priorizar, linhas do tempo para datas externas, roadmaps para objetivos.
• A configuração é paga em cada interação: mantenha os workflows entre três e cinco estados, resista a campos obrigatórios e nunca configure para um relatório do qual o time não tira nada.
• Ligue os itens a branches, commits e deploys; essa única integração gera release notes, rastreabilidade e métricas de entrega honestas quase de graça.
• Relatórios só são úteis com dados limpos, então feche, mescle e exclua sem dó, e mantenha a velocidade fora de qualquer dashboard que compare times.