DESARROLLO LEGISLATIVO (1978 – 2013)

gerente de projetos com maior foco na tecnologia utilizada. Existe uma visão excessivamente tecnológica em detrimento da visão e definição dos requerimentos.

Vamos imaginar o seguinte cenário:

“O projeto possui um forte patrocinador dentro da corporação, a equipe acabou de ser montada e possui um prazo limite de 6 meses para criar o data warehouse. Logo no início, o gerente reúne a equipe e seus futuros usuários. Por uma questão de facilidade, o gerente dá preferência aos usuários mais técnicos, afinal é muito mais fácil conversar de técnico para técnico. O levantamento é iniciado pela revisão dos relatórios já existentes e entrevistas para identificação de novos relatórios. Imediatamente após esta fase, a equipe já começa a trabalhar na especificação do banco de dados. A etapa relacionada a extração de dados é rapidamente resolvida pela fantástica ferramenta ETL adquirida. A camada de apresentação das informações também utiliza uma ferramenta de mercado muito intuitiva e fácil de ser utilizada. Aparentemente o projeto foi executado com sucesso e concluído antes do prazo estabelecido. Assim que é disponibilizado, as reclamações começam a chegar, primeiro os usuários questionam que algumas informações não foram contempladas, outros reclamam que o formato dos relatórios pré-definidos não atendem suas necessidades. A casos piores, onde o usuário questiona que a informação não está correta. Em resumo, o projeto falhou completamente”.

Este cenário é muito mais comum do que parece, pode-se listar como principais erros:

7.1 Ignorar os Processos de Iniciação

Todo o projeto precisa de um patrocinador, contudo os processos da fase de iniciação não podem ser ignorados. O cenário indica que o prazo foi estabelecido a partir do patrocinador, sem considerar os processos de inicialização. É importante que o gerente de projeto dedique tempo para:

i. Identificar a cultura da empresa e sistemas legados;

ii. Coletar informações históricas e entender processos da empresa; iii. Identificar todos os stakeholders;

iv. Documentar as necessidades de negócio; v. Determinar os objetivos do projeto;

vi. Documentar as premissas e restrições do projeto; vii. Desenvolver o project charter;

viii. Desenvolver o escopo preliminar do projeto.

7.2 Falhar na Identificação dos Requisitos

Infelizmente o ser humano tem a tendência de trabalhar dentro de uma zona de conforto, por isso que o gerente de projetos priorizou o levantamento de requisitos com usuários mais técnicos. Este é um erro grave, mas o maior erro é falhar na identificação dos principais envolvidos.

O gerente de projeto precisa identificar todos os envolvidos e/ou afetados pelo projeto. Uma lista relacionando todos os envolvidos deve fazer parte da documentação do projeto. A partir desta lista, a equipe deverá começar o levantamento pelos usuários de negócio. Isto pode até ser um pouco mais difícil, mas estes usuários representam o centro do projeto e precisam ser os primeiros a serem entrevistados. A linguagem e comunicação entre usuários de negócio e a equipe do projeto pode ser mais difícil, pode-se citar como exemplo a palavra “índice”, ela pode assumir diferentes significados, ora para um analista de negócio, ora para um DBA.

Daí a importância de montar uma equipe multidisciplinar, com integrantes que conheçam a linguagem dos usuários. As entrevistas não devem ser conduzidas para perguntar o que o usuário quer que o sistema apresente, na realidade o entrevistador deve conduzir de forma a entender os objetivos do negócio, quais são os desafios do usuário, como ele analisa as informações e toma suas decisões...

Outro aspecto muito importante e comumente desconsiderado é que o usuário não tem obrigação de conhecer ou saber o que o sistema estará proporcionando, quais são seus objetivos. Daí é muito fácil encontrar resistência nesta etapa de levantamento. Normalmente o usuário encara estas entrevistas como algo chato, uma verdadeira perda de tempo. A solução para ganhar a confiança e colaboração do usuário é apresentar os benefícios que terá ao final do projeto. A prototipação é um recurso muito útil nesta etapa, alguns usuários possuem dificuldade para enxergar o sistema pronto. Um protótipo ajudará a mostrar os recursos que estarão disponíveis, podendo estimular a participação.

7.3 Falhar na Identificação da Origem das Informações

Assim que os entrevistadores conseguem coletar informações e requisitos do negócio, a equipe deve começar a procurar os responsáveis pela administração dos sistemas transacionais. É importante avaliar se os requisitos informados pelos usuários de negócio são tangíveis e possíveis de serem obtidos a partir dos sistemas de origem.

Pode-se citar o seguinte exemplo:

“Uma indústria farmacêutica multinacional possui a composição de um medicamento com um item concentrado e importado. Seu custo é excessivamente elevado e um analista de negócio gostaria de saber o seu custo por caixa do medicamento. Por uma questão de segredo industrial, o percentual de utilização do concentrado não é conhecido, inviabilizando o atendimento deste requisito.”

A partir do momento que as entrevistas passam a mostrar temas e resultados consistentes, é a hora de sentar formalmente com os responsáveis e administradores dos sistemas transacionais. É importante identificar todas as possíveis origens e histórico das informações. Como o data warehouse estará captando informações históricas é importante observar o comportamento das informações ao longo do tempo, por exemplo: uma determinada coluna do banco de dados transacional era alimentada com um domínio específico até o ano 2002, a partir de uma mudança na legislação, o domínio foi alterado para outra especificação. Este tipo de análise é importante para garantir a integridade das informações. Em qualquer tipo de sistema da informação, a coerência e correção das informações são importantes, contudo sistemas data warehouse existem para apresentar informações; erros ou falhas na captação destas informações acabam por gerar a descrença e desconfiança do usuário, sendo um passo para o fracasso do projeto.

8. GERÊNCIA DE ESCOPO DO PROJETO PARA SISTEMAS DATA WAREHOUSE