Os requisitos e o sucesso do seu projeto.

Artigo reproduzido na integra.

Antes de começar de fato este artigo, quero passar algumas informações que colhi na minha pesquisa:(?)

·        Mais de 30% dos projetos são cancelados antes de serem completados

·        Mais de 70% dos projetos falham na entrega das funcionalidades esperadas

·        A média de falhas de projetos estoura em mais de 189% do orçamento e extrapola em 222% do cronograma previsto

·        Os seguintes fatores ajudam:

·        Falta de informações dos usuários:                                12,8%

·        Requisitos/especificações incompletos                          12,3%

·        Ausência de gerência de mudanças e especificações     11,8%

O propósito da  gerência de requisitos é estabelecer um entendimento comum entre o cliente/usuário e a equipe de IT/desenvolvimento em relação aos requisitos do cliente/usuário.

Parece simples mas não é!  O desafio é tão grande que está presente até nas especificações do CMM (Capability Maturity Model).  Além disto, estes requerimentos não ficam somente com a equipe de desenvolvimento:  eles se propagam por todo o IT.  Áreas como suporte, produção, telecom e outras são impactadas pelos requisitos que têm relação somente com aspectos internos destas áreas e que advêm dos requisitos básicos da aplicação em questão.

Os pontos onde falhamos:

1-Uma pobre gerência de requisitos:

Normalmente há a continuidade dos projetos mesmo com falhas nas informações dos usuários e sem a uma clara visão do problema que estamos tentando resolver

2-Falhas na gerência de mudanças:

Mudanças nos requerimentos e outras modificações são inevitáveis, apesar de raramente rastrearmos e entendermos o impacto destas mudanças

3-Controle de qualidade pobre

Temos fracas métricas de qualidade, pequeno conhecimento dos processos que afetam a qualidade, nenhum feedback para modificar o processo após testemunharmos os efeitos de uma estratégia de desenvolvimento particular (Web por exemplo)

4-Pequeno controle de cronogramas e custos

Planejamento cuidadoso é a exceção enquanto expectativas irreais são a norma.

Com base nestes dados acima, acho que temos tema suficiente para conversarmos.

Vamos examinar o primeiro ponto:

Uma das coisas mais comuns é a falta de entendimento entre os clientes e os analistas.  Acho que todos já viram um desenho muito comum nas áreas de desenvolvimento que mostra as várias fases de um projeto ilustrado por uma árvore e um balanço.

As perspectivas e a visão que os vários interessados no projeto têm nem sempre estão ajustadas.  E para o pessoal de TI as coisas são um pouco mais difíceis porque o entendimento vai além de simplesmente entender qual é o negócio.  Passa por verificar quais os impactos que a nova aplicação vai trazer para o ambiente já estabelecido, quais tecnologias serão envolvidas e etc...

Temos então vários tipos de requisitos:  funcionais, de teste, de performance, de ambiente, uma gama enorme que precisa ser gerenciada e distribuída entre a equipe de TI em suas respectivas responsabilidades.

Passa a existir um grande problema que é gerenciar os múltiplos requisitos.  Não importa se você usa papel, planilha, ou alguma ferramenta.  O principal desafio é garantir os seguintes pontos: 

• Você e os seus entenderam o que o cliente quer ?

• Você e os seus têm a mesma percepção do problema ? 

• Você consegue compartilhar com outros os problemas que vem da solução proposta ?

• Você consegue acompanhar a execução e a implementação dos requisitos ?

 Você já pensou nisto?  Como resolveu?  Quais foram os problemas que enfrentou?  Quanto custou?

Vamos para o segundo ponto:

Temos a certeza de que vão ocorrer mudanças, sejam elas advindas do negócio, dos problemas enfrentados para sua implementação, pela ausência de recursos ou outro motivo que os gerentes conseguem pensar sem fazer força.

O problema em questão é como acompanhá-las.  Mais uma vez os recursos para fazer o acompanhamento são vários, apesar de raramente se faz algumas análises importantes.

Entender o que cada mudança significa para cada parte do seu projeto é difícil, mas calcular o impacto que elas trazem para o todo é quase impossível.

A análise de impacto que cada mudança traz é uma atribuição da equipe envolvida no projeto e que normalmente não ocorre na sua total extensão.  O que as pessoas fazem é calcular o tempo adicional ou alguns outros itens, sem ter também um rastreamento de que requisitos serão atingidos com as mudanças.  E normalmente de forma manual...  e sem que outras equipes de TI que vão suportar a futura aplicação tenham acesso às mudanças.

Com isto se têm uma perda de produtividade enorme.  Aqueles que receberam a solicitação de mudança, seja ela evolutiva, corretiva ou emergencial, precisam comunicar as decisões de mudanças rapidamente para os outros de forma que haja uma diminuição da perda de recursos gastos em re-trabalhos ou conflitos.  E não somente no desenvolvimento mas no suporte, produção e etc...

Este controle de mudanças traz também outros benefícios como começar a ter um histórico do projeto para servir de base de conhecimento para os próximos.  Entender quanto tempo se investiu em determinada atividade motivada por uma mudança e melhorar as métricas gerais.  Na realidade até ter algumas informações como qual é a carga de trabalho por elemento da equipe, quais são as solicitações em aberto, por prioridade, criticidade, tempo:  bom uma infinidade de métricas e dados podem vir desta gerência, que é barata e efetiva.

Quando chegamos a este ponto, entendemos melhor o item 3 lá atrás.

Quais são as métricas de qualidade que você usa hoje nos seus projetos?

A pergunta é dolorosa mas normalmente mostra uma realidade muito pior do que queremos ver.  Normalmente temos muito poucas e confiáveis métricas para saber onde estamos e o quanto já fizemos.  É normal termos um projeto que está 80% pronto mas só falta um pouquinho.  Só que este pouquinho às vezes se torna outro projeto.  Mostrei as estatísticas no início do texto.

Gosto do que o Gartner chama de qualidade:  Qualidade nos requisitos, no controle das mudanças e nos testes.  Acho um tripé bastante claro e simples e que com ele dá para fazer várias análises em relação a se estabelecer métricas e pontos de controle.

O desafio mais uma vez é como implementar este tripé.  Até mesmo porque a maioria não tem histórico para saber quanto custo não ter.

Nos meus contatos com os clientes há uma constatação de que está havendo uma maturidade em relação ao tripé descrito acima.  Mais e mais empresas precisam ter diferenciais competitivos e rever seus processos de produção, seja no desenvolvimento seja na produção, são fatores de aumento de lucratividade ou diminuição de prejuízos.

Há vários institutos tratando do assunto métricas e meu intento aqui é só realçar a importância de ser ter algum, mesmo que depois se mude.  Criar a consciência da importância de se medir e ter histórico que foi feito.

Independente das métricas que você pode escolher, é importante que você tenha ferramentas para fazer as duas gerências que trato desde o início deste texto:  Requisitos e Mudanças

Sempre falo sobre o custo de não se ter ou ter alguma coisa e sempre tento analisar este fato.  Penso que você também pode fazer esta mesma análise.  E acho que você pode chegar a conclusões incríveis.

Agora vamos finalizar com os problemas de cronogramas e custos.

Várias vezes somos simplesmente informados de que temos uma tarefa a realizar e que temos um determinado prazo para tal.  Este prazo foi gerado a partir de um desejo, nem sempre realista.

Não temos métricas ou históricos para antecipar a duração ou o custo de determinada atividade.  Nossas informações são muitas vezes baseadas na experiência pessoal de cada um.  Isto faz com que o nível de erro fique muito alto de acordo com as estatísticas do início do texto.

Não podemos nos eximir de ter algum planejamento.  Porém o como vamos fazê-lo é determinante para diminuir a margem de erros.  Os riscos associados à falta de planejamento são críticos para todo o IT, não somente para o desenvolvimento.

O custo dos riscos é proporcional à ausência ou cuidado no planejamento.  E para fazermos este planejamento é fundamental termos todo cuidado na gerência dos requisitos e das mudanças.

Pensando simplesmente:  O sucesso do projeto é proporcional à qualidade gerencial que investimos nele.

referência : autor desconhecido.