Controlar o aumento do âmbito (com Suze Haworth)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe eventuais erros tipográficos, uma vez que o sistema automático não está correto a 100% do tempo.

Ben Aston:

Bem-vindos ao podcast do DPM, onde vamos além da teoria para oferecer aconselhamento especializado para liderar melhores projetos digitais. Obrigado por nos acompanhar. Sou Ben Aston, fundador do Digital Project Manager. Ora, se há algo que faz descarrilar quase todos os projetos, é o aumento do âmbito. Todos sabemos que é mau. Todos sabemos que o queremos evitar. Mas como é que o reconhecemos em todas as suas formas? O que o causa? De quem é a culpa? E, mais importante ainda, como lidamos efetivamente com ele? Tudo será revelado no podcast de hoje, onde falamos sobre como controlar o aumento do âmbito do projeto.

Este podcast é-lhe apresentado pela Clarizen, líder em projetos empresariais e software de gestão de projetos.

Saiba mais em clarizen.com

Hoje estou com Suze Hayworth. A Suze é uma das nossas especialistas residentes em DPM no Digital Project Manager e trabalha como gestora sénior de projetos digitais freelancer em Londres, no Reino Unido. Tem mais de 10 anos de experiência a trabalhar em agências e já passou por muitos casos de aumento do âmbito, por isso é uma excelente pessoa para conversar connosco hoje. Suze, bem-vinda.

Suze Hayworth:

Olá, Ben.

Ben Aston:

Então, Suze, estivemos a conversar antes de começar a gravação. Pode falar-nos um pouco sobre o tipo de projetos em que está a trabalhar atualmente e, sabe, sobre alguns dos desafios que está a enfrentar?

Suze Hayworth:

Sim. Atualmente estou a trabalhar numa agência em Londres como freelancer, por isso estou dividida entre uma função de gestora sénior de projetos e uma função de diretora de projetos, em duas contas. Numa delas trabalho para a IKEA, uma grande empresa de retalho e comércio eletrónico. Estamos a desenvolver um sistema de design para eles, uma espécie de protótipo de sistema de design. Também estou a trabalhar com outro retalhista de comércio eletrónico no Reino Unido. Portanto, neste momento tenho muitos projetos de retalho. Quanto aos desafios, penso que é sempre difícil falar sobre eles, especialmente quando estão a acontecer. Sim, penso que...

Ben Aston:

É aquele cliente incómodo?

Suze Hayworth:

Sim. Não, na verdade. São mesmo muito bons, tenho de dizer isto.

Ben Aston:

Tem de o dizer.

Suze Hayworth:

É verdade. É verdade. São clientes muito bons com quem estou a trabalhar neste momento. Penso que é, quer dizer, este é o lado bom e o lado mau dos projetos e de ser gestor de projetos em geral: trabalhar com pessoas. É ótimo. Gosto muito de trabalhar com pessoas, com personalidades e particularidades diferentes. Mas, por vezes, chega-se a um ponto em que ficamos um pouco frustrados por tentar obter resultados de pessoas que não querem fazer determinadas coisas. Por isso, acho que passei um pouco por isso recentemente.

Ben Aston:

Diversão e jogos. Então, fale-nos do projeto de criação de um sistema de design, porque penso que é um projeto interessante e, na verdade, é o tipo de projeto que vemos cada vez mais. Antes, talvez todos gostassem de tratar cada projeto como um caso único e, sabe, os criativos queriam ser criativos. Explique-nos então: o que é um sistema de design? Em que consiste realmente o projeto em que está a trabalhar? E como o estão a implementar?

Suze Hayworth:

Sim, é realmente muito interessante porque, como disse, os sistemas de design estão a ganhar cada vez mais importância no mundo digital. Basicamente, são uma espécie de biblioteca de estilos para o design digital de empresas e marcas. Definem uma base de componentes de design, módulos e modelos que qualquer designer ou programador que trabalhe com a marca pode utilizar para desenvolver os seus próprios designs e código. Funcionam como uma base: definem o design de referência e promovem a eficiência, através de código e designs reutilizáveis, bem como a eficiência e a consistência dentro da empresa.

Por exemplo, uma empresa como a IKEA é uma marca enorme e tem muitas agências, pessoas e organizações diferentes a trabalhar para si. Esse sistema de design pode estabelecer um padrão com o qual designers e programadores podem trabalhar. Assim, um botão numa página, uma chamada à ação, pode ser consistente em várias plataformas, dispositivos, aplicações e outros elementos, independentemente das propriedades utilizadas.

Ben Aston:

Explique-me o processo de gestão de um projeto destes. Pode ser um projeto do tipo “quanto mede um pedaço de fio”? Como é que funciona? Por onde começaram? Em que estão a iterar? Onde termina o produto?

Suze Hayworth:

No caso da IKEA, muitas marcas desenvolvem isto internamente. A IKEA procurou apoio externo e ajuda para este projeto e para nos envolver no design. Penso que foi uma decisão muito inteligente, porque podemos entrar como elementos externos e analisar as coisas com uma perspetiva menos condicionada pela empresa. Começámos por analisar conceptualmente os princípios, os princípios digitais fundamentais e o conceito por trás do design e dos princípios de design da marca IKEA. Essa foi a configuração inicial: uma análise mais estratégica de toda a experiência e dos princípios de design. Depois começámos a trabalhar mais concretamente nos designs, estabelecendo um design de base a partir dos elementos fundamentais existentes. São coisas como a cor, a tipografia e as grelhas, que depois desenvolvemos.

Fizemos alguns testes com utilizadores, utilizando esse design em várias plataformas escolhidas entre as propriedades da IKEA. Depois avançámos para o design e desenvolvimento de componentes específicos, alojando-os em sites de sistemas de design, que neste momento são apenas internos. Estamos a criar inicialmente um protótipo versátil para pôr tudo a funcionar e, quando terminarmos esta fase, desenvolveremos uma solução completa.

Ben Aston:

E como será essa solução completa? Será uma espécie de guia de estilos vivo e dinâmico, com excertos de código que as pessoas podem simplesmente copiar? Ou modelos que podem utilizar?

Suze Hayworth:

Sim, penso que qualquer projeto de sistema de design precisa de ser contínuo e estar em constante evolução. Não tem um fim definido. Não é um produto que se conclui e fica terminado. Tem de continuar a ser desenvolvido. Nós começámos agora e apenas arranhámos a superfície em termos de princípios iniciais, fundamentos e componentes. A partir daí, agrupam-se os componentes, desenvolvem-se módulos e criam-se também modelos. Depois é necessário perceber como levar as pessoas a utilizar o sistema, divulgá-lo e integrá-lo na organização. É um projeto enorme, especialmente devido à quantidade de intervenientes diferentes na empresa. Por isso, apesar de já estarmos a trabalhar nele há quase um ano, estamos praticamente ainda a começar.

Ben Aston:

Parece divertido. Tenho sempre curiosidade em saber se as pessoas encontraram recentemente alguma ferramenta ou o que está a tornar a sua vida melhor neste momento. Há alguma coisa que tenha descoberto? Algo que tenha lido? O que descobriu recentemente que outras pessoas deveriam conhecer?

Suze Hayworth:

Não tenho utilizado muitas ferramentas diferentes recentemente, para ser sincera. Continuo a utilizar aquilo que conheço. Mas isto é bastante irónico, considerando que estou num podcast: tenho ouvido mais podcasts ultimamente. Normalmente ouço música no caminho para o trabalho, durante uma hora de viagem, mas recentemente tenho ouvido vários podcasts. Tem sido muito bom porque é outra forma de aprender e de aproveitar o tempo enquanto estou de pé no comboio para o trabalho. Ia dizer sentada, mas nunca consigo lugar. Assim, tenho aproveitado esse tempo de forma bastante útil.

Ben Aston:

Há algum podcast que tenha considerado particularmente útil ou interessante?

Suze Hayworth:

Tenho de dizer que o podcast do Digital Project Manager, sem dúvida. Isso era garantido. Também ouvi recentemente um podcast do Drunken... Depois da minha sessão no DPM Summit, falei com ele sobre o tema da sessão. O Bureau of Digitalists, no DPM Summit, também tem alguns bons podcasts. E o Brett, que organiza o evento, publicou recentemente um chamado Sprints and Milestones, baseado no seu livro sobre gestão de projetos digitais, que é um recurso bastante útil.

Ben Aston:

Muito bem. Comecem então a ouvir podcasts. Uma coisa que achei muito interessante — não sei se já ouviu falar — chama-se Blinkist. Tenho de ser honesto: não ouço muitos podcasts, se é que ouço algum, para além do meu, onde sou eu quem fala. Mas costumo pensar que deveria ler determinado livro e depois compro-o e nunca chego a lê-lo, ou nem sequer o compro. O Blinkist tem esta coisa em que apresenta resumos muito condensados de livros. É uma espécie de...

Suze Hayworth:

Acho que já ouvi falar, sim.

Ben Aston:

Basicamente, demora cerca de 15 minutos a ler, ou pode ouvir o resumo. Alguém lê os pontos principais do livro. É uma espécie de podcast e o melhor é que também pode acelerar a reprodução. Pode ouvi-lo à velocidade normal ou a dobrar a velocidade. Assim, demora sete minutos e meio a ler ou ouvir um livro.

Suze Hayworth:

Isso é fantástico. Tenho de experimentar, porque também tenho tentado ler mais. Seria bom conseguir encaixar mais livros.

Ben Aston:

Essa é a minha dica para ler mais livros: Blinkist. Muito bem. Hoje deveríamos falar sobre o aumento do âmbito. Por isso, vamos falar sobre o aumento do âmbito. Para quem não conhece o conceito, o que é e porque devemos preocupar-nos com ele?

Suze Hayworth:

É basicamente quando o âmbito — ou seja, os seus resultados, tudo aquilo que foi acordado e as funcionalidades de um projeto — se expande ou cresce relativamente ao que foi acordado inicialmente. Isto acontece sem que o tempo adicional seja contabilizado. Um projeto pode ser afetado de várias formas, mas trata-se essencialmente de situações que começam a entrar ou a infiltrar-se e que acabam por prolongar o tempo e fazer com que outras tarefas se atrasem.

Ben Aston:

É trabalho adicional que não tínhamos previsto e que terá impacto no nosso orçamento, no nosso calendário e, obviamente, no âmbito, isto é, na quantidade de trabalho que estamos a realizar. Há muitas razões para isto acontecer. Somos muito bons a criar trabalho para nós próprios. No artigo que escreveu, não vamos abordar todas as causas, porque existem muitas.

Suze Hayworth:

Sim, existem muitas.

Ben Aston:

Quais diria que são as mais comuns? E depois podemos falar das mais sorrateiras.

Suze Hayworth:

As mais comuns que tenho observado começam por não sermos claros sobre o âmbito desde o início. Quando definimos os resultados e redigimos uma declaração de trabalho no início de um projeto, se formos demasiado vagos ou pouco rigorosos na forma como descrevemos as coisas, ou se não tivermos uma definição suficientemente precisa daquilo que estamos realmente a entregar, isso pode voltar a surgir mais tarde. O cliente ou até as pessoas internamente podem interpretar a mesma descrição de formas muito diferentes. E o projeto começa a crescer com base numa definição inicial pouco clara dos resultados.

Por isso, penso que a primeira coisa é definir claramente o âmbito desde o início e garantir que quem o aprova compreende perfeitamente o que vai receber. Uma declaração de trabalho é ótima para apresentar todos os resultados e tudo o que será feito no projeto, mas normalmente é um documento longo. Entregamo-lo ao cliente e esperamos que o leia, compreenda e assimile tudo. É muito importante destacar e explicar explicitamente os pontos essenciais, o que o cliente receberá, os prazos e o orçamento. Mesmo que pense que ele leu o documento, é importante analisar o âmbito inicial numa reunião e garantir que compreende o que vai receber.

Já vi muitos problemas acontecerem quando uma declaração de trabalho é aprovada e, mais tarde, alguém diz: “Mas eu pensei que ia receber isso”, apesar de isso poder estar descrito de forma mais explícita no documento.

Ben Aston:

Portanto, não sermos claros desde o início. Podemos dizer: “Sim, cliente, vamos criar um modelo de página para si”, mas não definimos totalmente o que entra nesse modelo. Muitas vezes, o desafio é precisamente o que mencionou: não somos claros ou não comunicamos ao cliente o que queremos dizer com “modelo”.

Suze Hayworth:

Exatamente. São duas coisas: definir e compreender claramente os resultados desde o início e garantir que quem aprova o âmbito compreende realmente aquilo que foi dito. Mesmo que sejamos bastante explícitos, essa pessoa pode continuar a ter uma ideia diferente daquilo que vai receber, algo que nem sequer foi incluído no âmbito.

Ben Aston:

Esses são, portanto, os casos típicos: não sermos claros e o cliente não compreender. Provavelmente são as duas situações mais comuns que causam o aumento do âmbito.

Mas e o lado mais sorrateiro? Qual foi o aumento do âmbito mais invulgar ou aquele que aconteceu sem que desse por isso? Como é que isso acontece, com base na sua experiência?

Suze Hayworth:

A forma típica como os gestores de projeto encaram o aumento do âmbito é pensar que vem do cliente: o cliente pede outra coisa, prolonga algo ou quer mais qualquer coisa. Mas também já vi isso acontecer com equipas internas e intervenientes internos. Se os membros da equipa não tiverem uma compreensão clara daquilo que estão a fazer, podem seguir direções diferentes e, sem se aperceberem, prolongar os prazos ou aumentar a funcionalidade. Um designer pode desenhar algo sem pensar devidamente no impacto que isso terá no âmbito de desenvolvimento. Pode fazê-lo sem intenção ou pode ter uma agenda própria e querer acrescentar algo ao que está a ser criado.

É provavelmente mais surpreendente quando vem de dentro, porque queremos que todos estejam alinhados, mas pode acontecer. Também pode resultar de necessidades da empresa introduzidas por outros intervenientes internos. Estes podem querer que entreguemos mais para preservar a relação com o cliente ou podem ter concordado com coisas de que não tínhamos conhecimento. Esse é outro caso clássico.

Ben Aston:

Concordo totalmente. Uma das causas mais sorrateiras do aumento do âmbito é quando vem de dentro, através do chamado aperfeiçoamento excessivo. As nossas equipas internas tentam acrescentar elementos ao trabalho, muitas vezes em estratégia, experiência do utilizador e design, embora também possa acontecer no desenvolvimento. Alguém quer fazer um trabalho extraordinário e pensa: “Podemos transformar isto numa peça de apresentação ou num projeto para submeter a prémios”, mas ninguém discutiu quem paga o trabalho adicional ou quem assume a responsabilidade por ele.

Suze Hayworth:

Exatamente.

Ben Aston:

As pessoas seguem o seu próprio caminho e criam a sua própria interpretação daquilo que lhes pedimos. Outro ponto que quero abordar, e que mencionou no artigo, é o controlo de qualidade. Quando estamos nessa fase, talvez não tenhamos definido completamente os critérios de aceitação ao escrever a história de utilizador. Ou talvez não tenhamos dito à equipa de controlo de qualidade: “Não se preocupem em testar no IE9; já não nos interessa”. A equipa pode responder que existem sempre erros no IE9 e que deve testá-lo. Pode descobrir que estão a testar num BlackBerry ou em qualquer outro dispositivo aleatório. De repente, não só passam muito tempo a testar coisas que não nos interessam, como também os programadores tentam corrigir problemas que não precisam de ser corrigidos. Isso também lhe acontece?

Suze Hayworth:

Completamente. O controlo de qualidade é uma das grandes áreas de um projeto, sobretudo nos projetos maiores, em que conseguimos estimar aproximadamente o esforço no início, com base no que sabemos sobre o período de desenvolvimento. Mas é muito difícil estimar a quantidade de trabalho de controlo de qualidade, incluindo o número de alterações e novos testes necessários. Isto pode aumentar sucessivamente, sobretudo se não definirmos os parâmetros desde o início. É necessário estabelecer os critérios de aceitação, avaliar a matriz de navegadores e dispositivos e definir as prioridades dos erros e problemas encontrados. Quais têm de ser corrigidos para podermos publicar? Quais são prioritários? Quais têm prioridade mais baixa e podem ser publicados sem serem resolvidos? Talvez sejam apenas alterações visuais ou de design.

Mais uma vez, trata-se de definir o âmbito fundamental das coisas tanto quanto possível e reduzir a incerteza desde o início. Mas também é essencial manter a comunicação aberta ao longo de todo o projeto. Se, durante o controlo de qualidade, verificarmos que está a ser gasto mais tempo num determinado dispositivo ou navegador, é importante comunicar isso rapidamente ao cliente ou ao interveniente.

Podemos explicar que, por exemplo, o IE está a exigir muito mais tempo de controlo de qualidade e sugerir alternativas. Podemos dizer que temos vários navegadores e dispositivos a cobrir, que o IE é importante devido à dimensão da base de utilizadores e que devemos dar-lhe prioridade, tratando os restantes navegadores de acordo com a respetiva importância. É importante identificar rapidamente qualquer problema em que o âmbito esteja a aumentar e apresentar soluções alternativas.

Ben Aston:

Falámos de algumas causas: âmbito pouco claro, decisões autónomas e controlo de qualidade. De quem é a culpa? Para lidar com o problema, ajuda identificar quem é responsável — não para apontar o dedo, mas para perceber como o resolver. Falámos do cliente, que pede mais coisas, talvez porque não compreendeu claramente o que íamos entregar. Falámos dos intervenientes internos e das equipas que acrescentam trabalho.

No seu artigo menciona também terceiros, utilizadores e nós, enquanto gestores de projeto. Até que ponto isto é um problema nosso? É um problema nosso ou de todos os outros?

Suze Hayworth:

Não se trata de culpar alguém pelo aumento do âmbito, mas de identificar os riscos. Em vez de procurarmos quem pode causar o problema, devemos avaliar o que cada pessoa pode fazer e utilizar essa análise para identificar os riscos desde o início.

No nosso caso, tendemos a olhar para fora e pensar no que a equipa pode fazer, no cliente e noutras causas. Mas, pessoalmente, também podemos falhar por não sinalizar ou destacar as situações quando acontecem. Às vezes tentamos resolver um problema e escondê-lo, porque não queremos estar constantemente a apresentar problemas ao cliente ou a expor uma perspetiva negativa do projeto.

Queremos manter o projeto em andamento, cumprir os prazos e entregar as coisas. Por isso, dizemos a nós próprios que podemos compensar aquilo aqui ou ali, sem revelar a situação ao cliente. Penso que esta é uma área importante em que podemos melhorar.

É muito mais fácil ter uma conversa quando somos honestos e transparentes e levantamos rapidamente uma questão. Podemos analisá-la e apresentar soluções. Não devemos apenas dizer que existe um problema e depois ficar sem saber o que fazer. Primeiro reconhecemos o problema, percebemos qual é a sua origem e depois apresentamos ao cliente várias soluções alternativas.

Se o aumento do âmbito tiver origem interna, podemos perceber como reduzi-lo, mas devemos informar o cliente de que aconteceu. Se o cliente pedir algo que exceda o que foi acordado, não devemos simplesmente absorver esse pedido. Devemos analisar o impacto, preparar algumas opções e discutir com o cliente o que pode ser despriorizado.

Ben Aston:

Saltámos para a forma de lidar com o problema.

Suze Hayworth:

Desculpe.

Ben Aston:

Não faz mal. Quando percebemos que existe aumento do âmbito, é exatamente disso que estamos a falar: como lidar com ele. Enquanto gestores de projeto, também podemos ser mais claros sobre o âmbito. Podemos pedir a outro gestor de projeto que reveja o documento. A equipa de controlo de qualidade e os analistas de negócio são excelentes a encontrar lacunas e a perguntar se pensámos em determinado aspeto ou se definimos algo suficientemente bem.

Também devemos melhorar a comunicação. Não devemos simplesmente enviar uma declaração de trabalho para o outro lado e esperar que o cliente a assine. É muito mais útil analisá-la em conjunto com o cliente e garantir que todos compreendem o que está a ser acordado.

Também é importante não esconder o problema. Enquanto gestores de projeto que lidam diretamente com clientes, podemos sentir a tentação de não o abordar para preservar a relação. Mas se não formos transparentes desde o início, o problema pode tornar-se demasiado grande. Ser proativo, transparente, analisar os impactos e definir prioridades é essencial.

O aumento do âmbito é frequentemente associado a projetos em cascata, nos quais se planeia muito no início e depois se executa fase a fase. Mas também é um problema em projetos ágeis? Como se manifesta num projeto ágil, mais iterativo e aparentemente mais flexível?

Suze Hayworth:

Era precisamente isso que eu queria transmitir no artigo. Vemos o aumento do âmbito como algo negativo porque tentamos manter um âmbito fixo e acordado e resistimos a qualquer alteração. O que é positivo no desenvolvimento ágil e na utilização de metodologias ágeis é que estas incentivam a mudança. É um dos princípios fundamentais do ágil. A mudança pode criar um produto ou serviço melhor. Permitir alterações pode ser algo positivo.

A mudança não deve ser vista como inimiga. É muitas vezes algo bom. O importante é a forma como lidamos com ela.

Num projeto baseado em Scrum, por exemplo, continuamos a acordar o trabalho para um período limitado, o sprint. Definimos o que entra no backlog. O proprietário do produto ou o cliente pode tentar acrescentar algo ao backlog durante um sprint, quando este já foi planeado e acordado. Isso pode afetar o que será entregue e o lançamento.

É necessário garantir que aquilo que é introduzido não seja simplesmente acrescentado a tudo o resto. Devemos reavaliar as prioridades e garantir que o esforço das histórias ou épicos introduzidos é compensado pela despriorização de outra coisa. Isto também acontece em projetos ágeis, mas os períodos mais curtos permitem lidar melhor com as alterações.

Ben Aston:

Gosto dessa mudança de perspetiva e da ideia de aceitar a mudança. Quando falamos de aumento do âmbito, a conversa é muitas vezes negativa porque normalmente significa custos adicionais. Temos de dizer ao cliente que está a pedir algo que não estava planeado e que isso exige mais tempo e orçamento.

Mas um diálogo contínuo e transparente com o cliente sobre o orçamento e as limitações permite definir prioridades em conjunto. Talvez o cliente não obtenha uma funcionalidade que imaginava receber inicialmente, mas, durante o projeto, identificámos algo mais importante. Essa pode ser uma boa mudança, benéfica para os utilizadores e para o projeto. A prioridade deve ser discutida ao longo de todo o projeto e não apenas no último momento, quando somos obrigados a dizer ao cliente que precisa de pagar mais ou que não pode ter determinada funcionalidade.

Suze Hayworth:

Concordo completamente. É muito importante conversar continuamente sobre aquilo que estamos a entregar, porque o objetivo deve ser perceber o que será mais benéfico para os utilizadores finais. Se o cliente pedir algo novo, não devemos pensar imediatamente que é impossível porque o plano já está definido. Devemos perguntar qual é o benefício para os utilizadores, porque surgiu o pedido e se estamos a responder a uma nova necessidade.

Se o pedido for válido e for realmente mais útil para os utilizadores, devemos compará-lo com outros resultados e perceber se é possível despriorizar algo menos importante. É fundamental manter o cliente envolvido, analisar os novos pedidos e compreender o benefício final de cada um.

Ben Aston:

É um excelente conselho: transformar o assunto numa conversa e pensar no utilizador. O aumento do âmbito não tem necessariamente de ser negativo. Pode ser bom para os utilizadores, para o cliente, para o projeto e para as equipas. Não é algo de que tenhamos obrigatoriamente de fugir ou ter medo. Aceitá-lo pode ser uma abordagem muito sólida.

Mas para quem pensa que todos os seus projetos acabam acima do orçamento, atrasados e com enormes problemas de aumento do âmbito — especialmente gestores de projeto que estão a começar — qual seria a primeira dica para recuperar o controlo?

Suze Hayworth:

Se vai entrar num projeto novo, que está a começar, a melhor coisa em que pode trabalhar é a estimativa e a forma como define o âmbito desse projeto. Não deve trabalhar isoladamente. Faça as estimativas com a equipa e certifique-se de que são tão boas quanto possível, tendo sempre presente que são estimativas. Assim, quando começar a entregar o que foi definido, não verá de repente os prazos e o orçamento a fugirem ao controlo.

Se entrar num projeto já em curso, faça um balanço da situação. Perceba quanto já foi ultrapassado, obtenha uma visão precisa do trabalho que falta e converse com o cliente sobre os problemas. Explique onde existem desvios e sinalize-os, mantendo uma comunicação aberta.

Ben Aston:

Muito bem. Suze, muito obrigado por se juntar a nós. Foi ótimo tê-la connosco. Como uma das nossas especialistas em DPM, a Suze também participará no nosso próximo curso, que começa em fevereiro. Chama-se “Dominar a gestão de projetos digitais”. Se não sabe do que estou a falar, mas sabe que precisa de formação em gestão de projetos, consulte-o. É um curso intensivo de sete semanas que inclui aulas de vídeo interativas, trabalhos, seminários online, discussões de grupo e a possibilidade de sessões de acompanhamento. Aceda a DPMschool.com e inscreva-se antes de as vagas esgotarem. Se quiser contribuir para esta conversa sobre o aumento do âmbito, comente a publicação e visite a secção de recursos de TheDigitalProjectManager.com para aderir à nossa equipa no Slack, onde encontrará todo o tipo de conversas interessantes. Até à próxima, obrigado por nos ouvir.