Quando comecei a fazer a pesquisa para este artigo confesso que estava com maiores expetativas de como algumas práticas na gestão de projetos de software estivessem a ser usadas na área da construção. Começa a haver alguma investigação e pilotos mas os resultados para já não são extraordinários. Hoje partilho um pouco do que têm os projetos de software e construção em comum e uma ideia que pode trazer valor.

O que têm os projetos de software e construção em comum?

A gestão de um projeto de desenvolvimento de software e de construção, pela sua natureza, têm algumas coisas em comum em particular alguns dos problemas:

• São projetos em que quanto mais cedo for identificado um erro ou alteração, menos custa corrigi-lo já que “o custo de correção dos defeitos cresce e exponencialmente à medida que o processo de desenvolvimento avança dentro do ciclo de vida do sistema”. Uma inconsistência, erro ou alteração em fase de projeto é muito mais facilmente corrigida do que em obra onde destruir e corrigir custa recursos e tempo. Uma alteração durante a fase de construção pode custar 100 vezes mais a implementar do que a mesma alteração na fase de projeto.
• Com frequência, os clientes não sabem o que querem e/ou querem alterar o âmbito ao longo do projeto.
• São projetos cujos stakeholders têm muitas vezes expetativas irrealistas em particular desejam prazos difíceis de cumprir. Muitas vezes colocar mais recursos não faz o projeto andar mais depressa.
• São projetos que podem ter pessoal com qualificações menores do que a desejável. É certo que num projeto de software a equipa é na maior parte das vezes constituída por engenheiros mas a sua inexperiência na tecnologia ou serem muito novos tem impacto no desempenho da equipa se isso não for tido em conta.
• Um projeto de desenvolvimento de software pode envolver várias empresas em que cada uma é responsável por uma parte do software e depois tudo tem de funcionar em conjunto.
• Quem gere o projeto são pessoas muitas vezes com conhecimento técnico que assumiram funções de gestão sem terem formação na área de gestão.

Metodologias ágeis de gestão

Sendo uma indústria mais recente, a área de desenvolvimento de software é mais madura do ponto de vista de gestão de projeto. A gestão de projetos de software é uma área de conhecimento por si só e há um grande esforço em desenvolver metodologias que apoiem uma produção que responda às necessidades dos clientes.

No início, os projetos de software seguiam um modelo de desenvolvimento chamado waterfall/cascata muito semelhante à estrutura dos projetos de construção. De um modo muito simplista estes projetos eram (e ainda são) constituídos pelas seguintes fases que são realizadas de um modo sequencial.

• Fase de levantamento de requisitos onde são levantadas quais as necessidades do cliente e o que o software deve fazer.
• Fase de desenho/projeto em que é desenhada a arquitetura do software (os vários módulos, como funcionam e como comunicam entre eles).
• Fase de desenvolvimento onde os engenheiros começam a programar (até aqui foi só papel…).
• Fase de teste e integração onde o software é testado com base numa lista de testes criados para validar se CADA UM dos requisitos foram cumpridos e se os vários sistemas funcionam entre si.
• Fase de validação/aceitação pelo cliente.

Este modelo implica muitas vezes que não se passa à fase seguinte até o produzido (por exemplo o documento de requisitos) ser aprovado pelo cliente. Tem também alguma dificuldade em acomodar alterações ou correção de erros.

Com o tempo, e à medida que os projetos de software foram crescendo em dimensão e complexidade, foram sendo criadas metodologias denominadas ágeis que nasceram para acomodar as derrapagens de tempo, custo e a criação de software que responda às reais necessidades.

Estas metodologias são iterativas e incrementais e em cada iteração focam-se na definição de requisitos, desenho, implementação e testes de uma parte do software. Isto permite ao cliente ir vendo o resultado e acomodar mudanças mais facilmente.

Algumas estratégias para experimentar

Na área da construção estas metodologias têm muitas vantagens na fase de projeto mas estão limitadas, pela sua natureza, na fase de construção.

Na fase de projeto materializam-se com um maior envolvimento do cliente, uma melhor comunicação e interligação entre os projetos das várias especialidades, e um melhor planeamento e estimativas.

No entanto, muitos clientes não são maduros o suficiente para se envolverem no processo ou quererem investir nele. Na prática, como os contratos são construídos de modo a que o risco está muitas vezes do lado do construtor, não há muitos incentivos para o cliente minimizar os riscos na fase de projeto.

Durante a fase de construção alguns conceitos destas metodologias trazem valor embora a baixa qualificação das equipas e o alto número de subcontratados (o que limita a sua lealdade) possa ser um obstáculo já que estas metodologias apoiam-se na ideia da auto-organização da equipa que executa.

Um dos conceitos principais das metodologias ágeis é a criação de equipas motivadas com um papel ativo. As equipas são encorajadas a contribuir no como fazer as coisas de um modo melhor, mais rápido, a identificarem as causas de problemas e atrasos e como os corrigir.

Uma estratégia usada para envolver os membros da equipa, planear e gerir riscos é a promoção de reuniões diárias curtas e altamente focadas. Acho particularmente interessante e útil a estrutura das reuniões diárias, presenciais, sempre à mesma hora, de 15 minutos da metodologia Scrum. Cada membro da equipa deve estar preparado para responder às perguntas seguintes:

1- O que fiz ontem?

2 – O que vou fazer hoje?

3 – Quais são os obstáculos no meu caminho?

Para todos é claro qual é o objetivo desse sprint (o objetivo de produção entre uma semana a um mês) e como estão a contribuir para ele.

A resposta a estas perguntas traz visibilidade a todos do progresso, dependências e uma visão global do que está a ser feito. Constrói também uma equipa capaz de contribuir para a resolução dos obstáculos mesmo quando não estão diretamente envolvidos.

Deixo a ideia…para pensar como se pode envolver mais a equipa e transformá-los em agentes ativos em todo o processo de execução, planeamento e gestão de riscos.

Se estes temas lhe interessam, convido-o a inscrever-se aqui na newsletter só para diretores de obra.