Medir a Ocupação versus Medir os Resultados

 

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoem eventuais erros de digitação, pois o sistema automático não está correto a 100% do tempo.

Galen Low: Pergunta rápida: está a meio do seu projeto e todas as suas métricas parecem excelentes. O seu fornecedor trabalhou o número de horas acordado e a velocidade e a utilização da sua equipa estão exatamente onde planeou que estivessem.

Mas, apesar de o seu projeto estar aparentemente saudável, o produto continua a falhar nos grupos de foco e nos testes com utilizadores. A tecnologia que o patrocinador executivo defendia firmemente está a tornar-se rapidamente obsoleta, o que dificulta a realização de alterações. E o moral da sua equipa está baixo: quando lhes pede soluções, encolhem os ombros e dizem que fizeram o que lhes foi pedido dentro do tempo atribuído.

Então, como pode o seu projeto estar saudável se o resultado não está a produzir o valor pretendido?

Se tem descoberto que as métricas do seu projeto estão a medir mais a ocupação do que o valor, continue a ouvir. Vamos explorar a mecânica prática de como as equipas de projeto podem medir o valor e analisar ideias para mudar o incentivo das horas despendidas para o valor criado.

Olá a todos, obrigado por estarem desse lado. O meu nome é Galen Low, do Digital Project Manager. Somos uma comunidade de profissionais digitais com a missão de nos ajudarmos mutuamente a adquirir competências, ganhar confiança e estabelecer ligações, para podermos amplificar o valor da gestão de projetos num mundo digital. Se quiser saber mais, visite thedigitalprojectmanager.com.

Muito bem. Hoje vamos falar sobre a diferença entre medir a saúde e o progresso de um projeto e medir o sucesso de um projeto. Será suficiente acompanhar a velocidade da equipa e o desempenho em termos de custos? Ou será também nossa responsabilidade, enquanto líderes de projeto, medir os resultados e o impacto do projeto?

Hoje tenho comigo Fred Fowler — um mestre Scrum certificado de nível 3, que publicou vários livros sobre a metodologia Scrum, é o organizador do grupo Silicon Valley Professional Scrum, com cerca de 2000 membros, lidera uma comunidade Scrum semelhante em Xangai, na China, e organizou a primeira conferência Silicon Valley Scrummit. Por outras palavras, alguém que percebe bastante de Scrum.

Bem-vindo, Fred!

Fred Fowler: Olá! Obrigado por me receber no programa.

Galen Low: É ótimo tê-lo aqui.

Fred Fowler: Apresento-me como um tipo muito ligado ao Scrum. Embora algumas pessoas digam que sou scrumcioso.

Galen Low: Bem, isso é melhor do que eu dizer que o Fred é o scrum da terra.

Fred Fowler: Há todo o tipo de formas de brincar com a palavra Scrum. Pode fazer trocadilhos e tudo mais. Enfim, prossiga.

Galen Low: Exatamente. Muito bem. Tem um percurso tão interessante, e penso que isso dará aos nossos ouvintes bastante contexto sobre a sua perspetiva relativamente às métricas de projeto. Se compreendi corretamente, começou como programador informático, depois passou para a política, tornou-se presidente de uma câmara municipal e, mais tarde, foi diretor de informação, antes de começar a utilizar a sua rara certificação de mestre Scrum de nível 3 para ajudar outras pessoas.

Gostaria de saber se nos podia falar um pouco sobre o seu percurso e sobre a forma como as suas experiências moldaram a maneira como vê as coisas atualmente.

Fred Fowler: Diria que a minha carreira se assemelhou a estar dentro de uma máquina de pinball.

Comecei como programador em 1980. Sabe, numa época antiga, a trabalhar numa máquina tão grande e pesada que basicamente precisava de equipamento especial para ser transportada e que era menos potente do que um telefone comum de hoje, o seu smartphone. Mas geríamos uma divisão de uma empresa de semicondutores utilizando essa máquina, e foi aí que aprendi as minhas competências.

Depois avancei, porque era o Silicon Valley dos primeiros tempos, o que significava muita volatilidade. Assim, nos primeiros oito anos da minha carreira, trabalhei para cinco empresas diferentes e foi simplesmente incrível — como digo, muita volatilidade. Finalmente, no fim desse período, pensei: preciso de alguma segurança profissional, por isso é melhor trabalhar por conta própria.

Tornei-me consultor e trabalhei para 60 empresas diferentes nos dez anos seguintes. Mais uma vez, fazendo essencialmente o mesmo: tentando sempre aplicar a tecnologia para resolver problemas empresariais, que é realmente o objetivo de tudo isto. Depois houve uma empresa para a qual trabalhei como consultor.

Fizeram-me uma proposta que não podia recusar. Acabei por gerir a operação de tecnologias de informação e por ser, como digo, o diretor de informação. Implementei muitas técnicas que acabaram por ser técnicas Scrum, embora na altura não me apercebesse disso. Dei às pessoas autonomia para resolver problemas e justifiquei o trabalho com base no retorno do investimento.

Naquela época, realizei muitos projetos que moldaram toda a minha visão sobre como organizar iniciativas. Há muitas coisas de que me orgulho. A empresa tinha trabalhado arduamente para criar um sítio Web utilizando uma grande empresa informática de três letras que todos reconheceriam.

Pagaram a essa empresa um quarto de milhão de dólares para criar uma solução de comércio eletrónico bastante fraca. De qualquer forma, envolvi-me no projeto e percebi que havia uma grande oportunidade de melhoria. Organizei um projeto e linhas Scrum longas.

Tínhamos duas tecnologias diferentes envolvidas. Havia um sistema legado, um minicomputador IBM daquela época chamado AS/400, que funcionava como retaguarda, mas precisávamos de uma interface. Viajei até à China e encontrei uma pequena empresa ambiciosa que faria a interface. Organizámos tudo de modo que a equipa dos Estados Unidos trabalhasse na retaguarda e a equipa chinesa na interface. Tudo o que tínhamos de fazer era descobrir como fazer as duas plataformas comunicar entre si.

Acabou por ser bastante simples. Substituímos um trabalho de um quarto de milhão de dólares por um sítio Web que, ao fim de seis meses, representava 40% do negócio da empresa, tendo custado 14 000 dólares. 14 000 dólares. Mas era simples. Tratava-se apenas de libertar as pessoas que compreendiam a tecnologia, dar-lhes um problema para resolver e deixá-las resolvê-lo.

Pode ter equipas em diferentes partes do mundo. Não há problema. Tudo o que tem de fazer é gerir a forma como interagem umas com as outras.

Galen Low: É isso mesmo. Equipas pequenas, contrato de dados e avançar.

Fred Fowler: Exatamente. E o aspeto verdadeiramente fundamental era compreender o que era importante medir.

Quando se fala de equipas externas e de tudo o resto, toda a gente entra em pânico: como sabemos o que estão a fazer? Queremos todo o tipo de ferramentas para medir o quanto estão a trabalhar e quão ocupadas estão, porque queremos que estejam ocupadas o tempo todo.

Certo? Adivinhe: isso não importa. Não faz diferença se as pessoas que trabalham externamente estão ocupadas ou não. Isso não é importante. O que importa é aquilo que entregam efetivamente, o valor do que entregam. É isso que deve medir. Esqueça tentar controlar as pessoas com cronómetros. Não importa se teve pessoas ocupadas.

Por exemplo, se tivesse uma equipa de mais de 200 pessoas a trabalhar oito ou dez horas por dia durante dois anos, em comparação com uma equipa de cinco ou seis — ou dez — pessoas a trabalhar o horário normal durante um ano, quem acha que entregaria mais valor? Acontece que as 200 pessoas que trabalharam durante dois anos criaram o healthcare.gov, um sítio Web de há vários anos que acabou por ser um desastre total.

Era suposto implementar o Obamacare. Porém, entrou em colapso porque essas 200 pessoas eram avaliadas pela sua ocupação. As dez pessoas do ano seguinte foram quem reescreveu completamente o sistema e o fez funcionar. Entregaram muito mais valor do que as 200 pessoas.

Galen Low: Ia precisamente dizer que devíamos aprofundar esse ponto, porque é muito importante. Referiu uma das razões pelas quais medimos a ocupação, mas no meu mundo — venho de agências e empresas de consultoria — tudo gira à volta das horas faturáveis, da utilização, do número de erros corrigidos ou de tarefas concluídas.

Porque temos esta tendência para medir a ocupação?

Fred Fowler: É simples. Porque é fácil de medir. Tudo o que precisa é de um relógio para medir quão ocupadas as pessoas estão. Para perceber se as pessoas estão a cumprir uma série de prazos, basta um calendário. É fácil de medir. E sabe que mais? É a base da remuneração.

Mencionou as horas faturáveis. Essa é uma grande falácia. A ideia de que o tempo das pessoas é valioso. O tempo das pessoas é valioso para elas, mas aquilo que é valioso para si é o que fazem com esse tempo. Seria muito melhor se o mundo tivesse uma boa régua para medir os resultados do tempo das pessoas.

Quando falo com empresas, tento dizer-lhes que, mais do que qualquer outra coisa, precisam de descobrir o valor daquilo que querem criar e conseguir dividi-lo em partes que façam sentido, para que seja mensurável. Depois devem medir o progresso com base no valor criado. No Lean existe a ideia de produto mínimo viável.

Faz-se o máximo necessário de um produto para colocar algo nas mãos do cliente. Sabe por que razão isso é uma boa ideia? Porque esse algo tem valor por estar nas mãos de um cliente. O cliente pode dizer-lhe quanto vale. Dessa forma, pode avaliar se o valor criado compensou a despesa necessária para o criar.

Se tiver uma aplicação que custa meio milhão de dólares a desenvolver, será um bom investimento? Depende. Se a aplicação for disponibilizada no iTunes e descarregada três milhões de vezes a dois dólares cada, acabou de ganhar seis milhões de dólares com um investimento de meio milhão.

É um excelente negócio. Faria isso todos os dias. Se investir o mesmo meio milhão, disponibilizar a aplicação no iTunes e ela tiver apenas 20 000 descargas a dois dólares — digamos 25 000 — gastou 500 000 dólares para criar 50 000 dólares de valor. O esforço foi o mesmo e o número de horas faturáveis também, mas o valor do resultado é diferente. E o valor do resultado é o que importa.

Galen Low: Referiu algo muito importante que penso que nem toda a gente compreende plenamente sobre o produto mínimo viável. Voltando ao que disse anteriormente, medimos a ocupação porque, por vezes, é uma questão de confiança. Não confiamos que as pessoas estejam a fazer alguma coisa. Mas, se pudermos controlar o relógio enquanto trabalham, pelo menos sabemos que estamos a pagar aquelas horas.

Mas, como diz, isso não mede o valor. Muitas pessoas dizem-me: claro que precisamos de horas faturáveis. É o contrato, é assim que as pessoas são remuneradas. É esse o acordo. Mas gosto do que disse sobre o produto mínimo viável: vamos colocar alguma coisa no mercado.

Será necessário um investimento. Depois, enquanto cliente, pode decidir se isso é valioso ou não. Algumas pessoas poderão pensar que querem saber se algo é valioso antes de gastar o dinheiro. Mas, na realidade, isso também não acontece. Tem 50 000 dólares, constrói o produto e, depois de gastar o dinheiro, pode continuar sem ter aquilo que pretendia e que criará valor.

Sente que as horas faturáveis e os dólares são um mal necessário para fazer negócios ou que devemos tentar ultrapassá-los?

Fred Fowler: De certa forma, são um mal necessário. Mas é preciso manter as pessoas no caminho certo, comparando o custo do seu trabalho com o valor do resultado. Há algo importante na estrutura Scrum: dentro do Scrum, é necessário criar algo concluído, terminado e pronto para entregar ao cliente no final de cada sprint.

Porque acha que isso acontece? Porque é importante que algo esteja concluído, pronto e possa ser entregue a um cliente?

Galen Low: Diria que é para que o valor possa ser medido.

Fred Fowler: Exatamente. Algo só tem valor quando está concluído e pronto para ser entregue a um cliente.

E é assim que se mede o valor: mede-se quanto um cliente pagará por algo. No Scrum, a cada duas semanas cria-se algo de valor para poder medir esse valor e compará-lo com o custo de o criar. Assim, sabe antecipadamente se está no caminho certo para criar um produto de seis milhões de dólares com um investimento de 50 000 ou 500 000, ou um produto de 50 000 dólares com um investimento de 500 000. É necessário dividir o trabalho em partes que tenham um valor mensurável — não um valor baseado numa opinião, mas um valor mensurável.

O Scrum salienta que as decisões devem basear-se em coisas que medimos, não em suposições ou opiniões. E a coisa mais importante a medir é o valor.

Galen Low: Poderia explicar-nos como medir o valor? Se medir a ocupação não é assim tão útil, que métricas devemos medir enquanto equipa Scrum? Parece-me que aquilo que está a dizer implica colocar algo no mercado. Mas quem avalia se algo é valioso de sprint para sprint? E como se acompanha isso?

Fred Fowler: Em primeiro lugar, é importante reconhecer que, na estrutura Scrum, medir o valor é realmente responsabilidade de uma única pessoa. O Scrum divide as responsabilidades em três partes: o proprietário do produto, os programadores e o mestre Scrum.

A função do proprietário do produto é maximizar o valor do trabalho da equipa. O proprietário do produto é responsável pelo valor. Não se pode maximizar algo sem o medir. Se não conseguir medir o que está a tentar maximizar, não saberá se o que está a fazer está a melhorar ou a piorar a situação.

Existem quatro formas de aumentar o valor. A mais comum é a receita. Outra é reduzir o custo de algo. Se produzir um milhão de artigos por ano e reduzir o custo em 50 cêntimos, isso vale meio milhão de dólares. A terceira forma é reduzir o risco. A quarta é aumentar a oportunidade.

Quando eu era diretor de informação, tínhamos um centro de dados ligado ao mundo exterior através de um cabo de fibra ótica. Uma vez por ano, alguém escavava acidentalmente o cabo e interrompia a ligação, deixando-nos fora de serviço durante um dia. Perdíamos cerca de um milhão de dólares por dia. O custo anual desse risco era, portanto, um milhão de dólares.

Propus transferir o centro de dados para uma localização muito segura fora de Sacramento. Gastámos 50 000 dólares. Gastaria 50 000 dólares para poupar um milhão? Claro que sim. Reduzir esse risco criou valor.

Galen Low: Isso é muito interessante. O proprietário do produto é responsável pelo valor e mede todos esses aspetos. Falamos destas quatro alavancas para aumentar o valor. Como é que essa informação chega à equipa de desenvolvimento?

Fred Fowler: O proprietário do produto mede o valor e toma decisões racionais sobre aquilo em que a equipa deve trabalhar. Não é possível medir o valor de algo que ainda não existe. Por isso, o proprietário do produto tem de fazer uma previsão sobre aquilo que será valioso. É uma decisão de investimento, como comprar ações. Faz uma estimativa fundamentada e orienta as equipas para criarem esse valor. Depois coloca o resultado nas mãos dos clientes para descobrir quanto vale.

Como saber se o proprietário do produto está a fazer um bom trabalho? Observando o retorno desses investimentos. Se gastar 50 000 dólares num sprint, obtém mais de 50 000 dólares de valor?

O proprietário do produto e a equipa estão no mesmo barco. Têm de entregar mais valor do que aquilo que custa produzi-lo.

Galen Low: É uma afirmação muito clara. Por vezes pensamos: vão pagar-me, claro, porque trabalhei 80 horas, tal como tinha dito que faria. Mas ficamos presos na nossa própria armadilha, porque a conversa deixa de ser sobre valor e passa a ser sobre trocar tempo por dinheiro.

Fred Fowler: Exatamente. Quando os programadores percebem isso, compreendem que têm interesse em garantir que aquilo que fazem é valioso.

O proprietário do produto desempenha uma função empresarial, não técnica. Deve identificar aquilo que seria interessante e valioso criar. Os programadores são os técnicos. O proprietário do produto diz o que é desejável; os programadores dizem o que é possível. Através de uma negociação, determinam o que é prático e mais valioso.

O Scrum consiste numa negociação entre pessoas responsáveis por essas duas áreas. O proprietário do produto compreende realmente o negócio e os programadores compreendem realmente a tecnologia. Juntos, conseguem dizer: este é um problema empresarial e podemos aplicar esta tecnologia para o resolver.

Galen Low: Gosto da palavra parceria. Muitas pessoas não veem a relação dessa forma. Pensam que aquilo que o proprietário do produto decidir é simplesmente o que será feito. Continua a parecer uma relação de servidão, mas não é. O Scrum trata de autonomia, de capacitar as pessoas e de negociar o equilíbrio entre o valor empresarial e aquilo que é tecnicamente viável.

Fred Fowler: Os programadores podem influenciar bastante o custo das coisas. Em vez de criarem um sistema de início de sessão de raiz, podem sugerir utilizar o início de sessão com o Google ou com o Facebook. Essas empresas já fizeram grande parte do trabalho. Os programadores devem ser questionados sobre se conseguem resolver um problema, não receber instruções detalhadas sobre cada passo.

O proprietário do produto diz o que é valioso; os programadores dizem o que é fácil ou difícil. A negociação consiste em encontrar a coisa mais simples que podemos fazer e que seja valiosa. Depois, deve ser criada de forma a poder ser entregue ao cliente e permitir medir o valor.

Galen Low: Pergunto isto porque já fui culpado de medir a ocupação ou até a velocidade. A velocidade continua a ser uma métrica. Temos gráficos de trabalho restante. Como são as conversas sobre valor nas equipas Scrum com que trabalhou?

Fred Fowler: Isso relaciona-se com a remuneração. Se toda a gente é paga à hora, o incentivo é fazer tudo da forma mais difícil. Trabalhei com uma empresa da Fortune 50 que tinha um projeto de dois anos e 500 milhões de dólares para reformular todas as suas operações. Havia um exército de pessoas extremamente ocupadas, reuniões, relatórios e código a ser escrito.

Foi aí que ouvi pela primeira vez o termo código descartável: código escrito para uma necessidade que depois se descobriu não existir. Ao fim de dois anos, tinham gasto a maior parte dos 500 milhões de dólares e não tinham criado qualquer valor. Tinham criado muito ruído, atividade e trabalho faturável, mas nenhum resultado valioso.

A remuneração tem dois aspetos. Primeiro, é necessário pagar a taxa de mercado para atrair as pessoas. Depois, como se recompensa o valor que produzem? É preciso dar-lhes parte desse valor como recompensa. Se uma equipa criar 100 000 dólares de valor, talvez 20% desse valor possa ser distribuído pela equipa. Deve ser entregue à equipa para que esta decida como o dividir de forma justa. Assim, todos têm um incentivo para criar valor.

Galen Low: É semelhante a um modelo de participação nos lucros: salário base para atrair as pessoas e um incentivo baseado no valor criado e medido com alguma consistência pelo proprietário do produto.

Fred Fowler: É o que faz sentido, porque alinha os incentivos. Essa é uma das grandes vantagens da estrutura Scrum. O proprietário do produto é como um investidor: deve ter autoridade para investir o tempo da equipa, mas os resultados desses investimentos devem ser medidos.

Da mesma forma, a equipa de desenvolvimento deve ter autoridade total para decidir como fazer o trabalho. Ninguém deve dizer-lhe como o fazer. Ao dar aos programadores autoridade para tomarem essas decisões, deixa de haver alguém a quem possam atribuir culpas, exceto a si próprios.

Galen Low: A nossa indústria não tem feito um bom trabalho a promover a responsabilização. Muitas vezes dizemos: faça assim porque eu mandei.

Fred Fowler: Isso é contraproducente, porque as lições aprendidas durante o trabalho não influenciam as pessoas que tomam as decisões. É por isso que o Scrum diz que as equipas de desenvolvimento devem ser autogeridas e multifuncionais. Devem conseguir criar o produto por si próprias e tomar as suas próprias decisões.

Há um velho ditado que diz que nada é impossível quando não somos nós a fazê-lo. Se alguém lhe disser para fazer algo, não será impossível para essa pessoa, porque não tem de o fazer. Quantas vezes lhe pediram para fazer o impossível? A mim, muitas.

Galen Low: É realmente uma questão de equilíbrio entre autonomia e responsabilização. Pode dar autonomia à equipa, mas ela terá de ser responsável, e isso é uma aprendizagem que não acontece de um dia para o outro.

Fred Fowler: São três coisas: autonomia, responsabilização e capacidade. As pessoas que recebem autonomia têm de ser capazes de executar o trabalho. O proprietário do produto tem de ser capaz de gerir investimentos de centenas de milhares ou milhões de dólares. Os programadores têm de ser capazes de criar o produto enquanto equipa.

Esse é o maior desafio do mestre Scrum: fazer com que todos trabalhem em conjunto e compreendam as suas responsabilidades. Um bom sistema de remuneração, que recompense o valor efetivamente criado, também pode ajudar.

Galen Low: Medir o valor e recompensar o valor.

Fred Fowler: Exatamente. É muito importante que o produto em que o proprietário do produto trabalha tenha um valor mensurável. Se não consegue medir o valor de algo, isso não é um produto e não pode tomar decisões racionais sobre o seu desenvolvimento.

Um produto é algo que pode ser produzido e que tem um valor objetivamente mensurável. Mede-se o produto vendendo-o e conseguindo que alguém pague por ele. Se não consegue vender algo, não tem um produto; tem uma parte de outro produto, que é o verdadeiro produto e que deve orientar as decisões de desenvolvimento.

Galen Low: Para terminar, falámos muito sobre Scrum e sei que é um grande defensor do Scrum. Mas, quando se trata de medir valor e impacto em vez de ocupação, isto pode funcionar com outras metodologias? Que conselho daria a essas pessoas?

Fred Fowler: Outras metodologias? Sim. O Scrum é uma camada sobre algo mais profundo. O Agile também é uma camada sobre algo mais profundo. O modelo Waterfall do PMI baseia-se no planeamento e na criação de uma receita para um grupo seguir passo a passo. O problema é que as coisas mudam.

Roman Pichler escreveu um livro chamado Agile Product Management with Scrum. Falou sobre um projeto de dois anos para reformular o produto principal de uma empresa de serviços médicos. A equipa planeou cuidadosamente o projeto segundo o modelo Waterfall. Geriu nove equipas, terminou dentro do prazo e abaixo do orçamento, mas descobriu que o produto já estava obsoleto antes da entrega.

As coisas mudam e seguir uma receita não funciona. O Scrum diz para criar incrementos, observar o que está a acontecer e aprender. A verdade mais profunda é que precisamos de pessoas qualificadas para tomar decisões pelas quais são responsáveis, tanto no negócio como no desenvolvimento do produto. Os programadores têm de conseguir criar o produto e gerir-se a si próprios.

É necessário algum método para medir o progresso incremental do produto. Essa é a base do Scrum e de tudo o resto. Independentemente do modelo utilizado, concentre-se em medir o valor em vez da atividade e os resultados em vez dos produtos do trabalho. Se conseguir medir os resultados e aprender com eles, estará no caminho do sucesso.

Galen Low: E aí está. Muito bom.

Fred, falámos sobre o seu grupo de encontros e sobre os livros que escreveu. Onde podem os ouvintes saber mais sobre essas duas coisas?

Fred Fowler: Organizo desde 2015 um grupo de encontros dedicado ao Scrum. Chama-se Advanced Scrum Case Studies.

De duas em duas semanas reunimo-nos online e publico antecipadamente um caso que apresenta algum problema de gestão de projetos ou de gestão Scrum, como lidar com equipas externas ou medir o valor.

Se tiver interesse, pode juntar-se. Procure no Meetup o grupo Silicon Valley Professional Scrum. Encontrará o nosso encontro Advanced Scrum Case Studies. Terei todo o gosto em recebê-lo.

Esse grupo produziu muito material interessante. Tenho notas sobre cerca de 60 casos, alguns enviados por mim e outros pelos membros. Reuni-os num volume chamado Advanced Scrum Case Studies. Está disponível na Amazon e também pode comprá-lo no meu sítio Web: www.siliconvalleyscrum.com.

O livro contém 15 casos muito interessantes e estou a trabalhar agora no Volume 2, com mais 15. Tenho mais de 60 casos reunidos e recebo novos casos a cada duas semanas.

Galen Low: É fantástico. Não sabia que o livro se baseava no material das discussões do grupo de encontros.

Fred, muito obrigado por participar no programa. Gostei muito das suas histórias e da sua perspetiva. A conversa sobre remuneração daria, por si só, um episódio inteiro.

Espero que todos os nossos ouvintes tenham retirado muito valor desta conversa. Obrigado.

Fred Fowler: Obrigado. Gostei muito de falar consigo. Obrigado pelo convite.

Galen Low: Então, o que pensa?

É viável que as equipas de projeto se orientem pela criação de valor, em vez de pelas horas trabalhadas ou pelas histórias de utilizador concluídas? Ou estamos demasiado dependentes de um modelo de troca de dinheiro por horas de trabalho?

Conte-nos uma história: quais foram as métricas certas para acompanhar nos seus projetos? E que alterações ou resultados observou por ter acesso aos dados do seu projeto?

Deixe as suas ideias nos comentários abaixo!

Se quiser aperfeiçoar as suas competências enquanto líder estratégico de projetos, junte-se à nossa comunidade!

Visite thedigitalprojectmanager.com/membership para ter acesso a uma comunidade solidária que partilha conhecimentos, resolve desafios complexos e molda em conjunto o futuro da nossa profissão.

Desde modelos completos e sessões de formação mensais que lhe poupam tempo e energia até ao apoio entre pares disponibilizado através das nossas discussões no Slack, eventos em direto e grupos de acompanhamento, ser membro da nossa comunidade significa ter mais de mil pessoas do seu lado enquanto desenvolve a sua carreira na entrega de projetos digitais.

Se gostou do que ouviu hoje, subscreva e mantenha-se em contacto através de thedigitalprojectmanager.com.

Até à próxima, obrigado por ouvir.