Todo responsável por projetos, gerente ou empresa, deseja que o mesmo atenda as especificações dos requisitos, seja executado no menor tempo e possua o menor custo possível. Neste cenário ideal, precisa-se atentar a qualidade que se pretende obter tanto no produto quanto no ciclo de vida do mesmo, contemplando o período pós-implantação com prováveis manutenções corretivas e evolutivas.
Quem gerencia projetos, ou já contratou empresas para executar projetos, sabe que podemos diminuir custos e diminuir prazos deixando de realizar fases importantes do mesmo, tais como fase de levantamento e análise de requisitos, design e documentação. Outra maneira é a de diminuir a própria qualidade do produto a ser desenvolvido, omitindo ou diminuindo a fase de testes.
É justamente aqui que vai se armando uma grande armadilha. Alguns envolvidos podem não estar cientes das consequências geradas para a empresa que estará recebendo o produto, pela decisão de omitir fases ou deixar de gerar documentação do projeto.
Para ilustração, comento que existem requisitos conhecidos como requisitos não funcionais, relacionados a características do software que estão embarcados na solução mas que não são funcionalidades utilizadas diretamente pelo usuário, descrevendo qualidades do sistema.
Um exemplo de requisito não funcional é o de confiabilidade, garantindo que as informações disponibilizadas pelo sistema a ser desenvolvido sejam fidedignas. Não conseguimos atingir esta meta se não realizarmos a fase de requisitos e de análise em nosso projeto.
Caso o projeto não atinja este quesito, apresentando informações consideradas não fidedignas pelos usuários, nenhum deles se interessará em utilizar o mesmo e o projeto fracassará, e todo o investimento será perdido. Tive a oportunidade de ver funcionários de uma grande empresa comentando justamente isto, que não utilizavam um sistema da mesma por não confiarem nas informações apresentadas.
Isto pode ser evitado caso o projeto utilize uma Metodologia de Desenvolvimento de Sistemas adequada.
Imagine agora um cenário de um sistema de Cobrança bancária, para o qual você poderia estar participando de um processo de manutenção corretiva, sem ter documentação do sistema e sem ter conhecimento das regras de negócio implementadas. Imagine também que esta manutenção está relacionada à correção de informações, que estão sendo geradas incorretamente Agora, para finalizar, imagine que o sistema possui milhares de linhas de código no paradigma procedural e você é novo na equipe e foi contratado recentemente, sendo que os programadores que implementaram o sistema não estão mais na empresa.
Por mais que este cenário seja assustador, podemos encontrá-lo neste exato momento em diversos lugares, enquanto você lê este parágrafo.
O que faltou no projeto de desenvolvimento deste tipo de sistema?
Entre outros, poderia citar:
- Utilização de Metodologia de Desenvolvimento de Software e os produtos de cada fase.
- Engenharia de Software e utilização de processos definidos.
- Utilização de paradigma de desenvolvimento Orientado a Objetos.
- Utilização de Design Patterns, caso coubesse.
- Documentação adequada.
Do lado humano, poderia citar:
- Participação no projeto de profissionais com conhecimento dos itens técnicos acima relacionados.
- Falta de percepção do sponsor responsável pelo projeto do valor e benefícios de se utilizar os itens acima relacionados.
- Falta de conhecimento dos envolvidos no projeto, das melhores práticas de mercado para desenvolvimento de software e de seus benefícios.
Já tive a oportunidade de presenciar de empresários e executivos, o seguinte comentário:
“Prefiro o desenvolvimento de software sem utilizar Orientação a Objetos e processos de desenvolvimento, pois é mais barato e mais rápido de se disponibilizar o sistema para os usuários.”
Desenvolver código baseado nesta ideia pode gerar as seguintes consequências:
- Implantação de sistemas cheios de erros, constantemente entrando em manutenção corretiva.
- Sistemas que podem não atender às expectativas dos Stakeholders.
- Softwares com alto custo de manutenção.
- Softwares difíceis de serem utilizados, não atendendo às necessidades dos StakeHolders.
- Grande insatisfação dos usuários.
- Fracasso do projeto.
O desenvolvimento de sistema sem utilizar processos, AD HOC, acaba custando muito mais caro, gerando insatisfação.
Já presenciei várias vezes, pessoas que simplesmente não queriam e não utilizavam sistemas disponibilizados pela empresa, por pelo menos um dos seguintes motivos:
- Não confiavam nos dados por eles apresentados.
- Porque não atendiam a suas expectativas e necessidades do dia a dia.
- Porque tinham usabilidade ruim.
- Porque viviam apresentando problemas de funcionamento.
O detalhe mais triste é que as empresas onde estas pessoas trabalhavam, investiram dinheiro e tentaram disponibilizar sistema para melhorar a produtividade e diminuir custos das mesmas. O resultado foi exatamente o contrário pois além de não diminuir custos, nem aumentar produtividade, as empresas perderam todo o investimento realizado e o sistema caiu em desuso, literalmente, sendo jogado fora.
Realizar um projeto omitindo fases cria uma grande armadilha, para a empresa que está adquirindo o sistema.
Para saber mais, leia o livro Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1
4 Comentários
Infelizmente esse é o dia-a-dia de uma empresa. Gerentes estão preocupados e agilizar e cortar custos e negligenciam muitas, muitas coisas.
Resultado? 100% das vezes algo sai errado ou o prazo não é cumprido.
Lamentável.
Utilização de Design Patterns, caso coube-se. Vc quis dizer caso coubesse?
E é bom saber também que já vi casos de utilizarem todos os passos da metodologia (cascade, por exemplo), mas sem comprometimento nenhum com a “verdade”; as fases eram aprovadas PORQUE os documentos estavam feitos, mas ninguém conseguia “ver” se estavam CERTOS e por isso MESMO aprovavam (os loucos lá devem saber o que estão fazendo!!).
E tudo foi por água abaixo, com metodologia e tudo.
SOMENTE seguir uma metodologia não garante o resultado.
Aliás, vi isso num sistema de cobrança bancária, exatamente o mesmo do seu exemplo. E vivi sistema de cobrança bancária sem metologia nenhuma funcionando e muito bem gerenciado SEM metologia nenhuma e por mais de 20 anos.
Concluo que sem o comprometimento das pessoas com os resultados Não há metodologia nenhuma que resolva (algumas ajudam, outras atrapalham demais).
Como determina a Lei de Murphy : “Se alguma coisa pode dar errado, com certeza dará” .
Concordo com o Carlos Tadeu.
O mais importante é o comprometimento das pessoas com o projeto. Uma metodologia só irá resolver o “problema”, se houver compromisso por parte dos envolvidos.