Os requisitos e o sucesso do seu projeto

 

Encontrei este artigo em um dos meus baús de artigos e o achei muito interessante. Reproduzo-o na íntegra pois creio que ajudará a muitos. Infelizmente não tenho a autoria do mesmo. 

 

 

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, telecomunicações 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: 

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.  Em geral 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 retrabalhos 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ências:

José Carlos Macoratti