CURSOS GRATUITOS AQUIPrezados, voces acabaram de ler omaior risco que um projeto pode ter: quando simplesmente o gerente de projetoafirma que nao tem muito nao deste negocio de risco no meu projeto.... Ora, ofato de assumirmos que simplesmente podemos ter nossa equipe de desenvolvimentoproduzindo sistemas de forma direta, sem nenhum tipo de previsao, sem nenhumtipo de estimativa, ja e algo execravel ha decadas.Excecoes a parte, daquelasreferentes a projetos muito pequenos, sobre a equipe ter pleno dominio donegocio e do sistema, nao e aconselhavel planejar o desenvolvimento bemsucedido de um projeto sem a devida visao de riscos. Consequentemente, edificil crer que, dentro de uma area de T.I. pode-se ter uma eficiente gestaode projetos sem a devida sinalizacao de riscos e problemas em potencial.O primeiro aspecto que precisaficar bem claro e deixarmos de lado a conotacao negativa do termo risco.Risco nao e um problema, e algum evento que pode acontecer no futuro. Logo,trata-se de uma possibilidade de perda, e nao de uma certeza de perda. Se, nadefinicao do escopo do projeto, for detectado alguma informacao que envolva umproblema em potencial, que possa vir a acarretar em atraso de prazo ou aumentode custo, por exemplo, cabe ao gerente de projeto alocar analistas para gerarum planejamento de gerenciamento de riscos.Esta disciplina de gerencia deprojetos e muito rica e ampla, porem vamos refletir sobre algumas definicoesbasicas. O ciclo de gerenciamento de riscos inicia na identificacao, depoistemos a analise de impacto, seguido do planejamento de mitigacao econtingencia. Apos o planejamento, o gerente monitora sua exposicao aos riscos,isto e, observa se algum risco esta prestes a efetivamente ocorrer. Ainda, executao plano de mitigacao, e, quando necessario, executa o plano de contingencia.O plano de mitigacao visa diminuira possibilidade de um risco se tornar um problema de fato, enquanto que o planode contingencia visa resolver um risco que porventura tenha efetivamenteacontecido, isto e, que tenha se tornado um problema.Nao e novidade que a principalpercepcao de qualidade relativa ao nosso trabalho e aquela do nosso cliente,porem bem sabemos que o nivel de participacao do cliente em projetos de desenvolvimentode sistemas e muito determinante ao sucesso de nossos esforcos. Logo, porquenao comecar por ele, o nosso cliente, para alcancarmos uma previsao de algunsriscos?O cliente sempre tem suascaracteristicas unicas, como personalidade, grau de conhecimento da tecnologiae no proprio negocio no qual trabalha, e disponibilidade de tempo e boa vontadepara participar no ciclo de vida de seu projeto.Segue abaixo, para refletirmos,sugestoes de perguntas que podemos estar fazendo sobre o cliente. Se a maioriadas respostas a essas perguntas for nao, vale ter na equipe o esforconecessario para analisar o impacto, minimizar as chances de problemasocorrerem, e ainda definir como reagir quando o problema realmente ocorrer.Voce ja trabalhou com o clienteno passado?O cliente possui uma solida ideiasobre suas necessidades? Ele reserva algum tempo para descreve-las?O cliente concorda em reservartempo para participar de sessoes de identificacao e descoberta de requisitos?O cliente esta disposto aestabelecer vinculos de comunicacao com a equipe de desenvolvimento?O cliente concorda em participarde revisoes de fim de fase do projeto?Qual e o dominio do cliente naarea do produto?O cliente entende os processos dedesenvolvimento de sistemas?O