Utilize Declarações de Âmbito do Projeto para se Salvar (com Robyn Birkedal)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros de digitação, uma vez que o sistema automático não está correto 100% das vezes.

Ben Aston:

Está nervoso, a segurar o telefone, coberto de suor frio. O cliente está furioso. Está ao telefone, a ameaçar cancelar o projeto e não pagar pelo trabalho. E, até agora, tudo estava a correr tão bem. Estavam completamente tranquilos, e você também. Queriam que o site fosse reformulado. Parecia simples. E você nem se deu ao trabalho de escrever nada, porque... bem, parecia que todos tinham percebido. Todos estavam tranquilos e agora já não estão. O que eles pensavam que iam receber era, na realidade, uma reformulação da marca além daquele site reformulado. Agora está com o estômago às voltas porque sabe que estragou tudo. Nada ficou escrito. E a palavra deles está contra a sua. Neste momento, estou stressado só de dizer isto. Por isso, se quiser muito menos stress, continue a ouvir este podcast para descobrir por que razão as declarações de âmbito são tão importantes, como escrevê-las e como utilizá-las no seu projeto.

Obrigado por nos ouvir. Sou Ben Aston, fundador do The Digital Project Manager. Bem-vindo ao podcast do DPM. Temos como missão ajudar os gestores de projetos a ter sucesso e ajudar as pessoas que gerem projetos a entregá-los melhor. Estamos aqui para o ajudar a levar a gestão dos seus projetos para o nível seguinte. Visite thedigitalprojectmanager.com para saber mais sobre a formação e os recursos que disponibilizamos através da adesão. Este podcast é-lhe apresentado pela Clarizen, líder em software empresarial de gestão de projetos e portefólios. Visite Clarizen.com para saber mais.

Hoje estou acompanhado pela Robyn. A Robyn é uma das nossas especialistas residentes do DPM. E, convenientemente, vive mesmo perto de mim. Gosta de emojis, de fazer listas e de cachorros. Foi chef e tornou-se gestora de projetos, com mais de 10 anos de experiência em gestão de projetos em agências e startups. Em breve estará também mais disponível para aceitar trabalho como prestadora de serviços. Por isso, se estiver à procura de uma gestora de projetos contratada, procure-a no LinkedIn. Robyn, muito obrigado por se juntar a nós hoje.

Robyn Birkedal:

Olá, Ben. É sempre bom estar consigo.

Ben Aston:

Quero começar por voltar à questão das listas e dos cachorros. Já fez a lista de hoje?

Robyn Birkedal:

Fiz. Na verdade, e isto é tão típico de mim, tenho uma lista com os principais objetivos de hoje. Tenho outra lista no meu planeador. E também tenho o meu Google Calendar. Portanto, aparentemente, preciso de três listas diferentes em qualquer momento. E aquilo que não consegue ver atrás de mim é a minha parede de notas autocolantes.

Ben Aston:

É como o arquivo de listas.

Robyn Birkedal:

Coisas em categorias diferentes que estou a tentar alcançar, pessoal e profissionalmente, ou simplesmente ideias de conteúdos diferentes para si.

Ben Aston:

Também tem um cachorro consigo?

Robyn Birkedal:

Tenho o meu cachorro de oito anos. Mas, obviamente, gosto muito mais de cães do que de gatos, e toda a gente pode criticar-me por isso. Ultimamente, os emojis parecem-me menos entusiásticos. Mas acho que essa era a expressão.

Ben Aston:

Eu era assim no ano passado.

Robyn Birkedal:

Não sei.

Ben Aston:

É óbvio que fazer listas é importante para si. Algumas pessoas consideram-nas inspiradoras. Mas tenho curiosidade em saber onde encontra inspiração. O que está a ler? O que está a consumir neste momento para se inspirar e continuar motivada?

Robyn Birkedal:

Ótima pergunta. Sinto que poderia falar durante 30 minutos sobre isto. Obviamente, o The Digital Project Manager é uma fonte constante de inspiração. Fiz uma pequena pausa no meu envolvimento intenso com a comunidade no Slack e, agora que voltei, percebi que tinha saudades de muitos dos meus amigos de lá. Tem sido uma verdadeira alegria. Também encontro inspiração nos meus amigos e na minha comunidade local. Quero destacar um dos grupos comunitários de Portland com que me envolvi ao longo dos anos, chamado PDXWIT, que significa Mulheres de Portland na Tecnologia. Aprecio muito esta comunidade, que organiza eventos de desenvolvimento de competências, mentoria e acesso a empregos. Ensinaram-me muito sobre diversidade e inclusão. Por isso, recomendo vivamente que criem algo semelhante ou que os visitem em pdxwit.org.

Ben Aston:

Isso é excelente. E em que está a tentar melhorar? Todos temos um pouco mais de tempo disponível neste momento. Sinto que estou a ser inundado por cursos, exercício físico e todo o tipo de coisas. Mas, quando pensa no que a inspira, há alguma coisa que esteja particularmente a desenvolver? Um novo passatempo? Está a aprender uma nova linguagem de programação ou a aprofundar algum tema? O que está a fazer?

Robyn Birkedal:

Recentemente, voltei a trabalhar com Drupal, depois de cerca de sete anos, por isso estou a tentar perceber o ponto em que está atualmente. Para além disso, e Ben, conhece-me há anos, isto parece quase um verdadeiro segredo que estou a partilhar consigo em voz alta: estou a pensar obter algumas certificações. Talvez obter a certificação PMP ou fazer algo como a SAFe. Ainda tenho de perceber exatamente o que é, mas estou a explorar a possibilidade de avançar nessa direção e de conhecer melhor essas metodologias, em vez de continuar simplesmente a preocupar-me com elas.

Ben Aston:

Isso é ótimo. Boa sorte. E descobriu recentemente mais alguma coisa que esteja a tornar a sua vida melhor? Pequenas coisas que lhe tragam um sorriso ou um momento de alegria?

Robyn Birkedal:

Isto também é embaraçoso. Não sei por que razão estou tão nervosa hoje, mas tenho gostado muito de trabalhar a partir de casa. Em segundo plano, ponho um canal específico no YouTube TV, ao qual tenho uma subscrição. É um canal dedicado a surf a cem por cento. Como vivo em Portland, demoro uma hora e meia a chegar à praia. Não sou surfista e não sei nada sobre surf, mas tenho gostado muito de ver os campeonatos de surf ambiente em segundo plano. Agora estou obcecada por várias pessoas, como Andy Irons, e pela história de Kelly Slater. Aprendi muito, o que é a coisa mais estranha que recentemente tornou a minha vida melhor.

Ben Aston:

Quem é o seu surfista preferido?

Robyn Birkedal:

Sem dúvida, Kelly Slater.

Ben Aston:

Sabe, ele esteve aqui. Foi uma boa introdução. A minha história mais famosa é que fui surfar com Kelly Slater no Havai.

Robyn Birkedal:

Não pode simplesmente dizer isso e achar que resulta.

Ben Aston:

Estávamos a sair da água e ele estava a entrar com a namorada. Cruzámo-nos e dissemos: Olá, Kelly. Portanto, fomos surfar com ele.

Robyn Birkedal:

Sim, estavam na água ao mesmo tempo.

Ben Aston:

Sim, exatamente.

Robyn Birkedal:

Parece que estavam debaixo de ondas enormes, se estavam ali fora com o Kelly.

Ben Aston:

Pois. Mas voltemos ao tema sério e afastemo-nos da praia para falar das declarações de âmbito. Comecemos pelo motivo. Tentei explicar no início por que razão devemos preocupar-nos com as declarações de âmbito. Os projetos correm mal. Surgem mal-entendidos e as declarações de âmbito podem salvar-nos. Tem histórias assustadoras de situações em que não existiam declarações de âmbito? Falei disso na introdução. Porque é que as declarações de âmbito a entusiasmam?

Robyn Birkedal:

Sem dúvida. Só de ouvir a sua introdução, pensei em como esse trauma voltou e como continuará a voltar. As declarações de âmbito são extremamente importantes porque garantem que a sua equipa e o cliente compreendem claramente quais são os requisitos gerais. Em última análise, vão definir de que forma o projeto pode falhar e como essa situação será gerida. O que estamos a tentar proteger é evitar conflitos com o cliente, com a equipa interna e, além disso, evitar problemas legais.

Ben Aston:

Estamos a tentar clarificar e uniformizar a compreensão tanto quanto possível. E penso que as declarações de âmbito são ótimas para codificar esse entendimento. Às vezes pensamos: estamos todos alinhados, somos todos amigos. Na verdade, pode ser pior quando somos amigos, porque todos assumem que os outros estão a compreender-se. Depois surgem palavras aparentemente inofensivas, como atualizar ou renovar, que são realmente ambíguas. O que as declarações de âmbito fazem é reduzir essa ambiguidade nas zonas cinzentas e tornar as coisas muito mais claras.

Robyn Birkedal:

Sem dúvida. Mesmo nos 10 anos em que trabalhei nesta área, a terminologia muda trimestralmente. Antes de falarmos sobre o que são e como funcionam, quero dizer que escrever uma declaração de âmbito é uma tarefa muito subvalorizada neste trabalho. É a parte mais seca da função e, normalmente, a mais difícil para iniciar um projeto. Ninguém quer assumir a responsabilidade. Mas, pessoalmente, gosto muito de o fazer porque dedicar tempo no início do projeto garante um futuro muito mais eficiente para esse projeto.

Ben Aston:

Falemos então do nível mais básico. Para quem está a pensar: espere, o que é uma declaração de âmbito? Como a descreveria?

Robyn Birkedal:

Existe uma grande variedade de terminologia, como estava a dizer, por exemplo, renovar em vez de reformular. E como é que isso se distingue de uma declaração de trabalho? Uma declaração de âmbito é simplesmente uma forma de descrever o trabalho que se está a comprometer a entregar. Descreve também, nos seus elementos mais fundamentais, as restrições ou limitações do projeto. Falamos sobre o que será entregue, o que não será entregue, os pressupostos sobre o que será entregue e quaisquer esclarecimentos adicionais.

Ben Aston:

A declaração de âmbito serve para descrever e codificar o trabalho. Dizemos: é isto que vamos fazer e é isto que não vamos fazer. E, quando não conseguimos definir exatamente o que vamos ou não vamos fazer, podemos pelo menos descrever o processo que iremos seguir e aquilo que esse processo poderá produzir. Muitas pessoas perguntam se precisam de uma declaração de trabalho ou como será uma declaração de trabalho num projeto ágil. Continuamos a precisar de definir o que vamos e não vamos fazer. Em vez de definir todas as entregas, podemos definir o resultado que queremos alcançar e o processo que vamos seguir para lá chegar.

Robyn Birkedal:

Exatamente. Existem alguns princípios básicos a seguir, e falaremos sobre algumas dicas. Mas não há um único modelo que todos os gestores de projetos digitais devam seguir. Não existe uma única fórmula que todos utilizem e que possa simplesmente ser copiada. Cada empresa é diferente. Cada projeto ou programa é diferente. O que procuramos é consistência para nos protegermos, ou, como escrevi no artigo, para salvarmos o nosso projeto. É preciso proteger a equipa e a iniciativa empresarial.

Ben Aston:

Tem histórias sobre situações em que não definiu as declarações de âmbito de forma tão completa quanto devia e o que aconteceu?

Robyn Birkedal:

Esta é uma questão delicada, porque em funções anteriores fui aconselhada a não incluir demasiados detalhes, pois isso poderia expor-nos a processos judiciais. Se incluirmos demasiada informação, deixamos menos espaço para discutir uma zona cinzenta. No entanto, o maior sucesso que tive foi incluir o máximo de detalhes possível. Quer seja num projeto em cascata ou ágil, defina tudo na declaração e confirme-o com o cliente. Ao longo dos anos, aprendi que nem sempre será perfeito e que o cliente poderá interpretar algo de forma diferente. O importante é navegar esse contexto e dedicar tempo à preparação.

Ben Aston:

A minha história assustadora envolve um grande cliente de eletrónica de consumo. Estávamos a criar algumas animações personalizadas e o cliente queria garantir que tínhamos comprado os direitos. Comprámos os direitos por cinco anos, embora apenas precisássemos das animações durante um ano. Mais tarde, o cliente disse que precisava dos direitos perpetuamente, para utilizar as animações para sempre, em qualquer meio e formato. Só tínhamos comprado os direitos por cinco anos. Isso tornou-se um enorme problema, porque o estúdio de animação sabia que nos podia cobrar qualquer valor. No final, toda a relação com o cliente se desfez devido a uma declaração de âmbito que não definia completamente a duração dos direitos de utilização. Pequenas ambiguidades podem ter consequências enormes.

É por isso que estas questões devem ser levadas muito a sério. Podem afundar o projeto e toda a relação com o cliente. Falemos então sobre como escrever estas declarações de âmbito e sobre o processo que utiliza. Como decide o que incluir e até que ponto deve ser específico?

Robyn Birkedal:

Antes de mais, não sou advogada e não presto aconselhamento jurídico formal. Estou apenas a falar da minha experiência, principalmente na área da publicidade. Em segundo lugar, compreendo perfeitamente o problema dos direitos perpétuos. A diferença entre um ano, cinco anos e perpetuidade é enorme. A lição foi importante. No nosso contexto, as declarações de âmbito podem assumir muitas formas. Podemos chamar-lhes estimativas, declarações de trabalho, contratos ou propostas. São essencialmente um conjunto de elementos que podem existir em formatos diferentes. Já utilizei declarações de trabalho, contratos e propostas. No entanto, não são um NDA, MSA, ICA ou SLA. Pode saber mais sobre essas definições no meu artigo. A declaração de âmbito não é a única coisa que deve fornecer ao cliente; é apenas um componente.

Ben Aston:

Sem dúvida.

Robyn Birkedal:

Voltando à sua pergunta, como escrevo uma declaração de âmbito? Qual é o meu processo?

Ben Aston:

Sim.

Robyn Birkedal:

Existem várias abordagens. Normalmente utilizo modelos fornecidos pela equipa interna. Tive a sorte de trabalhar em locais que já tinham modelos disponíveis. Também guardo versões de declarações de trabalho anteriores numa pasta pessoal, para poder consultar como estruturei uma declaração para um projeto de marca, digital, renovação ou reformulação. O The Digital Project Manager também é um excelente recurso. Sei que escreveu um ótimo artigo sobre como escrever uma declaração de trabalho, que inclui um modelo.

Ben Aston:

É muito importante criar o seu próprio banco de declarações de âmbito que possa reduzir, reutilizar e reciclar. Quando falamos sobre a entrega de trabalho, normalmente descrevemos parâmetros semelhantes: num projeto de reformulação da marca, quantos conceitos vamos desenvolver, quantas rondas de revisão teremos, como será a interação com o cliente e o ciclo de feedback e quais serão as entregas finais. Se produzirmos o mesmo tipo de entregas repetidamente e seguirmos o mesmo processo, as declarações podem ser facilmente reutilizadas.

No artigo, em thedigitalprojectmanager.com/project-scope-statement, encontrará várias declarações de âmbito. Algumas são genéricas e podem ser reutilizadas nos seus próprios projetos, alterando apenas os nomes. Outras são mais específicas. Também existem declarações reutilizáveis sobre quem pagará ou será responsável pelo licenciamento de imagens ou vídeos, o prazo para o cliente aprovar um trabalho ou enviar feedback consolidado e o número de rondas de aprovação.

Falemos então sobre declarações de âmbito boas e más. Podemos pensar num contínuo entre uma declaração pouco rigorosa e uma declaração muito específica. Não é necessariamente uma questão de bom ou mau, mas o que torna uma declaração de âmbito boa ou má?

Robyn Birkedal:

É uma pergunta ampla. Poderíamos passar horas a falar sobre isso. Recomendo que utilize o seu banco de declarações anteriores e consulte colegas ou amigos para saber se têm algo semelhante que tenha sido eficaz. Não precisa de começar sempre do zero. Apoie-se na comunidade do DPM. Mas posso partilhar cinco coisas que pode fazer para se proteger.

Ben Aston:

Força.

Robyn Birkedal:

Isto baseia-se apenas na minha experiência. Em primeiro lugar, defina o motivo. Normalmente chamo a esta parte a visão geral, porque soa um pouco mais formal. É a primeira secção, onde se define o trabalho, por que razão o projeto ou programa existe, por que está a acontecer e o que irá alcançar. Pode pedir ao gestor de conta para preparar esta parte e validá-la com o cliente, de modo a obter os indicadores-chave de desempenho. Não é necessário narrar tudo. Mantenha-a curta e concisa. Precisamos apenas de enquadrar o trabalho e definir a proposta de valor que irá explicar o resto.

Ben Aston:

Começar pelo motivo é importante porque, se tudo o resto falhar, esse motivo é a nossa salvaguarda. Se conseguirmos demonstrar que aquilo que entregámos cumpre a intenção original, temos uma base sólida. Se o objetivo era aumentar o número de subscritores, o cliente pode não gostar da execução, mas, se conseguirmos provar que o número de subscritores aumentou, temos um resultado comum para avaliar.

Robyn Birkedal:

Isso funciona em todas as metodologias de projeto. É sempre necessário saber por que razão estamos a avançar. Também é útil colocar o motivo no topo do canal do Slack ou na documentação da equipa, para alinhar todos. A segunda dica é definir o processo de aprovação. Pode parecer básico, mas é aqui que muitas coisas se complicam. Inclua linguagem que explique o processo de aprovação das entregas: quando deve o cliente enviar feedback, quem o fornece e como deve ser entregue? Fale verbalmente sobre o feedback e o processo de aprovação com o cliente, mas registe tudo por escrito na declaração.

Ben Aston:

Exatamente.

Robyn Birkedal:

A terceira dica é identificar o que será efetivamente entregue. Normalmente, esta será a maior parte da declaração de âmbito. Pode ser muito detalhada num projeto em cascata ou mais orientada para o processo numa abordagem ágil. Deve indicar exatamente o que as pessoas vão receber, quando o vão receber e como o vão receber. Recomendo ser detalhado relativamente às rondas de revisão, introdução de conteúdos, migração, alojamento, configuração, garantia de qualidade, direitos de imagem e implementação final.

Ben Aston:

Também acredito que, se conseguirmos definir algo, devemos defini-lo. Se não soubermos exatamente o que vamos entregar, podemos adotar uma abordagem conservadora. Digamos que sabemos que vamos entregar pelo menos dois conceitos: definamos dois. Se achamos que podemos desenvolver até cinco componentes numa página, definamos cinco e acordemos cinco, mesmo que talvez sejam seis ou sete. Esta abordagem ajuda a encontrar uma base comum, evita compromissos excessivos e permite surpreender positivamente o cliente.

Robyn Birkedal:

Isso também ajuda a controlar o trabalho interno da equipa. O designer, o programador ou o estratega podem ter opiniões diferentes sobre a carga de trabalho. Ao ter essas conversas de descoberta antecipadamente, conseguimos reduzir essa instabilidade interna, não apenas gerir o cliente. A quarta dica é definir o que está incluído e o que não está incluído. Normalmente coloco isto numa secção separada das entregas. Depois de identificar, por exemplo, que o cliente receberá três módulos, incluo uma lista detalhada para proteger o que sei e o que não sei.

Gosto de chamar a esta secção dependências e pressupostos. É aqui que se explicam questões como o feedback escrito, quem o deve fornecer e o que acontece se existirem várias implementações. Se o cliente adiar a data de implementação, deve ser emitida uma alteração ao pedido, porque isso exigirá tempo adicional e a reorganização dos recursos da equipa.

Também gosto da secção chamada declarações de exclusão, ou fora do âmbito. Inclui tudo aquilo que o cliente poderá pedir, mas que não está a ser fornecido. Pode abranger documentação de formação, alojamento, custos de fontes, guias de estilo digitais ou direitos de imagem perpétuos. O objetivo é deixar claro que não é responsável por fornecer esses elementos se eles não tiverem sido acordados.

Ben Aston:

É precisamente nesses mal-entendidos que surgem problemas. Estas também podem ser chamadas declarações de âmbito negativo. É uma lista de tudo aquilo que definitivamente não será feito. Se o cliente disser que quer reformular o site e também renovar a marca, mas o orçamento não incluir uma reformulação completa da marca, deve incluir uma declaração que diga claramente que não será realizado qualquer trabalho de reformulação da marca.

Ao antecipar as possíveis interpretações do cliente, reveja todas as conversas que tiveram e inclua na lista as ideias ou pedidos que possam ter sido mencionados, mas que não fazem parte do projeto.

Robyn Birkedal:

Gosto dessa abordagem. Não existe uma única forma correta de fazer isto. É uma questão de confiar no seu instinto e listar todas as formas como as coisas podem correr mal. Alguns gestores disseram-me que estava a catastrofizar demasiado. Para mim, mapear o que pode correr mal e resumir de forma concisa ajuda a mitigar o risco desde o início.

A quinta e última dica é criar uma matriz de declaração de âmbito. Percebi que, no passado, passei horas num projeto ativo a consultar versões de documentos, ficheiros, Slack, emails, ficheiros de design e código para perceber exatamente o que tinha sido acordado. Aprendi que posso fazer esse trabalho antecipadamente e acompanhar as entregas, para que exista uma compreensão clara de como estamos a executar a declaração.

Ben Aston:

A ideia é transformar a declaração de trabalho num documento relevante durante todo o projeto, e não numa coisa utilizada apenas uma vez. Ao colocar as entregas numa matriz e acompanhá-las, podemos lembrar ao cliente ou às partes interessadas que estamos a levar o documento a sério e que o estamos a utilizar para acompanhar o trabalho.

Robyn Birkedal:

Correto. Nem sempre partilho estas matrizes diretamente com o cliente. Por vezes, mantenho-as na estrutura interna de ficheiros do projeto. Mas posso utilizá-las quando surge um conflito, porque tenho todos os recursos necessários para resolver rapidamente o problema, sem passar horas a investigar.

Ben Aston:

Tudo isto parece simples. Se seguir estas dicas, tudo correrá maravilhosamente bem, certo? Ou não? Quais foram os maiores desafios que enfrentou e onde é que as declarações de âmbito falham?

Robyn Birkedal:

As coisas não funcionam quando tentamos seguir as regras de forma rígida, sem adaptar a abordagem a cada projeto. Há alguns anos, eu pensava que existia um modelo e que devia segui-lo sempre. Precisamos de ser mais flexíveis, porque os clientes estão em níveis diferentes e têm formas diferentes de abordar o trabalho. Ao longo dos anos, tornei-me mais flexível na forma de abordar cada projeto, mas também mais rigorosa relativamente àquilo que realmente estamos a aceitar fazer.

Ben Aston:

Um dos maiores desafios é decidir até que ponto devemos ser definitivos. Quando começamos um projeto e ainda não temos a certeza do que vamos entregar, podemos exagerar e afirmar que vamos entregar determinadas coisas. Depois da fase de descoberta ou de design, podemos perceber que uma parte do projeto é desnecessária ou demasiado cara. Por isso, é importante considerar o horizonte de planeamento. Pode escrever declarações para fases realistas do projeto, em vez de tentar definir tudo de uma só vez.

Robyn Birkedal:

Outro desafio ocorre quando obtemos a aprovação da declaração de âmbito pelo cliente, mas nem todas as partes interessadas participaram. Isso pode prejudicar muito o projeto. Uma apresentação verbal e uma sessão de alinhamento são muito úteis.

Ben Aston:

O acompanhamento verbal é importante porque não queremos que os clientes assinem algo que não leram ou compreenderam. Queremos que compreendam aquilo a que se comprometeram. A declaração de âmbito não deve ser um documento jurídico criado para levar alguém a tribunal. Deve facilitar uma conversa e alinhar expectativas. Não estamos a tentar enganar o cliente; estamos a tentar garantir que todos estão na mesma página e que ficam satisfeitos com o resultado.

Robyn Birkedal:

Não há nada melhor do que poder copiar e colar uma declaração de âmbito num documento juridicamente vinculativo e saber que todas as partes estão alinhadas, tanto o cliente como a equipa interna.

Ben Aston:

Vamos então conseguir esse alinhamento. Robyn, muito obrigado por se juntar a nós hoje. Foi ótimo tê-la connosco.

Robyn Birkedal:

Obrigada pelo convite.

Ben Aston:

Gostaria de saber, para quem nos está a ouvir, quais são as vossas dicas e truques para declarações de âmbito e declarações de trabalho. Onde guardam as declarações? Como as produzem? O que funciona e o que não funciona? Partilhem nos comentários. Contem-nos as vossas histórias de fracasso e sucesso. Se quiserem aprender mais e avançar na vossa carreira, juntem-se à nossa comunidade através da adesão ao DPM. Visitem thedigitaprojectmanager.com/membership para terem acesso à nossa equipa no Slack, mentoria, modelos, workshops, horários de atendimento, sessões de perguntas e respostas, livros digitais e muito mais. Se gostaram do que ouviram hoje, subscrevam o podcast e mantenham-se em contacto através de thedigitalprojectmanager.com. Até à próxima. Muito obrigado por nos ouvirem.