Aplicações como o Asana: o que procurar para além das listas de tarefas

Porque é que as equipas começam a procurar aplicações como o Asana

O Asana faz bem aquilo para que foi concebido. Dá à equipa um lugar partilhado para tarefas, atribuições, comentários e ficheiros, aprende-se depressa e as pessoas usam-no de facto, o que é uma fasquia mais alta do que a que a maioria do software ultrapassa. Quando as equipas começam a procurar alternativas, o gatilho raramente é uma falha. É uma mudança naquilo que lhes pedem para gerir: uma equipa que coordenava campanhas agora entrega uma implementação para um cliente com um valor de contrato, ou uma empresa que levava quatro projetos ao mesmo tempo leva agora trinta. As tarefas não ficaram mais difíceis; a responsabilidade ficou.

O ponto em que um sistema de gestão de projetos se torna indispensável merece ser nomeado com precisão, porque determina o tipo de ferramenta que deveria procurar. Alguém pergunta agora quando é que o projeto termina, quanto resta do orçamento e se as pessoas necessárias em março estarão disponíveis em março. Se a sua resposta é «precisamos de mais ordem nas tarefas», o mercado de alternativas ao Asana é vasto e em grande parte intercambiável. Se é «temos de gerir projetos, não tarefas», a maior parte desse mercado não lhe diz respeito de todo.

Onde uma lista de tarefas deixa de ser um plano

Uma lista de tarefas contém datas. Um plano contém relações entre as datas. A diferença é invisível enquanto nada muda, e total assim que tudo muda. Quando um fornecedor confirma duas semanas mais tarde do que o previsto, uma lista de tarefas deixa-o alterar esse único prazo; cada tarefa que dependia dele mantém a sua data original e o plano está agora silenciosamente errado. Alguém tem de reparar, pensar nos efeitos em cascata e alterar à mão outras quinze datas.

Os sintomas são reconhecíveis: o estado reconstruído de memória na reunião semanal em vez de lido do plano, um cronograma mantido numa folha de cálculo ao lado da ferramenta de tarefas, ninguém capaz de dizer que atraso ameaça realmente a data, e derrapagens de orçamento descobertas por uma fatura em vez de previstas por uma previsão. Nada disto é falta de disciplina. É uma ferramenta construída para responder a «quem faz o quê» a que se pede que responda a «vamos conseguir, e a que custo».

Três classes de ferramentas por trás da mesma procura

Quase toda a lista de ferramentas como o Asana mistura três classes de software sem o dizer, e é por isso que os leitores saem dela mais confusos do que quando entraram.

• Aplicações de tarefas e de to-do organizam o trabalho pessoal e de pequenas equipas: listas, quadros, lembretes, uma vista partilhada. Não modelam dependências, orçamentos nem capacidade, e não tentam fazê-lo.
• Plataformas de gestão do trabalho são onde se situa o próprio Asana. Acrescentam várias vistas, campos personalizados, automatizações, objetivos e relatórios entre equipas. A sua camada de planeamento é normalmente uma linha temporal: datas arrastáveis, com uma lógica de dependências limitada ou opcional.
• Sistemas de gestão de projetos e portefólios são construídos em torno do projeto como objeto dotado de cronograma, orçamento, riscos, recursos, entregáveis e histórico de aprovações. O centro de gravidade é o plano e a sua execução face a esse plano.

O sistema de gestão de projetos FlexiProject pertence à terceira classe. É o posicionamento honesto: se o seu problema é um quadro de tarefas sobrelotado, é a resposta errada. Torna-se a resposta certa no ponto em que o plano, o dinheiro e as pessoas têm de ser geridos como um único objeto em vez de três folhas de cálculo. Uma comparação capacidade a capacidade no comparativo entre o FlexiProject e o Asana cobre o mesmo terreno para esta ferramenta em particular.

Oito capacidades que separam as aplicações semelhantes ao Asana

Retire o marketing das comparações de ferramentas e as diferenças que contam na prática reduzem-se a oito capacidades. Cada uma está presente como módulo real ou está ausente, e nenhuma quantidade de campos personalizados substitui as que faltam.

O resto do artigo pega nestas linhas uma a uma, porque a tabela diz-lhe o que existe, não porque importa. Em separado explicamos como abordar o planeamento de projetos que o sistema mantém sozinho.

Um cronograma que se recalcula sozinho quando as datas mudam

Numa plataforma de gestão do trabalho, uma linha temporal é uma visualização de datas que é você que mantém. Num sistema de projeto, o cronograma é um modelo: descreve como o trabalho está estruturado e como as partes dependem umas das outras, e o modelo diz-lhe quais são as datas. Esta distinção torna-se concreta na primeira vez que a realidade intervém. Uma tarefa-chave desliza cinco dias; num cronograma baseado num modelo, tudo o que se segue desloca-se automaticamente, o caminho crítico é recalculado e vê de imediato se a data final se moveu ou se a folga absorveu o atraso. O trabalho do gestor de projeto passa a ser decidir o que fazer, não calcular o que significa.

Uma WBS ilimitada em vez de uma lista plana de tarefas

Os projetos de uma mesma organização diferem enormemente em escala. Uma melhoria de processo dura seis semanas com uma dúzia de tarefas; um investimento fabril dura três anos com várias centenas, agrupadas em fases e etapas. Uma ferramenta que limita a profundidade de aninhamento obriga a partir o maior projeto em vários «projetos» artificiais para caber, e a partir daí o relatório está errado, porque nenhum objeto único representa a iniciativa real.

O módulo de cronograma do projeto do FlexiProject não tem qualquer limite de profundidade de aninhamento, pelo que um Quick Win pode ficar plano enquanto um investimento plurianual carrega uma estrutura de decomposição do trabalho completa, ambos na mesma interface e ambos a reportar ao mesmo portefólio. O mesmo cronograma está disponível em três vistas que partilham um único conjunto de dados: uma lista de tarefas para o detalhe, o diagrama de Gantt no FlexiProject para o trabalho sobre dependências e um quadro Kanban para acompanhar o progresso. Isto importa para a adoção, porque o gestor de projeto pode trabalhar na vista estruturada enquanto a equipa permanece no quadro que lhe é familiar, sem que ninguém mantenha uma segunda cópia da verdade.

Dependências, atraso e caminho crítico

Saber traçar uma linha entre duas tarefas não é o mesmo que saber exprimir de que tipo de relação se trata. O FlexiProject suporta os quatro tipos de relação padrão, pelo que pode dizer que o teste começa quando o desenvolvimento termina, que dois fluxos de trabalho começam juntos, que têm de terminar juntos, ou o caso mais raro em que o início de uma tarefa governa o fim de outra. Um atraso fixo cobre os dias que têm simplesmente de decorrer e em que ninguém trabalha: a cura do betão, um prazo de consulta imposto por lei, o prazo de entrega de um fornecedor. Modelá-los como um atraso na relação, e não como uma falsa tarefa, mantém o cronograma honesto, porque o tempo de espera desloca-se com a tarefa que o precede. As relações rígidas impedem que a ligação se quebre por um arrasto distraído, o que protege as sequências em que a ordem é um requisito técnico ou contratual.

Acima desta estrutura está o caminho crítico. Responde à pergunta que todo o comité de acompanhamento acaba por fazer: das seis coisas atrasadas, quais ameaçam realmente a data. Sem este cálculo, cada atraso parece igualmente alarmante e a atenção da direção distribui-se por igual entre problemas de importância muito distinta. O calendário do projeto por baixo gere os dias não úteis e as ausências, pelo que uma tarefa planeada em cinco dias úteis não consome silenciosamente um fim de semana.

Progresso que se consolida para cima e atrasos que vê logo

Na maioria das ferramentas de tarefas, a percentagem de conclusão de uma fase é algo que uma pessoa digita. Esse número é uma estimativa, está desatualizado no instante em que é introduzido, e é o número que acaba no relatório ao comité. O FlexiProject só pergunta o progresso ao nível das tarefas individuais e calcula as etapas, as fases e o projeto inteiro a partir delas, pelo que os valores nas vistas de portefólio e nos relatórios são coerentes por construção, não por disciplina.

As tarefas atrasadas são realçadas a vermelho diretamente no cronograma, pelo que o gestor de projeto vê os pontos que exigem intervenção logo ao abrir o projeto, sem gerar primeiro um relatório. O intervalo entre o surgimento de um problema e o momento em que alguém repara nele é onde se acumula a maior parte do dano ao cronograma, e reduzir esse intervalo de uma semana para um instante muda o que ainda é recuperável.

Uma linha de base: o plano por que realmente lhe podem pedir contas

Pergunte a uma equipa sem linha de base se o projeto está atrasado e obterá uma resposta ponderada, sincera e irrefutável. Não é desonestidade. É que o plano e a realidade foram o mesmo documento todo o tempo: sempre que uma data se movia, o plano movia-se com ela, pelo que em qualquer momento o projeto está exatamente no prazo de um cronograma reescrito uma dúzia de vezes.

Uma linha de base quebra este ciclo. Uma vez acordados o cronograma e o orçamento, são aprovados e congelados como ponto de referência, e a partir daí o sistema assinala o desvio entre aquilo a que se comprometeram e o que acontece. A aprovação passa por um circuito definido no FlexiProject em vez de uma assinatura numa impressão, pelo que fica registo de quem aprovou que versão e quando. O que compra assim é tempo: um projeto com quatro dias de atraso no segundo mês de um cronograma de dezoito meses é uma conversa, enquanto o mesmo projeto descoberto com seis semanas de atraso no décimo sexto mês é uma crise sem opções restantes.

Um orçamento de projeto com previsão até à conclusão

Um campo personalizado chamado «orçamento» num cartão de projeto não é gestão de orçamento; é um número que alguém atualiza de vez em quando e em que, ao segundo mês, já ninguém confia. Gerir o orçamento de um projeto significa seguir os montantes planeados, o gasto efetivo e o custo restante esperado, a um nível de detalhe que mostra de onde vem o desvio.

Custos, receitas e o resultado do projeto

O módulo de orçamento do projeto constrói o orçamento de ambos os lados, custos e receitas, com rubricas agrupadas conforme a organização precisa. Para os projetos que geram receita, o sistema mostra o resultado planeado, o desvio face ao plano e a previsão do resultado financeiro final, não apenas o lado da despesa. Para uma empresa de serviços profissionais ou de engenharia em que cada projeto é um contrato, é este o número que a direção realmente pede, e não se deduz de um total de custos sozinho.

As rubricas de orçamento podem ser ligadas dinamicamente às tarefas do cronograma, pelo que quando a data de uma tarefa muda, a data da rubrica de orçamento correspondente muda com ela e o fluxo de caixa reflete sempre o plano atual. Cada rubrica pode carregar os atributos de que a área financeira precisa, incluindo centro de custo, natureza da despesa, categoria e fornecedor, com as faturas anexadas à respetiva linha. O FlexiProject integra-se ainda com os sistemas de contabilidade e importa as faturas ligadas ao projeto com a data, o montante, o número de documento e o fornecedor, o que elimina a dupla introdução que de outro modo faz os orçamentos de projeto divergirem da contabilidade.

Porque é que «quanto gastámos» é a pergunta errada

O gasto efetivo descreve o passado. Quando mostra um problema, o dinheiro já foi. A pergunta que muda as decisões é quanto se vai ainda gastar antes de o projeto terminar, e respondê-la exige uma previsão mantida ao lado do real.

O FlexiProject mostra três valores em conjunto para cada linha de orçamento: o plano, o montante gasto até agora e a previsão do custo restante, com o desvio resultante. Um gestor de projeto que ao terceiro mês vê que a previsão excede o plano em doze por cento tem opções: renegociar o âmbito, escalar cedo, recorrer a uma reserva. O mesmo gestor a trabalhar apenas com o real fica a sabê-lo ao oitavo mês, quando a única opção restante é explicá-lo. A área financeira pode ainda mandar desenhar relatórios no corte de que precisa, por categoria, fornecedor ou período, sempre com dados atualizados. À parte detalhamos o que é um verdadeiro controlo do orçamento do projeto.

Um registo de riscos que funciona acima de um único projeto

Numa ferramenta de tarefas, um risco torna-se uma tarefa com uma etiqueta, ou um ponto num documento de estado que ninguém relê. Um registo de riscos é outro objeto: cada entrada tem uma avaliação de probabilidade e impacto, um responsável, um plano de resposta e um histórico, e vive ao lado do cronograma em vez de num documento paralelo.

O registo de riscos do FlexiProject permite-lhe configurar as dimensões da matriz de riscos durante a implementação. Parece um ajuste menor e é muitas vezes a razão pela qual um módulo de risco fica por usar: uma organização que trabalha há anos com uma matriz três por três não vai adotar um sistema que fixa cinco por cinco, pelo que o módulo é abandonado em silêncio e a gestão de riscos regressa a um diapositivo. Os riscos recorrentes são geridos através de modelos, pelo que uma equipa que arranca com uma nova implementação não parte de um registo vazio, mas de uma base curada que ajusta a este projeto. Isto transforma a identificação de riscos de um exercício de imaginação numa revisão da experiência acumulada da organização.

Acima do projeto individual, cada portefólio tem o seu próprio separador de riscos que reúne num só lugar os riscos de todos os seus projetos. Isto faz emergir algo de outro modo invisível: três gestores de projeto gerem de forma independente o mesmo risco de fornecedor, dedicam-lhe o triplo do esforço e chegam a três conclusões diferentes. Visto ao nível do portefólio, esse risco recebe um responsável e uma resposta, e os relatórios de riscos permitem a uma equipa que arranca com um novo projeto rever o que realmente ameaçou projetos semelhantes antes. Mostramos igualmente como funciona a gestão de riscos do projeto na prática.

A carga dos recursos antes de se comprometer com uma data

A pergunta mais difícil numa organização orientada por projetos não é «o que temos de fazer», mas «quem o vai fazer e está livre». As aplicações de tarefas mostram a carga como uma contagem de atribuições, o que quase nada diz, porque oito pequenas tarefas e uma tarefa de três semanas parecem-se e consomem porções do mês de uma pessoa totalmente distintas.

O FlexiProject aborda isto como software de gestão de recursos: modela a disponibilidade por pessoa e por dia, tem em conta férias e ausências, e alerta quando a carga planeada excede a capacidade disponível. Isto evita a armadilha conhecida em que um perito aparece ao mesmo tempo nos planos de dez projetos, cada plano razoável isoladamente e a soma impossível. A carga é visível diretamente a partir do diagrama de Gantt: à medida que desloca as tarefas no tempo, observa a carga a mudar, o que torna o planeamento uma simulação que corre antes de aprovar o plano em vez de uma descoberta que faz depois.

Acima do projeto individual, a organização obtém uma vista de todos os recursos de projeto para os meses seguintes, repartida por estrutura organizacional. O PMO e a direção veem quando determinadas equipas têm capacidade livre, o que transforma duas decisões recorrentes de instinto em aritmética: concorrer ou não ao trabalho que está a chegar à mesa, e quando começar a recrutar.

Uma carta de projeto e modelos que carregam o seu padrão

A maioria das organizações que gere projetos a sério tem um padrão. Costuma viver num modelo Word, numa apresentação e na cabeça de duas pessoas experientes, o que significa que é seguido quando essas duas estão envolvidas e improvisado de outro modo. Uma ferramenta que carrega o padrão é uma proposta diferente de uma ferramenta que fica ao lado dele.

O módulo de carta de projeto do FlexiProject é montado a partir de componentes, sem qualquer programação, pelo que o documento reflete a disposição que a organização já afinou ao longo de centenas de projetos, em vez de um modelo fixo de um fornecedor. Pode definir mais do que um padrão de carta: projetos de I&D com campos relevantes para o desenvolvimento, projetos de marketing com diferenciadores de mercado e canais, projetos de investimento com campos de tecnologia e retorno, enquanto um conjunto de campos ao nível da empresa permanece comum a todos. É isto que permite à padronização sobreviver ao contacto com a realidade, porque os departamentos não são forçados a um documento de compromisso que não serve a nenhum.

Uma parte importante da carta preenche-se sozinha: marcos, riscos-chave e outros elementos são extraídos automaticamente do cronograma e do registo de riscos, pelo que a carta permanece coerente com os dados subjacentes. As cartas são versionadas e aprovadas através de circuitos de aprovação, e cada versão aprovada deixa registo de quem a aprovou e quando. A mesma lógica estende-se aos modelos de projeto do FlexiProject, que empacotam a estrutura do cronograma, os riscos típicos e as disposições de documentos por tipo de projeto, pelo que um novo projeto arranca a partir da prática acumulada da organização em vez de um ecrã em branco.

Portefólios e programas: a vista acima de um projeto

Quando uma organização leva trinta, cinquenta ou cem projetos, as perguntas úteis mudam. Ninguém ao nível da direção quer saber o que uma pessoa específica faz à quinta-feira. Querem saber que projetos estão a derrapar, quais consomem mais do que o previsto e se o portefólio ainda reflete a estratégia. Os painéis que agregam contagens de tarefas não respondem a nada disto.

Esta lacuna é preenchida pelo software de portefólio de projetos. O FlexiProject fornece uma vista estratégica dedicada: um roteiro dos projetos com marcos e o seu estado, uma comparação com o plano e o progresso financeiro de cada projeto e do portefólio no seu conjunto. Um projeto pode pertencer a vários portefólios ao mesmo tempo, o que importa mais do que parece, porque um único investimento em TI faz muitas vezes parte, simultaneamente, de um portefólio tecnológico e de um programa de transformação. Os programas acrescentam a camada de cima: grupos de projetos relacionados com dependências a correr entre eles, que é o ponto de rutura da maioria das entregas multiequipa, porque cada plano é coerente por dentro enquanto as passagens são geridas por email. A pontuação de projetos sustenta a decisão que precede tudo isto, e o módulo de revisões de projetos mantém o estado vindo do sistema em vez de uma ronda de insistências. À parte explicamos o que uma alternativa ao Asana para um PMO tem de oferecer.

Licenciamento, línguas e onde residem os seus dados

Três critérios raramente aparecem nas comparações de funcionalidades e decidem regularmente o resultado assim que uma organização ultrapassa o piloto.

O primeiro é o modelo de licenciamento. A maioria dos sistemas cobra uma tarifa comparável por cada utilizador, pelo que uma organização paga um lugar completo por pessoas que abrem a ferramenta para atualizar as suas próprias tarefas e consultar um estado. O FlexiProject oferece três níveis ajustados ao papel real: uma licença completa para gestores de projeto, membros do PMO, patrocinadores e decisores; uma licença standard para os participantes ativos que reportam progresso e colaboram nas tarefas; e uma licença gratuita para quem só precisa de visibilidade sobre o próprio trabalho. A organização decide a mistura, o que mantém o custo de cobrir a equipa alargada proporcional ao valor que essas pessoas retiram.

O segundo é a língua. A interface do FlexiProject está disponível em 28 línguas, incluindo inglês, alemão, francês, espanhol, italiano, neerlandês, polaco, checo, eslovaco, húngaro, romeno, búlgaro, ucraniano, sueco, dinamarquês, norueguês, finlandês, estónio, letão, lituano, esloveno, grego, português, turco, russo, indonésio, japonês e chinês. A documentação de utilizador está disponível em 11 línguas e os vídeos de formação em polaco e inglês. Para um grupo com filiais em vários países, é isto que permite um padrão e um sistema enquanto cada um trabalha na sua própria língua. O terceiro é a implantação: o FlexiProject está disponível on-premises a par da nuvem, o que, para os setores regulados, não é uma preferência mas uma condição para sequer ser considerado.

Como testar aplicações semelhantes ao Asana sem desperdiçar um trimestre

As comparações de funcionalidades têm um mau historial como método de seleção, porque a página de cada fornecedor diz sim a tudo. Um ensaio de duas semanas num projeto real responde mais do que um mês de demonstrações, desde que seja montado para testar aquilo que realmente se diferencia. Ponha na ferramenta um projeto vivo, não um de demonstração: pegue num projeto já em curso, com o seu cronograma, pessoas e orçamento reais, e reconstrua-o. O atrito que encontra durante essa reconstrução é o atrito que encontrará todas as semanas depois, e serve ainda de formação, porque quem aprende o sistema no seu próprio projeto retém mais do que quem faz um exercício com dados inventados.

Depois, corra os quatro testes que separam as classes. Desloque uma tarefa a meio do cronograma uma semana e veja o que se recalcula. Aprove uma linha de base, faça uma alteração e veja se o desvio é visível sem ninguém o calcular. Introduza o orçamento com uma previsão até à conclusão e verifique se o desvio é legível. Afete duas pessoas já ocupadas noutro lado e veja se a ferramenta o avisa. Se uma ferramenta passa estes quatro, o resto é questão de gosto; se falha neles, nenhuma quantidade de campos personalizados fecha a lacuna.

Por fim, seja deliberado sobre o que leva consigo. Uma migração é o único momento em que é barato deixar para trás as categorias que ninguém usa e as convenções que eram contornos para os limites da ferramenta anterior. Leve o trabalho em aberto, a estrutura que quer para o futuro e os projetos históricos com que vale a pena aprender.

Perguntas frequentes

Para que servem as aplicações como o Asana?

As aplicações como o Asana servem para organizar e acompanhar o trabalho de equipa num lugar partilhado: tarefas, responsáveis, datas, comentários e ficheiros. São mais fortes no trabalho colaborativo e recorrente, como marketing, operações e suporte. Quando o trabalho tem um cronograma com dependências, um orçamento e recursos afetos, um sistema de gestão de projetos ajusta-se melhor.

Qual é a diferença entre uma aplicação de tarefas e um software de gestão de projetos?

Uma aplicação de tarefas armazena itens de trabalho e datas. Um software de gestão de projetos modela o projeto: recalcula o cronograma quando as datas mudam, compara a execução com uma linha de base aprovada, segue custos e previsões, mantém um registo de riscos e gere a capacidade dos recursos. O teste prático é se deslocar uma tarefa desloca automaticamente tudo o que dela depende.

O Asana tem uma linha de base de projeto?

O Asana não fornece uma linha de base de projeto aprovada com acompanhamento de desvios. A sua linha temporal reflete o estado atual do plano, pelo que quando as datas mudam, o compromisso original deixa de estar disponível para comparação. Os sistemas de classe PPM, incluindo o FlexiProject, aprovam e congelam uma linha de base e depois assinalam o desvio entre ela e a execução real.

As aplicações semelhantes ao Asana conseguem gerir orçamentos de projeto?

A maioria não consegue, para além de um campo personalizado que contém um número. Gerir o orçamento de um projeto exige montantes planeados, gasto efetivo e uma previsão do custo restante por linha, ligada ao cronograma para que as datas se mantenham coerentes. No FlexiProject o orçamento cobre custos e receitas e mostra plano, real e previsão até à conclusão lado a lado.

Quando é demasiado cedo para deixar o Asana?

Se os seus projetos são curtos, levados com um punhado de pessoas, sem orçamento formal nem compromissos externos de datas, mudar de ferramenta acrescentará processo sem acrescentar controlo. O sinal da mudança é estrutural: dependências que não consegue exprimir, um orçamento mantido numa folha de cálculo à parte e reuniões de estado feitas para reconstruir informação que já deveria estar no sistema.

Quanto tempo leva a tirar um projeto do Asana?

Reconstruir um único projeto em curso num novo sistema leva normalmente algumas horas para a estrutura de cronograma e orçamento, e alguns dias se se definirem modelos e padrões ao mesmo tempo. A implantação à escala de uma organização depende menos dos dados do que das decisões: que padrão, que modelos e quem aprova o quê.

A procura de aplicações como o Asana começa quase sempre como uma questão de ferramenta e revela-se uma questão sobre o que a organização realmente gere. Se a resposta é a colaboração de equipa num trabalho partilhado, o mercado está bem servido e as diferenças entre as principais opções são sobretudo questões de interface e preço. Se a resposta é projetos com compromissos associados, as capacidades relevantes não são as que aparecem nas páginas de comparação: um cronograma que se recalcula sozinho, uma linha de base aprovada que torna o atraso visível enquanto ainda é pequeno, um orçamento com previsão em vez de um total de despesas, um registo de riscos que funciona acima do nível de um projeto, e uma capacidade de recursos que pode verificar antes de prometer uma data. O FlexiProject é construído em torno destas coisas, o que o torna a escolha errada para uma equipa que precisa de um quadro de tarefas mais arrumado, e a certa para uma organização que tem de responder por datas e dinheiro. A forma mais fiável de saber quem é não é uma tabela de funcionalidades, mas duas semanas: pegue num projeto real, reconstrua-o, desloque uma tarefa e veja o que a ferramenta lhe diz.