Categorias
Tech

3 motivos para a falha de projetos de software

Trabalhando por muitos anos no desenvolvimento, já tive a oportunidade de participar de muitos projetos de software. Boa parte deles como membro de equipe, alguns como Scrum Master e outros como freelancer, fazendo todo o trabalho sozinho.

Isso me trouxe alguma experiência no quesito projeto de software.

Acompanhei projetos que deram muito certo e outros que nem tanto. Sobre estes sempre fica a pergunta: “por que este projeto falhou?”.

Cada projeto tem suas características específicas, mas para me aprofundar mais nos motivos gerais das falhas resolvi fazer uma rápida pesquisa para procurar artigos acadêmicos que falam sobre esse assunto.

Analisando alguns deles fica claro quais são os principais motivos listados.

  • objetivos não realistas ou não articulados
  • software que não atende às reais necessidades do negócio
  • requisitos de sistema, requisitos dos usuários e especificação de requisitos mal definidos
  • gestão de projeto deficiente
  • metodologias/práticas de desenvolvimento desleixadas
  • prazos e orçamentos do projeto
  • estimativas imprecisas dos recursos necessários
  • má comunicação entre clientes, desenvolvedores e usuários
  • uso de tecnologia imatura
  • pressões comerciais
  • satisfação do cliente
  • qualidade do produto
  • entre outros (lista completa neste artigo)

Como podemos perceber, são muitas as possíveis causas de um projeto de software ser malsucedido.

Essas pesquisas foram feitas com diversos projetos e estão em artigos espalhados por aí, mas eu quero focar naqueles motivos que já senti na pele, como um envolvido no projeto.

1. Requisitos de sistema mal definidos

Este é um caso muito mais comum do que se imagina. Acontece o tempo todo e já passei por diversos projetos com esse problema, por isso ele está no topo da minha lista.

Análise de requisitos é um processo complicado e demorado. É preciso da atenção de um profissional especialista e que vai conseguir levantar exatamente tudo que é preciso para que aquele projeto de software atenda às necessidades dos interessados.

Isso faz parte de projetos de softwares mais tradicionais e não necessariamente funciona do mesmo jeito em projetos ágeis, em empresas que necessitam de entregas mais constantes como as startups de tecnologia ou que possuem prazo e orçamento mais apertado como as fábricas de software menores.

Acontece que não ter um levantamento de requisitos tradicional não libera ninguém de levantar requisitos.

Talvez alguns gestores não entendam que o uso de métodos ágeis não é desculpa para que as descrições de tarefas sejam muito bem pensadas e completas.

“Gastar” tempo levantando requisitos bem definidos com os stakeholders (as partes interessadas no projeto) aumenta as chances de uma entrega mais assertiva e rápida do software.

2. Gestão de projeto deficiente

Eis um tópico extremamente genérico e que afeta muito os projetos de software. Uma má gestão pode significar diferentes problemas para a equipe, incluindo o tópico anterior.

Mesmo que as equipes ágeis sejam autogerenciáveis segundo a teoria, normalmente existe alguém que centraliza essa tarefa mais do que os outros membros. Além disso, em muitos casos, os executivos da empresa costumam não permitir tanta autonomia para que a equipe se gerencie.

A gestão de projetos deficiente acaba tendo um impacto muito grande na motivação da equipe, na falha de comunicação, na necessidade de retrabalho, na má administração dos recursos e dos prazos, etc.

Já presenciei alguns casos de má gestão e a responsabilidade pela falha do projeto costuma sobrar para os membros da equipe…

3. Qualidade do produto

Em alguns casos na minha experiência o produto tinha um potencial incrível, poderia trazer muito valor para os usuários… mas simplesmente não funcionou quando eles precisaram.

A qualidade do produto faz parte do valor agregado entregue em qualquer projeto.

É muito comum existir um membro da equipe focado nesse assunto. Uma pessoa para garantir a qualidade do software e mantê-lo sempre na sua melhor versão possível, sem erros e sem problemas de usabilidade.

Projetos de software que falham por falta de qualidade do produto não precisam de muita explicação, não é…

Eis um investimento que vale a pena, mas que muitas vezes é subestimado pelos responsáveis do projeto.

Entre outros…

Os motivos selecionados aqui são os que mais me chamaram a atenção por acontecerem em diversos projetos os quais eu participei. Por isso estão nesta lista em ordem de importância.

Na minha experiência pessoal eu não vejo um motivo específico para a falha de projetos de software e sim uma combinação de problemas que se acumulam e minam o projeto como um todo.

Em diversos dos casos que presenciei mais de um desses itens estavam combinados com outros também descritos na primeira lista retirada dos artigos pesquisados no início dessa publicação.

O que fazer?

Pessoalmente, acredito que uma das formas de evitar a falha de um projeto é ouvindo as pessoas envolvidas. Aproveitar a experiência de quem participa do desenvolvimento para tentar entender o que está acontecendo durante todo o processo.

Uma liderança mais aberta e que se importa com a opinião dos envolvidos tem maior chance de identificar um possível motivo de falha antes que o mesmo se torne irreversível para o projeto.

A chave é não esperar o projeto chegar em um nível crítico para então parar para analisar o que pode estar dando errado.

Por isso as empresas que mais crescem e entregam tecnologias incríveis valorizam tanto os profissionais que colaboram para que isso aconteça. Mantendo sempre um ambiente com menos fricção para comunicação e mais atenção ao que está acontecendo durante as iterações de desenvolvimento.

Para você, quais são os maiores motivos para a falha em projetos de software? Deixe sua opinião sobre o assunto nos comentários.

Até a próxima!

Categorias
Crônicas Tech

The King of the Sprint

Nesta segunda-feira recebi o prêmio recém inventado na minha equipe de trabalho: “The King of the Sprint“. O presente ao ganhador era uma caneca com uma ilustração dos membros do grupo com os dizeres “The King of the Sprint”. =)

Mas o que diabos é Sprint? Pra saber isso, primeiro vamos saber o que é Scrum, via Wikipédia.

O Scrum é um framework para desenvolvimento ágil e Gerenciamento de Projetos.

A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.

E sprint?

Sprint é uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.

Simplificando ao extremo, Sprint é um ciclo de tarefas dentro do projeto. E nosso prêmio seria entregue aquele que vencesse o maior número de tarefas dentro deste Sprint. Desta vez o vencedor fui eu!

Mas o mais legal de tudo é que não existe uma competição entre nossa equipe e o pessoal se divertiu muito com essa brincadeira. E no final eu saí com uma caneca novinha!