Gestão Tradicional x Gestão Ágil de Projetos: qual escolher?

Este artigo é a segunda parte de uma trilogia na qual estamos juntos refletindo sobre o papel da Geoinformação durante o gerenciamento de um projeto. Na primeira você viu uma introdução à gestão tradicional e à gestão ágil de projetos, nesta segunda parte veremos as diferenças entre elas, as vantagens de cada uma e sua integração e abordaremos o framework Scrum, enquanto na terceira e última será a vez de entrarmos mais a fundo nas Geociências e na gestão de projetos geoespaciais

Por Eduardo Freitas Oliveira*

Clique aqui e acesse a primeira parte desta trilogia: Qual o papel da Geoinformação na Gestão de Projetos?

Por dentro do Scrum

Como já vimos no artigo anterior, dentre os diferentes métodos ágeis, o que mais se destaca é o Scrum, um framework para desenvolvimento de produtos que apresenta um conjunto de valores, princípios e práticas dentro dos quais pode-se tratar e resolver problemas complexos, como os encontrados no setor de Geociências.

O Scrum tem como base o conhecimento obtido através da experiência e de tomada de decisões baseadas no que é conhecido, sustentando-se em três pilares: transparência, inspeção e adaptação.

No framework Scrum, pequenos times possuem papéis e responsabilidades e, juntos, realizam eventos de duração fixa, que são os ciclos iterativos. Ou seja, um projeto é “quebrado” em projetos menores, com entregas parciais.

No início do projeto é feita uma reunião de planejamento com desenvolvedores, clientes, parceiros e demais envolvidos, para que seja definido o Backlog do Produto, no qual são listadas todas as características, funções, requisitos e funcionalidades do produto a ser entregue, ordenados por prioridade. É importante ressaltar que esta listagem deve ser dinâmica e atualizada sempre que houver mudanças nos requisitos de negócio, condições de mercado ou tecnologia, tornando assim o produto adequado ao mercado geoespacial.

O Scrum tem papéis bem definidos, e são eles:

1. Time: responsável por executar o desenvolvimento e transformar o escopo definido para o projeto em algo pronto e disponível para entrega ao cliente.

2. Scrum Master: é um dos membros do Time, eleito para garantir que o mesmo siga as regras do Scrum e por remover os impedimentos existentes para que a equipe não tenha problemas para atingir sua meta.

3. Product Owner ou Dono do Produto: responsável por gerenciar o escopo do projeto e garantir o valor do trabalho gerado pelo Time.

É importante ressaltar que o Product Owner deve ter amplo conhecimento sobre o negócio e deve garantir a entrega de um produto que agregue real valor ao cliente. Por sua vez, os times de desenvolvimento organizam e gerenciam seu próprio trabalho com o objetivo de atingir a meta estabelecida pelo dono do produto.

O Scrum tem seu progresso baseado em uma série de iterações bem definidas, chamadas de Sprints, com duração de um mês ou menos, nas quais são implementados os itens definidos no Backlog do Produto, resultando em algo que gere valor ao cliente.

Na reunião de planejamento da Sprint são avaliados quais pontos do Backlog de Produto serão atendidos durante aquele período, além da capacidade da equipe e as tarefas a serem desenvolvida por cada membro. Esta reunião resulta no Sprint Backlog, uma lista de tarefas específicas a serem executadas na Sprint.

Dentro de cada Sprint ocorrem reuniões diárias, conhecidas como Daily Scrum, de quinze minutos e no início do dia, que visam analisar os resultados das tarefas do dia anterior e definir quais tarefas serão executadas no decorrer do dia. Esta reunião diária é a chave para a inspeção e a adaptação, uma vez que melhora a comunicação, identifica impedimentos para o desenvolvimento, promove rápida tomada de decisão e melhora o nível de conhecimento do time.

Ao final de uma Sprint, são realizadas duas reuniões: a revisão da Sprint (Sprint Review) e a retrospectiva da Sprint (Sprint Retrospective). Na revisão da Sprint, o Product Owner e o time validam os itens entregues e avaliam se o objetivo foi atingido. Já na reunião de retrospectiva são discutidos os erros e acertos, fazendo os devidos ajustes para as Sprints seguintes.

Em resumo, a Sprint é uma caixa fechada que possui uma data determinada para iniciar e terminar, possuindo atividades bem definidas para serem cumpridas neste tempo, sendo justamente esta caixa fechada a maior qualidade da aplicação do Scrum. O conceito de “caixa” permite o controle total do que está contido dentro dela, possibilitando a percepção mais rápida de erros ou desvios e, consequentemente, a reação a estes problemas é mais ágil, evitando que eles causem danos maiores.

O método prevê, ainda, que seja dada visibilidade a todas as atividades em andamento ou já mapeadas no planejamento, com objetivo de estimular o engajamento dos envolvidos e o acompanhamento por parte de toda equipe. Isso se dá com o uso de quadros – o famoso Kanban – nos quais está explícito o que já está pronto, o que está em andamento e o que ainda falta ser feito.

Os times Scrum devem sempre ser enxutos, então no caso de grandes projetos, são criados vários times e o Scrum Master de cada um se reúne com os demais para um Scrum de Scrums.

Gestão Ágil ou Gestão Tradicional?

Os problemas com a aplicação de métodos de gerenciamento de projetos em produtos inovadores fizeram parte de intensos debates no início dos anos 2000, o que levou ao desenvolvimento de abordagens alternativas. Estas teorias com princípios, técnicas e ferramentas mais tarde foram rotuladas como Gerenciamento Ágil de Projetos.

Em métodos tradicionais de gestão, entende-se que o produto só faz sentido quando é entregue em sua totalidade, ou seja, apenas com 100% do projeto cumprido é que o cliente perceberá algum valor. Por outro lado, métodos ágeis podem ser usados em projetos nos quais um conjunto mínimo de funcionalidades já sirva para solucionar parte da necessidade do cliente, gerando valor ao seu negócio.

Ou seja, no método tradicional o projeto é um só, enquanto no ágil ele pode ser quebrado em pequenos projetos e entregas parciais.

Outro ponto importante entre os dois métodos é que, no ágil, quando combinado que o projeto irá entregar as funcionalidades mínimas, o cliente nem sempre tem noção do custo final do produto. Já nos métodos tradicionais, o valor é fechado junto com o escopo, o que sugere que não estão previstas alterações significativas nesse quesito durante o andamento do projeto.

Em suma, no método ágil a mudança é esperada e positiva, enquanto na abordagem tradicional ela é negativa e onerosa.

Em relação às “esteiras de trabalho” dentro das organizações, no método tradicional são implementadas estruturas formais para registrar os padrões de gerenciamento de projetos e não é possível se desviar deles. Por sua vez, nos modelos ágeis as equipes são enxutas, multidisciplinares e atuam de forma autogerida, de forma que cada colaborador se sente um gerente responsável pelas ações a ele delegadas.

Ou seja, no método ágil, desaparece a figura do gestor do projeto e entram as equipes auto-gerenciáveis.

A escolha entre modo tradicional e ágil não precisa ser um conflito, pois não existe uma máxima que defina que uma empresa precisa adotar um ou outro modelo de gestão de projetos. É preciso entender a diferença entre eles e analisar o projeto que será iniciado para então enquadrar a metodologia que melhor atenderá os objetivos.

Outro ponto a ser considerado quando está se decidindo por métodos tradicionais ou ágeis é a cultura da empresa. Muitas vezes, mesmo quando cabe no projeto um gerenciamento ágil, pode ser que isto não seja exequível se os agentes envolvidos não estiverem acostumados com entregas rápidas e percepção de valor antes do produto final.

Da mesma forma, quando o Scrum não se aplica por se tratar de projetos que não se adequam à metodologia de entregas contínuas e incrementais, ou se a expectativa do cliente seja de uma entrega final completa, aí cabe focar nos processos sugeridos pelo PMBoK.

Por sua vez, quando o cliente declara que tem menos tempo para a entrega do que seu próprio planejamento exigiria, o ideal seria partir para as possibilidades oferecidas por métodos ágeis e aplicar o Scrum.

Assim, o importante é estabelecer uma forma na qual as duas características sejam aliadas, valorizando as especificidades de cada uma. Seria um raciocínio no qual se teria à disposição toda a organização do PMBoK – em termos de processos, técnicas e ferramentas -, porém atuando em conjunto com a simplicidade e objetividade do Scrum.

Fica claro aqui que ambas abordagens são excelentes, mas não perfeitas e possuem fraquezas em áreas específicas ou em determinados tipos de projetos. No entanto, quando aplicadas em conjunto, podem fortalecer uma à outra.

No próximo artigo vamos entrar mais a fundo nas questões que envolvem a Ciência da Informação Geográfica e na gestão de projetos geoespaciais. Até lá!

Enquanto isso, cadastre-se para receber uma notificação por email de quando sair o próximo artigo e também de quando abrirem as inscrições para o Workshop gratuito sobre Gestão de Projetos Geo:


 

Eduardo Freitas Oliveira*, Idealizador do geoXchange, Co-Fundador do MDI, Consultor-Especialista no GEOeduc, Diretor de Operações do MundoGEO, Projetista na Engest Engenharia. Engenheiro Cartógrafo (UFPR), Técnico em Edificações (UTFPR), Especialização em Gestão Estratégica em EAD (Senac-SP), com mais de 20 anos de experiência em Obras Civis e Geotecnologia, atuando em empresas como Engebanc, Vertrag, Absoluta, Empresa Júnior de Cartografia da UFPR, entre outras. Coordenador do Instituto GEOeduc de 2014 a 2017. Diretor Financeiro da Associação Brasileira de Engenheiros Cartógrafos – Regional Paraná (ABEC-PR) 2013/2015, Membro da Associação Brasileira de Educação a Distância (ABED) e do Instituto de Engenharia do Paraná (IEP), Tradutor de 2007 a 2013 do Informativo para América Latina e Caribe da Associação para a Infraestrutura Global de Dados Espaciais (GSDI), Tradutor desde 2012 do Informativo do Fórum Ibero-Americano do Consórcio Geoespacial Aberto (OGC), Tradutor desde 2014 do Informativo GeoSUR, Membro da Equipe de Tradução do software livre QGIS – 2015/2016, Membro da Comissão Avaliadora das Jornadas Internacionais do software livre gvSIG – 2013-2014. Atuou como Gerente de Social Media, Editor das Revistas/Portais MundoGEO & DroneShow e Coordenador da Programação dos Eventos Presenciais (Seminários, Hackatons, MundoGEO#Connect & DroneShow) e Online (Webinars, Workshops) da MundoGEO. Liderou a participação da MundoGEO em Projetos de Cooperação Internacional envolvendo instituições latino-americanas e europeias. Autor do blog GeoDrops. Artigos publicados nas revistas Scientific American Brasil, GIS Development, entre outras. Participação no documentário Todo Mapa tem um Discurso. Criador do primeiro grupo de Mastermind de Geotecnologia (Geomind). Criador da página I See Maps All The Time. Palestrante em Conferências Nacionais e Internacionais sobre Tendências em Geotecnologia & Drones, (Geo)Marketing Digital, GeoEmpreendedorismo, Qualificação/Atualização Profissional e temas afins.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *