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

Por Marilia Coelho – IBM Rational IT Specialist

Einstein afirmou que se ele tivesse 1 hora para salvar o mundo, ele gastaria 55 minutos definindo o problema e apenas 5 minutos buscando a solução.

Marília Coelho, Especialista em TI, IBM

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



08/Dez/2009

Exceto pela proporção do tempo dedicado ao problema e a 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 estas 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 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 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. Esta 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 vêem algo palpável como linhas de código. Nenhum problema nisto 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 tem 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. A IBM Rational defende 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 falicitem 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. Neste 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 esta 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 conseqüentemente não serão utilizadas, pois sua percepção da situação desejada pode estar distorcida. Uma evidência disto é 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 a 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 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 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.

1 Agile Modeling: Effective Practices for Extreme Programming and the Unified Process by Scott Ambler
2 Rational Requirements Composer – http://www.ibm.com/software/awdtools/rrc/
3 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

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=430050
ArticleTitle=Precisamos ser mais psicólogos que engenheiros para ter sucesso com engenharia de software
publish-date=12082009