Ao longo de mais de 30 anos em tecnologia e de mais de mil projetos web, encontrei problemas apresentados como técnicos que, na realidade, tinham outra origem.
“É um problema do software.”
“O sistema não está a funcionar.”
“As pessoas não usam a ferramenta.”
“Precisamos de uma aplicação nova.”
Muitas vezes, a tecnologia estava a funcionar exactamente como tinha sido configurada. O problema era que estava a acelerar uma decisão mal tomada, a automatizar um processo incompleto ou a tornar visível uma falta de organização que já existia.
Esta é uma distinção importante: a tecnologia não corrige automaticamente a ambiguidade, a falta de liderança ou a ausência de processo. Na maioria dos casos, amplifica aquilo que encontra.
Se encontra uma organização clara, pode multiplicar a eficiência. Se encontra confusão, pode multiplicar a confusão.
A investigação sobre tecnologia como amplificador chega à mesma conclusão: ferramentas digitais tendem a reforçar as capacidades e limitações já existentes numa organização. Podes consultar, por exemplo, o trabalho de Kentaro Toyama sobre o efeito amplificador da tecnologia.
Nos projectos, este padrão aparece repetidamente em quatro formas.
1. Falta de dono: quando ninguém responde pelo resultado
Um dos problemas mais frequentes começa com uma pergunta simples:
Quem é responsável por isto?
Não quem participou na reunião. Não quem enviou o último e-mail. Não quem conhece melhor o sistema. Quem tem autoridade e responsabilidade para garantir que o resultado acontece?
Quando ninguém é claramente o dono, todas as pessoas podem estar envolvidas e, ao mesmo tempo, ninguém estar verdadeiramente responsável.
Sinais de alerta
Reconheces este padrão quando:
- as decisões ficam sempre para a próxima reunião;
- todos dão opinião, mas ninguém decide;
- uma tarefa passa por várias pessoas sem prazo definido;
- os problemas são encaminhados, mas nunca resolvidos;
- a equipa procura constantemente “quem devia tratar disto”;
- o projecto continua activo, mas não tem um responsável pelo resultado final.
Em projectos digitais, isto acontece muitas vezes quando o cliente nomeia vários interlocutores, mas nenhum tem autoridade para validar conteúdos, aprovar funcionalidades ou desbloquear prioridades.
Também acontece dentro das empresas. O marketing espera pelo comercial. O comercial espera pelo director. O director espera pelos dados. E o sistema continua a aguardar uma decisão.
A consequência
A falta de dono transforma pequenos atrasos em bloqueios. Uma aprovação que podia demorar uma hora passa a demorar uma semana. Uma alteração simples gera discussões sobre responsabilidade. O custo não está apenas no tempo perdido: está na energia consumida por pessoas que tentam proteger-se de decisões que ninguém assumiu.
A tecnologia torna este problema mais evidente. Um painel pode mostrar todos os indicadores, mas não decide quem deve agir. Uma automação pode enviar alertas, mas não cria responsabilidade. Uma aplicação pode distribuir tarefas, mas não substitui a liderança.
A intervenção prática
Antes de escolher uma ferramenta, define quatro elementos para cada processo importante:
- Dono do resultado: quem responde pelo que deve acontecer?
- Responsável pela execução: quem faz o trabalho?
- Autoridade de decisão: quem pode aprovar ou rejeitar?
- Prazo de decisão: até quando é preciso decidir?
Não compliques. Uma tabela com estas quatro colunas pode evitar semanas de confusão.
Se a resposta for “somos todos responsáveis”, normalmente significa que ninguém é. A responsabilidade pode ser partilhada na execução, mas o resultado precisa de ter um dono identificável.
2. Decisões implícitas: quando cada pessoa sai da reunião com uma versão diferente
Outro padrão recorrente é a decisão que nunca foi realmente registada.
Alguém diz: “Ficou combinado que avançávamos.”
Outra pessoa responde: “Eu percebi que era apenas uma possibilidade.”
Uma terceira já começou a executar uma versão diferente.
A reunião aconteceu. As pessoas estavam presentes. Houve conversa. Mas não houve uma decisão suficientemente clara.
Sinais de alerta
Este problema aparece quando:
- se usam expressões vagas como “em princípio”, “depois vemos” ou “é mais ou menos isto”;
- não existe uma lista de decisões tomadas;
- os requisitos são transmitidos apenas por conversa;
- cada departamento usa palavras diferentes para descrever o mesmo objectivo;
- uma alteração é considerada óbvia por uma pessoa e significativa por outra;
- o projecto depende constantemente da memória de quem esteve numa reunião.
A comunicação digital pode agravar este padrão. Mensagens rápidas em chats, chamadas improvisadas e comentários dispersos criam uma sensação de alinhamento sem deixarem uma referência clara. Estudos sobre ferramentas de colaboração mostram precisamente este risco: mais comunicação não significa necessariamente mais clareza.
A consequência
As decisões implícitas criam retrabalho. Cada pessoa preenche as lacunas com a sua própria interpretação. Quando o resultado não corresponde ao esperado, começa a discussão sobre quem percebeu mal.
O problema raramente é falta de inteligência ou de empenho. É falta de uma versão comum da decisão.
Isto é particularmente perigoso em websites, aplicações e automações. Uma frase como “queremos algo simples” pode significar uma página básica para uma pessoa e uma experiência sofisticada, rápida e integrada para outra.
A intervenção prática
Transforma todas as decisões relevantes em algo verificável. Depois de uma reunião, regista:
- o que foi decidido;
- o que ficou fora do âmbito;
- quem ficou responsável;
- qual é o prazo;
- que condição determina que o trabalho está concluído.
Pede confirmação quando existir ambiguidade. Não assumes que uma expressão conhecida tem o mesmo significado para toda a gente.
Também vale a pena criar um pequeno glossário interno para termos críticos. “Lead”, “cliente”, “proposta enviada”, “projecto concluído” e “urgente” podem ter significados diferentes dentro da mesma empresa.
Documentar uma decisão não é burocracia. É evitar que a decisão seja reinventada três semanas depois.
3. Expectativas desalinhadas: quando prazo, orçamento e resultado significam coisas diferentes
Muitos conflitos de projecto não começam com uma falha técnica. Começam antes, quando duas partes concordam com as mesmas palavras, mas não com a mesma realidade.
“Fica pronto rapidamente.”
“É um projecto simples.”
“Queremos algo profissional.”
“Não pode ultrapassar este orçamento.”
Cada frase parece clara até ser necessário transformá-la em trabalho concreto.
Sinais de alerta
Deves parar e clarificar quando:
- o prazo foi definido sem listar entregáveis;
- o orçamento foi discutido sem definir o âmbito;
- a qualidade é descrita apenas com adjectivos;
- ninguém sabe quais são os critérios de aceitação;
- o resultado esperado depende de factores que não estão sob controlo do projecto;
- o cliente espera estratégia, execução, formação e acompanhamento dentro do mesmo valor.
Um website pode ser tecnicamente entregue no prazo e, ainda assim, ser considerado um fracasso porque não gera contactos. Uma campanha pode gerar tráfego e falhar porque atrai as pessoas erradas. Uma automação pode funcionar e produzir dados inúteis.
A consequência
Quando as expectativas não estão alinhadas, cada pessoa avalia o projecto com uma régua diferente. O fornecedor olha para o que foi entregue. O cliente olha para o impacto no negócio. A equipa olha para o esforço realizado. A direcção olha para o retorno.
Todos podem estar a falar verdade e, mesmo assim, existir um problema.
A tecnologia torna esta diferença mais rápida e mais cara. É possível lançar campanhas, criar funcionalidades e processar dados a grande velocidade. Mas velocidade de execução não resolve uma definição fraca de sucesso.
A intervenção prática
Antes de iniciar, transforma expectativas em critérios concretos:
- Prazo: o que estará disponível nessa data?
- Orçamento: que trabalho está incluído e o que fica de fora?
- Qualidade: que requisitos devem ser cumpridos?
- Resultado: que indicador permitirá avaliar o impacto?
- Dependências: que materiais, acessos ou decisões são necessários?
- Limitações: o que o projecto não promete?
No artigo sobre consultoria de transformação digital, explico por que razão escolher um parceiro não deve resumir-se a comparar propostas e preços. O contexto, o método e a capacidade de acompanhar decisões contam tanto como a tecnologia utilizada.
4. Resistência à mudança: quando a ferramenta é implementada, mas o comportamento não muda
Há projectos em que tudo parece estar pronto.
A plataforma foi instalada. Os acessos foram criados. A formação aconteceu. A documentação foi entregue.
Mas, passado algum tempo, as pessoas continuam a trabalhar como antes.
Guardam informação em folhas de cálculo pessoais. Enviam pedidos por e-mail em vez de usar o sistema. Ignoram os campos obrigatórios. Pedem à mesma pessoa para fazer manualmente o que a ferramenta já automatiza.
É fácil chamar a isto resistência à mudança. Às vezes é. Mas nem sempre.
Sinais de alerta
A resistência pode estar presente quando:
- as pessoas não percebem por que razão a mudança é necessária;
- a nova ferramenta acrescenta trabalho sem retirar tarefas antigas;
- o processo foi desenhado sem ouvir quem o executa;
- os incentivos continuam a premiar o comportamento anterior;
- a formação se limitou a explicar botões;
- a liderança não usa o sistema que exige aos outros;
- existe receio de perder autonomia, controlo ou relevância.
A consequência
A empresa acaba com dois sistemas em paralelo: o oficial e o real.
O sistema oficial tem regras, campos e fluxos. O sistema real vive em mensagens, ficheiros locais e atalhos pessoais. Os dados deixam de ser fiáveis porque ninguém sabe qual das versões representa a verdade.
Comprar uma ferramenta mais avançada não resolve o problema. Pode até piorá-lo, porque aumenta a complexidade e o custo da rejeição.
A intervenção prática
Não tentes mudar tudo de uma vez. Escolhe um processo concreto, explica o motivo da alteração e mede uma melhoria visível.
Faz estas perguntas:
- Que problema específico estamos a tentar resolver?
- O que fica mais fácil para quem executa o trabalho?
- Que comportamento novo é esperado?
- Como será acompanhado?
- O que deixa de ser necessário fazer?
- Quem dá apoio quando surgir uma excepção?
A adopção precisa de liderança contínua. Uma formação isolada não muda hábitos. O comportamento muda quando o novo processo é compreensível, útil, acompanhado e coerente com aquilo que a liderança pratica.
Podes encontrar exemplos de processos onde a automação pode ajudar no artigo sobre automação com IA para negócios, mas a regra mantém-se: primeiro clarifica o processo; depois escolhe o que faz sentido automatizar.
A tecnologia não substitui organização
Depois de tantos projectos, continuo a acreditar profundamente na tecnologia. Um bom website, uma aplicação adequada, uma automação bem desenhada ou uma estratégia digital consistente podem mudar os resultados de um negócio.
Mas não fazem milagres.
A tecnologia amplifica a organização que já existe:
- se existe um dono claro, acelera a execução;
- se as decisões estão documentadas, reduz a dúvida;
- se as expectativas estão alinhadas, melhora a entrega;
- se existe abertura à mudança, aumenta a capacidade da empresa.
No sentido contrário, também amplifica:
- a falta de responsabilidade;
- a comunicação ambígua;
- as promessas mal definidas;
- os hábitos que ninguém quer questionar.
Por isso, antes de perguntares qual é a melhor ferramenta, pergunta primeiro:
Quem decide? O que ficou realmente combinado? Como vamos medir o sucesso? E que comportamento terá de mudar?
Estas perguntas parecem menos tecnológicas. São precisamente as que mais evitam que um projecto tecnológico falhe.