Porque Falham os Arranques de Projeto para Quem Entra Mais Tarde
O Mito do Arranque: Os arranques de projeto criam alinhamento no início, mas as coisas mudarão inevitavelmente.
A Responsabilidade é Importante: Quando as pessoas que entram a meio do projeto não assumem responsabilidades, o ritmo, a motivação e o impacto do projeto serão afetados.
O Desafio da Documentação: A documentação tradicional falha em projetos acelerados; formatos leves e adaptáveis são essenciais.
IA e Neurodiversidade: As ferramentas de IA podem ajudar na integração, fornecendo informações acessíveis sobre o projeto, mas exigem dados exatos.
Uma Cultura de Pertença: Promover um sentimento de pertença é crucial para uma integração eficiente da equipa e para o sucesso do projeto.
Porque as reuniões de arranque são excelentes… mas têm falhas
Adoro uma excelente reunião de arranque de projeto. É uma oportunidade para criar entusiasmo, ganhar impulso e promover o alinhamento com todas as pessoas certas na sala.
Exceto que... as reuniões de arranque de projetos são um mito completo.
Pelo menos, essa versão delas é.
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
A versão em que reunimos todas as partes interessadas conhecidas, concordamos numa Estrela Polar, gravamos a nossa abordagem na pedra e depois avançamos juntos, partindo do princípio de que a energia cinética que criámos nesse dia irá, por si só, conduzir o projeto do início ao fim.
A realidade é que a mudança é inevitável e a abordagem da maioria das equipas às reuniões de arranque de projetos está, na verdade, errada.
E isso vai começar a ser muito importante na economia de trabalhadores fracionários impulsionada pela IA em que estamos a entrar.
Porque uma boa reunião de arranque não garante um bom projeto
Costumava pensar que a minha capacidade de liderar excelentes reuniões de arranque de projetos era a minha vantagem injusta enquanto PM. Quando dava início aos meus projetos, as equipas começavam com clareza e impulso, em vez de confusão e ainda mais perguntas sem resposta.
Na verdade, as pessoas vinham ter comigo depois de uma reunião de arranque e pediam-me emprestada a minha agenda ou apresentação para as poderem usar nos seus projetos. Era um motivo de orgulho para mim.
Mas depois aconteceu algo que mudou completamente a forma como penso nas reuniões de arranque.
Num dos meus projetos, membros essenciais da minha equipa foram retirados e alocados a outros projetos — tudo sem tempo para uma transferência adequada de conhecimento. As pessoas talentosas que entraram também eram muito competentes, mas sentiam que estavam a começar em desvantagem, a viver à sombra do que já tinha acontecido. Qualificavam todas as conversas com frases como "mas eu não estava cá quando o projeto começou" ou "ainda estou a pôr-me a par, não deixem que as minhas ideias desviem os vossos planos".
Para os novos membros da equipa, não era por não terem a informação, a autoridade ou sequer as ideias. Era por não sentirem que tinham responsabilidade pelo projeto.
E, sem esse sentido de responsabilidade, perderam o ímpeto. A missão não era deles. Sentiam-se como professores substitutos obrigados a ficar com o problema nas mãos — vítimas das circunstâncias, com pouca influência ou controlo.
Infelizmente, ainda não me tinha apercebido disso.
O problema da transferência de conhecimento
Na altura, a solução parecia simples: bastava pôr as pessoas novas a par. Transferir o conhecimento para os seus cérebros. Certo?
Afinal, há sessões informativas, declarações de âmbito e documentos de requisitos com fartura — sem mencionar a apresentação de arranque e os resultados dos exercícios de definição da visão.
Mas mesmo quando todos os documentos do projeto estão organizados e em ordem, a experiência de um novo membro da equipa ao tentar compreender uma montanha de informação pouco estruturada pode parecer contabilidade forense com uma arma apontada à cabeça.
Claro que os novos membros da equipa podem fazer perguntas, mas não sabem o que não sabem. E, na maior parte das vezes, ainda não se sentem à vontade para fazer as perguntas “parvas”, com receio de receberem a temida resposta: “isso estava nos documentos, não viste?”
Isto criou um ciclo em que os recém-chegados continuavam perdidos durante mais tempo — o que apenas tornava o projeto mais difícil de orientar.
O problema da manutenção
E, para além disso, sempre que integrava um novo membro na minha equipa do projeto, apercebia-me de que, no meio dos meus maravilhosos documentos, pequenos detalhes — bolas, por vezes detalhes importantes — estavam desfasados do estado atual do projeto.
Desde a reunião de arranque, tinham sido tomadas centenas de milhares de microdecisões. Não as grandes decisões que colocamos num registo de decisões — mas as pequenas, que escapam às atualizações da documentação.
Dava por mim a explicar discrepâncias, a esclarecer pequenas nuances e a transmitir conversas informais entre membros da equipa que nunca nos ocorreu registar.
O problema da velocidade
Poderia ter atenuado tudo isto utilizando um “sistema de acompanhamento”, em que um novo membro seria emparelhado com um colega do projeto? Acreditem, tentei. Mas também não resultou, porque o projeto não podia permitir-se ter um membro da equipa a prestar apoio a tempo parcial.
Já estávamos a trabalhar a um ritmo máximo e não podíamos permitir-nos abrandar. Os prazos aproximavam-se, a pressão aumentava, a visibilidade crescia e a expectativa era que a equipa trabalhasse mais depressa à medida que entravam mais pessoas, não mais devagar.
Por isso, em vez de abrandar o ritmo, continuei com o status quo: a versão em que os recém-chegados a meio do projeto ficam presos a saltar para um carro em movimento e a meter a mão no fogo.
O problema do sentimento de pertença
Mas, enquanto continuava a atirar freneticamente documentos e convites para reuniões às pessoas que iam sendo adicionadas ao projeto — e enquanto a equipa percorria mecanicamente as tarefas da lista de pendências — algo se tornou muito claro: não se tratava de informação. Tratava-se de pertença. E esse é um estado emocional que não pode ser alcançado apenas através da documentação.
Não conseguia fazer com que os novos membros da equipa sentissem que pertenciam ao grupo apenas por lhes transmitir confiança ou por falar mais com eles. Nenhum sistema de acompanhamento iria resolver isto. Nenhuma reunião de “pergunte-me o que quiser” com uma agenda definida iria suavizar a situação. Eram necessários espaços seguros e alternativos.
As pessoas encontram um sentimento de pertença de formas diferentes em contextos diferentes: algumas querem tempo tranquilo com a documentação antes de falar com a equipa; algumas querem um colega de acompanhamento; algumas querem um espaço seguro para fazer as perguntas “parvas”; e algumas só querem compreender o “porquê” por detrás da missão e o seu papel nela.
Era nisso que deveria ter investido o meu tempo e energia: na construção de uma estrutura que permitisse aos membros da equipa encontrar o seu sentimento de pertença nos seus próprios termos.
Em última análise, estava a investir demasiado na cerimónia de lançamento, mas depois deixava os membros que entravam a meio do projeto entregues à sua sorte.
Este ciclo de integração inadequada não frustra apenas as pessoas — põe em causa projetos inteiros. Quando os recém-chegados não conseguem ficar a par rapidamente, as decisões tornam-se mais lentas, os erros multiplicam-se e o moral da equipa sofre.
E quando a mudança é inevitável — quando os membros da equipa entram e saem ao longo do ciclo de vida de um projeto — esta abordagem torna-se insustentável.
Para os novos membros da equipa, não era por não terem a informação, a autoridade ou sequer as ideias. Era por não sentirem que tinham responsabilidade sobre o projeto.
Uma Forma Diferente de Pensar nos Lançamentos: Integração Contínua
Então qual é a resposta? Se estamos a investir demasiado nos lançamentos e demasiado pouco na gestão da mudança e na integração a meio do projeto, como podemos corrigir isso?
Tinha as minhas hipóteses, mas também tive um momento de revelação graças a alguém que respeito muito, que disse:
"Estou sempre a reformular o ponto central em praticamente todas as reuniões, porque a 'estrela polar' está sempre a mudar. Faz-me lembrar a forma como praticamos Kung Fu… Há um ponto central cujo controlo procuramos manter e, fora dele, tudo é contexto para regressarmos a essa verdade. É uma conversa, com ambos os lados a 'fazer perguntas' e a receber respostas em tempo real, usando todos os sentidos."
Por outras palavras, em vez de dependermos do grande entusiasmo de um lançamento, podemos usar cada interação para reforçar a essência do que é importante no projeto. Isso fica incorporado no ato de colaborar, em vez de ser uma grande festa que facilmente nos faz sentir que perdemos algo se não estivemos presentes.
Por isso, eis o que tenho tentado fazer em todos os projetos desde então:
1. Uma Política de Documentação Leve e Fácil de Atualizar
Tenho deixado de lado as minhas apresentações bonitas de lançamento e os artefactos de projeto muito aperfeiçoados (resumos, relatórios de estado, agendas de reuniões, registos RAID), e, em vez disso, estou a dar prioridade a ter tudo num formato fácil de atualizar e fácil de ler para colegas humanos ou de IA.
Depois, trabalho com as equipas do projeto para atribuir responsáveis pelas atualizações dos documentos — tal como faríamos com os responsáveis pelos riscos. Isso distribui a carga e dá aos membros da equipa autonomia para promoverem uma documentação rigorosa.
Por exemplo, temos documentos simples e sucintos no Notion ou no Slite para as funções e responsabilidades da equipa, o resumo do projeto e os nossos planos de comunicação do projeto. Nada fica fechado em folhas de cálculo ou PDFs.
2. A Integração Contínua como uma Verdade Aceite
Juntamente com a documentação, tenho gerido as expectativas da equipa desde o início, explicando que as equipas, os objetivos e os restantes elementos do projeto podem mudar a qualquer momento, e que teremos de nos mobilizar.
Por outras palavras, em vez de esperar e rezar para que as equipas e os objetivos não mudem, parta do princípio de que vão mudar.
Isso significa manter o mínimo possível fechado na cabeça das pessoas ou relegado para um momento específico. As reuniões têm transcrições, as notas dos oradores estão disponíveis por escrito, a maioria das conversas do projeto decorre em canais públicos e as decisões são registadas diligentemente.
Isto ajuda a garantir que as pessoas que perderam o primeiro dia do projeto continuam a ter acesso à informação de que precisam. E também nos ajuda a mudar de direção como um bando de cotovias se algum dos objetivos ou circunstâncias do projeto mudar.
3. A IA como Fonte de Verdade para Todos os Neurotipos
Além disso, eu e as minhas equipas estamos a configurar chatbots de IA ou bases de conhecimento de projetos consultáveis o mais cedo possível no projeto.
Em muitos casos, não é tão sofisticado como poderíamos imaginar quando se trata de IA, mas faz algo realmente importante por nós: cria uma forma relativamente privada, segura e menos politizada de os membros da equipa interagirem com a informação do projeto — nos seus próprios termos, da forma como gostam de aprender.
Estes chatbots são alimentados com dados estruturados e não estruturados do projeto desde o início — briefings, SOWs, relatórios de estado, atas de reuniões e algumas conversas da equipa. E porque a documentação é suficientemente simples para que os membros humanos da equipa a mantenham atualizada, é relativamente fácil para uma IA acompanhar o que mudou ao longo do projeto — decisões que foram tomadas, orçamento que foi acrescentado, problemas que surgiram, riscos que se concretizaram, situações que foram escaladas, etc.
Depois, qualquer membro da equipa poderia consultar esse chatbot a qualquer momento, num contexto em que não teria de se preocupar em parecer ignorante nem de marcar uma reunião com uma figura de autoridade que já tem pouco tempo disponível.
Por exemplo, um membro da equipa pode fazer perguntas como:
- “De que forma a minha tarefa contribui para o objetivo geral do projeto?”
- “Quem está a depender de mim para concluir o meu resultado dentro do prazo?”
- “Onde devo guardar os meus resultados finais e qual é a nossa convenção de nomenclatura de ficheiros?”
Estas podem ser perguntas para as quais já sabem a resposta, mas talvez queiram obter confirmação quando estão a alternar entre projetos e outras tarefas.
Em última análise, os chatbots de IA simplificam o processo de acesso à informação, aumentando a eficiência ao eliminar a necessidade de formação extensa ou de consultar várias fontes, e melhoram a acessibilidade através de uma interface fácil de utilizar, que pode ser acedida a partir de qualquer dispositivo com ligação à Internet, 24 horas por dia, 7 dias por semana.
Mas há um problema: sabe-se que a IA pode estar errada.
E, se estiver errada, isso pode desviar um projeto muito rapidamente. A consequência geral seria acrescentar uma etapa: tentar perguntar ao chatbot, analisar cuidadosamente a resposta porque pode estar errada e depois usar a sua intuição para decidir se deve seguir a resposta recebida sem perguntar a mais ninguém, ou encontrar alguém a quem perguntar — por outras palavras, quando não confiamos na IA, voltamos ao ponto de partida.
Por isso, os dados têm de estar suficientemente limpos para não serem contraditórios. E depois, as pessoas da equipa precisam de confiar efetivamente na sua exatidão (partindo do princípio de que não lhe fornecemos informação incorreta).
Para ajudar a garantir isso, a nossa prioridade é assegurar a maior exatidão possível, com membros-chave da equipa a atuar como promotores e árbitros da qualidade, utilizando alguns casos de teste e verificações pontuais que realizamos regularmente.
4. Reforço Ritualizado dos Objetivos
E depois, para ligar tudo, tenho tentado retirar alguns dos meus elementos favoritos do lançamento de projeto, tragicamente “momentâneo”, e integrá-los no dia a dia. Coisas como reiterar e questionar constantemente a visão do produto ou o BHAG, para que a missão seja suficientemente compreendida e possa ser analisada, garantindo que continuamos a construir aquilo que devemos.
Por exemplo, tento recordar às pessoas os resultados pretendidos para o projeto no início de cada reunião da equipa. Algo como: "como lembrete, este projeto vai ajudar os utilizadores de transportes públicos com diferentes capacidades a chegar ao seu destino de forma mais segura e com menos frustração."
E, se essa Estrela Polar tiver mudado, tento reafirmá-lo também em todas as reuniões ou atualizações de estado: "Como lembrete, isto começou como uma iniciativa para utilizadores de transportes públicos com deficiência, mas agora é uma oportunidade para melhorar a experiência de todos os clientes em várias redes de transportes públicos."
A outra coisa que faço é utilizar o meu papel de generalista para colocar perguntas que orientem as decisões para o nosso objetivo. Por exemplo, se a equipa estivesse a tentar decidir entre duas abordagens, perguntaria algo como "qual delas nos ajudará a eliminar mais obstáculos da experiência do cliente?"
Em relação a coisas como os valores da equipa e as formas de trabalhar, opto por terminar as reuniões com esse lembrete: "Não se esqueçam de manter as comunicações importantes no canal partilhado, caso possam ajudar outras pessoas a desempenhar o seu trabalho."
Isto não só faz com que as pessoas que entram a meio do projeto sintam menos que perderam algo no início, como também ajuda a reforçar continuamente a missão junto de todas as partes interessadas.
5. Uma Cultura de Pertença
Mas, acima de tudo, estou a tentar mudar a minha mentalidade de “transferência de conhecimento” para “transferência de responsabilidade” ao dar prioridade a formas de ajudar os novos membros da equipa ou as partes interessadas a sentirem que “pertencem” ao projeto e que podem contribuir plenamente para ele.
Na minha opinião, não existe uma forma única e infalível de fazer isto, mas acredito firmemente que a resposta não consiste em despejar mais informação sobre as pessoas. Nós, seres humanos, precisamos de usar a nossa humanidade para abordar as coisas que são inequivocamente humanas — emoções, ego, comunidade e propósito.
Quando as pessoas não sentem que o projeto também lhes pertence, é menos provável que se manifestem quando algo parece errado ou que questionem uma decisão que possa desviar o projeto do rumo certo.
Porque é que isto é agora ainda mais importante
Hoje, vejo o problema da integração a meio do projeto tornar-se cada vez maior. Os membros da minha comunidade estão a gerir projetos que são uma porta giratória de especialistas a tempo parcial, freelancers e até FTEs que são transferidos fluidamente entre projetos para se manterem ocupados.
Ao mesmo tempo, as ferramentas de IA estão a criar expectativas fluidas entre as partes interessadas nos projetos: espera-se que os projetos avancem mais depressa, lidem melhor com a mudança e proporcionem mais valor, tirando partido de informações obtidas a partir de dados, da automatização e da tomada de decisões autónoma.
Por outras palavras, as equipas estão mais voláteis e o ritmo está a acelerar. O que significa que a lacuna de pertença aumenta quando tudo se move mais depressa e muda com maior frequência.
Eis o verdadeiro risco: não queremos simplesmente construir a coisa errada mais depressa.
Quando as pessoas não sentem que o projeto também lhes pertence, é menos provável que se manifestem quando algo parece errado ou que questionem uma decisão que possa desviar o projeto do rumo certo.
É por isso que a integração contínua já não é opcional. Não é algo desejável, nem uma competência comportamental. É uma necessidade empresarial. Se queremos equipas capazes de se adaptar e proporcionar valor real neste panorama de projetos mais rápido e fragmentado, precisamos de pessoas que se sintam investidas na visão, e não apenas informadas sobre as tarefas.
Então, as reuniões de arranque estão ultrapassadas?
As reuniões de arranque de projetos não estão, de forma alguma, ultrapassadas. Não para mim, nem para muitas equipas de projeto.
Pessoalmente, adoro-as. Acho que as reuniões de arranque de projetos são encontros que podem criar laços entre as pessoas e proporcionar espaços de diálogo num momento crucial do ciclo de vida de um projeto. Acho que são muito humanas. Por isso, sim, continuo a realizar reuniões de arranque, e terão de me arrancar esse hábito das mãos frias e mortas.
O que faço de forma diferente, no entanto, é não concentrar todas as minhas esperanças e sonhos nas reuniões de arranque. Não invisto tanta energia em torná-las perfeitas, brilhantes e performativas. Não ambiciono transformá-las na cerimónia definitiva que faz com que as pessoas que não estiveram presentes desde o início se sintam cidadãos de segunda classe. E definitivamente não tento transformá-las em algo que nos prenda à expectativa de um único caminho imutável.
Porque os projetos não são uma linha reta. São como um papagaio ao vento, constantemente desviado e que tem de ser conduzido ativamente, aconteça o que acontecer. A mudança é inevitável. Por isso, é para nos prepararmos para ela que devemos investir a nossa energia.
O que pensa?
Mas também gostava de ouvir a sua opinião: as reuniões de arranque são tão problemáticas como as fiz parecer? Como está a pensar na integração nos seus projetos, especialmente quando os membros da equipa entram a meio do percurso?
