UMA IDEIA DA GESTÃO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE PARA A ÁREA DA CONSTRUÇÃO
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.
Os clientes podem não saber 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 foi cumprido 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. Traz 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 na fase de construção pela sua natureza.
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 se apoiam 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:
O que fiz ontem?
O que vou fazer hoje?
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á-la em agentes ativos em todo o processo de execução, planeamento e gestão de riscos.
Ana Relvas
Ph.D. Engenharia Aeroespacial | Consultora de Desempenho | Coach
Tem uma história para partilhar? email EngenhoeArte@yahoo.com
Comments