Equipas de Projeto Sem Gestores de Projeto: Explorar o Dilema do Gestor de Projeto

Leia a transcrição:

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

Galen Low: Equipas de projeto autogeridas. Só esta expressão é suficiente para desencadear uma crise existencial em qualquer gestor de projeto. Mas será uma ameaça à nossa existência? Ou será a chave para elevar o gestor de projeto a uma função decididamente mais estratégica?

Se tem estado a refletir sobre o futuro da gestão de projetos e sobre se os gestores de projetos digitais continuarão a ser relevantes, continue a ouvir. Vamos analisar como uma organização está a criar, com sucesso, soluções de software complexas utilizando equipas distribuídas e autogeridas, e o que isso significa para a gestão de projetos digitais em geral.

Obrigado por nos acompanhar. O meu nome é Galen Low e falo em nome do The Digital Project Manager. Somos uma comunidade de profissionais digitais com a missão de nos ajudarmos mutuamente a adquirir competências, confiança e ligações, para podermos entregar projetos com propósito e impacto. Se quiser saber mais, visite thedigitalprojectmanager.com.

Julia Ryzhkova: Olá! Olá a todos!

Galen Low: Obrigado por se juntar a nós hoje. Estou muito entusiasmado com este episódio, porque aborda algo que nos deixa a todos um pouco inseguros enquanto gestores de projeto: os gestores de projeto continuarão a existir?

Julia Ryzhkova: Se falarmos de algo relacionado com a Railsware, diria que é o modelo BRIDGeS. É uma estrutura de decisão que permite descrever um problema a um nível elevado e transformá-lo numa solução. Criámo-la ao longo de mais de 15 anos e estamos agora a torná-la pública, o que me entusiasma bastante.

De uma perspetiva pessoal, também colaboro com a escola de negócios de Lviv. Estamos atualmente a realizar um curso público online sobre processos empresariais e espero que isso contribua para melhorar a maturidade geral da cultura de processos empresariais na Ucrânia.

Galen Low: Muito interessante. E o que a entusiasma mais em 2022?

Julia Ryzhkova: Toda a gente fala atualmente de inteligência artificial e aprendizagem automática. Recentemente, tivemos uma reunião para discutir as visões dos nossos produtos e surgiu a ideia de utilizar inteligência artificial no Coupler.io. Estou muito interessada em experimentar e ver como corre.

Galen Low: Hoje vamos falar sobre como pequenas equipas ágeis remotas podem gerir-se e organizar-se autonomamente em grupos para criar soluções de software complexas sem precisarem de um gestor de projeto em nenhum momento. Será uma ameaça para nós, gestores de projeto? Ou uma oportunidade para sermos mais estratégicos?

Julia Ryzhkova: Atualmente sou gestora de produto, o que significa que acompanho o desenvolvimento dos produtos, o marketing, a estratégia de preços e a força de vendas. Tenho formação técnica em informática, mas nunca gostei verdadeiramente de programar. Queria criar algoritmos e deixar outra pessoa escrever o código, e foi assim que me tornei analista de negócio. Mais tarde, desenvolvi competências de liderança e tornei-me líder de uma equipa de analistas de negócio, gestora de projeto e responsável pelo departamento.

Com o tempo, percebi que os resultados do meu trabalho dependiam muito do produto em que estava a trabalhar. Por isso, passei para I&D como responsável pelo produto. Foi a primeira vez que senti estar realmente no lugar certo. Mais tarde, tornei-me diretora adjunta de produto, diretora de experiência do cliente e diretora do PMO.

Depois da licença de maternidade, quis regressar à gestão de produto. Queria concentrar-me nos benefícios para os clientes, deixando a gestão dos processos para outras pessoas. Para mim, os gestores de produto concentram-se no produto e no cliente, enquanto os gestores de projeto se concentram no processo e nos resultados desse processo. Existem muitas semelhanças entre as duas funções.

É neste contexto que as equipas autogeridas são cruciais. Quando conheci a Railsware e li sobre a sua forma de trabalhar, percebi que era uma combinação perfeita.

Galen Low: Fale-nos um pouco da Railsware, da estrutura das equipas que supervisiona e dos tipos de projetos em que trabalham.

Julia Ryzhkova: Somos um estúdio de produtos, o que significa que criamos produtos para nós próprios e para outras empresas. Gostamos de automatizar tudo e, por vezes, não encontramos no mercado uma ferramenta que faça exatamente o que precisamos. Nesses casos, desenvolvemos algo para os nossos próprios fins, utilizamo-lo e depois lançamo-lo publicamente, porque sabemos que não somos os únicos a precisar dele.

Normalmente começamos com uma equipa pequena. Em produtos mais pequenos, como o Coupler.io, temos uma equipa de desenvolvimento com quatro ou cinco programadores e uma equipa de marketing com quatro ou cinco especialistas. As restantes pessoas trabalham a tempo parcial, incluindo analistas de dados, responsáveis pelo apoio e eu própria enquanto gestora de produto.

Quando um produto cresce, expandimos a equipa de desenvolvimento e dividimo-la em várias equipas pequenas, porque acreditamos que é mais eficiente trabalhar dessa forma. O Calendly, por exemplo, tem atualmente três equipas do nosso lado e muitos programadores do lado do cliente.

Galen Low: Qual é o maior desafio que enfrenta atualmente do ponto de vista do desenvolvimento de produto?

Julia Ryzhkova: O desafio habitual de qualquer gestor de produto numa startup é encontrar a oportunidade certa no mercado. Resolvemos uma dor do cliente, a nossa base de clientes cresce e os indicadores melhoram, mas queremos manter o ritmo e duplicá-lo. Precisamos, por isso, de encontrar outro problema pelo qual os clientes estejam dispostos a pagar para resolver.

Galen Low: Como funcionam as equipas autogeridas na Railsware e na equipa do Coupler.io?

Julia Ryzhkova: Tudo está ligado ao nosso conceito de mentalidade de produto por parte dos programadores. Procuramos profissionais maduros e com competências em forma de T, ou seja, pessoas com experiência em várias áreas. Um programador pode trabalhar com o cliente como responsável pelo produto, gestor de projeto e programador durante o período do produto mínimo viável.

Investimos muito no processo de recrutamento e integração. Antes de trabalhar num produto de um cliente, cada pessoa passa algum tempo a trabalhar nos nossos produtos internos, para conhecer a nossa forma de trabalhar e desenvolver esta mentalidade de produto.

O mesmo se aplica às outras funções. Cada pessoa na Railsware pode trabalhar de forma autónoma. Muitos de nós tiveram experiência de gestão ou até geriram os seus próprios negócios. No entanto, ninguém é o gestor direto da equipa. A autoridade conquista-se através do princípio de liderar pelo exemplo. Lidera-se o produto e demonstra-se à equipa que se é digno de a liderar.

Galen Low: Enquanto pessoa com experiência em gestão de projetos e liderança de um PMO, alguma vez achou a ideia de equipas autogeridas desconfortável ou ameaçadora?

Julia Ryzhkova: Sim, durante o meu período experimental na Railsware. É fácil avaliar a nossa necessidade para a empresa quando somos a pessoa indispensável e, sem nós, tudo fica descontrolado. Contudo, quando tudo corre bem sem nós, deixamos de sentir o impacto da mesma forma.

Implementamos um novo processo ou fazemos uma melhoria e as coisas mudam, mas apenas um pouco. Percebemos que podemos tirar duas semanas de férias e nada vai correr mal. Então pensamos: por que precisam de mim? A certa altura, deixamos de tentar controlar tudo e encontramos outras formas de causar impacto.

Concentramo-nos no produto, no cliente e na estratégia. Com o tempo livre, conseguimos causar um impacto ainda maior. Quando damos mais espaço à equipa, ela pode criar algo extraordinário através das comunidades de prática. Temos comunidades de programadores, de QA e de gestão de produto. Foi a comunidade de gestão de produto que criou a estrutura BRIDGeS.

Galen Low: Continua a utilizar competências de gestão de projetos enquanto gestora de produto?

Julia Ryzhkova: Sem dúvida. Não consigo imaginar que alguém possa ser gestor de produto sem alguma experiência de gestão de projetos. Na nossa matriz de competências, todas as funções sénior incluem competências de gestão de projetos, como comunicação, gestão do âmbito, custos, calendário e partes interessadas.

Não faço praticamente gestão da integração e da comunicação, porque isso faz parte da autogestão. A qualidade pertence sobretudo às equipas de QA e engenharia. A gestão de riscos está distribuída por todos os membros da equipa, tal como as aquisições. Se alguém precisa de alguma coisa para trabalhar, cria um pedido de compra e explica porquê.

Galen Low: Como comunicam e se mantêm alinhadas estas equipas?

Julia Ryzhkova: Isso faz parte da cultura. Desde o início, os fundadores definiram processos e documentaram tudo. Temos um processo de integração sólido e seguimos o princípio de documentar à medida que avançamos.

Qualquer reunião pode ter um documento partilhado ou um quadro do Figma associado. As pessoas escrevem notas antes ou durante a reunião, não depois. Assim, depois de duas semanas de férias, posso abrir alguns documentos, lê-los e perceber o que aconteceu, onde estamos e o que precisa de mim, sem necessitar de uma reunião adicional.

A comunicação é transparente e feita em canais públicos do Slack. Temos mais de 300 canais e quase não existem conversas privadas relacionadas com o trabalho. Tudo é partilhado publicamente, pelo que qualquer pessoa pode acompanhar o que aconteceu durante a sua ausência.

Galen Low: Que métricas utiliza para saber se as equipas estão no caminho certo?

Julia Ryzhkova: Não acompanho métricas de desempenho das pessoas. Acompanho métricas do produto: crescimento, indicadores SaaS, conversão, receitas e outros resultados. Também acompanho a velocidade da equipa, mas não como métrica de desempenho. Utilizo-a para prever o que podemos fazer numa versão ou nos próximos três meses.

As equipas gerem o seu próprio desempenho através de programação em pares, testes cruzados e revisão de código. Dão feedback umas às outras e identificam claramente o que precisa de ser melhorado. Esta cultura de feedback começa durante o recrutamento e a integração.

Galen Low: O que acontece quando as prioridades ou o plano do produto mudam?

Julia Ryzhkova: Nada de especial. Posso retirar uma tarefa de um sprint, adicionar outra e explicar o motivo. Podemos alterar o backlog a meio do sprint sem o interromper, desde que sejam apenas uma ou duas tarefas. Reunimo-nos, discutimos o que precisa de ser feito, fazemos uma estimativa e sincronizamo-nos.

A equipa conhece a visão do produto e participa nas reuniões de estratégia com os executivos. Assim, os membros da equipa compreendem por que motivo as prioridades mudam e podem contribuir com perspetivas técnicas. Quando alterámos o modelo de preços, por exemplo, foi um programador que identificou uma incompatibilidade com o modelo de preços de um sistema utilizado por muitos clientes.

Galen Low: Este modelo funciona apenas com desenvolvimento de software ágil?

Julia Ryzhkova: É necessário ser ágil, mas o Manifesto Ágil não diz que temos de criar software. As nossas equipas de marketing, finanças e operações utilizam abordagens semelhantes. Fazem estimativas, gerem roadmaps, planeiam, acompanham a velocidade e utilizam backlogs. A engenharia e o design utilizam Scrum; o marketing utiliza Kanban. São abordagens diferentes, mas todas são ágeis.

Galen Low: Quais são as limitações deste modelo?

Julia Ryzhkova: Uma equipa nem sempre consegue ver o que está a acontecer dentro das outras equipas. Por vezes, uma equipa de desenvolvimento cria muitas funcionalidades e a pequena equipa de marketing não consegue comunicá-las ao mercado. Noutras situações, acontece o contrário. Nesses casos, a gestão precisa de tomar decisões ao nível da empresa, como transferir parte da equipa de marketing ou de engenharia entre produtos.

As equipas continuam alinhadas através de demonstrações, sincronizações semanais e um processo de gestão de contributos. Qualquer pessoa pode propor uma entrada para o backlog de outra equipa. As propostas são analisadas semanalmente e alinhadas com a visão e o roadmap.

Galen Low: Como lidam com equipas distribuídas por diferentes países e fusos horários?

Julia Ryzhkova: O trabalho remoto permite-nos ser mais eficientes. Por vezes é difícil marcar uma chamada entre um programador na Argentina e um gestor de produto na Tailândia, mas essa é provavelmente a única grande dificuldade. Mais de 80% da nossa equipa trabalha remotamente, em mais de 15 países. Os documentos partilhados, os canais públicos e a comunicação assíncrona permitem organizar o trabalho de forma eficaz.

Galen Low: A gestão de projetos é vista como um estigma nestas equipas?

Julia Ryzhkova: Não. Gostamos de experimentar e não existe obrigação de fazer nada de uma forma específica. Partilhamos conhecimentos quando são necessários, por exemplo, sobre estimativas, pontos de história, Kanban ou Scrum. Se alguém sentir que precisa de formação básica em gestão de projetos, pode utilizar o orçamento de formação. No entanto, é mais eficiente partilhar o conhecimento no momento em que ele é necessário.

Galen Low: Considera as equipas autogeridas o futuro da gestão de projetos?

Julia Ryzhkova: Penso que são o futuro das empresas de produto bem-sucedidas. As equipas autogeridas permitem que os gestores de projeto concentrem os seus esforços na estratégia, no produto e no cliente. Permitem finalmente trabalhar naquilo que é importante, mas não urgente, em vez de passarem todo o tempo a resolver o que é urgente, mas não importante.

Ainda assim, não podemos esperar que todas as pessoas sejam autogeridas, especialmente no início das suas carreiras. Os profissionais juniores precisam de orientação, mentoria e gestão direta. Algumas pessoas também precisam que outras definam prazos para conseguirem trabalhar eficazmente. Por isso, haverá sempre espaço para a gestão de projetos tradicional.

No entanto, acredito que qualquer empresa ou equipa que queira alcançar resultados excecionais deve chegar ao ponto em que a autogestão substitui a gestão direta de projetos, libertando tempo para a estratégia e para a melhoria geral dos processos, em vez de resolver cada problema específico.

Galen Low: Que conselho daria a uma organização que quer avançar para equipas pequenas e autogeridas?

Julia Ryzhkova: Não tente apenas fazê-lo: comece. Comece com uma equipa pequena. Não tente implementar esta abordagem em toda a organização se ela for grande. Reúna as melhores pessoas, dê-lhes a autoridade de que precisam e garanta que existem resultados. Quando vir os benefícios, faça o necessário para transferir esta abordagem para toda a empresa. Para alcançar o sucesso, é preciso experimentar com as pessoas que melhor se adequam a este modelo.

Galen Low: O que pensa? Serão as equipas autogeridas o caminho do futuro ou terão limitações que as tornam inadequadas para determinados tipos de organizações e setores?

Conte-nos uma história. Qual foi a equipa de projeto mais autogerida com que trabalhou e como correu? Por outro lado, qual foi a sua experiência mais frustrante ao ter de controlar constantemente o trabalho em vez de ser estratégico? Partilhe 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 conhecimento, resolve desafios complexos e molda o futuro da nossa profissão — em conjunto.

Desde modelos completos e sessões de formação mensais que lhe poupam tempo e energia, até ao apoio entre pares no nosso fórum de discussão, eventos da comunidade 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.