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. Consequentemente, é 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.
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 fazer 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.
Autor: Marcelo Jacintho
5 Comentários. Deixe novo
Rafa,
O organização define o tempo de retenção e descarte do registro, normalmente quem determina este tempo é o gestor do processo junto com a gestão da qualidade. A questão é quanto tempo reter um registro? Depende do impacto que este registro tem no sistema de qualidade e no produto. Por exemplo uma ordem de compra pode ser retida por um mês após o recebimento do pedido, já um relatório de validação do produto deveria ficar retido pelo tempo de produção do produto + 5 anos por exemplo.
Conte comigo
Rafa Batista;
Sugiro apenas alterar a Matriz de Registros.
Att:
Wilson Miranda
Auditor de Certificação
Por favor, preciso de ajuda, se puderem me tirar essa duvida serei muito grato.
Recentemente assumi o controle de qualidade de uma organização certificada, no que fiz de auditoria fui orientado a guardar registros de até dois anos, porém na matriz de registros aqui da empresa a disposição de descarte da maioria dos registros é de seis meses, a auditoria se aproxima e não sei o que fazer.
abraços
Olá Rafael, pedi ajuda ao nosso consultor e auditor da qualidade, Ivan Gonçalves e ele me passou o seguinte:
O tempo de retenção dos registros é definido pela empresa (normalmente o RD), em função de legislação (no caso de uma contabilidade: alguns registros precisam obrigatoriamente ser guardados até 30 anos para atendimento a legislação trabalhista) ou da percepção do gestor.
Para o caso de nosso amigo Rafhael há duas alternativas (desde que a orientação para arquivamento dos registros por até dois anos não siga nenhuma legislação específica):
1 – Ele altera a matriz de registros da empresa para dois anos e segue o que foi orientado a fazer ou
2 – Ele descarta os registros com mais de seis meses e atende o que a matriz estabelece.
Lembre-o que a definição é dele (salvo em caso de atendimento à legislação). O que é necessário é a consistência entre o que diz a matriz e o que ele faz na prática.
Esperamos tê-lo ajudado!
Abraço e ótimo trabalho!
This is the perfect way to break down this inainmftoor.
Você precisa fazer o login para publicar um comentário.