Os artigos refletem a opinião pessoal do autor, e não de seus empregadores.

quarta-feira, 5 de dezembro de 2007

Qual a diferença entre um projeto bem e mal sucedido?

Podemos dizer que hoje o tema da segurança alcançou um bom nível de maturidade. Empresas (a até mesmo pequenos usuários) entendem os riscos da Internet e que não podem utilizar a rede sem algum plano de segurança. Passar do entendimento para uma proteção eficiente é outro problema, e ainda um grande desafio. Mesmo empresas de porte e bem estruturadas fracassam em implementar seus planos de segurança.

Essa é uma discussão antiga e ainda comum, e existe para quase todas as aplicações de informática. Por que projetos fracassam enquanto outros, usando as mesmas tecnologias, são bem sucedidos? Revisando os projetos de segurança que acompanhei pude elaborar uma pequena lista, com a pretensão de ajudar empresas de diferentes tamanhos e desejando implementar distintas tecnologias. Estou partindo do pressuposto que a tecnologia e produtos escolhidos não só funcionam (é incrivel dizer isso mas há produtos a venda no mercado que simplesmente não funcionam ou praticamente não fazem o que prometem) como atendem aos requerimentos para a solução dos problemas que originaram a compra.

A equipe: o começo de tudo
O ponto de partida é obviamente a equipe que irá instalar o produto. Do gerente de projeto aos técnicos de instalação, passando pelos patrocinadores do projeto. Um projeto de segurança, seja a instalação de um personal firewall ou de um sistema de gestão de identidades, sempre irá mexer com pessoas, com áreas e suas práticas e ações políticas. A equipe como um todo precisa estar ciente e sensível a esse fato, e o gerente de projeto precisa ser uma pessoa equilibrada e experiente em relações pessoais. Não seria preciso dizer mas os técnicos precisam dominar as tecnologias/produtos que serão instalados. Produto de segurança não é aplicativo que se instala “apertando next”.

Não se esqueça dele, o usuário
O segundo passo é obter o comprometimento e confiança (ou no mínimo a aceitação) de todas as áreas que serão afetadas pela implantação. Todas mesmo, sem exceção. Áreas de negócio, de suporte ao usuário, gerências diversas, etc. Dá um trabalhão enorme mas reduz em mais da metade as possíveis turbulências. Quanto maior a empresa mais necessária se torna essa atividade. É nessa hora que eventuais oposições serão resolvidas.
Há alguns anos fiz um curso muito interessante, destinado a implementadores de produtos, chamado de “Gerenciando Expectativas dos Clientes”. Como o nome já explica, o curso ensinava sobre como trabalhar com as expectativas daqueles que irão trabalhar ou serão afetados pelo produto instalado. Se o cliente final espera A e lhe damos B, haverá alguma insatisfação. Logo temos que identificar o que o cliente espera, dissipar seus receios, solucionar dúvidas, passar-lhe confiança e avisar o antes possível que algo irá dar errado.
Se for o caso, o usuário precisa ser treinado antes que o produto seja instalado em sua área ou computador. Se for apenas um caso de informá-lo uma apresentação via rede dá conta do recado. Se algum produto for instalado nos computadores pessoais a área de suporte ao usuário precisa também ser treinada.

Testes, testes, testes
Enquanto se trabalha na parte humana e política os especialistas de produto devem trabalhar na revisão do projeto (ou na criação de um caso não este tenha sido feito antes). Todos sabemos que algumas vezes o tempo entre a confecção inicial do projeto e o inicio de instalação dá meses. Esse projeto precisa ser validado em um piloto que tente reproduzir o ambiente em pequena escala. Um bom piloto poderá identificar muitos problemas ou desvios, mais uma vez reduzindo turbulências futuras.

Instalação
O momento ideal para começar a instalação propriamente dita é quando todos souberem o que irá acontecer, inclusive os técnicos. Em um dos projetos que acompanhei, para instalação de personal firewall em milhares de computadores, as fases anteriores foram tão bem realizadas que a instalação ocorreu via software de distribuição com uma porcentagem de problemas desprezíveis. Como a instalação ocorre de maneira planejada e previsível, e portanto com menos incidentes, a agilidade da fase compensa o tempo gasto nas fases anteriores, e com o cliente muito mais satisfeito.

Quem vai gerenciar esse negócio?
Mais eis que mesmo projetos bem planejados fracassaram? O que deu errado? Na verdade nada deu errado, apenas esqueceram do gerenciamento do produto já instalado. Um erro freqüente é iniciar a fase de gerenciamento depois do término da instalação. Este erro se agrava quando o projeto é grande e demanda meses, o que faz com que os produtos instalados no inicio do projeto cheguem ao inicio do gerenciamento possivelmente exigindo uma nova instalação ou com problemas acumulados.

A fase de gerenciamento, portanto, é paralela a de instalação. O inicio do gerenciamento de um produto começa no final de sua instalação, seja qual for o produto, seja para redes, servidores ou computadores. O que está implicado nessa afirmação? Que a equipe de gerenciamento deve fazer parte do projeto desde o seu inicio, e que a infra-estrutura de gerenciamento deve estar funcionando, pronta, antes que se instale o primeiro produto do projeto.

Já vi projetos em que a infraestrutura de gerenciamento foi instalada na fase de piloto, que contribuiu para os ajustes finos no gerenciamento. Mas pode também ser a primeira etapa da fase de instalação. O mais importante é que no momento seguinte à instalação, o produto (software ou hardware) comece a ser gerenciado. Outro efeito importante é que a equipe de gerenciamento fica responsável por resolver problemas em produtos instalados enquanto a equipe de instalação continua a fazer o que deve fazer: instalar. Usar os instaladores para resolver problemas é problema na certa.

Cadê a documentação?
Por fim vem a documentação, que não por acaso é sempre deixada para o fim: ninguém gosta de fazê-la. Diagramas de instalação, cópias de configuração dos diversos sistemas envolvidos, etc e etc são uma dor de cabeça para todos. A equipe de instalação não se entende com a equipe de gerência, o usuário final reclama que “nada está documentado” e por aí temos o projeto morrendo na praia. Mas a documentação tem uma função importante: descrever o que foi instalado e como foi instalado, tornando o projeto impessoal. Todo projeto deveria ser impessoal mas isso nem sempre ocorre.A documentação deve começar a ser gerada desde o inicio, na fase de piloto. Os instaladores deveriam já ter uma documentação guiando-os durante o processo de instalação, para que não necessitem decidir nada durante a instalação. As decisões devem ser tomadas antes do início da instalação propriamente dita. Os instaladores devem apenas seguir um guia que contenha todas as respostas para suas eventuais perguntas (que idealmente serão listadas nos pilotos).

Nenhum comentário:

Postar um comentário