Não, não tenho muito risco por aqui não...Prezados, vocês acabaram de ler o maior risco que um projeto pode ter: quando simplesmente o gerente de projeto afirma que “não tem muito não deste negócio de risco no meu projeto...”. Ora, o fato de assumirmos que simplesmente podemos ter nossa equipe de desenvolvimento produzindo sistemas de forma direta, sem nenhum tipo de previsão, sem nenhum tipo de estimativa, já é algo execrável há décadas.
Exceções à parte, daquelas referentes a projetos muito pequenos, sobre a equipe ter pleno domínio do negócio e do sistema, não é aconselhável planejar o desenvolvimento bem sucedido de um projeto sem a devida visão de riscos. Conseqüentemente, é difícil crer que, dentro de uma área de T.I. pode-se ter uma eficiente gestão de projetos sem a devida sinalização de riscos e problemas em potencial.
O primeiro aspecto que precisa ficar bem claro é deixarmos de lado a conotação negativa do termo “risco”. Risco não é um problema, é algum evento que pode acontecer no futuro. Logo, trata-se de uma possibilidade de perda, e não de uma certeza de perda. Se, na definição do escopo do projeto, for detectado alguma informação que envolva um problema em potencial, que possa vir a acarretar em atraso de prazo ou aumento de custo, por exemplo, cabe ao gerente de projeto alocar analistas para gerar um planejamento de gerenciamento de riscos.
Esta disciplina de gerência de projetos é muito rica e ampla, porém vamos refletir sobre algumas definições básicas. O ciclo de gerenciamento de riscos inicia na identificação, depois temos a análise de impacto, seguido do planejamento de mitigação e contingência. Após o planejamento, o gerente monitora sua exposição aos riscos, isto é, observa se algum risco está prestes a efetivamente ocorrer. Ainda, executa o plano de mitigação, e, quando necessário, executa o plano de contingência.
O plano de mitigação visa diminuir a possibilidade de um risco se tornar um problema de fato, enquanto que o plano de contingência visa resolver um risco que porventura tenha efetivamente acontecido, isto é, que tenha se tornado um problema.
Não é novidade que a principal percepção de qualidade relativa ao nosso trabalho é aquela do nosso cliente, porém bem sabemos que o nível de participação do cliente em projetos de desenvolvimento de sistemas é muito determinante ao sucesso de nossos esforços. Logo, porque não começar por ele, o nosso cliente, para alcançarmos uma previsão de alguns riscos?
O cliente sempre tem suas características únicas, como personalidade, grau de conhecimento da tecnologia e no próprio negócio no qual trabalha, e disponibilidade de tempo e boa vontade para participar no ciclo de vida de seu projeto.
Segue abaixo, para refletirmos, sugestões de perguntas que podemos estar fazendo sobre o cliente. Se a maioria das respostas a essas perguntas for “não”, vale ter na equipe o esforço necessário para analisar o impacto, minimizar as chances de problemas ocorrerem, e ainda definir como reagir quando o problema realmente ocorrer.
–Você já trabalhou com o cliente no passado?
–O cliente possui uma sólida idéia sobre suas necessidades? Ele reserva algum tempo para descrevê-las?
–O cliente concorda em reservar tempo para participar de sessões de identificação e descoberta de requisitos?
–O cliente está disposto a estabelecer vínculos de comunicação com a equipe de desenvolvimento?
–O cliente concorda em participar de revisões de fim de fase do projeto?
–Qual é o domínio do cliente na área do produto?
–O cliente entende os processos de desenvolvimento de sistemas?
–O cliente tende a criar resistência para participar de trabalhos técnicos detalhados junto à equipe de desenvolvimento?
-O cliente tende a trazer, com muita freqüência, novos requisitos durante o desenvolvimento do sistema?
Com uma visão clara e madura dos riscos associados a cada projeto de uma organização, fica evidente onde devem ser concentrados os esforços para garantir o sucesso dos projetos de desenvolvimento de sistemas.
ABRAÇO, e até o próximo artigo.
Marcelo Jacintho
marcelo.jacinto@internativa.com.br