Ligados, mas Desligados: As Funcionalidades de Gestão de Projetos que as Equipas Deixam de Utilizar
Registo de Tempo: Muitas equipas abandonam as funcionalidades de registo de tempo devido à sua fraca adequação às necessidades reais de acompanhamento do progresso dos projetos.
Colunas Personalizadas: Um número excessivo de colunas personalizadas pode complicar os fluxos de trabalho e reduzir a eficiência e a clareza gerais da equipa.
Dependências entre Tarefas: As dependências entre tarefas falham frequentemente na prática devido aos desafios de manutenção e às perturbações do mundo real.
Automatização Excessiva: Uma automatização complexa pode confundir as equipas, levando à desconfiança e ao afastamento dos fluxos de trabalho previstos.
A Simplicidade Vence: Regressar a métodos simples e eficazes conduz frequentemente a melhores resultados na gestão de projetos do que utilizar funcionalidades complexas.
Ferramentas de gestão de projetos estão repletas de funcionalidades concebidas para trazer ordem a trabalhos complexos. Mas mais funcionalidades nem sempre significam melhores resultados. Em equipas de todas as dimensões, o padrão repete-se: uma funcionalidade promissora é ativada, funciona durante algumas semanas e morre silenciosamente. O que resta é um sistema mais difícil de utilizar do que antes e uma equipa que encontrou as suas próprias soluções alternativas.
Perguntámos a vários profissionais que funcionalidades encontraram no terreno que pareciam úteis na configuração, mas falharam na prática. Eis o bom, o mau e o péssimo.
A promessa do controlo de tempo (e porque fracassou)
O controlo de tempo nativo é uma das funcionalidades mais frequentemente ativadas — e abandonadas — em ferramentas como o Jira. Aaron Whittaker, VP de Geração de Procura da Thrive Agency, ativou o registo de trabalho integrado do Jira exatamente pelas razões que levam a maioria das equipas a fazê-lo. "Ativámo-lo porque parecia uma forma prática de compreender como o esforço estava a ser distribuído entre o trabalho de meios pagos, SEO e conteúdos", afirma. "O objetivo era obter relatórios mais claros e um melhor planeamento dos prazos das campanhas."
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Nunca chegou a consolidar-se. Whittaker aponta para uma incompatibilidade fundamental entre aquilo que a funcionalidade mede e aquilo que as equipas realmente precisam de saber. "A funcionalidade regista horas, não progresso", explica. "Registar cinco ou seis horas na otimização de anúncios ou em atualizações de páginas de destino não indica se o desempenho melhorou ou se o trabalho está perto de ser concluído."
A necessidade de introdução manual piorou a situação. Depois de utilizar a funcionalidade durante cerca de um mês em mais de 170 itens de trabalho, apenas cerca de 55 tinham registos utilizáveis — e estes não eram consistentes. "Registar o tempo significava entrar em várias tarefas ao longo do dia, o que interrompia constantemente a concentração", afirma Whittaker. "Ao fim de algum tempo, parecia simplesmente algo que tínhamos de fazer, não algo que ajudasse realmente."
Registar o tempo significava entrar em várias tarefas ao longo do dia, o que interrompia constantemente a concentração. Ao fim de algum tempo, parecia simplesmente algo que tínhamos de fazer, não algo que ajudasse realmente.
A equipa abandonou-a e voltou a um simples fluxo de trabalho baseado num quadro. "O controlo de tempo parecia útil durante a configuração, mas nos fluxos de trabalho reais duplicava a visibilidade que já tínhamos e acrescentava atrito sem melhorar a entrega."
Colunas de fluxo de trabalho personalizadas: quando a flexibilidade se torna uma desvantagem
As colunas personalizadas parecem uma extensão natural de uma boa abordagem aos processos. Scott Davis, Fundador e CEO da Outreach.io, aprendeu da pior forma que esta funcionalidade pode rapidamente fugir ao controlo. "Ativámos a opção 'adicionar colunas personalizadas' nos quadros Scrum do Jira há alguns anos, para garantir transparência no nosso fluxo de trabalho", afirma. "Ativámos a funcionalidade em menos de um minuto. Passámos semanas a transformá-la numa sobrecarga oculta."
Ativámos a funcionalidade em menos de um minuto. Passámos semanas a transformá-la numa sobrecarga oculta
O que começou como uma única coluna "A verificar" entre Em curso e Concluído multiplicou-se rapidamente. "Antes de darmos por isso, havia uma coluna de revisão para cada equipa", afirma Davis, acrescentando que a equipa de Produto adicionou uma coluna para aprovação das partes interessadas e a equipa de QA acrescentou outra para verificações adicionais. "Cada quadro Scrum era diferente dos restantes e não era fácil de navegar. As pessoas tinham de verificar as configurações do quadro só para saber como mover aquele item."
O custo tornou-se visível nos dados. "O tempo de ciclo da nossa equipa durante os sprints de elevado volume continuou a aumentar, passando de 8 dias para 10,75 dias em média, sobretudo porque não era claro o significado de cada campo de estado personalizado adicional", explica Davis. "As métricas do nosso feedback de retrospetivas estavam cheias de 'tempo desperdiçado a discutir nomes de estados'."
O seu conselho para qualquer equipa que esteja a considerar personalizar colunas é o seguinte: "Tratem cada coluna adicionada como dívida técnica. Sem uma boa disciplina de funções e uma razão válida para se desviarem das predefinições, é mais difícil escalar o trabalho do que modificar o fluxo de trabalho predefinido. A maioria das equipas acabará por abandonar silenciosamente essas colunas adicionais após alguns sprints."
Dependências de tarefas: impecáveis na teoria, problemáticas na prática
As dependências de tarefas são uma das funcionalidades mais apelativas de qualquer ferramenta de gestão de projetos. A lógica é sólida: associar tarefas para que os atrasos sejam automaticamente detetados e acionem as respostas adequadas. Na prática, a funcionalidade tende a desmoronar sob o peso da variabilidade do mundo real.
Dmitrii Malashkin, fundador e diretor executivo da Born to Move, implementou dependências e automatizações avançadas de conclusão de tarefas no Asana — e mais tarde no monday.com — para manter os cronogramas dos projetos atualizados e sob controlo. "A realidade, porém, é que os membros da nossa equipa nunca as utilizaram realmente para além da primeira semana após a implementação", afirma. O motivo era simples: "Manter as dependências e as automatizações é um trabalho completo por si só que ninguém é suposto fazer, nem quer realmente fazer, sobretudo quando não é obrigatório."
Manter as dependências e as automatizações é um trabalho completo por si só que ninguém é suposto fazer, nem quer realmente fazer, sobretudo quando não é obrigatório.
Quando surgiram imprevistos do mundo real — uma licença em falta, uma alteração de horário de última hora, um conflito de disponibilidade do cliente — a cadeia quebrou-se. "Isso faz com que um único ponto de falha interrompa toda a cadeia de dependências", explica Malashkin. "O fluxo de trabalho acaba por enviar às pessoas uma enxurrada de pedidos genéricos de atualização de estado, o que depois leva toda a gente a silenciá-los." O resultado foi fadiga de notificações generalizada.
A sua equipa acabou por abandonar completamente a funcionalidade. "Os nossos gestores de projeto e responsáveis pelas equipas acabaram por voltar a utilizar listas de tarefas simples e não hierárquicas, além de conversas de grupo, como principal modus operandi para coordenar esforços e realizar mais trabalho."
Eric Turney, presidente da The Monterey Company, observou o mesmo padrão. "A funcionalidade que vi fracassar assim que entrou em contacto com fluxos de trabalho reais foi a das dependências de tarefas numa ferramenta de gestão de projetos", afirma. "Nunca vingou, porque as prioridades mudavam com demasiada frequência, a manutenção era incómoda e o sistema ficava desatualizado mais depressa do que qualquer pessoa queria mantê-lo." A sua equipa voltou a adotar uma atribuição de responsabilidades mais simples, datas-limite claras e comunicação direta. "A funcionalidade parecia inteligente na fase de configuração, mas, na vida real, acrescentava trabalho administrativo sem nos devolver controlo suficiente para o justificar."
[As dependências de tarefas] nunca vingaram, porque as prioridades mudavam com demasiada frequência, a manutenção era incómoda e o sistema ficava desatualizado mais depressa do que qualquer pessoa queria mantê-lo.
Automatização excessiva: quando o sistema trabalha contra a equipa
A automatização é uma das maiores vantagens comerciais das plataformas modernas de gestão de projetos — e uma das coisas mais fáceis de levar longe demais. Tom Jauncey, diretor-geral da Global Sound Group, descreve uma armadilha familiar: "Uma coisa que parece bem no papel, mas que não funciona realmente, é quando tornamos as ferramentas como o monday.com demasiado automáticas. Pode tornar-se demasiado complicado para a equipa acompanhar."
Uma coisa que parece bem no papel, mas que não funciona realmente, é quando tornamos as ferramentas como o monday.com demasiado automáticas. Pode tornar-se demasiado complicado para a equipa acompanhar.
Quando a automatização se torna demasiado complexa, as equipas deixam de confiar nela. "O que acontece é que as pessoas começam a ignorar o sistema ou a fazer as coisas à sua maneira, porque parece demasiado difícil de compreender ou porque sentem que as está a impedir de avançar", afirma Jauncey. O fluxo de trabalho planeado e o fluxo de trabalho real divergem. "A forma como planeamos o trabalho parece ótima quando o estamos a planear. Na realidade, não corresponde à forma como a equipa trabalha no dia a dia."
A lição a que a sua equipa chegou foi simples: "A melhor forma de fazer as coisas é a forma como as pessoas realmente as utilizam, não a forma que tem mais funcionalidades."
Campos de percentagem de conclusão e a ilusão de progresso
Algumas funcionalidades não falham por serem demasiado complexas — falham por serem demasiado redutoras. Nikita Patil Brennan, Gestora de Projetos Sénior, aponta os campos de percentagem de conclusão como um exemplo paradigmático. "Uma funcionalidade de gestão de projetos que aparece no MS Project/Asana é a percentagem de conclusão das tarefas", afirma. "Não conta toda a história — 71% pode refletir tarefas quase concluídas, tarefas em risco, tarefas bloqueadas, etc." Um único número elimina o contexto de que as equipas precisam para agir. O progresso não é o mesmo que a saúde do projeto, e uma métrica que não consegue distinguir entre os dois não fornece informação útil a ninguém.
[A percentagem de conclusão das tarefas] não conta toda a história — 71% pode refletir tarefas quase concluídas, tarefas em risco, tarefas bloqueadas, etc.\u0022
More Articles
- As ferramentas de gestão de projetos que os gestores de projetos tiveram de deixar de utilizar
- A única ferramenta de gestão de projetos de que nunca abdicaria
- O conjunto de ferramentas tecnológicas que 6 especialistas em gestão de projetos usariam se tivessem de começar do zero
- 14 Prós & Contras do Software de Gestão de Projetos para os Gestores de Projetos de Hoje’s
Funcionalidades de IA que prometeram demasiado e entregaram pouco
À medida que as funcionalidades de IA foram implementadas nas plataformas de gestão de projetos, a diferença entre o desempenho nas demonstrações e a utilidade no mundo real tornou-se uma fonte recorrente de frustração. Megan Cotterman, Gestora de Projetos a Tempo Parcial e Consultora de Operações, passou por esta situação em primeira mão. "Tive essa experiência quando o Asana lançou inicialmente a sua funcionalidade de IA", afirma. "Fazia perguntas sobre determinados projetos em determinados contextos e tinha muita dificuldade em encontrar aquilo que procurava."
Fazia perguntas [à IA do Asana] sobre determinados projetos em determinados contextos e tinha muita dificuldade em encontrar aquilo que procurava.
O problema não é exclusivo do Asana — reflete um desafio mais amplo das funcionalidades de IA concebidas para casos de utilização gerais, mas que ainda não foram treinadas tendo em conta a especificidade e as nuances da forma como os dados reais dos projetos são estruturados e pesquisados.
Regressar ao essencial — o caso da simplicidade
Em todas as categorias de funcionalidades, as equipas que recuperaram o rumo fizeram-no através da simplificação. James Dyble capta o sentimento a que muitos profissionais acabam por chegar. "Costumava defender acerrimamente os gestores de tarefas digitais, convencido de que tudo devia estar numa aplicação", afirma. "Depois, dei por mim a voltar repetidamente à caneta e ao papel."
Costumava defender acerrimamente os gestores de tarefas digitais, convencido de que tudo devia estar numa aplicação. Depois, dei por mim a voltar repetidamente à caneta e ao papel.
A solução não foi abandonar completamente as ferramentas digitais, mas ser mais intencional quanto à sua utilização. "Agora optei por uma abordagem híbrida: mantenho os meus principais projetos e listas numa ferramenta digital, mas giro as minhas prioridades diárias num simples papel autocolante. Há algo de satisfatório no ato físico de assinalar as tarefas à medida que as vou concluindo."
O sistema de gestão de projetos mais eficaz não é aquele que tem mais funcionalidades ativadas. É aquele que a equipa irá realmente utilizar.
Quer obter mais informações como estas? Crie uma conta DPM gratuita para ouvir mais especialistas como estes.
