Blog

20 de maio de 2021

Em março, escrevi sobre a linguagem de gerenciamento de projetos e a necessidade de usar termos ou jargões familiares ao público ao qual você está se dirigindo (“Em Busca de um Entendimento Comum”). Às vezes, você tem que traçar uma linha. Eu estava conversando com um cliente que disse que eu não poderia usar a palavra “projeto” ao me comunicar com os praticantes de Agile. Raramente fico sem palavras, mas essa declaração me pegou.

O cliente argumentou que, como a maioria das equipes ágeis estão evoluindo para um modelo de produto com equipes permanentes ou semipermanentes focadas na entrega contínua, os projetos são associados (em suas mentes) a tudo o que há de errado com a forma como o trabalho é feito – burocracia; um foco na gestão e governança ao invés de focar na execução do trabalho. Bem, eu entendo o argumento, mas não concordo com ele.

O Agile é mais do que produtos

Muito foco dentro do Agile tem sido na evolução de projetos para produtos, principalmente quando se trata de desenvolvimento de software. Esta é uma resposta positiva e lógica ao que agora é possível. Não faz sentido empacotar arbitrariamente a funcionalidade em uma versão do projeto quando essa funcionalidade pode ser entregue assim que estiver pronta, sem comprometer a qualidade ou aumentar o risco.

Apoiar equipes ágeis estáveis que são financiadas continuamente enquanto o trabalho que estão produzindo está entregando valor – um modelo baseado em produto – permite que esse valor seja alcançado da maneira mais rápida e eficaz possível. Quer esses produtos digitais sejam ofertas internas ou para o cliente, ou se combinem em soluções e serviços maiores, há lógica para evoluir a estrutura do trabalho. Eu poderia argumentar que um modelo baseado em produto é apenas uma etapa provisória para chegar a um modelo baseado em capacidade que financia a funcionalidade de negócios diretamente, mas isso é outro artigo.

Também faz sentido estender esse modelo baseado em produto para outras áreas de trabalho. Se uma organização opera com um modelo de infraestrutura baseada em serviços, o conceito pode muito bem ser aplicado a essas mudanças de infraestrutura, por exemplo. E com o crescimento dos ambientes de Citizen Developer, há oportunidades para expandi-lo ainda mais (embora haja limitações em torno de alguns dos outros elementos de trabalho que provavelmente estarão envolvidos).

Mas isso não representa todas as situações em que a entrega baseada em agilidade é usada. Não faz muitos anos que os entusiastas do Agile insistiam que o Agile pode ser usado em quase todas as áreas do negócio e em todo tipo de projeto. E eles estavam certos! Não é a abordagem certa para todos os projetos, mas é apropriada para muito mais do que desenvolvimento de software e trabalho relacionado. E esse trabalho ainda é entregue usando um modelo baseado em projeto – um esforço temporário que envolve uma peça única de trabalho projetada para atingir um conjunto definido de resultados de negócios e entregue dentro de certos parâmetros.

Perguntei ao meu cliente como deveríamos chamar esse tipo de trabalho se não fosse chamá-lo de projeto, e a resposta foi que era uma “iniciativa”. Bem, além do fato de que a iniciativa tem uma definição específica em ágil como uma coleção de épicos direcionados a um objetivo comum, agora estamos de volta ao problema que abordei naquele artigo anterior – estamos brincando com as palavras. Chame de iniciativa se quiser, mas também é um projeto e não há por que argumentar o contrário.

O real problema

Há uma preocupação real aqui, mas não é que o Agile não faça “projetos”. A questão é que, para alguns praticantes do Agile, o projeto tem uma conotação negativa. Por extensão, o mesmo ocorre com o gerenciamento de projetos, o escritório de gerenciamento de projetos e outras ideias e termos relacionados. Historicamente, tem havido tensão e desconfiança entre os praticantes de projetos ágeis e tradicionais. A resistência dos tradicionalistas quando o Agile surgiu pela primeira vez torna compreensível que os entusiastas do Agile devam se distanciar dos projetos quando surge a oportunidade. Não há muitas pessoas que trabalham com Agile por um longo período de tempo que não experimentaram estruturas excessivamente burocráticas, lidaram com PMOs que querem atualizações constantes sobre o desempenho em relação à restrição tripla, ou disseram que o Agile não é um abordagem “real”.

Embora muita coisa tenha (felizmente) mudado, ainda existem áreas em que os proponentes do Agile podem se sentir frustrados. Meu colega Jesse Fewell abordou esse problema há quase dois anos em um artigo para a PM Network. A infraestrutura de gerenciamento de projetos – a forma como os projetos sempre foram planejados, financiados, iniciados e entregues – nunca foi projetada para operar em um ambiente de ritmo acelerado, que muda rapidamente e está sujeito a inúmeras partes móveis. Esses aspectos ainda não foram modernizados em algumas organizações por 20 anos ou mais.

Se os profissionais ágeis desejam se afastar de qualquer associação com projetos, é porque essa associação prejudica sua capacidade de fornecer soluções de maneira eficaz. É porque seus apelos às organizações para modernizar o financiamento, planejamento, supervisão e entrega foram ignorados. Em muitos casos, é porque a liderança organizacional, que muitas vezes tem exposição limitada ao Agile, ainda vê isso como uma abordagem de nicho que não é apropriada para iniciativas estratégicas críticas de negócios.

Isso é um problema real, e não é um problema para aqueles praticantes ágeis que não gostam da palavra projeto; é um problema para todos na organização porque o trabalho não está sendo executado da maneira mais eficaz e eficiente. Como resultado, os resultados de negócios não são otimizados e o desempenho geral dos negócios é inferior ao que poderia ou deveria ser.

A solução

Este problema não será resolvido por indivíduos ou grupos que se recusem a reconhecer o termo “projeto” para o trabalho que estão fazendo. Isso só será resolvido quando as organizações reconhecerem que ágil é, de fato, uma abordagem de entrega de projeto e também uma forma de pensar; uma forma de operar uma empresa no mundo de hoje. Não usamos tecnologia de 20 anos atrás e também não deveríamos usar processos estratégicos de lá. Ainda precisamos planejar com eficácia, financiar adequadamente e entregar com eficiência, mas a forma como fazemos isso tem que mudar.

Para tornar essas mudanças o mais eficaz possível, precisamos nos envolver com as pessoas que estão mais familiarizadas com as formas adaptativas de trabalho. Esses são os praticantes e proponentes ágeis que aprenderam ao longo das últimas duas décadas como entregar o melhor desempenho possível em todas as áreas – qualidade, valor, risco. Em vez de ver esses grupos como áreas de nicho do negócio, eles precisam ser abraçados como precursores da maneira como todos os aspectos dos negócios precisam ser conduzidos.

Isso não significa que o gerenciamento de projetos tradicional está morto; sempre haverá projetos que são mais adequados para uma abordagem de entrega em fases bem estruturada. Mas significa que as questões maiores de planejamento estratégico e financiamento devem mudar fundamentalmente para serem mais capazes de antecipar e responder às evoluções que acontecem constantemente em praticamente todos os setores.

Conclusões

Para que as organizações sobrevivam e prosperem hoje, é fundamental que todos os aspectos dos negócios estejam alinhados. Cada departamento, função e indivíduo deve entender o que a organização está tentando alcançar e como planeja alcançá-lo. E todos eles devem estar comprometidos com esses planos e garantir que tudo o que fizerem ajude a mover a organização em direção a esses objetivos. Qualquer desalinhamento é como pisar no freio ao mesmo tempo em que pisa no acelerador – ele retarda o progresso e cria atrito, enfraquecendo a organização no processo.

É o que acontece quando os grupos sentem que não são valorizados ou que suas opiniões não são consideradas relevantes. Não sei qual a porcentagem de praticantes ágeis que realmente ficam chateados com o uso da palavra projeto, mas o fato de que uma parte deles fica é um reflexo do problema maior de que eles não se sentem compreendidos por alguns de seus empregadores ou colegas. Ainda vou usar a palavra projeto em torno de equipes e indivíduos ágeis, mas também vou pedir aos executivos que tornem suas organizações – e suas atitudes – mais ágeis.

Andy Jordan é presidente da Roffensian Consulting S.A., uma empresa de consultoria de gestão sediada em Roatan, em Honduras, com uma prática abrangente de gerenciamento de projetos. Andy sempre aprecia feedback e discussão sobre as questões levantadas em seus artigos e pode ser contatado em andy.jordan@roffensian.com. O novo livro de Andy “Risk Management for Project Driven Organizations” já está disponível.

Tradução: Ricardo Coutinho

Fonte: https://www.projectmanagement.com/articles/705986/Project-is-Not-a-Four-Letter-Word