Ana, O problema são sempre os prazos. As áreas de negócio quando decidem implementar a change a querem "pra ontem" e muitas vezes TI se atropela na ânsia de atendê-las. Creio que cabe aí o gestor de mudanças, juntamente com os gestores de TI e de qualidade planejarem sobre o que será executado e quando, buscando um equilíbrio para ambas as partes.
Por experiência própria, quando eu digo "planejar", querio dizer colocar efetivamente no papel o que se pretende executar. Normalmente, as changes que implemento causam N impactos e todos eles precisam ser abordados neste plano, senão vc implementa a change e no final das contas, aparecem várias falhas do tipo: "ahhm, esqueci de tal coisa" ou "fiz isso e agora deu pau em tal lugar"... Quando termino de implementar a change tbm costumo fazer um relatório sobre o que foi executado. Este relatório tem que manter uma rastreabilidade fiel ao que foi planejado. Há sempre lições a serem aprendidas no final. Você vê onde errou pra melhorar. Eu tenho certeza absoluta que tudo sai melhor quando há planejamento. Pode não sair 100%, mas sai melhor. Sempre. Gisely Ferraz Em 28/05/08, Ana Marque <[EMAIL PROTECTED]> escreveu: > > Olá > > > > Trabalho em uma indústria, na área de TI. Estamos com o processo de change > managment bastante avançado em termos de processo, conscientização e > ferramentas. > > > > Mas a gente queria dar mais um passo, que é fazer com que a equipe de > projetos (infa-estrutura e sistemas) começarem a pensar na change ANTES de > inciar o projeto. > > > > Esperamos dessa forma, transformar as changes e releases mais tranquilas > com menos atrito entre as áreas de operaçoes e projetos. > > > > Gostaria de ouvir comentários e sugestoes sobre esse tema. Experiencias > nesse sentido, seria ótimo!!! > > > > Ana > > ------------------------------ > Abra sua conta no Yahoo! > Mail<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.mail.yahoo.com/>, > o único sem limite de espaço para armazenamento! > > >
