Precisamos ser mais psicólogos que engenheiros para ter sucesso com engenharia de software

Einstein afirmou que se ele tivesse uma hora para salvar o mundo, ele gastaria 55 minutos definindo o problema e apenas 5 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 solução do mesmo.

Entendimento do problema na Engenharia de Software deve acontecer no início da etapa de definição dos Requisitos do Sistema. Problema mal entendido implica em requisitos mal definidos, incompletos que causam insucesso dos projetos. Há anos a estatística de projetos que falham e os custos associados a essas falhas trazem números desanimadores. Somente para citar alguns:

• 41% dos projetos falham em adicionar valor ao negócio e Retorno de Investimento – ROI.
• 49% dos projetos ultrapassam as estimativas iniciais de custo.
• Somente 28% dos projetos acontecem no prazo e no orçamento.

(Fonte: Standish Group)

O Standish Group também associa tamanho 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 ainda é mais específico em apontar as causas do fracasso. Segundo o IDC, mais de 80% das falhas em desenvolvimento de software resultam diretamente de problemas no levantamento, na gerência ou na análise dos requisitos.

Segundo o IAG Consulting, mais de 40% do budget de TI será consumido por especificações pobres de 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 envolvidos, fazer as perguntas corretas para explorar o problema, utilizar técnicas apropriadas para ser capaz de descrever o que o sistema deve fazer e para que ele está sendo criado. Apesar de parecer óbvio, por que essa questão reconhecida na indústria de software é tão difícil de endereçar?

Eu enumeraria alguns motivos:

• É típica da natureza humana a ansiedade por buscar a solução rapidamente para algo que lhe foi demandado. O analista mais inexperiente principalmente sente-se desafiado a resolver a questão, ignorando o entendimento detalhado da demanda. Muitas vezes fica pensando se vai ou não utilizar aquele componente que fez no projeto anterior enquanto o usuário continua explicando suas dificuldades em vão. Essa ansiedade pela solução 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. Nenhum problema nisso desde que não incentivem o início da implementação ignorando a importância do entendimento dos problemas de negócio.
• Não é confortável para analistas e engenheiros de sistemas navegar em áreas de conhecimento muitas vezes desconhecidas como os processos de negócio e conhecimentos da indústria. É sempre mais fácil falar sobre tabelas, relatórios, funções e dados.
• Falta de preparação dos profissionais de TI pela maioria das faculdades e universidades nos cursos relacionados à área. Somos bem treinados em termos de ciência e engenharia da computação. Sabemos sistemas operacionais, estatística, cálculos, física, compiladores, linguagens de programação, etc. Não existe foco em termos de ciências humanas ou psicologia para aprendermos a nos comunicar com pessoas que não têm conhecimento técnico.
• 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 aceite do sistema.

A boa notícia é que existem caminhos. Através da IBM Rational, conseguimos defender que a mudança de cultura necessária para se implantar ou aumentar a maturidade de uma disciplina de engenharia de software exige investimento em 3 pilares: processo, ferramentas e pessoas.

Em termos de processo, houve uma grande evolução nos últimos anos. Pode-se citar o Rational Unified Process tradicional, os processos ágeis como o Agile Unified Process ou o XP (Extreme Programming), cada um com suas características próprias em maior ou menor ênfase, defendem pontos básicos relacionados a requisitos como: envolvimento constante do usuário e envolvidos, não especificação de todos os requisitos no início do projeto, mas sim 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 e a participação constante dos envolvidos é ponto fundamental de sucesso. O grau de formalismo no uso da técnica e o tempo dedicado às atividades é que variam de acordo com o processo.

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 de ferramental para desenvolvimento colaborativo é premente.

Nesse ponto, o Rational Requirements Composer (RRC)² é uma excelente opção, seja para desenvolvimento ágil em projetos que exijam menos formalismos, seja para projetos tradicionais muitas vezes sujeitos ao cumprimento de regulamentações e auditoria. O RRC é construído sobre a plataforma colaborativa Jazz da IBM e possui recursos para suportar as etapas de entendimento do problema, levantamento e definição dos requisitos. O produto complementa a plataforma Rational que já possui ferramenta para gerenciamento de requisitos.

Em termos de pessoas é preciso primeiramente selecionar analistas que tenham perfil adequado, fornecer treinamento e mentorização. Existem técnicas, e boas práticas que podem aperfeiçoar o trabalho da equipe. Donald Gause e Gerald Weinberg³ definem problema como sendo a diferença ou o gap existente entre apercepção da situação atual e a situação desejada. Dada essa definição, existem diferentes formas de resolver o problema. Nem sempre a melhor solução é fornecer a situação desejada. A mudança de percepção da situação atual pode alterar a definição do problema.

A maioria das solicitações de melhoria recebidas pela Microsoft, por exemplo, para produtos como Word, são de funcionalidades já existentes no produto. A solução correta seria então mudar a percepção da situação atual, através de um treinamento, por exemplo. A explicação do custo envolvido ou de outros aspectos de uma solução pode mudar a percepção do cliente sobre a situação desejada. Algumas vezes o cliente solicita funcionalidades que não resolverão o problema dele e consequentemente não serão utilizadas, pois sua percepção da situação desejada pode estar distorcida.

Uma evidência disso é a estatística publicada pelo Standish Group: “Tipicamente entre 20-40% das linhas de código dos sistemas não são utilizadas”. Técnicas de análise de problemas nos ensinam a fazer perguntas corretas, mudar o foco para explorar diferentes pontos de vista, quebrar o problema a fim de encontrar a raiz do que aparentemente é um problema, mas é apenas um sintoma.

O mais fantástico é que tais habilidades em geral formam o profissional para ser bem sucedido em outras profissões. O sucesso em vendas está diretamente relacionado à capacidade de entender os problemas de negócio do cliente. O profissional de Marketing precisa entender as necessidades do mercado e o comportamento do consumidor. Uma boa capacidade de comunicação e de análise de problema ajuda nos relacionamentos familiares. Ser capaz de entender as razões do comportamento do filho adolescente pode ser mais difícil que entender as resistências e dificuldades que você pode encontrar para entender seu cliente.

É preciso saber lidar com pessoas, com percepções diferentes, saber se colocar no lugar do outro para genuinamente entender suas dificuldades e necessidades. Alguns têm facilidade nata, outros precisam reconhecer suas limitações e aperfeiçoar suas habilidades através de técnicas e treinamentos adequados.

Curiosamente, há exatamente 37 anos o mesmo Weinberg publicou o livro “The Psycology of Computer Programming”. O livro é considerado atual até hoje, e as mesmas questões básicas e óbvias persistem por décadas. Segundo o autor, um pouco de psicologia e ciências humanas seria a chave para o sucesso individual e de equipes de desenvolvimento.

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 a TI. Pense em fazer algo para mudar o futuro da engenharia de software, consequentemente 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.

By: ED.