Há cerca de um mês deparei-me com o artigo de Joe Marasco: “Software development productivity and Project success rates: Are we attacking the right problem?” . Ele toca num assunto que havia chamado minha atenção durante várias sessões de “project assessments” que eu me dediquei em 2005. Durante o ano passado participei da avaliação de cerca de 14 projetos ou organizações de desenvolvimento em 6 países da América latina (México, Brasil, Chile, Argentina, Peru e Colômbia), em diversos setores da economia (finanças, seguros, telecom, software houses, órgão públicos, energia) e abrangendo diversas tecnologias. Do desenvolvimento Java ao mainframe, da criação de produtos de prateleira à manutenção de ERPs. Nesses diagnósticos dois aspectos se sobressaíram.
O primeiro deles está relacionado ao estágio de desenvolvimento que a indústria de software se encontra em nossa região. É interessante notar que não há diferenças significativas de maturidade entre os projetos dessa pequena amostra. Estamos todos mais ou menos com as mesmas questões e caminhando na mesma direção.
O outro aspecto está relacionado a um problema comum a todos os projetos analisados: levantamento de requisitos . Não importa o sintoma apresentado pela equipe: “Não conseguimos testar, os sistemas são muito voláteis” ou “Os usuários mudam de idéia muitas vezes” ou “Tudo muda o tempo todo”. O fato é que todos os projetos analisados usam técnicas muito primárias para levantamento de requisitos. É quase como se quisessem tirar esse “problema” da frente e começar a desenvolver. É esse ponto que gostaria de explorar um pouco mais.
O interessante é que quase todas as equipes possuem bons padrões de documentação de requisitos: especificações funcionais, modelos, planilhas, etc. Entretanto, praticamente todos os grupos usam apenas uma técnica de levantamento de requisitos. Muitos deles recebem as especificações escritas e as tomam como boas, sem um aprofundamento maior, seja do problema ou da solução. É quase como se uma testemunha fosse interrogada apenas pelo promotor ou pelo advogado de defesa, sem nenhuma verificação ou busca de contradições no seu depoimento.
O senhor Marasco coloca esse tema sobre outro ponto de vista. Ele apresenta um contraste entre o importante ganho de produtividade das equipes de nas últimas décadas e a relativa pequena melhora na taxa de êxito nos projetos. Segundo o Chaos Report , publicado desde 1994 pelo Standish Group, a taxa de sucesso em projetos passou de 16% em 94, para 28% em 2001 e 31% em 2003. Nesse ritmo, apenas em 2014 vamos conseguir fazer com que metade dos projetos de desenvolvimento tenha sucesso.
Joe Marasco defende a tese que estamos sendo muito bons em desenvolver novas soluções, mas pouco eficientes em levantar o problema correto e os requisitos corretos. Ou seja, fazemos mais rápido e com técnicas mais sofisticadas as soluções erradas.
A prática de gerência de requisitos nos ensina que devemos combinar várias técnicas para levantar e esclarecer os requisitos. Assim conseguiremos validar o que um grupo está nos dizendo, o reinquirindo de outras formas e/ou comparando suas repostas com as de outros grupos. Técnicas como entrevistas, questionários, workshops, brain storms, entre outras, são raramente usadas de forma combinada com esse propósito.
Nossa experiência tem mostrado que não basta o uso de técnicas como casos de uso e desenvolvimento iterativo ou o uso de ferramentas de gerência de requisitos que permitam controlá-los, acompanhar suas mudanças e manter a rastreabilidade entre eles e os demais artefatos de software. Tudo isso é importante e garante um ganho de produtividade significativo, mas o uso de técnicas mais sofisticadas de levantamento é chave para quebrarmos o ciclo de construir a aplicação que achamos ser correta, receber as críticas, tentar novamente,...
Muitas vezes o simples treinamento em conjunto dos analistas de negócio, usuários e o pessoal de sistemas nas técnicas corretas, como aquelas descritas no RUP , reduzem graves problemas de entendimento entre os dois grupos. Em outras, o uso de uma consultoria especializada pode ajudar à organização a reduzir o abismo entre as áreas, diminuindo o estresse e facilitando o sucesso coletivo.
Como um colega costuma dizer: “Os usuários sabem o que querem, mas em geral não sabem descrevê-lo! Mas quando o vêem sabem identificá-lo”. Somente com um trabalho sistemático de levantamento das necessidades de negócios, dos requisitos de software, das especificações funcionais e não-funcionais, suportado por ferramentas que possibilitem o gerenciamento e a colaboração é que poderemos levar nossas equipes de desenvolvimento a um novo patamar. O patamar de produtividade e qualidade que nossas organizações precisam para competir no mundo plano .
Referências:
“Software development productivity and Project sucess rates: Are we attacking the right problem?”, por Joe Marasco, CEO, Ravenflow:
http://www-128.ibm.com/
“Requirements: An introduction” por Scott McEwen, Metasys Technologies, Inc.
http://www-128.ibm.com/
Para mais informações ver: http://www.standishgroup.com
“Dissecting business from software requirements” por Jochen Krebs:
http://www-128.ibm.com/
RUP - Rational Unfied Process
http://www-128.ibm.com/
