Alternativa à Asana para o planeamento de projetos

Onde a linha do tempo da Asana deixa de ser um cronograma

A maioria dos artigos sobre uma alternativa à Asana para o planeamento de projetos começa por afirmar que a Asana não tem diagrama de Gantt. Não é verdade, e partir de uma premissa falsa é uma má forma de ajudar alguém a escolher uma ferramenta. A Asana tem uma vista de linha do tempo que desenha barras num eixo horizontal, liga-as com setas, marca os marcos como losangos e, a pedido, pode destacar o caminho crítico. Para uma campanha, o lançamento de um produto ou um processo de recrutamento, é uma forma perfeitamente razoável de planear.

A pergunta honesta é outra. Não se o diagrama existe, mas se por trás dele há um modelo de planeamento, ou seja, um conjunto de regras que o sistema aplica quando algo se move. Um diagrama sem modelo é a imagem de um plano. Um diagrama com modelo é um plano. A diferença só se vê quando a realidade começa a pressionar as datas, o que costuma acontecer na terceira semana, não no dia em que o plano é aprovado.

O que a Asana faz bem

A Asana é realmente boa a tornar o trabalho visível e a levar as pessoas a agir sobre ele. As tarefas têm responsáveis, comentários e prazos claros, a linha do tempo é fácil de manipular e as tarefas dependentes deslocam-se quando o seu antecessor se move. As dependências são descritas numa linguagem que ninguém precisa de aprender, bloqueia e bloqueada por, razão pela qual as equipas adotam a ferramenta numa tarde. Para dez pessoas a conduzir uma campanha de oito semanas, isso não é um compromisso, é a quantidade certa de ferramenta para a tarefa. Qualquer comparação que finja o contrário está a vender em vez de aconselhar.

Vale a pena notar onde se paga essa simplicidade. Cada capacidade que a Asana deixa de fora da linha do tempo é uma que teria tornado o produto mais difícil de aprender, e para a maioria dos seus utilizadores essa é a troca certa. A questão é o que acontece às equipas para quem não é.

O momento em que o plano deixa de se recalcular sozinho

O ponto de viragem chega em silêncio. Um fornecedor confirma a entrega duas semanas mais tarde do que o previsto, e o gestor de projeto move uma tarefa na linha do tempo. A sucessora imediata segue-a, porque essa ligação é compreendida. Depois o gestor repara que o teste de aceitação agendado após um período obrigatório de cura de duas semanas começa agora demasiado cedo, porque o intervalo entre essas tarefas nunca foi uma regra, apenas espaço vazio num diagrama. A tarefa do projeto vizinho que devia começar após esta entrega não se move de todo, porque os dois projetos não sabem um do outro. Meia hora depois o gestor está a arrastar barras à mão e a conferir datas com uma folha de cálculo.

Esse é o momento em que um cronograma deixa de ser um modelo. O plano já não é algo que o sistema mantém, é algo que uma pessoa mantém, e essa pessoa torna-se o único ponto de falha. Cada replaneamento custa horas, cada hora de replaneamento é uma hora não dedicada ao problema real, e após a terceira ou quarta iteração as pessoas deixam de atualizar o plano por completo porque o esforço já não compensa. Um plano abandonado é pior do que nenhum plano, porque continuam a ser gerados relatórios a partir dele.

Cinco sinais de que ultrapassou o planeamento da Asana

Nenhum destes sinais tem a ver com o tamanho da equipa nem com o orçamento. Têm a ver com a forma do trabalho, razão pela qual uma equipa de engenharia de doze pessoas pode esbarrar neles enquanto um departamento de marketing de sessenta nunca o faz. Se dois ou mais descrevem os seus projetos, a sua restrição é a camada de planeamento, não o número de funcionalidades.

Planeia em dias úteis, não em dias de calendário. Uma tarefa de cinco dias que começa na quinta-feira deve terminar na quarta-feira seguinte, e um feriado no meio deve empurrar o fim mais um dia. Se as suas durações incluem em silêncio os fins de semana, cada estimativa carrega um erro embutido que se acumula ao longo de um plano de vários meses.

Alguns intervalos do seu plano são física, não preferência. O betão cura, os revestimentos secam, corre um período de validação, expira um prazo de pré-aviso, um regulador tem trinta dias para responder. Não são tarefas que alguém execute, são intervalos que têm de decorrer entre duas tarefas. As equipas sem forma de os exprimir inventam tarefas de preenchimento chamadas «a aguardar aprovação», o que polui a lista de tarefas e induz em erro cada relatório construído sobre ela.

O cronograma de um projeto impulsiona o de outro. No momento em que uma entrega no projeto de infraestrutura condiciona o arranque do projeto de migração, e ambos são geridos separadamente, alguém está a guardar essa dependência na memória. A memória não envia notificações e não sobrevive às férias.

Perguntam-lhe quanto o projeto se desviou do plano original. Não quais são as datas atuais, mas como se comparam com o que foi aprovado, e porquê. Sem uma linha de base guardada a resposta honesta é que ninguém sabe, e a versão que circula na apresentação do comité de direção é uma reconstrução.

O cronograma precisa de mais de dois níveis. Fases que contêm etapas que contêm tarefas, com o progresso a somar-se automaticamente para cima e com datas próprias em cada nível. Uma lista plana com cabeçalhos de secção parece semelhante no ecrã e comporta-se de forma totalmente diferente quando o plano muda.

Os tipos de dependência e porque a sua semântica decide o plano

Uma dependência não é uma linha traçada entre duas barras. É uma regra que o sistema aplica sempre que qualquer uma das extremidades se move, e o tipo de relação é o conteúdo dessa regra. É a parte que a maioria das comparações de ferramentas salta, porque uma tabela com um visto ao lado de «dependências de tarefas» esconde a diferença entre um sistema que redesenha setas e um sistema que recalcula datas. Tanto o FlexiProject como a Asana suportam os quatro tipos padrão, por isso a pergunta interessante é o que os rodeia.

Acertar na semântica não é precisão pela precisão. Decide se um gestor de projeto responde à pergunta «se isto atrasar uma semana, quando terminamos» em três segundos a olhar para o diagrama, ou em três horas a reconstruir o plano. Onde vários projetos competem pelas mesmas pessoas, essa diferença decide se o replaneamento chega sequer a acontecer.

FS, SS, FF e SF na prática

Fim para início é o valor por omissão em todo o lado e cobre a maior parte do trabalho sequencial: a parede tem de ser construída antes de ser pintada. Início para início descreve trabalho que corre em paralelo a partir de um gatilho comum, por exemplo a documentação que começa no momento em que começa o desenvolvimento e se mantém mais ou menos a par. Fim para fim descreve trabalho que tem de aterrar em conjunto, como a formação de utilizadores que tem de estar completa no dia em que o sistema entra em produção, independentemente de quando começou. Início para fim é raro e aparece sobretudo em transições, onde o sistema antigo só pode ser desligado quando o novo estiver a funcionar.

Quem constrói cronogramas a sério usará pelo menos os três primeiros, e as organizações de projeto maduras usam os quatro para modelar a realidade com precisão em vez de forçar tudo numa cadeia de ligações fim para início. Se quiser um percurso mais aprofundado com exemplos trabalhados, escrevemos em separado sobre os tipos de dependências de tarefas num diagrama de Gantt.

Atraso fixo: os dias que simplesmente têm de passar

No FlexiProject, cada relação pode carregar um atraso fixo expresso em dias. A dependência significa então «começa esta tarefa quatro dias depois de a anterior terminar», e esses quatro dias fazem parte da regra em vez de serem um intervalo que alguém estimou a olho no diagrama. Quando o antecessor se move, o atraso move-se com ele, automaticamente e sem que ninguém se lembre de que estava lá.

O efeito de negócio é que as restrições tecnológicas deixam de viver na cabeça das pessoas. Um período de cura, uma janela de revisão regulatória, uma quarentena obrigatória entre lotes de produção ou um prazo de pré-aviso contratual passa a fazer parte da lógica do plano. Ninguém tem de criar uma tarefa falsa para manter o espaço aberto, ninguém tem de explicar a um colega porque é que duas barras não devem ser juntadas, e nenhum replaneamento pode eliminar em silêncio uma restrição imposta pela física ou por um contrato. Em projetos onde uma sequência falhada significa retrabalho e não um e-mail atrasado, esta é a diferença entre um plano em que se pode confiar e um plano que se tem de verificar duas vezes.

Relações rígidas: quando a ligação não deve ser quebrada

O FlexiProject distingue ainda as relações rígidas, marcadas no painel da tarefa com dois anéis entrelaçados. Uma relação rígida significa que o elemento ligado não pode ser arrastado à mão para longe do seu antecessor. O sistema não deixará um utilizador quebrar em silêncio a sequência movendo uma barra no diagrama, o que soa restritivo até se ter visto um cronograma degradar-se ao longo de seis meses de ajustes manuais bem-intencionados.

Isto importa sobretudo onde um cronograma é um documento partilhado e não o ficheiro de uma só pessoa. Num projeto grande várias pessoas editam o plano, e cada uma tem uma razão local para mover algo. Uma relação rígida codifica a diferença entre uma sequência que é um pressuposto de planeamento, e por isso aberta a discussão, e uma sequência que é uma restrição rígida, e por isso não. O gestor de projeto deixa de vigiar o plano à mão e começa a confiar nele, que é todo o propósito de um software de planeamento desde o início.

Dependências entre projetos: a camada que a Asana não tem

Dentro de um único projeto, as dependências são uma conveniência. Entre projetos, são a diferença entre um programa e uma pasta de planos sem ligação. No FlexiProject uma relação pode ligar uma tarefa de um projeto a uma tarefa de outro, de modo que a entrega de infraestrutura que condiciona uma migração é uma ligação que o sistema conhece e não uma nota na ata de reunião de alguém. Quando a data de um lado se move, as tarefas dependentes do outro projeto são recalculadas e os seus responsáveis notificados.

A consequência prática aparece na tomada de decisão, não no diagrama. Antes de aprovar uma alteração num projeto, um gestor de programa pode ver como essa alteração se propaga pelos restantes projetos, comparar o cronograma antes e depois e ajuizar o custo real de dizer que sim. Sem isso, o custo emerge semanas mais tarde como uma série de surpresas separadas, cada uma das quais parece um problema local e é tratada como tal. Os programas plurianuais são exatamente onde isto se acumula, porque uma decisão de duas semanas tomada de ânimo leve no terceiro mês pode mover uma data de entrada em produção no vigésimo.

Todas as tarefas de um programa são além disso visíveis num único diagrama de Gantt partilhado, de modo que um gestor de programa vê as ligações num só lugar em vez de as reconstruir a partir de relatórios de estado. As equipas que precisam disto costumam descobri-lo da forma difícil, depois de terem primeiro tentado coordenar o mesmo com uma reunião recorrente. Se a sua organização vai nessa direção, o nosso software para gerir programas de projetos explica como os programas são estruturados.

O modelo por baixo do diagrama de Gantt

As relações são a parte mais visível do modelo de planeamento, mas não são todo o modelo. Outros quatro mecanismos decidem se um diagrama se comporta como um plano, e são eles que separam um software de diagrama de Gantt de um widget de linha do tempo. Nenhum deles é exótico. Todos são daquelas coisas que só se sentem em falta quando se precisa delas.

WBS ilimitada e progresso que se soma sozinho

Os projetos de uma organização variam enormemente em escala, de uma vitória rápida de duas semanas a um investimento de capital de vários anos, e uma única estrutura rígida não pode servir ambos. O FlexiProject não põe limite à profundidade da estrutura de tarefas, por isso um projeto pode ser dividido em fases, etapas, tarefas e marcos tão abaixo quanto for preciso. Um projeto pequeno pode ficar plano com um punhado de tarefas, enquanto um projeto de investimento pode carregar uma estrutura de decomposição do trabalho de vários níveis, e ambos usam a mesma interface.

O progresso é introduzido apenas ao nível das tarefas individuais. O progresso de etapa e o progresso global do projeto são calculados automaticamente a partir das tarefas abaixo, por isso ninguém tem de se lembrar de atualizar os agregados antes de sair um relatório. Isto soa a pequena conveniência e é na verdade um mecanismo de qualidade de dados: o estado ao nível do portefólio é derivado dos mesmos números que a equipa mantém diariamente, e não de um resumo que alguém digitou à pressa na véspera de um comité de direção.

Um calendário de trabalho em vez de datas de calendário em bruto

Um cronograma que conta os fins de semana como tempo de trabalho produz datas erradas desde o primeiro dia. O FlexiProject calcula as durações contra um calendário de trabalho, por isso uma tarefa expressa em dias úteis aterra onde realmente aterra depois de considerados os fins de semana e os feriados. A mesma lógica sustenta os modelos reutilizáveis: as tarefas de um modelo guardam uma duração em dias úteis e um conjunto de dependências em vez de datas fixas, por isso introduzir uma data de início do projeto gera todo o cronograma automaticamente.

Para uma organização que executa projetos semelhantes repetidamente, é aqui que o tempo de planeamento desaba. Em vez de reconstruir um plano do zero e voltar a derivar cada data, um gestor de projeto parte de uma estrutura aprovada e ajusta o que é verdadeiramente diferente neste caso. O nosso módulo de modelos de projeto existe exatamente para este padrão, e é também a razão pela qual os modelos construídos por um PMO experiente mantêm o seu valor durante anos.

Linha de base e desvio face ao plano

Uma vez aprovado um plano, o FlexiProject guarda-o como linha de base. O diagrama de Gantt mostra então o plano original ao lado do cronograma atual, de modo que cada desvio é visível de imediato em vez de inferido. O sistema também prevê a data de conclusão do projeto face à aprovada, que costuma ser o único número que um conselho de administração realmente quer.

O valor aqui tem menos a ver com a medição e mais com a qualidade da conversa. Um gestor de projeto que consegue mostrar o que foi aprovado, qual é a situação agora e que decisão causou a diferença está numa posição diferente de quem só consegue relatar as datas atuais. A discussão passa de se o projeto está atrasado para o que fazer com a causa concreta, que é a única versão dessa conversa que termina numa decisão.

Caminho crítico e folga

O FlexiProject identifica o caminho crítico automaticamente e marca-o a vermelho no diagrama de Gantt, por isso um gestor de projeto sabe de imediato que tarefas merecem atenção. O uso prático está na triagem. Um deslize de dois dias numa tarefa crítica é um deslize de dois dias para todo o projeto, enquanto um deslize de dois dias numa tarefa com dez dias de folga é ruído. Sem essa distinção cada atraso é escalado com a mesma urgência, o que ensina toda a gente a ignorar os escalonamentos.

Com vários fluxos em paralelo, por exemplo a obra a correr ao lado da montagem e da documentação, o caminho crítico é o que impede um gestor de otimizar o errado. Se o conceito é novo para a sua equipa, cobrimos com mais profundidade o que é o caminho crítico e como o gerir.

Recursos no diagrama de Gantt: tempo e capacidade planeados em conjunto

Um cronograma que ignora quem está disponível é uma lista de desejos. O FlexiProject mostra a carga de recursos diretamente a partir do diagrama de Gantt, por isso um gestor de projeto vê num relance que pessoas estão sobrecarregadas num dado período e quais ainda têm capacidade. As tarefas podem ser movidas ao longo da linha do tempo enquanto se observa a carga mudar, o que transforma o replaneamento numa simulação em vez de um palpite: o plano é otimizado antes de ser aprovado, não depois de alguém se queixar.

Isto fecha uma lacuna que aparece constantemente em organizações que conduzem vários projetos com as mesmas pessoas. Planear um novo projeto significa saber se os especialistas de que precisa já estão comprometidos noutro lado, e na maioria das empresas essa verificação é feita à mão, numa folha de cálculo, com um atraso longo o suficiente para tornar a resposta obsoleta. Quando a capacidade está na mesma vista que as datas, a troca entre terminar mais cedo e sobrecarregar uma equipa deixa de ser invisível até alguém se despedir.

Os atrasos afloram com a mesma franqueza. As tarefas que ficaram para trás são realçadas a vermelho, por isso abrir o projeto basta para ver onde é preciso intervir, sem gerar primeiro um relatório. Para organizações que querem ir mais longe e gerir a disponibilidade em todo o portefólio, o nosso software de gestão de recursos trata a carga para além de um único projeto.

FlexiProject e Asana: as capacidades de planeamento comparadas

A tabela abaixo é deliberadamente estreita. Cobre apenas o planeamento e concede à Asana cada capacidade que ela realmente tem, porque uma comparação que subestima um concorrente é inútil para quem a lê. A colaboração, a automatização de fluxos e as integrações são outra conversa, e em várias delas a Asana é o produto mais forte.

Leia a tabela como uma descrição de intenção e não como um marcador. A Asana está construída para que qualquer pessoa possa planear sem formação, e cada capacidade acima que omite é uma que tornaria o produto mais difícil de aprender. O FlexiProject aceita um arranque um pouco mais íngreme em troca de um cronograma que mantém a forma sob pressão. Que troca é a correta depende inteiramente de os seus projetos penalizarem um plano impreciso.

Tirar um cronograma da Asana sem perder o plano

A parte mecânica de uma migração leva menos tempo do que as pessoas esperam. Um cronograma importa-se a partir de um ficheiro Excel ou de um ficheiro Microsoft Project, trazendo tarefas, responsáveis, atributos disponíveis e, quando existe, a estrutura de dependências, por isso as organizações sentadas sobre anos de planos históricos não têm de os redigitar. As exportações vão no sentido contrário para Excel, Microsoft Project XML, PDF e PNG, o que importa quando um empreiteiro ou um auditor insiste num formato específico.

A parte que merece verdadeira reflexão é a remodelação. Um plano construído na Asana foi construído sob as restrições da Asana, o que significa que os períodos de espera são provavelmente tarefas falsas, a sequência é provavelmente uma cadeia de ligações fim para início e a estrutura de fases são provavelmente cabeçalhos de secção. Copiar isso fielmente reproduz a limitação num sistema que já não a tem. A melhor abordagem é pegar num projeto representativo, reconstruir a sua lógica como deve ser com os tipos de relação certos, atrasos fixos onde os intervalos são obrigatórios e relações rígidas onde a sequência não é negociável, e usar o resultado como modelo para tudo o que se segue.

Para a primeira passagem há um atalho que vale a pena conhecer. O FlexiProject consegue gerar um rascunho de cronograma a partir de uma descrição dos objetivos e requisitos do projeto, produzindo tarefas, marcos, dependências e um diagrama de Gantt que um gestor de projeto depois edita em vez de construir do nada. Não substituirá o discernimento de um planeador experiente, mas remove o problema da página em branco, onde a maioria dos esforços de replaneamento encalha. Para um percurso estruturado, escrevemos sobre como construir um cronograma de projeto passo a passo.

Perguntas frequentes

A Asana suporta os quatro tipos de dependência?

Sim. A Asana suporta fim para início, fim para fim, início para início e início para fim, com fim para início por omissão. As afirmações de que a Asana só oferece um tipo de dependência aparecem em vários artigos de comparação e estão desatualizadas. As lacunas relevantes no planeamento da Asana estão noutro lado: nos atrasos fixos, nas relações rígidas, nos calendários de trabalho, nas linhas de base e nas ligações entre projetos.

É possível definir um tempo de atraso entre tarefas na Asana?

Não. A Asana não permite anexar um atraso fixo a uma dependência, por isso um intervalo obrigatório entre duas tarefas tem de ser representado de outra forma, normalmente com um espaço vazio na linha do tempo ou uma tarefa de preenchimento. Ambas as soluções de recurso quebram assim que o antecessor se move, porque nenhuma leva o atraso consigo. No FlexiProject o atraso é uma propriedade da própria relação e é expresso em dias.

A Asana tem uma linha de base de projeto?

Não. A Asana não guarda uma versão aprovada do cronograma para comparação, por isso não há forma integrada de ver quanto o plano atual se desviou do que foi acordado inicialmente. As equipas que precisam disto costumam guardar um instantâneo numa folha de cálculo, que responde à pergunta uma vez e depois fica obsoleto. O FlexiProject conserva o plano aprovado como linha de base e mostra-o ao lado do cronograma atual no diagrama de Gantt.

É possível ligar tarefas de dois projetos diferentes?

Na Asana não. As dependências ficam dentro de um único projeto, por isso uma sequência entre projetos tem de ser coordenada por pessoas em vez de mantida pelo sistema. O FlexiProject permite uma relação entre tarefas pertencentes a projetos diferentes, recalcula as datas dependentes quando qualquer um dos lados se move e notifica os responsáveis afetados, que é o requisito básico para gerir um programa em vez de um conjunto de projetos paralelos.

O FlexiProject é mais difícil de usar do que a Asana?

Pede mais no início e menos depois. A Asana está concebida para que alguém possa planear no seu primeiro dia, em parte deixando de fora os conceitos descritos neste artigo. O FlexiProject espera que um gestor de projeto compreenda os tipos de relação, os calendários de trabalho e as linhas de base, e em troca mantém o plano em vez de pedir a uma pessoa que o mantenha. As equipas com projetos simples acharão a Asana mais rápida. As equipas cujos projetos penalizam um plano impreciso costumam achar o contrário.

Escolher uma alternativa à Asana para o planeamento de projetos não é realmente uma escolha entre duas ferramentas. É uma decisão sobre se os seus projetos precisam de um plano que uma pessoa mantém ou de um plano que um sistema mantém, e isso depende de quão caro é quando as datas estão erradas. Se uma data derrapada significa uma reunião reagendada, a Asana é uma boa resposta e acrescentar maquinaria de planeamento só atrasaria a equipa. Se uma data derrapada significa empreiteiros parados, uma janela regulatória perdida, retrabalho numa linha de produção ou uma cláusula de penalização, então o modelo por baixo do diagrama não é um pormenor. É o produto.

O que muda com um modelo de planeamento completo é mais pequeno do que uma lista de funcionalidades sugere e maior do que parece. As relações carregam atrasos fixos, por isso os intervalos obrigatórios fazem parte do plano em vez da memória de alguém. As relações rígidas seguram sequências que não estão abertas a negociação. As dependências atravessam projetos, por isso um programa comporta-se como um programa. Um calendário de trabalho faz com que as durações signifiquem o que dizem, uma linha de base torna o desvio visível, e o caminho crítico diz que atrasos importam de facto. Em separado parecem refinamentos. Em conjunto são a diferença entre replanear em minutos e replanear ao longo de um fim de semana.

Se quiser ver os dois produtos lado a lado em todo o âmbito e não apenas no cronograma, incluindo orçamentos, riscos, termos de abertura de projeto e governação de portefólio, preparámos uma comparação detalhada entre FlexiProject e Asana. E se os seus projetos já estão a pressionar os limites descritos aqui, o passo seguinte mais útil é pegar num deles, reconstruir o seu cronograma como deve ser e ver quanto trabalho manual desaparece.