Comece os Seus Projetos da Forma Certa (com Suze Haworth)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa informático. Perdoe quaisquer erros de digitação, uma vez que o sistema automático não está correto a 100% do tempo.

Ben Aston:

Bem-vindo ao podcast DPM, onde vamos além da teoria para fornecer aconselhamento especializado de gestão de projetos para liderar melhores projetos digitais. Obrigado por nos acompanhar. Sou Ben Aston, fundador do The Digital Project Manager.

Todos sabemos que o início de um projeto é realmente fundamental para o seu sucesso, mas pode ser uma fase bastante complicada. Existe muita ambiguidade. Existe muita confusão. Há muitos desacordos e uma grande dose de incerteza. Enquanto gestores de projetos, cabe-nos pôr o projeto em marcha e mantê-lo em movimento, e ganhamos pontos extra se conseguirmos começar a liderar esse projeto na direção certa. Mas o que podemos realmente fazer para garantir que seguimos nessa direção? Que começamos as coisas da forma certa? É disso que trata o podcast de hoje. Continue a ouvir para descobrir como pode começar os seus projetos da forma certa.

Hoje estou acompanhado por Suze Haworth. Olá, Suze.

Suze Haworth:

Olá.

Ben Aston:

A Suze é uma das nossas especialistas residentes em gestão de projetos digitais no The Digital Project Manager. Trabalha como gestora sénior freelance de projetos digitais em Londres. Suze, porque não nos fala um pouco sobre alguns dos projetos em que tem trabalhado recentemente?

Suze Haworth:

Sim. Sou gestora de projetos freelance. Há algumas semanas terminei recentemente um contrato, que era bastante longo, numa agência. Tinha lá duas funções principais. Uma delas era mais semelhante à função de diretora de programa, responsável por uma conta. Tratava-se da Specsavers, uma grande marca de óculos de retalho no Reino Unido, que também está presente nos países nórdicos e na Austrália. Geria uma gestora sénior de projetos responsável por todo o trabalho criativo, de experiência do utilizador e digital da Specsavers. Era um programa de trabalho bastante grande. Também trabalhava num projeto para a Ikea. Tratava-se de um projeto para conceber e criar um protótipo de um sistema de design para a marca.

Ben Aston:

Muito bem. Portanto, a Specsavers era mais um projeto de comércio eletrónico e otimização da conversão?

Suze Haworth:

Sim. Dependia realmente do mercado, mas, na verdade, não costumam vender óculos online devido a determinadas regulamentações. Por isso, grande parte do trabalho consistia em levar as pessoas a marcar consultas e a deslocarem-se às lojas. Mas sim, como diz, era sobretudo conversão e otimização.

Ben Aston:

O que foi difícil nesses projetos? Quais foram alguns dos desafios que enfrentou com o próprio projeto, com o cliente ou com a equipa? É sempre interessante para as pessoas ouvirem que outros profissionais têm problemas semelhantes. O que foi difícil?

Suze Haworth:

No programa de trabalho da Specsavers, foi uma altura muito interessante quando comecei, porque comecei em março, no início do novo ano, e passámos a trabalhar de uma forma completamente nova. Anteriormente, trabalhávamos como agência de design em conjunto com a agência de desenvolvimento e estávamos integrados nas respetivas equipas Scrum. Tínhamos um designer e profissionais de experiência do utilizador em cada uma das equipas Scrum, distribuídos pelos vários fluxos de trabalho. Decidimos retirar todos os nossos designers e profissionais de experiência do utilizador dessas equipas Scrum, reuni-los numa única equipa do nosso lado e passar a utilizar um processo de dupla via. Estávamos a executar aquilo a que chamávamos uma via de descoberta, praticamente acima da via de entrega, que correspondia mais à equipa de desenvolvimento baseada em Scrum.

Isso deu-nos espaço para realizar testes com utilizadores, explorar soluções, formular hipóteses e testar pressupostos com os utilizadores. Também permitiu fazer muito mais investigação e utilizar dados para alimentar o processo, dando-nos mais margem de manobra para entregar coisas que os utilizadores realmente queriam. Foi uma altura muito interessante para implementar essa nova forma de trabalhar, garantir que estava a funcionar e fazê-la avançar. Foi um desafio, mas também foi muito entusiasmante.

Ben Aston:

Então, qual era exatamente a sua função? Era a função de proprietária do produto? Tinha estes dois fluxos de trabalho paralelos. Um destinava-se à estratégia, à experiência do utilizador e ao design, e presumo que eram essas pessoas que realizavam os testes com utilizadores para identificar as necessidades destes. Depois, essas necessidades eram priorizadas, algumas passavam para o fluxo de experiência do utilizador e design e, finalmente, desciam para o desenvolvimento. Era assim que funcionava?

Suze Haworth:

Sim. O que estávamos a perceber era que ter os profissionais de design e de experiência do utilizador integrados na equipa Scrum, a trabalhar em ciclos de duas semanas e a tentar entregar resultados nesse período, era bastante limitador. Passavam muito tempo nos aspetos mais técnicos. Participavam em longas reuniões de planeamento de sprint, embora apenas estivessem envolvidos em partes mais pequenas, ou participavam em reuniões diárias e outras reuniões nas quais se falava sobretudo de erros. Em vez de pensarem nas necessidades reais dos clientes, o trabalho estava a tornar-se demasiado orientado para a tecnologia. A decisão de os retirar dessa equipa e de os colocar numa via paralela, acima da via de desenvolvimento, permitiu-nos ter o tempo adequado. Continuávamos a trabalhar rapidamente, mas tínhamos tempo para analisar dados e investigação existentes, bem como a investigação que realizávamos, e identificar pressupostos e hipóteses sobre a forma de resolver problemas dos clientes.

Podíamos então começar rapidamente a fazer design de experiência do utilizador ou protótipos, conforme a necessidade, e colocá-los de imediato à frente dos clientes. Assim, estes podiam validá-los antes de entrarem em produção. Era uma forma de simplificar o desenvolvimento e evitar criar coisas que os clientes não queriam. Tentávamos atualizar as decisões de design e de experiência do utilizador antes de estas entrarem nos sprints. Continuávamos a envolver pessoas da área técnica na via de descoberta, mas, em vez de validarem apenas a viabilidade técnica depois de dizermos “é isto que o cliente quer e gostou desta funcionalidade”, envolvíamo-las mais cedo. Era uma tentativa de simplificar o processo, mas também um verdadeiro esforço para entregar aquilo de que o cliente precisa, em vez de apenas aquilo que é possível fazer. Percebe?

Ben Aston:

Acho que este é um desafio comum a muitas agências que tentam utilizar Scrum. É evidente que o Scrum não é a única forma de executar um projeto ágil, mas parece ser a regra geralmente aceite: é preciso utilizar Scrum. Um dos grandes desafios de utilizar Scrum numa agência é perceber o que devem fazer as pessoas de experiência do utilizador e de design durante o sprint. Uma forma é fazer com que trabalhem alguns sprints à frente do desenvolvimento, mas depois nada fica concluído. A ideia de um sprint é que, no final, se desenvolva algo que possa ser entregue e que cumpra os critérios de aceitação. É muito difícil fazer isso num período de duas semanas, passando pela estratégia, experiência do utilizador, design e desenvolvimento de uma funcionalidade.

Gosto da ideia de executar os dois fluxos de trabalho em paralelo e, à medida que as coisas são validadas, o proprietário do produto pode colocá-las no backlog de desenvolvimento. Assim, temos dois backlogs diferentes. Num backlog estratégico, perguntamos se esta é a coisa certa a fazer. No outro, sabemos que é a coisa certa porque foi validada e podemos desenvolvê-la. Acho que isso resolve certamente alguns dos desafios.

Suze Haworth:

Sim, exatamente. Como disse, significa que estamos efetivamente a criar funcionalidades que validámos que os clientes querem, o que produz muito menos desperdício. É um processo muito mais eficiente, o que só pode ser positivo.

Ben Aston:

Muito bem. Vamos falar sobre a iniciação de projetos e sobre começar efetivamente os projetos. Gostava de saber se esteve envolvida desde o início nos projetos da Ikea ou da Specsavers.

Suze Haworth:

No caso da Specsavers, esta nova forma de trabalhar era para uma equipa permanente, com um âmbito definido para o ano e uma determinada composição da equipa. Comecei depois de essa forma de trabalhar ter sido inicialmente definida de forma geral e de o âmbito de trabalho ter sido escrito. Este é um dos desafios de que falo no meu artigo: assumir algo ou um projeto que já começou ou que já foi definido por outra pessoa. Assumi-o pouco depois de o âmbito ter sido definido, quando a forma de trabalhar já tinha sido estabelecida de determinada maneira. Quando começou a ser implementada, percebi que precisava de ajustes e alterações. Evoluiu bastante em relação ao que tinha sido originalmente proposto, porque, quando começamos efetivamente a trabalhar de determinada forma, descobrimos coisas que não funcionam totalmente e que precisam de ser ajustadas e adaptadas ao longo do caminho.

No caso do projeto da Ikea, este foi executado por fases e, mais uma vez, não trabalhei na primeira fase: entrei na segunda. O projeto já tinha começado antes de eu entrar.

Ben Aston:

E penso que isso acontece frequentemente nos projetos que assumimos enquanto gestores de projetos. Muitas vezes assumimo-los não exatamente no início, e isso pode contribuir para alguma confusão. Enquanto gestor de projetos, é colocado num projeto que lhe foi entregue pela equipa de desenvolvimento de negócio, pela equipa de gestão de contas ou pela equipa de vendas. Recebe algo que foi planeado, mas não totalmente. Existe algum grau de incerteza. Por isso, ao falarmos de iniciação de projetos, podemos imaginar que esta diz respeito tanto ao momento em que recebemos um projeto como ao seu início. Vamos falar das coisas que mencionou no seu artigo: gerir as pessoas, o processo e o produto, e obter alinhamento e clareza em relação a esses elementos. Ou seja, quem, como e o quê.

Suze Haworth:

Quando se inicia um projeto, é necessário pensar em alguns grupos principais e nas pessoas envolvidas. Primeiro, a equipa: quem vai trabalhar no projeto? Na fase de iniciação, define-se quem vai ser incluído no projeto e quem irá trabalhar nele. É importante pensar não só em quem está disponível, mas também em quem é adequado para o projeto: as suas competências, a forma como trabalha, os tipos de projetos que tem e o tipo de cliente com quem vai trabalhar.

Se conhecer os membros da sua equipa, é importante perceber quem poderá trabalhar melhor e quem poderá colaborar bem. Isso pode ser um luxo, pois a decisão pode depender apenas de quem está disponível, mas é algo útil para ponderar desde o início. Mesmo que tenha de utilizar determinadas pessoas, compreender inicialmente a forma como trabalham pode ajudá-lo mais tarde caso surjam problemas.

É importante garantir que as pessoas que vão trabalhar no projeto estejam envolvidas desde o início. Ao longo dos anos, trabalhando com designers, programadores e profissionais de garantia de qualidade, percebi que uma das coisas que mais detestam é não fazerem parte do projeto desde o início, não saberem nada sobre ele e receberem algo já definido para simplesmente lhes dizerem: “Pode desenhar isto?” ou “Pode desenvolver isto?”. Quando lhes é retirada qualquer autonomia e lhes dizem apenas o que devem fazer, isso torna-se um problema.

Se houver tempo e orçamento suficientes, é uma excelente ideia envolvê-los, ainda que ligeiramente, desde o início. Depois da reunião inicial de arranque interna, fale com eles sobre o que pensam do projeto, como gostariam que funcionasse e quais são as suas expectativas. Assim, ficam envolvidos desde o início.

Ben Aston:

Penso que isto está relacionado com a questão da afetação de recursos. Tanto quanto possível, devemos garantir desde o início os recursos da equipa de que precisamos e que queremos, e envolvê-la no projeto o mais cedo possível para obter o seu apoio. As pessoas tendem a reagir quando recebem algo que outra pessoa pensou, mas não teve tempo suficiente para desenvolver devidamente. Queremos que pensem: “Sim, isto também é meu.” Quando têm esse sentimento de propriedade, em vez de reagirem a uma ideia incompleta de outra pessoa, normalmente obtemos resultados muito melhores.

Suze Haworth:

Exatamente.

Ben Aston:

Gostaria de passar à questão do processo, porque também está relacionada. Já temos a equipa e sabemos quem a constitui. Agora, como vamos utilizá-la para entregar o projeto? Existe frequentemente desacordo sobre a forma de entregar o projeto, sobre o processo, a metodologia e as ferramentas a utilizar. O que faz para alinhar a equipa e ultrapassar esse desacordo quase inevitável?

Suze Haworth:

Provavelmente nunca encontrará uma solução de processo ideal que satisfaça toda a gente em todos os aspetos. Haverá tensões ao longo do projeto. Por vezes, herdamos um processo que a agência ou organização já utiliza, ou o cliente pode determiná-lo. Se tiver a oportunidade de o definir, pode tentar encontrar algo que se adeque ao projeto e ao cliente. Se já existir um processo definido, é útil explicá-lo à equipa numa reunião interna de arranque, incluindo os motivos para o utilizar, e tentar obter o seu apoio desde o início.

Também é muito importante adaptar o processo ao longo do caminho. Nunca devemos manter rigidamente algo que não esteja a funcionar. A equipa deve saber que, se tiver problemas com o processo, com as ferramentas ou com a forma de comunicar, deve levantá-los e falar abertamente sobre eles, para podermos encontrar formas de os atenuar e adaptar o trabalho.

Ben Aston:

Acho que essa flexibilidade é fundamental para o sucesso. Muitas vezes, os gestores de projetos ou as equipas dizem: “Não é assim que o Scrum funciona”, “Isso não é ágil” ou “Isso é demasiado cascata”. Na realidade, não importa tanto o que é ou deixa de ser. O que importa é o que funciona melhor para a equipa, para o projeto e para o cliente. O essencial é não ser dogmático em relação a uma abordagem. Com a equipa que temos e o trabalho que precisamos de realizar, qual é a melhor forma de o entregar?

Por vezes, isso significa reinventar a roda, mas a realidade é que os projetos são todos diferentes. Tentar aplicar um único processo ou método a tudo é muito complicado. Se estivermos a fazer trabalho de manutenção ou pequenas atualizações contínuas de funcionalidades, faz sentido normalizar as coisas. Mas, se formos colocados num novo projeto para um novo cliente, temos liberdade para definir a melhor abordagem.

Falámos sobre quem: a equipa e as partes interessadas. Falámos sobre como: navegar pelo processo e ser flexível. Quanto ao quê, ou seja, ao que estamos efetivamente a fazer e a entregar, esta pode ser uma das partes mais difíceis quando herdamos um âmbito de trabalho muito vago da equipa de vendas ou um conjunto pouco claro de requisitos do cliente. Como elimina a ambiguidade em torno do projeto ou do produto e chega ao ponto de dizer: “Está bem, vamos concordar que vamos entregar isto?”

Suze Haworth:

Depende novamente do tipo de projeto. Idealmente, não queremos que tudo seja demasiado rígido e definitivo no início, porque as coisas mudam muito e podemos acabar com algo completamente diferente mais tarde. Prefiro âmbitos que permitam alterações e que não fixem completamente os resultados desde o início. Para esclarecer os requisitos, é necessário começar a conversar com os clientes, compreender as necessidades dos utilizadores e do negócio e perceber verdadeiramente o contexto do projeto.

Depois, devemos desenvolver todos esses requisitos com a equipa. Isto significa envolvê-la desde cedo, não apenas uma pessoa, mas vários responsáveis de disciplina, caso a equipa ainda não esteja formada, ou vários membros da equipa. Devemos explicar-lhes o âmbito do projeto e os requisitos, e estabelecer alguns parâmetros para aquilo que o projeto poderá ser.

Ben Aston:

Nas primeiras sessões em que tentamos definir o que estamos realmente a fazer, considero útil reunir as pessoas durante meio dia, com um quadro branco, notas autocolantes e vários materiais. Tentamos conceber a solução a um nível muito elevado. O meu objetivo é criar uma compreensão partilhada e alinhamento, porque, no início de um projeto, as pessoas tendem a ter interpretações diferentes sobre o significado das coisas. Ao desenhar os elementos e colocá-los na parede, criamos conversas que revelam essas diferenças. Assim, identificamos as áreas ambíguas e podemos voltar ao cliente com diferentes formas de abordar o trabalho.

É importante ter uma visão geral do projeto, colocar toda a gente na mesma página e guardar uma fotografia do quadro branco. Essa imagem passa a ser uma referência para perceber como as diferentes partes se ligam e o que estamos a entregar. Definir uma arquitetura geral da solução, mesmo que seja apenas uma primeira proposta, ajuda a estabelecer os limites do projeto e a clarificar até onde vamos e o que vamos fazer.

Suze Haworth:

Sem dúvida. Workshops desse tipo são excelentes para reunir as pessoas, discutir os temas e defini-los. Mesmo que as coisas mudem, pelo menos existe uma primeira referência. Também é muito útil fazer isso com o cliente. É uma boa forma de iniciar um projeto e permite compreender melhor a perspetiva do cliente. O cliente também percebe melhor a nossa posição. Pode começar por fazer uma sessão interna e depois levá-la ao cliente, trabalhando com ele em sessões de meio dia.

Ben Aston:

Falámos sobre quem, as pessoas e a equipa; sobre como, o processo e a metodologia; e sobre o quê, começando a esboçar a solução e a arquitetura. Também podemos começar a definir o orçamento, os prazos e as métricas de sucesso. Ter tudo isso num grande quadro branco no início, mesmo que venha a mudar, é muito útil.

No entanto, no início de um projeto podemos estar a tentar conceber uma solução antes de o projeto ser aprovado. Existe uma tensão sobre quanto trabalho fazer e até onde avançar. Devemos fazer o máximo possível ou ser mais cautelosos e fazer apenas o suficiente para avançar um pouco? Muitas vezes ainda não temos a aprovação final, mas sabemos que, se não fizermos mais trabalho, nunca cumpriremos a data de entrega. Como gere essa tensão entre avançar demasiado, com o risco de entrar num caminho sem saída, e ser cautelosa, podendo ficar atrasada algumas semanas mais tarde?

Suze Haworth:

Provavelmente tendo para o lado mais cauteloso, mas sendo completamente transparente. Se o cliente estiver a atrasar a aprovação ou a rever continuamente o âmbito, é importante garantir que tem consciência dos atrasos e de como estes podem afetar o projeto global. Devemos estar conscientes dos riscos associados a algo não estar definido e ao facto de não podermos iniciar formalmente o trabalho.

Ainda assim, começar a avançar e a pensar nas coisas é positivo. Mesmo adotando uma abordagem cautelosa, é possível fazer o suficiente para manter o projeto em movimento. No início de um projeto existe sempre algum dinamismo: a equipa envolve-se, conversa sobre o trabalho e fica entusiasmada com aquilo que vai criar ou desenvolver. Se esse ritmo abrandar e parar, os membros da equipa e, por vezes, os clientes podem perder o foco e dedicar-se a outras coisas. Manter o dinamismo é importante.

Ben Aston:

Vamos falar sobre alguns desses desafios. Um dos mais comuns é a falta de dinamismo no início do projeto. As pessoas são informadas sobre um projeto, mas depois nada acontece, ou o projeto fica bloqueado devido a ambiguidades e perguntas sem resposta. O que faz quando as coisas parecem parar completamente?

Suze Haworth:

É uma situação difícil, porque podemos já ter pessoas reservadas para o projeto sem ter recebido a aprovação oficial. No entanto, se tivermos algum tempo que possa ser utilizado, é importante reservar um pouco desse tempo para a equipa iniciar ligeiramente o trabalho. Podemos fazer o suficiente para manter o dinamismo e o envolvimento, através de investigação preliminar, análise de dados existentes ou análise de concorrentes. Isso inicia o processo de reflexão e mantém a equipa envolvida num nível mais reduzido até ser possível começar oficialmente.

Ben Aston:

Mesmo uma reunião rápida com a equipa pode ajudar. Podemos dizer: “Pensávamos que o projeto começaria esta semana, mas isso não vai acontecer. Eis as últimas informações.” Assim, mantemos a equipa envolvida e evitamos que o projeto desapareça completamente do seu radar.

Suze Haworth:

Não há nada pior do que deixar de comunicar completamente e, três semanas ou um mês mais tarde, aparecer a dizer: “Ótimo, agora podemos começar.” É importante manter a equipa informada sobre as conversas com o cliente, explicar o motivo do atraso, quando o trabalho começará e o que podemos fazer entretanto. Devemos manter a conversa.

Ben Aston:

Uma situação que muitos gestores de projetos enfrentam é assumir um projeto a meio. Herdamos o plano de outra pessoa relativamente às pessoas, ao processo e ao produto, mas passamos a ser responsáveis pela entrega. Que conselhos tem para compreender essa situação?

Suze Haworth:

É provavelmente um dos maiores desafios, porque normalmente não estamos envolvidos desde o início da maioria dos projetos. A fase inicial é muitas vezes tratada pela direção de gestão de projetos ou de entrega, ou por outros membros da equipa. Muitos dos projetos em que acabamos por trabalhar vêm de outro contexto e já têm determinadas expectativas definidas. Muitas vezes, trabalhamos com custos previamente acordados e um âmbito muito vago, tendo de o adaptar ao orçamento. Acabamos por assumir algo que foi definido por outra pessoa.

É importante analisar os parâmetros existentes e perceber onde há flexibilidade e margem de manobra. Se já existir um custo definido, devemos analisar o âmbito e aquilo que podemos entregar, garantindo que é realista, mesmo que isso implique conversar sobre o facto de o trabalho ter sido vendido em excesso. Se houver demasiado trabalho para o custo previsto, temos de ser realistas sobre o que podemos entregar. Devemos identificar onde podemos ser flexíveis e onde será necessário conversar sobre o âmbito ou os prazos.

Se assumirmos um projeto a meio, depois de este ter sido iniciado por outro gestor de projetos, há duas coisas fundamentais a fazer: obter o máximo de informação possível sobre o projeto, o que aconteceu, o que foi entregue, o cliente e todos os restantes elementos; e depois fazer uma espécie de reinício. Devemos realizar um novo arranque, mesmo que seja a meio do projeto. Reunir a equipa e conversar com o cliente. É importante deixar claro que este é um ponto de reinício e que estamos a começar novamente com uma nova pessoa responsável. Mesmo que as pessoas sintam que já passaram por isso, é uma excelente forma de fazer o projeto avançar, compreender o que aconteceu e perceber o que não funcionou, o que deve ser alterado e o que deve continuar.

Ben Aston:

Ter confiança para reiniciar um projeto é muito importante. Por vezes, entramos num projeto sem saber praticamente nada. Fazer perguntas difíceis, ou até aparentemente estúpidas, quase sempre revela muita ambiguidade que também existia para outras pessoas da equipa. À medida que um projeto avança, as pessoas começam novamente a fazer pressupostos que nem sempre são documentados e a sua compreensão começa a divergir. Um reinício permite perguntar: “Esta pode ser uma pergunta estúpida, mas como funciona isto? E como se relaciona com aquela outra coisa que estamos a desenvolver?” Isso revela problemas, questões que ainda ninguém tinha considerado e desafios latentes que precisam de ser resolvidos.

Suze Haworth:

Nunca devemos ter medo de fazer muitas perguntas. Sempre disse isso, e digo-o aos novos gestores de projetos: façam perguntas. Não tenham medo de parecer pouco informados. É muito melhor fazer essas perguntas e descobrir o que precisam de saber do que permanecer em silêncio e ter uma surpresa mais tarde.

Ben Aston:

É um excelente conselho para a iniciação de projetos em geral. A arte de iniciar bem os projetos resume-se à comunicação: fazer as perguntas difíceis que ninguém quer fazer e que toda a gente sabe que precisam de ser feitas. É preciso ter confiança para fazer perguntas difíceis, incómodas e irritantes, porque é assim que começamos a obter clareza. Quando conseguimos definir as coisas, o projeto decorre de forma muito mais tranquila, com menos trabalho desperdiçado e menos esforço desnecessário, à medida que todos alcançam clareza sobre a direção comum. Suze, muito obrigado por se juntar a nós. Foi ótimo tê-la connosco.

Suze Haworth:

Obrigada. Foi ótimo estar aqui.

Ben Aston:

Como uma das nossas especialistas DPM, a Suze participará no nosso próximo curso, que começa em fevereiro. Chama-se domínio da gestão de projetos digitais e é um curso intensivo de sete semanas que inclui aulas de vídeo interativas, debates em painel e a opção de sessões de acompanhamento. Se quiser compreender melhor como melhorar a iniciação de projetos e começar corretamente os projetos, visite DPMSchool.com e inscreva-se antes de o curso esgotar. Se quiser contribuir para esta conversa sobre iniciação de projetos e sobre como fazê-la melhor, comente a publicação e visite também a secção de recursos do DigitalProjectManager.com para aderir à nossa equipa no Slack. Encontrará todo o tipo de conversas sobre iniciação de projetos e gestão de projetos. Até à próxima, obrigado por nos ouvir.