Einstein certa vez afirmou que se ele tivesse uma hora para salvar o mundo, gastaria 55 minutos definindo o problema e apenas cinco minutos buscando a solução. Exceto pela proporção do tempo dedicado ao problema e à solução, concordo inteiramente com a importância que Einstein dava ao entendimento do problema antes de partir para a resolução do mesmo.
O entendimento do problema na engenharia de software deve acontecer logo no início da etapa de definição dos requisitos do sistema. Um problema mal entendido implica em requisitos mal definidos e incompletos, que causam o fracasso de projetos. Há anos a estatística de projetos que falham e os custos associados a estas falhas trazem números desanimadores. O Standish Group listou alguns dos fatores relacionados a este fracasso:
- 41% dos projetos falham em adicionar valor ao negócio e sobre o Retorno de Investimento – ROI
- 49% dos projetos ultrapassam as estimativas iniciais de custo
- Somente 28% dos projetos acontecem no prazo e no orçamento
O Standish Group também associa o tamanho do insucesso com os seguintes fatores: falta de envolvimento do usuário, falta de clareza nos objetivo de negócio, incapacidade de se capturar requisitos básicos, falta de controle do escopo do projeto e falta de suporte executivo.
O IDC (International Data Corporation) é ainda mais específico em apontar as causas do fracasso em projetos. Segundo o instituto, mais de 80% das falhas em desenvolvimento de software resultam diretamente de problemas no levantamento, na gerência ou na análise dos requisitos.
Os números mostram que Einstein tinha uma certa razão. Investir tempo no espaço do problema em termos de desenvolvimento de software significa entender os objetivos de negócio, identificar corretamente os processos envolvidos, fazer as perguntas apropriadas para explorar o problema, utilizar técnicas capazes de descrever o que o sistema deve fazer e para quê ele está sendo criado. Apesar de parecer óbvio, por que esta questão reconhecida na indústria de software é tão difícil de ser resolvida?
Podemos descrever alguns motivos:
- É típica da natureza humana a ansiedade por buscar uma solução rapidamente para algo que lhe foi demandado, muitas vezes ignorando o entendimento detalhado da demanda. Esta ansiedade acontece em diversos níveis, pois o gerente de projeto e o coordenador da área também só sentem progresso quando veem algo palpável como linhas de código.
- Não é confortável para analistas e engenheiros de sistemas navegarem em áreas de conhecimento muitas vezes desconhecidas, como os processos de negócio e conhecimentos da indústria. É mais fácil falar sobre tabelas, relatórios, funções e dados.
- O baixo envolvimento do usuário durante o projeto está muitas vezes relacionado à cultura imposta pelo processo de desenvolvimento em cascata, muito utilizado ainda no Brasil, que envolve o usuário no início do projeto para definição dos requisitos e somente depois, no final, para o aceitamento do sistema.
A boa notícia é que existem caminhos para iniciarmos a solução dos problemas relacionados ao desenvolvimento de software. É necessária uma mudança de cultura para implantarmos ou aumentarmos a maturidade da engenharia de software. Esse processo exige investimentos em 3 pilares: processo, ferramentas e pessoas.
Em termos de processos, houve uma grande evolução nos últimos anos. Podemos citar os processos ágeis como o Agile Unified Process ou o XP (Extreme Programming), cada um com suas características próprias e que defendem pontos básicos relacionados a requisitos, como envolvimento constante do usuário, não especificação de todos os requisitos no início do projeto e iterativamente e utilização de técnicas apropriadas para facilitar o processo. Scott W. Ambler, em seu livro “Agile Modeling: Effective Practices for Extreme Programming and the Unified Process” explica o quão importante é a modelagem e a documentação de qualquer projeto de software, incluindo os projetos ágeis. Ele enfatiza que técnicas tradicionais, como JAD, casos de uso, entrevistas, observação, entre outras, podem ser adaptadas aos processos ágeis.
Em termos de ferramentas, alguns agilistas extremados defendem o uso de papel simplesmente. Outros utilizam algumas técnicas e ferramentas. Considerando que o sistema é algo que vai existir na organização durante anos ou décadas e vai sofrer manutenção, é preciso utilizar recursos que facilitem a documentação e a alteração da mesma. Além do fato de que o desenvolvimento geograficamente distribuído está se tornando cada vez mais comum, a necessidade de um suporte ferramental para desenvolvimento colaborativo é premente.
Já o sucesso das vendas está diretamente relacionado à capacidade das pessoas envolvidas em entender os problemas de negócio do cliente. O profissional de Marketing precisa entender as necessidades do mercado e o comportamento do consumidor. É preciso saber lidar com pessoas, com percepções diferentes, saber se colocar no lugar do outro para genuinamente entender suas dificuldades e necessidades.
Para que os três pilares – processo, ferramentas e pessoas – funcionem de forma harmônica na organização, o suporte executivo é fundamental, pois as ansiedades, e a pressão do “fazer para ontem” são forças que devem ser gerenciadas corretamente. Os números mostram que continuar como está não é bom para o negócio e não é bom para TI. Pense em fazer algo para mudar o futuro da engenharia de software, conseqüentemente mudando a percepção de que TI não é um centro de custo, mas sim uma área que agrega valor ao negócio através da inovação tecnológica.
Nota sobre a autora: Marília Coelho é especialista em TI da IBM Brasil