Riscos acompanham qualquer atividade humana. (Ghezzi et al., 1991)

Atualmente na empresa onde trabalho existe uma questão que perturbava e pertuba a maioria dos funcionários quando se trata de gerência de Projetos. Os métodos aplicados na empresa não satisfaz a muito tempo programadores e designers que ali convivem juntos.

Logo que o assunto virou um dilema do dia a dia, eu comecei a ler sobre o assunto. Fiz uma pesquisa no PAI DOS AUTODIDATAS (Google)  e como sempre achei inúmeras fontes com textos muito interessantes sobre o assunto em questão.

Eu, totalmente leigo no assunto li algumas matérias e cada vez mais que eu lia via que o que acontece na empresa onde eu trabalho é realmente tudo errado. 

Sendo asssim, gerência de projetos virou um dos importantes assuntos no qual eu pretendo seguir estudando como autodidata.

O primeiro post sobre gerência de projetos é exatamente sobre um dos assuntos que me chama muita atenção em gerência de projetos, o GRS (Gerência de Risco de Software).

São grandes os riscos de um projeto não sair como o esperado. São ínumeros erros que podem acontecer e está preparado para resolve-los é essêncial.

O que esperamos de um projeto é basicamente um software confiável feito com o tempo e recursos determinados. Mais em qualquer projeto há riscos de extrapolar tempo e orçamento.

GRS é um assunto muitas vezes sem importância para algumas empresas, mais o estudo e busca de soluções para minimizar os riscos de tudo dar errado no seu projeto é essêncial para empresas que querem se destacar no mercado e logicamente vender qualidade.

Sobre GRS, encontrei um estudo onde apontava quais eram os riscos de software mais comuns, no qual alguns importantes gerentes de projetos apontavam quais realmente eram os problemas que faziam parte da vida deles.

Achei bem interessante porque alguns dos problemas apontados fazem realmente parte do dia a dia da empresa no qual eu trabalho.

O estudo tinha os seguintes itens:

RISCOS CLASSIFICADOS POR TIPO DE RISCO

1 – CLIENTE

1.1 – Falta de Envolvimento dos usuários.
1.2 – Falha em obter compromisso dos usuários.
1.3 – Falha na gerência de expectativas dos usuários.
1.4 – Conflito entre os departamentos do usuário.

2 - REQUISITOS

2.1 – Não entendimento dos requisitos.
2.2 – Escopo/Objetivos não claros.
2.3 – Instabilidade de requisitos.

3 – PLANEJAMENTO

3.1 – Falta de compromisso da gerência sênior com o projeto.
3.2 – Falta de conhecimento/Habilidade pela equipe.
3.3 – Equipe insuficiente ou inadequada.
3.4 – Cronograma e orçamento não realistas.
3.5 – Falta de uma metodologia de projeto.

4 – EXECUÇÃO

4.1 – Introdução de novas tecnologias.
4.2 – Requisitos criados pelos desenvolvedores (gold plating).
4.3 – Desenvolvimento errado das funções ou interface (implementação não atende à especificação).
4.4 – Sub-contratação (tarefas ou componentes desenvolvidos externamente).
4.5 – Uso de recursos e desempenho do sistema inadequados.
4.6 – Projeto (desenho) inviável.

 fonte:  18º Simpósio Brasileiro de Engenharia de Software

Apesar de todos os itens citados acima realmente ser de grande importância pra análise os itens que mais me chamam atenção são:

2.2 – Escopo/Objetivos não claros.
3.1 – Falta de compromisso da gerência sênior com o projeto.
3.4 – Cronograma e orçamento não realistas.

Isso talvez pelo fato de que são os problemas mais real dentro do meu local de trabalho.

O estudo mostrava também algumas práticas para minimizar esses riscos, mais quem sabe isso não fica para um post futuro?

Grande Abraço