Qual é o melhor modelo para a gestão de projetos? Métodos ágeis funcionam mesmo? O Scrum é tão eficaz como é promovido? Estas são algumas das perguntas que surgem no dia-a-dia do nosso trabalho e são agora respondidas neste artigo de opinião do nosso Primer Leonardo Magalhães:

“Para entender os benefícios do Scrum, é necessário inicialmente compreender as principais características e diferenças entre os modelos de gestão de projectos: waterfall e ágil.

O tradicional modelo waterfall, descrito pelo cientista computacional Wiston Royce na década de 1970, prevê uma sequência de fases, em que só se dá início a uma fase após terminar a anterior, culminando com a entrega de um produto final quando se conclui a última fase. Royce, ao apresentar este modelo, fê-lo com o intuito de criticá-lo porque trazia muitos riscos associados, uma vez que o cliente desejava, logo no início do projecto, uma especificação completa e detalhada (âmbito do projecto ou project scope). Mas, na época, os programadores gostaram tanto deste modelo que deixaram a crítica de lado e adoptaram-no como padrão. Foi basicamente um “copy/paste literal”, como afirmou “Uncle” Bob Martin (um dos especialistas que participou no Manifesto Ágil) numa das suas palestras.

A seguir, apresento uma compração entre os dois modelos:

Este modelo waterfall funciona muito bem quando há uma visão clara do produto final, desde o início do projecto, ou seja, quando o cliente sabe exactamente o que pretende. Com os objectivos bem definidos é possível saber previamente o que será executado e o resultado esperado. Isso possibilita definir com maior precisão quais as ferramentas a utilizar, quais equipamentos comprar, quais recursos contratar, etc. É um modelo que pode ser muito bem aplicado em projectos de construção civil e de produção em massa, com resultados mais tangíveis e que, de um modo geral, tenham uma duração elevada (superior a 1 ano), possuindo uma maior necessidade de especificação e documentação. Aqui, a qualidade tem um papel mais importante do que a velocidade. Contudo, como o projecto é validado apenas no final, o controlo das alterações é mais rígido e gera um impacto muito mais elevado, principalmente no planeamento de custo e cronograma. Assim, é possível afirmar que, neste modelo, as mudanças não são bem-vindas.

Na construção de uma ponte para atravessar um rio, por exemplo, uma vez definido que o projecto é uma ponte de arco, não será possível, no decorrer dos trabalhos, alterar para uma ponte suspensa. Se esse mesmo modelo waterfall for utilizado para o desenvolvimento de um website, o seu lançamento só acontecerá depois de todas as etapas, até chegar aos testes, serem realizadas. A inclusão, exclusão ou alteração de funcionalidades neste website, fará com que todo o projecto tenha que ser revisto, redesenhado, recodificado e testado novamente.

Já os métodos ágeis são o opostos. Dentre deles, o mais utilizado actualmente é o Scrum que, ao contrário do que dizem, não é um método propriamente dito, mas um framework que define o que deve ser feito, mas não como ser feito (por isso não é “método”). O Scrum reúne técnicas, práticas, princípios e valores que permitem à equipa do projecto fazer entregas rápidas e de alto valor agregado em ambientes complexos e instáveis. De forma geral, o Scrum é muito utilizado em projectos de tecnologia de ponta, disruptivos e de resultados mais intangíveis, geralmente – mas não exclusivamente –, softwares. Por ser intangível, não se sabe exactamente como será o produto final. A sua a construção é feita por partes e com vários ciclos curtos de desenvolvimento, geralmente de duas semanas (chamado de Sprint), que produzem um incremento de produto potencialmente utilizável no final de cada ciclo, conforme visto na imagem em cima. O tempo de resposta para atender às necessidades do mercado (o time to market) é muito mais rápido. Então, ao invés de perder muito tempo para criar um produto “perfeito”, robusto, com infinitas funcionalidades – muitas que o cliente nunca utilizará na vida (mas que ele pagou por isso) –, o foco é entregar um MVP (Minimum Viable Product) com os itens fundamentais e ter a possibilidade de fazer logo o seu lançamento para obter algum retorno financeiro já no início do projecto.

É importante relembrar que os produtos disruptivos não são necessariamente os mais valiosos do mercado e nem atendem todas as necessidades dos clientes, mas eles são a ponta do iceberg da mudança no modelo de competição e podem transformar toda uma indústria. Basta olhar para o Waze, Uber, Spotify, Instagram, TransferWise etc. – com uma breve pesquisa é possível encontrar as primeiras versões dessas apps e perceber como são incompletas e pouco chamativas. A partir das interações que o produto tiver com os usuários finais, é possível obter um feedback e rapidamente gerar atualizações (updates), corrigindo imperfeições e adequando o produto para atender às recentes necessidades do mercado. Sim, nos métodos ágeis as mudanças são esperadas e bem-vindas – e o cliente adora isso! Como a tendência do produto é de evolução constante, o Scrum passa a ser mais um framework para a gestão de produtos do que gestão de projectos propriamente ditos, que possuem início e fim, claramente definidos.

O Scrum gera resultados mais rápidos do que os métodos tradicionais. A interação com o cliente é intensa, o seu envolvimento é muito maior ao longo do projecto, uma vez que este último participa activamente, fornecendo feedback de forma constante. Então, as entregas finais são mais alinhadas com as suas expectativas do que no método waterfall. Isto resulta numa maior satisfação por parte do cliente, ficando mais susceptível a desenvolver novos projectos com a organização.

Estas características tornam o Scrum um modelo que pode trazer resultados significativos, mas é necessário um maior envolvimento e compromisso por parte do cliente. Ao mesmo tempo, a participação do Business Manager no processo de sensibilização também tem de ser mais activa, uma vez que, passaria a ser com um número determinado de sprints que atenderiam a uma ideia macro do cliente e não através de um âmbito fechado e restrito a mudanças… Mas isso é assunto para outro artigo! ”

Leonardo Magalhães

Project Manager – Prime Solutions