Projetos com Sucesso - III

Retomando esta série de posts, vou falar hoje sobre as atitudes de quem contrata o projeto (o cliente). Esta é uma visão delicada, já que estamos condicionados que "o cliente tem sempre a razão" e "culpar o cliente" é uma postura condenável (embora muito praticada). E assim caímos direto no primeiro ponto.

O Cliente Também É Responsável Pelo Sucesso do Projeto

Umas das expressões ouvidas quando um projeto descarrilha é "contratei vocês para não ter problemas" (ou algo equivalente). Quem contrata um projeto precisa estar ciente que mesmo a melhor empresa vai precisar do apoio seu apoio.

Conhecimentos sobre "as melhores práticas do segmento" precisam ser complementados com as características específicas do cliente. Em alguns casos estas características se sobrepõem às melhores práticas, e em outros geram a necessidade de cuidados especiais ao adotá-las.

Defina um Ponto de Contato Principal

É fundamental alocar uma pessoa para ser o contato principal com a empresa contratada. Esta pessoa não precisa necessariamente ter autonomia para decisões, mas precisa estar ciente de todas as comunicações, garantindo que elas cheguem às pessoas apropriadas. Muitos problemas de projeto ocorrem por decisões não serem tomadas ou informadas às pessoas corretas.

O ideal é que esta pessoa exerça uma função de Gerente de Projeto, acompanhando o cronograma e os resultados.

O caminho inverso também é importante: é preciso saber que é o ponto de contato principal na empresa contratada. Muitos clientes assumem que esta pessoa é o representante comercial que o atendeu durante as negociações, mas em todas empresas que conheço a responsabilidade muda de mãos após o fechamento do negócio.

Envolva As Pessoas Corretas, o Mais Cedo Possível

Por mais estranho que pareça, muitos clientes só envolvem na implantação as pessoas que serão os usuários do projeto. Estas pessoas precisam ser envolvidas no começo, para darem o seu depoimento sobre o processo atual e necessidades. Este envolvimento cria também uma certa "cumplicidade" com o projeto, que passa a ser também delas e não algo que está sendo "imposto de cima para baixo".

Além dos usuários diretos, outras pessoas serão afetadas, de forma nem sempre facilmente prevista. O envolvimento delas diminui a probabilidade de surpresas desagradáveis durante ou logo após a implantação.

Não Menospreze a Documentação

Muitas pessoas (e não somente no lado do cliente, isto se aplica também à empresa e ao desenvolvedor) tendem a tratar documentação como uma burocracia que atraza o andamento real do projeto.

O primeiro documento importante é a proposta, que precisa definir de forma clara o escopo. O segundo é o detalhamento da especificação. Lembre-se que mudar no papel é sempre mais fácil que mudar um projeto pronto. A especificação detalhada é também a base para os testes. O terceiro documento é o manual, que contém as instruções de instalação e operação e será a base para resolver dúvidas rapidamente, sem ter que consultar o fornecedor.

Tente Manter a Calma Quando as Coisas Dão Errado

É natural que o cliente fique descontente quando prazos não são cumpridos e as coisas não funcionam como esperado. Nesta hora é preciso que todos mantenham a calma e foquem em como colocar o projeto nos trilhos.

O pior que pode ser feito é se deixar levar pela raiva e tentar consertar o projeto "no grito". Ataques pessoais devem particularmente evitados, pois não contribuem em nada com a solução dos problemas. Infelizmente já tive a oportunidade de ver clientes que "queimaram todas as pontes" com o fornecedor. O resultado nestes casos, quando o projeto não é simplesmente abortado para prejuízo e alívio mútuo, é um sistema extremamente ruim encerrado pelo cansaço das duas partes. E o sistema permanece desta forma, pois não existe clima para continuidade dos trabalhos. Após uns poucos anos de operação capenga um novo projeto é iniciado, retomando o ciclo.

Prepare os Testes de Aceitação

Testar um projeto (particularmente um de software) é uma coisa complexa.

O primeiro ponto a planejar é como (e onde) viabilizar um teste. Isto pode exigir disponibilizar equipamentos extras (como um servidor de teste) e montar uma operação simulada (envolvendo pessoas, equipamentos e materiais).

O segundo ponto é pensar o que se quer testar. A especificação detalhada é a base para isto.

O terceiro ponto é detalhar o procedimento de teste e preparar os dados necessários. Muitas vezes se vê testes totalmente aleatórios e desorganizados; além de não cobrirem adequadamente o projeto estes testes são muitas vezes irreprodutíveis.

Um bom roteiro de teste servirá não somente para um primeiro teste mas também para verificar que os problemas encontrados foram solucionados e que outros erros não foram introduzidos e para validar versões posteriores.

Faça Uma Implantação Gradual

É normal surgirem dificuldades operacionais quando um novo processo é introduzido. É também possível que sejam encontrados problemas, por melhor que tenham sido os testes. É, portanto, importante que a implantação seja gradual e com uma opção de contingência (se possível sendo usada em paralelo).

Aqui cabe o relato de um caso real. Certa vez um cliente estava implantando um sistema que ia ser usado nas seis docas da sua expedição. No primeiro dia o gerente juntou todos os funcionários, fez uma apresentação bem detalhada de todo o sistema e mandou todos trabalharem. Não demorou muito para ser chamado para uma das docas para tirar uma dúvida. Antes de acabar de resolvê-la, uma outra doca já estava parada aguardando para tirar outra dúvida. O gerente passou o dia todo correndo de uma doca para outra. No fim do dia estava cansado, frustado e a produtividade estava lá em baixo. No dia seguinte ele resolveu usar uma tática diferente: deixou cinco docas trabalhando com o sistema antigo e ficou direto na doca restante. Ao final da manhã os funcionários daquela doca já estavam seguros na operação do novo sistema; à tarde ele os deixou trabalhando sozinhos e foi para a segunda doca. Ao final do dia ele estava com duas docas operando com o sistema novo e os ganhos de produtividade já começavam a ser sentidos. E ele estava bem menos cansado. Mais dois dias e todas as docas estavam operando o novo sistema. Se o gerente tivesse insistido em implantar simultaneamente em todas as docas era bem provável que o sistema tivesse sido "queimado".

Evolua o Sistema

Um engano comum é pensar que um sistema está pronto quando foi implantado. Isto se deve às vezes pelo desgaste durante o projeto, mas muitas vezes é apenas um visão equivocada.

Durante o projeto é comum surgirem muitas ideias, a maioria das quais são deixadas de lado por não estarem no escopo. O uso real do sistema é também fonte para ideias de aperfeiçoamento. Estas ideias não devem ser desperdiçadas!

A maioria das empresas fornece apenas correções durante a garantia. Contratos de manutenção às vezes incluem pequenos aperfeiçoamentos; poucos clientes optam por estes contratos e, dentre os que optam, muitos simplesmente os sub-utilizam. Um outro ponto a favor dos contratos de manutenção é que a empresa contratada fica obrigada a manter profissionais preparados para dar suporte e manutenção. Embora na prática muitas empresas continuem dando suporte após o término da garantia, com o passar dos anos é grande o risco das pessoas envolvidas terem mudado de cargo ou deixado a empresa e não estarem mais disponíveis pessoas que conheçam o projeto ou mesmo as tecnologias envolvidas.