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 a percepçã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.

¹ Agile Modeling: Effective Practices for Extreme Programming and the Unified Process by
Scott Ambler
² Rational Requirements Composer
http://www.ibm.com/software/awdtools/rrc/
³ Exploring Requirements: Quality Before
Design by Donald C Gause and Gerald M Weingberg
The Psychology of Computer
Programming: Silver Anniversary Edition by Gerald M. Weinberg

*

artigo publicado originalmente no developerWorks Brasil, por Marília Coelho

Marília Coelho é especialista em TI da IBM Brasil, com certificação em IBM Rational Consultant – Rational Unified Process v2003.