Lições aprendidas na gestão da mudança

[00:00:00] Excelente. Muito obrigado a todos por se juntarem hoje. Vamos falar sobre gestão da mudança. Este é um tema que surgiu muitas vezes na nossa conversa ao longo do último período. Por isso, achei que já era altura de reunir algumas pessoas e falar sobre algumas das questões que estavam a acontecer.

O objetivo é criar um momento para partilhar e ajudar a desenvolver algum do conhecimento coletivo aqui, porque todos passámos por gestão da mudança nos nossos próprios projetos e organizações e estivemos tanto do lado de quem a implementa como de quem a recebe. Queria aproveitar este tempo para partilhar algumas histórias, falar sobre aquilo que aprendemos ao longo do caminho e ajudar outras pessoas, onde quer que estejam nos seus próprios processos ou na sua própria mudança.

É essa, de qualquer forma, a beleza da comunidade: construir conhecimento coletivo. Pedi a algumas pessoas que trouxessem histórias. Se não tiverem nenhuma, tudo bem. Se se lembrarem de uma durante a sessão, também será ótimo. O que quero fazer é simplesmente partilhar algumas dessas histórias.

À medida que surgirem perguntas, sintam-se à vontade para as colocar no chat ou fazê-las em voz alta. Esta será sobretudo uma discussão. Podemos partilhar algumas das coisas que aprendemos pelo caminho. A ideia é que, quando terminarmos hoje, tenhamos mais algumas ferramentas e ideias para abordar a mudança nos nossos próprios projetos.

Uma das pessoas que se disponibilizou para começar com uma história foi o Fred. Fred, se não te importares, podes começar e nós damos início à conversa. Como mencionei, podem colocar perguntas no chat, levantar a mão ou fazê-las em voz alta. Vamos divertir-nos.

Sim, claro. Obrigado. Antes de mais, obrigado por organizarem isto. Acho que não só é interessante ver eventos como este, como é ainda melhor vê-los acontecerem em resposta direta às perguntas e necessidades das pessoas, porque isso contribui realmente para criar comunidade.

Obrigado também pelo convite para partilhar uma história. A minha formação é em design de sistemas de instrução e tenho, na verdade, um doutoramento nessa área. Estudei toda a teoria e os modelos, e uma parte do design de sistemas de instrução é o desenvolvimento organizacional. Por isso, uma grande parte está relacionada com a gestão da mudança.

Embora não tenha uma enorme experiência com gestão formal da mudança, no sentido de fazer parte de uma equipa de mudança, tenho alguma experiência de investigação na área. A ideia de organização aprendente, por exemplo, e modelos como o da quinta disciplina, o modelo de oito passos de Kotter e o modelo de Lewin — descongelar, mudar e recongelar — são muito úteis como formas de pensar sobre a mudança.

Também há muito trabalho de Everett Rogers sobre a difusão de inovações e a adoção. A ideia é que se atinge uma massa crítica quando uma tecnologia está a ser adotada. Existem os inovadores, que aderem a praticamente tudo e defendem a ideia durante algum tempo. Depois, quando esse mercado fica saturado, é necessário alcançar os primeiros utilizadores e, posteriormente, uma massa crítica.

A partir daí, toda a gente sabe o que é a tecnologia e começa a considerá-la, avançando depois para a fase dos utilizadores tardios. É quando, por exemplo, toda a organização já utiliza o Microsoft Teams. E há sempre algumas pessoas no fim, os retardatários, que dizem: “Não vou fazer isso. Não vai acontecer.”

Venho do ensino superior e, mesmo quando toda a instituição utiliza Google, Microsoft ou outra plataforma, há sempre alguns docentes que dizem: “Não uso esse e-mail. Uso o meu outro e-mail porque prefiro.” Depois perguntamos como é que os alunos marcam reuniões com essa pessoa, e eles têm de passar por uma espécie de máquina de Rube Goldberg para descobrir como ligar o calendário, enviar um e-mail e resolver tudo isso.

Existem modelos e teorias por detrás de tudo isto, mas, para não me alongar demasiado, vou partilhar rapidamente uma experiência. Ao longo dos anos, tive muitas experiências diferentes e aquela que me parece mais aplicável aqui está relacionada com o trabalho que faço a ajudar organizações a reformular os seus sistemas utilizando o monday.com e ferramentas semelhantes.

Tive um cliente que produzia formação eletrónica para empresas maiores. Já tinha utilizado o Monday, mas era uma daquelas situações em que alguém entrou, implementou a ferramenta e não houve necessariamente um planeamento adequado. Muitos dos projetos de Monday em que trabalho não são realmente projetos de Monday; são projetos de processos empresariais.

O que descobrimos é que as pessoas muitas vezes não têm os procedimentos operacionais normalizados definidos, não mapearam o fluxo de trabalho ou não pensaram devidamente naquilo que seria o processo ideal. Se não soubermos onde estamos, não conseguimos mudar essa realidade. E nada irá funcionar da forma pretendida.

Nesse caso específico, demorei cerca de um ano, mas trabalhei com a organização de forma bastante aprofundada para reformular os seus sistemas. No final, melhorámos significativamente o desempenho, a entrega dos projetos e reduzimos os problemas de qualidade.

Tudo resultou de muitos ciclos iterativos: como deveria ser o processo e como é atualmente? Como podemos juntar as duas realidades para ficarmos mais próximos do que pretendemos? Penso que esse processo é provavelmente o mais simples possível, mas é também aquilo a que todos os modelos de mudança tentam chegar.

É algo bastante universal. Quer se esteja a tentar perder peso, ganhar força, aprender uma competência, fazer obras em casa ou realizar qualquer outra coisa, é necessário analisar qual é o estado ideal e onde estamos agora.

Uma das principais lições que retirei desse projeto foi a importância de definir claramente o problema desde o início. Passei muito tempo a mapear processos e percebi que grande parte do desafio era o facto de o problema não estar definido. Se o problema não estiver definido, não pode ser resolvido.

Também analisei os diferentes fluxos de trabalho dos projetos, que nem sempre estavam ligados entre si. Havia situações em que alguém perguntava: “Em que estado está este projeto?” e a resposta era: “Entreguei-o ao cliente.” “Quando?” “Há cerca de três semanas.” “E onde está agora?” “Ainda não obtive resposta.” “Fizeste o acompanhamento?” “Ainda não.”

Por isso, é importante mapear o processo e ter consciência dele. As lições que retirei foram as seguintes: sempre que começo a trabalhar com um novo cliente, procuro definir muito bem o problema desde o início, analisá-lo e perceber exatamente o que a organização está a tentar fazer.

Nem sequer começo pelo Monday ou por qualquer outra ferramenta. A programação é muito semelhante: não se abre o editor e começa simplesmente a escrever código. É preciso saber o que se pretende alcançar antes de começar. É planeamento, e é uma parte para a qual não tenho uma predisposição natural, mas que me obriguei a aprender.

Também é essencial pedir às pessoas que articulem o processo que pretendem. Se querem que algo aconteça, o que é que isso significa? Para quem passa a seguir? Para onde é encaminhado? O que acontece depois? De onde vêm os dados necessários? O objetivo é criar um mapa.

Talvez isto se afaste um pouco do tema que pretendíamos abordar, mas posso desenvolver o assunto. Não quero ocupar demasiado tempo e estou curioso para ouvir a primeira pergunta.

A minha pergunta é: quando entra neste contexto e precisa essencialmente de criar procedimentos operacionais normalizados para pessoas que não têm nada definido, encontrou resistência? É provável que essas pessoas já tenham os seus próprios procedimentos pessoais. Como conseguiu que aderissem?

É uma excelente questão. Neste caso, trabalhei sobretudo com as proprietárias, o que foi útil porque uma delas era a principal parte interessada e tinha tudo na cabeça. Um dos desafios era precisamente esse: toda a informação existia, mas apenas dentro da cabeça dela. Não estava necessariamente documentada, praticada ou aplicada.

Neste caso, as outras pessoas eram consultores, não funcionários a tempo inteiro. Eram prestadores de serviços. O interesse deles era entrar, entregar o projeto da forma mais rápida e eficiente possível e sair. Não estavam necessariamente investidos no negócio ou no seu sucesso para além da entrega de um bom produto.

Também tinham a sua própria forma de trabalhar, que podia ser um processo normalizado, bem definido ou não, dependendo do tempo que já trabalhavam como prestadores. Mas essas duas abordagens nem sempre coincidiam.

Assim, a proprietária dizia: “Este é o processo. Mapeámo-lo e é isto que quero que sigam.” O prestador podia concordar ou não. Entravam então questões de política, como as horas atribuídas ao projeto, as etapas obrigatórias e os pontos de controlo.

Existe resistência. Penso que há sempre resistência. Voltamos ao modelo de difusão das inovações: algumas pessoas aderem imediatamente, existe uma autoridade que define o processo, mas também é necessário estar aberto a sugestões e permitir que as pessoas contribuam para construir a solução.

O equilíbrio adequado depende de cada caso e daquilo que se consegue negociar. Gostaria de saber como é que isto ressoa com as outras pessoas na chamada: que desafios e abordagens semelhantes já encontraram ou utilizaram?

É uma experiência completamente única, que mais ninguém teve? Certamente já encontrei situações em que as pessoas resistiram a novas ideias, mudanças ou processos.

Temos algumas câmaras desligadas, por isso talvez algumas pessoas estejam simplesmente a ouvir enquanto trabalham. Está tudo bem.

Tenho uma pergunta para o Fred. Nestas situações, falou sobre uma pessoa que tinha tudo na cabeça e era necessário extrair essa informação. Como se explica a essa pessoa que isto é importante e que precisa de reservar tempo para transmitir a informação? Como se consegue continuar a ensinar as pessoas a resolverem os problemas por si próprias quando dizem que não têm tempo e que estamos a fazer coisas que não pediram?

Há muitas coisas que me ocorrem. Uma parte é compreender a posição que ocupamos. Costumo dizer que, enquanto gestores de projetos, não seguramos o volante. Estamos no lugar do passageiro, com o mapa, a dizer: “É preciso virar à esquerda. A curva aproxima-se. Ligue o pisca e prepare-se para virar.”

Mas, se a pessoa não virar, nós não seguramos o volante. O nosso trabalho passa a ser dizer: “Parece que passámos a curva que precisávamos de fazer. O melhor agora é voltar atrás e seguir por outro caminho.” Continuamos sem controlar o volante.

No final da viagem, a pessoa pode perguntar porque demorou mais três horas e olhar para nós como se a responsabilidade fosse nossa. Podemos explicar que avisámos várias vezes que era necessário virar à esquerda e que, como isso não aconteceu, tivemos de compensar e encontrar outro caminho.

Essa é normalmente a analogia que utilizo. É importante ter isso presente. Talvez a pessoa não saiba, talvez esteja ocupada, talvez não tenha tudo mapeado. Mas documentar as coisas demora tempo. Muitas vezes, as pessoas pensam que algo está concluído e não está. Pensam que os outros compreendem, mas isso pode não ser verdade.

Neste caso específico, passámos muito tempo em reuniões em que eu simplesmente ficava a ouvir a cliente falar sobre tudo o que tinha em mãos, enquanto enviava mensagens às pessoas. Era muito difícil conseguir um minuto da sua atenção.

O melhor que eu conseguia fazer era, no final, dizer: “Penso que estas são as ações que devo assumir. Concorda?” Se não concordasse, perguntava o que deveria fazer em alternativa. Por vezes, reuníamo-nos durante uma hora e eu só conseguia obter autorização para trabalhar em duas ou três coisas.

Foi um processo longo. Se trabalhamos à hora, é possível funcionar dessa forma. Se o projeto tem um preço fixo, é necessário adotar uma abordagem diferente. Costumo dizer às pessoas que sou um terapeuta ou amigo caro. Se quiserem gastar as horas dessa forma, podemos fazê-lo, mas tenho a obrigação de explicar que não é a melhor forma de trabalhar.

E se não virarem à esquerda, eu continuo a acompanhar a viagem. Espero que tenha ajudado, Robin.

Ajudou, sim. E gostaria de propor um novo título profissional: terapeuta caro.

Por vezes, esse título é bastante adequado. Já vi situações em que as pessoas davam instruções contraditórias. Diziam: “Quero que faças A”, trabalhávamos em A durante algum tempo e depois diziam: “Na verdade, quero que faças B.” Passávamos para B e perguntavam porque tínhamos feito B. A resposta era: “Porque foi isso que pediu.”

Se trabalho à hora, posso continuar nesse sentido, embora explique que não é a melhor opção. Se é isso que a pessoa precisa, é isso que fazemos. Num projeto com preço fixo, tenho de interromper imediatamente esse comportamento, porque já perdi centenas de horas de trabalho devido a mudanças de direção a meio do processo.

Por vezes, os clientes dizem que querem um carro rápido, mas não sabem se querem um Porsche ou um Lamborghini. Só percebem quando olham para o resultado e dizem: “É isto que quero” ou “Não é isto”.

Trabalhar à hora pode ser a melhor solução. Algumas pessoas precisam de falar durante todo o processo para conseguirem organizar o pensamento. Nesse caso, deixamo-las falar e, no fim, resumimos: “É isto que retiro da nossa conversa. Corrija-me se estiver errado. Estas são as cinco coisas em que vou trabalhar e estas são as três coisas que irá entregar.”

Procuro sempre resumir tudo num e-mail. Indico aquilo que cada pessoa irá fazer. Assim, duas semanas depois, quando alguém se esquece, podemos consultar o que ficou combinado. Também posso relembrar o que estava previsto na reunião anterior e indicar aquilo que ainda falta receber.

As gravações são úteis, sobretudo para acompanhar as ações.

Robin, a pergunta que colocou sobre a pessoa que tinha tudo na cabeça estava relacionada com algo que está a enfrentar atualmente ou com desafios anteriores na gestão da mudança?

Penso que, por vezes, vivemos num projeto caótico e queremos criar processos ou procedimentos operacionais normalizados que sejam úteis no futuro. Mas nem sempre temos tempo para recolher essa informação da pessoa certa. Também tenho dúvidas sobre a diferença entre gestão da mudança e gestão de projetos, porque sinto que quase tudo pode ser um projeto.

É uma excelente pergunta. Posso tentar responder, embora já tenha falado bastante. Alguém gostaria de responder?

Se olharmos para as definições, um projeto é um esforço temporário que conduz a um produto, serviço ou resultado. A gestão da mudança é o processo de gerir a mudança. Como gestores de projetos digitais, podemos pensar num novo website. Entregamos o website a alguém, mas o que acontece a seguir?

A implementação desse website irá alterar os processos da organização. Talvez o formulário de contacto tenha sido reformulado e os contactos passem a entrar de outra forma. Talvez tenha sido criada uma ligação ao sistema de gestão de clientes com novos campos. São melhorias, mas representam mudanças.

Por isso, temos de pensar em como comunicar a mudança, como preparar as pessoas e como apoiar aquelas que resistem. O Fred explicou muito bem anteriormente o que pode acontecer às pessoas que têm dificuldade em aceitar a mudança.

Estou atualmente num projeto que assumi de outro gestor de projetos. Logo no primeiro dia, tive de informar o cliente de que tinha cometido um erro de seis ou sete algarismos no início do projeto. O lançamento seria adiado e seria necessário obter muito mais financiamento para corrigir o problema.

Isto estava relacionado com a substituição de software com cerca de vinte anos, ao qual várias pessoas tinham acrescentado soluções improvisadas. Havia outro fornecedor envolvido e foi-nos pedido que mantivéssemos a situação em segredo. Só podíamos falar com um grupo muito pequeno de partes interessadas.

Esse grupo forneceu informações que a equipa utilizou, mas, durante os testes com os utilizadores, descobrimos que essas informações estavam erradas. Tivemos então de refazer todo o trabalho. Foi daí que surgiu o erro de seis ou sete algarismos.

Havia razões válidas para não abrirmos imediatamente as portas a todos os utilizadores. Se o outro fornecedor se irritasse e retirasse o software antes de estarmos preparados para a transição, o cliente não conseguiria gerir o negócio.

Em retrospetiva, tudo faz sentido. Mas, se tivesse estado envolvida desde o início, provavelmente teria proposto outras formas de trabalhar ou teria pedido ao cliente que assinasse um registo de riscos, reconhecendo os riscos de seguir aquele caminho e de não disponibilizar à equipa o acesso às pessoas certas.

Agora estamos perto do final do projeto e começamos a pensar no lançamento. O cliente participou num processo de lançamento preliminar, que funcionou como testes de usabilidade contínuos e como parte da gestão da mudança. Isto também lhes permitiu dar feedback, o que considero essencial. Quando as pessoas sentem que são ouvidas, tendem a aceitar melhor a mudança do que quando esta lhes é simplesmente imposta.

Inicialmente, o cliente queria entregar o software às pessoas e dizer-lhes para começarem a utilizá-lo. Depois de fazermos isso uma vez, percebemos que era uma ideia péssima. Regressámos a um processo de lançamento preliminar muito mais formal.

Organizámos os restantes grupos que tinham de realizar testes em equipas e criámos uma comunicação baseada numa espécie de pressão positiva entre pares. Era uma cadeia de e-mails em que todas as pessoas do grupo participavam, podendo ver as perguntas dos colegas. Assim, conseguíamos perceber quem estava a participar e quem não estava.

Houve muitas partes móveis: mudança no software, mudança na equipa do projeto e, agora, mudança dentro da empresa do cliente.

Foi perguntado se, perante erros tão graves, se deve suavizar a situação e proteger-se para não ser responsabilizado por transmitir más notícias. Neste caso, eu era uma gestora de projetos contratada, uma terceira parte relativamente neutra. Tinha estado envolvida como consultora, saí durante algum tempo e regressei quando o gestor de projetos anterior deixou o projeto.

Por isso, pude dizer: “Esta é a situação em que estamos. Temos de encontrar uma forma de sair dela.” Como era relativamente independente e não tinha sido a gestora durante todo o projeto, não parecia que eu tivesse permitido más decisões por alguma razão.

Algumas decisões que tinham sido tomadas continuavam a parecer-me adequadas na altura, mas não tinham sido decisões minhas. Agora tinha a responsabilidade final. Expliquei ao cliente o que tinha sido feito, porque tinha sido feito, onde estávamos e quais eram os caminhos possíveis para resolver a situação. A maioria exigia uma quantia significativa de dinheiro.

Robin, sente que obteve uma resposta clara sobre a diferença entre gestão de projetos e gestão da mudança?

Sim. Valorizei as contribuições de todos, mas foi útil simplificar a questão. Quando pesquiso gestão da mudança, encontro muitos modelos, certificações e conceitos que não compreendo. Foi útil explicar que, depois de concluir um website, é necessário compreender como o manter e atualizar.

É semelhante à gestão de projetos: a gestão de projetos é o processo de gerir projetos e tudo o que lhes está associado. A gestão da mudança segue uma abordagem semelhante. Temos de realizar uma mudança e, como os projetos não são operações correntes, estamos perante uma circunstância específica.

Gostaria de saber se alguém já trabalhou, enquanto gestor de projetos, com uma equipa de gestão da mudança. Imagino que exista alguma sobreposição e pergunto-me se é possível não sentir que estamos a fazer o trabalho dos outros ou a interferir.

Este ano trabalhei numa das grandes consultoras. Havia um departamento que disponibilizava profissionais de gestão da mudança aos clientes. Grande parte do trabalho estava relacionada com comunicação, recolha de contributos e obtenção de apoio.

Normalmente, essas pessoas ajudavam a ligar todas as partes. Quando se reformula um website, lança uma aplicação ou realiza uma grande campanha de marketing, isso costuma ser apenas uma parte do conjunto. Alguém tem de supervisionar a forma como todo o conjunto é implementado do ponto de vista da mudança.

Foi interessante observar, porque inicialmente toda a gente perguntava o que aquelas pessoas estavam ali a fazer. Parecia que estavam a pairar sobre tudo sem que fosse claro o seu contributo. Mas havia valor, porque alguém precisava de ligar as várias partes e garantir que a mudança era uma prioridade.

Em muitos projetos, ninguém pensa na gestão da mudança. Muitas vezes, essa responsabilidade acaba por recair sobre o gestor do projeto. Ou então o projeto é lançado e falha porque ninguém pensou no que aconteceria depois. Nenhuma das situações é positiva. Foi interessante, mas também foi um processo político.

Tive uma experiência semelhante quando trabalhava na Aramark. Estávamos a realizar uma transição de CRM. Eu fazia parte do projeto como responsável pela comunicação e havia também uma pessoa responsável pela mudança.

Quando analisávamos o projeto, a minha chefe perguntava porque é que a gestão da mudança dizia que algo devia ser comunicado por e-mail, através de uma reunião ou por formação. Expliquei que essa era a função dela: indicar o meio mais adequado e, depois, eu criava os e-mails, organizava os webinars ou produzia os materiais de comunicação.

Essa era a fronteira entre as nossas funções. Às vezes era confuso, mas o valor estava presente. Foi um grande privilégio aprender com essa pessoa e com toda a equipa de gestão da mudança.

Queria apresentar outra história relacionada com a gestão da mudança. Sarah, se tiveres uma história breve, seria útil para mostrar uma perspetiva diferente.

O exemplo que gostaria de partilhar vem de uma agência onde trabalhei. A maioria das agências onde trabalhei era bastante pequena, normalmente com vinte pessoas ou menos, muitas vezes entre cinco e dez.

Essa agência passou por várias vagas de despedimentos. Como parte dessas reduções, deixou de existir uma equipa criativa. A agência tinha deixado de realizar grandes projetos criativos e trabalhos editoriais com sessões fotográficas, porque as necessidades dos clientes tinham mudado e passaram a exigir mais investigação e estratégia do que produção criativa.

Os processos e a documentação das ferramentas que utilizávamos já não eram relevantes. A equipa de operações chegou a ter três pessoas, depois duas e finalmente fiquei apenas eu. Não tinha tempo para atualizar tudo.

Quando uma equipa diminui, as necessidades mudam. Um processo que funcionava quando havia vinte pessoas pode não funcionar quando existe apenas uma. Torna-se muito mais importante trabalhar de forma inteligente e não simplesmente trabalhar mais.

Um dos problemas era que a equipa não sabia utilizar o Asana, que era a nossa principal ferramenta de gestão de projetos. Havia muita confusão entre o que acontecia no Slack e aquilo que deveria ser feito no Asana.

Por isso, um dos meus objetivos trimestrais foi criar um programa de formação. O primeiro passo foi rever aquilo que já existia e definir o que era importante para a equipa. Tal como o Fred disse, é essencial definir primeiro o problema antes de determinar os passos seguintes.

O moral estava baixo devido aos despedimentos, a capacidade de atenção era limitada e a equipa trabalhava remotamente. As pessoas não queriam passar tempo em reuniões nem ler um documento de quarenta páginas sobre como utilizar o Asana e o Slack.

Por isso, a formação tinha de ser dividida em pequenas partes e ser relevante. Tudo o que fosse informação extra, embora pudesse ser útil para a equipa de operações, tinha de ser excluído. O objetivo era criar um programa de formação e redefinir a forma como a agência utilizava as ferramentas.

O segundo passo foi perceber o que já estava disponível. Como era agora um departamento de uma só pessoa, procurei saber se o Asana ou algum blogue já tinha materiais que pudesse utilizar. Encontrei recursos úteis e selecionei as partes mais relevantes.

Criei um pequeno programa de formação no Asana. Criei um projeto que podia duplicar para cada pessoa. As tarefas deveriam ser realizadas de cima para baixo e cada uma correspondia a uma explicação de cerca de cinco minutos.

A equipa nem sequer sabia utilizar algumas funções básicas do Asana. Encontrei um vídeo de cinco minutos criado pelo próprio Asana que explicava o essencial, por isso pedi-lhes que começassem por aí.

Depois expliquei as expectativas: como comentar tarefas, como configurar o perfil, como desligar notificações, como trabalhar a partir da caixa de entrada e como evitar receber quatro notificações diferentes sobre o mesmo assunto.

Se uma pessoa é nova no Asana, pode não saber que estas opções existem. Se trabalha com uma equipa pouco orientada para processos, é possível que ninguém saiba como desligar notificações ou que isso seja sequer possível.

Antes de disponibilizar a formação, apresentei-a à equipa numa sessão muito curta. Expliquei que a finalidade era proporcionar estabilidade e facilitar o trabalho diário. Não queria que parecesse apenas uma formação aborrecida que ninguém queria fazer.

A equipa tinha acabado de passar por muitas mudanças. Expliquei que, se todos estivéssemos alinhados, o programa levaria menos de uma hora no total. As partes eram pequenas e não tinham de ser realizadas todas de uma vez.

Eu era copiada em todas as tarefas, por isso sabia quando eram concluídas. Pedi às pessoas que marcassem cada tarefa como concluída à medida que avançavam e que não a marcassem se algo não estivesse claro. Nesse caso, poderiam comentar e falar diretamente comigo ou com o respetivo responsável.

Como a equipa era pequena e muito competente, não tive muitos problemas. Quando a equipa criativa ainda existia, era mais difícil concluir algumas tarefas administrativas. Os investigadores e estrategas gostavam mais de listas de verificação; a equipa criativa não queria consultar tarefas nem receber lembretes.

A composição da equipa ajudou. As pessoas sabiam que era uma tarefa que tinham de concluir durante o trimestre. Criei o programa e elas tinham de o concluir no mês seguinte.

Não gosto de ser a pessoa que envia lembretes, mas isso faz parte do trabalho. Procuro ser tão cordial quanto possível. Também é útil manter um registo escrito: poder mostrar que uma pessoa foi identificada num comentário há dois meses ou há uma semana e que ainda não respondeu.

Esse registo é importante quando é necessário fazer cumprir uma mudança. Se apenas dissermos que transmitimos uma informação, mas não conseguirmos mostrar onde e quando, torna-se mais difícil.

A questão era saber como garantir que as pessoas cumpriam o que estava definido, sem controlar excessivamente o seu trabalho nem prejudicar a relação com elas. Eu comecei por explicar o propósito da formação e como iria facilitar o dia a dia.

Também aproveitei o facto de a equipa gostar de listas e tarefas. Em vez de obrigar as pessoas a adotar uma forma completamente diferente de trabalhar, utilizei um sistema que já lhes era familiar. Isso reduziu a barreira à mudança.

Na maioria dos casos, recebi comentários muito positivos. Algumas pessoas disseram que nunca tinham compreendido a diferença entre o que deveria ser publicado no Asana e aquilo que devia ser discutido no Slack. O trabalho começou a avançar com maior rapidez.

Não tínhamos mais um coordenador de projetos. Antes, essa função era essencial, porque alguém garantia que tudo o que acontecia no Slack era registado no Asana e que as tarefas eram atualizadas. Sem esse papel, o gestor de projetos precisa de ter visibilidade diretamente no sistema.

Algumas pessoas continuaram a preferir o Slack, porque é uma ferramenta familiar, semelhante às mensagens de texto. Isso é compreensível, mas pode criar problemas quando é necessário acompanhar o estado do trabalho.

Gostaria de colocar uma questão ao grupo sobre fadiga da mudança. Temos um projeto longo, as prioridades mudam constantemente e o cliente surge todos os dias com uma nova necessidade. Muitas pessoas também passaram por grandes reorganizações depois da pandemia, despedimentos e mudanças frequentes de funções.

Alguém tem experiência de fadiga da mudança ou estratégias para ajudar as equipas, ou a si próprio, a lidar com isso?

Uma forma de abordar a questão, especialmente no ensino superior, é ajudar as pessoas a encontrar algo familiar na nova realidade. Quando a pandemia obrigou os docentes a passar para o ensino online, muitos resistiram porque acreditavam que as suas aulas não podiam ser lecionadas remotamente.

Mas continuavam a ensinar, a envolver os alunos, a responsabilizá-los e a realizar as mesmas atividades. A diferença era o ambiente. Encontrar as semelhanças ajuda as pessoas a relacionarem-se com a mudança e a concentrarem-se naquilo que continua igual.

A longo prazo, a situação transforma-se numa conversa cultural. Quando uma organização muda constantemente de tecnologia e de ferramentas, as pessoas deixam de confiar que uma solução irá durar. Perguntam-se por que razão devem investir tempo e energia a aprender algo que pode desaparecer dentro de seis meses.

Quando a mudança é constante, a confiança é afetada. As pessoas acabam por criar uma base pessoal de trabalho independente das ferramentas. Torna-se difícil convencê-las de que uma nova ferramenta ou prática veio para ficar, porque podem pensar que é apenas mais uma moda que durará três meses.

Nesses casos, é necessário ter uma conversa cultural e reconhecer que a mudança frequente pode ser desgastante.

Também é importante reconhecer que, depois de uma mudança, as coisas demoram mais tempo. As pessoas precisam de aprender novos processos, o que retira tempo às tarefas habituais. Quando há muitas mudanças a acontecer, a produtividade pode diminuir temporariamente.

É necessário aceitar esse abrandamento até que as pessoas se reorientem e consigam trabalhar de forma mais eficaz. A mudança tem altos e baixos e pode ser sazonal.

A mudança também afeta a motivação. Se uma pessoa sente que está a produzir menos, pode sentir-se desmotivada, sobretudo quando compara o desempenho atual com o passado. É importante definir expectativas realistas e explicar que é aceitável avançar mais devagar enquanto se aprende um novo processo.

Também é importante estabelecer um ritmo sustentável. As pessoas tendem a comparar o seu ritmo com aquilo que pensam que os outros estão a fazer. Definir três tarefas para um dia e permitir que isso seja suficiente pode ajudar a evitar a sensação de que nunca se fez o bastante.

Reconheço que estamos a chegar ao fim da chamada. Quero agradecer a todos por terem participado e contribuído. Foi muito útil ouvir histórias sobre os desafios que outras pessoas enfrentaram.

É importante validar esses desafios e levar algumas destas ideias e processos para o nosso próprio trabalho. Espero que todos tenham retirado algumas aprendizagens que possam aplicar aos seus sistemas, organizações e processos.

O nosso próximo evento será no dia 23 de maio. Será um fórum em direto, no qual poderão trazer os principais desafios que estão a enfrentar no trabalho. Vamos discutir esses desafios em conjunto, de forma semelhante a esta conversa, mas de maneira mais aberta.

Não será apenas sobre gestão da mudança; poderão trazer qualquer tema que esteja presente no vosso trabalho. Esperamos que possam participar.

Obrigado novamente. Tenham um excelente resto de dia. Espero que tudo corra bem e falaremos no Slack. Adeus a todos. [00:55:00] [00:56:00] Obrigado.