Assim como as pessoas, os sistemas gostam de permanecer como estão, não gostam de mudar.

O primeiro pensamento que me vem à mente, em relação ao título deste artigo, já se tornou até clichê: as pessoas são resistentes a mudanças.

Não há dúvidas disso, porém não é intenção deste texto enveredar para a área de psicologia; trata-se apenas de uma ligação com o tema de mudanças relacionado a TI, ou ao gerenciamento de mudanças da ITIL.

Será então que este autor está fora de si? Talvez, mas o elo que busco é o de associar a resistência a mudar que as pessoas têm com a resistência que os sistemas têm em sofrer mudanças sem desestabilizarem-se. Isso não é loucura, é mais certo do que dois e dois são quatro. Sistemas gostam de permanecer como estão, não gostam de mudar. Se mudarem, as chances de apresentarem problemas são enormes.

Isso é mais antigo que a ITIL. Bem mais. No tempo dos mainframes, há 20 anos ou até mais, isso já era tratado como dogma sagrado: cuidado ao mexer, cuidado ao mudar qualquer coisa. Isso era tão ou mais crítico, pois o processamento era todo centralizado e todos os usuários dependiam do processamento central; se parasse um elemento no sistema central, paravam todos os usuários MESMO.  Depois, com a microinformática, o processamento se distribuiu e em alguns casos o impacto de paradas ficou menos crítico. A ITIL, com o gerenciamento de mudanças, resgatou esta preocupação e tornou-a mais sistemática e processual.

Em qualquer nível de ortodoxia que se deseje implantar o gerenciamento de mudanças da ITIL (referindo-se a seguir de forma mais ou menos literal as práticas sugeridas pela cartilha), alguns preceitos são básicos e são de fundamental importância. De forma geral, podemos afirmar que, em se tratando de controlar mudanças, temos que ter em mente os seguintes preceitos (não exclusivamente, mas principalmente estes):

- Antes de mudar, avalie o que pode parar, o que pode ser impactado pela mudança e qual a possível consequência disso
- Planeje a mudança, da forma mais detalhada possível, como um roteiro passo-a-passo ou um check-list
- Compartilhe responsabilidade sobre a decisão de realizar a mudança planejada, com pessoas-chave envolvidas, incluindo aquelas das áreas que são usuárias
- Comunique a todos os envolvidos sobre a parada que será necessária para que a mudança aconteça
- Pense no que pode dar errado (há grande chance de que dê errado) e como as ações realizadas podem ser revertidas
- Antes de achar que tudo está bem, teste e re-teste, exaustivamente (não esqueça de envolver os usuários nos testes)

Os itens acima não são uma receita definitiva, mas com certeza qualquer mudança que os siga tem maior probabilidade de ser bem sucedida.

Juliano Statdlober é diretor de Desenvolvimento e Tecnologia da Constat.

Data: 07/09/09

http://www.baguete.com.br/artigosDetalhes.php?id=982