Kanban ou Gantt? A resposta é quase sempre os dois

A pergunta aparece em todas as implementações de ferramentas: a equipa vai trabalhar com um quadro Kanban ou com um cronograma de Gantt? Em geral é feita como se fosse uma escolha de metodologia, quase uma escolha de identidade — os ágeis de um lado, os tradicionais do outro.

Só que as duas coisas respondem a perguntas diferentes. Escolher uma é abdicar da resposta da outra. E quem abdica costuma descobri-lo tarde, no dia em que o cliente pergunta a data de entrega e ninguém sabe dizer sem abrir uma folha de cálculo paralela.

O que cada um responde

O quadro responde "em que ponto estamos"

O Kanban mostra o trabalho parado a meio do caminho. Cada cartão é uma tarefa, cada coluna é um estágio, e o olho apanha em dois segundos o que está bloqueado na revisão há uma semana. É uma fotografia do presente, boa para a conversa diária da equipa.

O que o quadro não diz: se aquela acumulação na coluna de revisão vai ou não rebentar a entrega de novembro. Não tem noção de futuro.

O cronograma responde "quando termina"

O Gantt transforma cada tarefa numa barra no tempo e liga umas às outras. Existe para responder a duas perguntas que o quadro ignora: quando é que isto acaba, e o que acontece se esta etapa se atrasar três dias.

O que o cronograma não diz: quem está com o quê agora, e onde o trabalho está encravado hoje. É bom ao mês, mau à terça-feira.

Quando o quadro sozinho resolve

Existe um caso legítimo para usar só o quadro. Surge quando o trabalho tem três características:

• Fluxo contínuo, sem data final combinada. Suporte, manutenção, pedidos internos, conteúdo recorrente. Não existe "entrega do projeto", existe fila.
• Tarefas independentes. Nenhuma espera que a outra termine. Se tudo pode andar em paralelo, não há nada a sequenciar.
• Ninguém de fora cobra datas. Quando não há contrato nem cliente à espera, a previsão vale menos do que o andamento.

Metade das equipas que usam uma ferramenta de projetos está neste caso. Para elas, montar um cronograma é uma cerimónia sem retorno.

Quando o cronograma deixa de ser opcional

Passa a ser obrigatório quando existe dependência com data prometida. Uma obra que só começa depois da licença. Uma campanha que depende da aprovação do cliente. Uma implementação com marco contratual. Nestes casos, a pergunta "isto atrasa a entrega?" é feita todas as semanas, e responder a olho custa caro.

Um sinal de que chegou a hora: alguém da equipa mantém uma folha de cálculo de datas fora da ferramenta. Essa folha é o cronograma que o quadro não dá.

Há um segundo sinal, mais subtil. Quando a equipa começa a discutir a ordem de execução nas reuniões — "isto tem de sair antes daquilo, senão bloqueia" —, essa conversa está a tentar resolver, na memória de todos, um problema de sequência. A sequência é exatamente o que uma barra ligada a outra regista, e registar liberta a equipa de repetir a discussão todas as semanas.

Lado a lado

Pergunta do dia a dia	Quadro	Cronograma
Em que ponto está o trabalho agora?	Responde bem	Responde mal
Quem está sobrecarregado?	Responde bem, com pistas por responsável	Responde mal
Quando termina o projeto?	Não responde	Responde bem
Este atraso de hoje altera a entrega?	Não responde	Responde bem, pelas dependências
O que fazer nesta semana?	Responde bem	Responde assim-assim

O trabalho a dobrar que assusta (e como evitá-lo)

A resistência a usar os dois quase nunca é conceptual. É prática: quem já manteve um quadro numa ferramenta e um cronograma numa folha de cálculo sabe que os dois se desfazem em duas semanas. Alguém move o cartão, ninguém atualiza a barra, e o cronograma passa a ser ficção.

O problema aqui não é a técnica, é a duplicação. Quando quadro e cronograma são a mesma tarefa vista de duas maneiras, não há sincronização para fazer: concluir o cartão move a barra, e arrastar a barra altera o prazo que aparece no cartão. É assim que funciona o quadro Kanban da Tasskee em relação ao cronograma com dependências e caminho crítico.

Se a sua ferramenta atual o obriga a manter duas listas, o problema é a ferramenta. E vale a pena dizer: lista e quadro estão em todos os planos da Tasskee, incluindo o Free; o cronograma entra no Pro, que o teste de 15 dias liberta sem cartão.

Vale a pena fazer um teste antes de adotar qualquer ferramenta: altere a data de uma tarefa no cronograma e veja se ela muda no quadro. Depois conclua o cartão no quadro e veja se a barra o reflete. Se qualquer um dos dois exigir uma segunda edição manual, vai acabar por manter duas verdades — e a que ninguém atualiza é sempre a que o cliente vê.

Como usar os dois sem cair na burocracia

1. Monte o cronograma só ao nível que consegue defender. Vinte barras que representam etapas, não duzentas que representam cada subtarefa. O detalhe fino vive no quadro.
2. Ligue apenas as dependências reais. Dependência é "não pode começar antes", não "seria melhor fazer por esta ordem". Um cronograma cheio de linhas falsas bloqueia sozinho.
3. Use o quadro para a conversa do dia. A reunião diária olha para colunas, não para barras.
4. Use o cronograma para a conversa do mês. A reunião com o cliente ou a direção olha para marcos e datas.
5. Reveja o cronograma uma vez por semana. Quinze minutos. Se precisar de mais do que isso, está demasiado detalhado.

E os ciclos curtos?

Existe uma terceira vista que costuma entrar nesta discussão: o sprint. Não compete com nenhuma das duas — resolve o "o que cabe nas próximas duas semanas", que o quadro não delimita e o cronograma não decide. As equipas que trabalham por ciclos usam as três: cronograma para a viagem, sprint para o troço, quadro para o dia.

E se a dúvida for por onde começar, comece pelo quadro. É mais barato de adotar, a equipa percebe-o sem formação e já organiza o presente. O cronograma entra quando surgir a primeira pergunta sobre datas a que não consiga responder olhando para as colunas. Tratamos do passo seguinte em como montar um cronograma que a equipa cumpre.