Como ter sucesso no desenvolvimento de projetos de TI - Parte I: Gerência de Requisitos

Todos nós sabemos como é difícil desenvolver (e implantar) projetos de Tecnologia da Informação, especialmente aqueles de grande fôlego, que vão influenciar o cotidiano de toda a empresa (como os ERPs, por exemplo).

Para ter sucesso garantido nesse processo, no entanto, é preciso que todas as suas etapas sejam bem pensadas e planejadas, e cumpridas à risca. Aqui, comentaremos algumas delas como mais detalhe, levando em consideração as regras propostas pelo MPS.BR, o programa para melhoria de processo do software brasileiro.

A primeira delas, como não podia deixar de ser, é a Gerência de Requisitos (GRE).

Pra quem ainda não sabe, requisitos são as demandas do cliente, daquele que vai usar o sistema. É claro que essa etapa é a mais importante, pois se a softwarehouse não entender o que o seu cliente deseja e precisa, ela vai desenhar um sistema que, na melhor das hipóteses, será sub-utilizado. Para que isso não aconteça, o MPS.BR de nível G definiu um processo para gerenciar essa etapa: é a Gerência de Requisitos.

Os objetivos da Gerência de Requisitos são:
1 - gerenciar os requisitos dos produtos e componentes do produto do projeto;
2 - identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.

O processo Gerência de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto.
Quando um projeto recebe requisitos de um FORNECEDOR DE REQUISITOS (pessoa autorizada a participar de sua definição e a solicitar modificação), estes devem ser revisados para resolver questões e prevenir erros de entendimento e interpretação, antes que os requisitos sejam incorporados ao escopo do projeto.

Quando o fornecedor de requisitos e a organização chegam a um acordo, é obtido um compromisso das demais partes interessadas (ex: consultoria, analistas e programadores) sobre os requisitos.
[Fonte: Guia MPS.BR versão 1.2]

Para refletir: Quantos projetos não são bem sucedidos por falha no entendimento dos requisitos, ou até mesmo por não saber identificar o "verdadeiro" Fornecedor de Requisitos?

Ou seja, OUVIR O CLIENTE É FUNDAMENTAL!