Veja 11 dicas para avaliar riscos dos projetos de TI

O mundo da TI está familiarizado com projetos que
fracassam. E qualquer um que tenha participado
de um esforço de TI mal-sucedido possivelmente sentiu os sinais do fracasso antes da
data de lançamento. Esse sexto sentido é inestimável em um campo concorrido
como o da TI – mas apenas se for usado, e de maneira ágil e profissional.

Esteja você buscando evitar estar fadado a um fracasso
ou recolocar um projeto fracassado de volta ao prumo, você deve ser capaz de
reconhecer os sinais de fracasso iminente muito antes do projeto sair do prumo, desandar completamente. Isso pode salvar sua carreira.

Nós enumeramos 11 sinais de alerta que devem ser observados para avaliar a saúde de um projeto de TI. Seja proativo sempre que você
encontrar um deles – ou simplesmente se afaste. Sua carreira depende
disso.

Nº 1: O projeto foi lançado sem o apoio da diretoria
Quer uma receita infalível para a falha de um projeto
de TI? Comece a trabalhar antes de receber o sinal verde dos níveis superiores.

Isso nunca acontece? Pense bem… Uma
personalidade forte dentro da empresa cria uma ideia ou solução absolutamente “tremenda”
e começa a planejar reuniões e a alocar recursos sem esperar para ver se a
gestão sênior concorda. Muitos desses projetos prosseguem, até o ponto onde algum dinheiro de verdade deve ser gasto, e então eles entram em um colapso total.
Muitas vezes, todos no projeto, exceto seu criador, nem mesmo sabem que o
projeto não foi aprovado, e nem que o orçamento não foi alocado.

Para evitar prender-se a tal projeto, sempre pergunte
quem dentro da área de gestão sênior é um patrocinador e como será feita a alocação de
orçamento. Não aceite respostas como a de que o orçamento ainda não foi
alocado, pois as pessoas não sabem o quanto irá custar até o projeto ter sido
iniciado.

Caso você seja um consultor sendo atraído para o
projeto, certifique-se de que um orçamento significativo foi alocado antes de
participar da segunda reunião. Você não precisa saber o valor do orçamento
final, mas precisa saber que a gestão sênior é séria com relação a seu suporte e que possui alguma ideia do custo eventual. Eu já participei de
grandes projetos que obviamente custariam milhões de dólares para serem
resolvidos, mas a gestão estava pensando na faixa de alguns milhares de
dólares. Não fique preso em tal projeto.

Nº 2: Não existe um plano
detalhado do projeto
Um software de planejamento de projeto pode ser
complexo e frustrante de usar. A única coisa que eu odeio mais do que
arquitetar um plano de projeto detalhado é estar envolvido em um projeto que
não possui um. Os planos formais de projeto forçam o administrador
e todos os envolvidos a considerarem todas as fases e etapas necessárias, e a
ordem na qual prosseguir. Para parafrasear uma frase frequentemente citada,
“falhar ao planejar é planejar para falhar”.

Qualquer projeto com um cronograma maior do que de
duas semanas deve possuir um plano de projeto sólido e planejado. Caso você seja
apresentado um projeto que não possua tais características, desenvolva-as. Além
de forçar todos a considerar todas as tarefas e táticas, fazê-lo os forçará a
criar agendas realistas. Um plano de projeto detalhado é muito melhor do que
sua “melhor suposição” ou intuição.

Nº 3: Reuniões foram agendadas sem
preocupação com a disponibilidade de membros da equipe
Quando um projeto ou líder de equipe arbitrariamente
agenda reuniões em conflito com outras reuniões importantes e já marcadas, você
sabe que seu projeto está condenado. Fazer isso garante que membros vitais da
equipe não estarão presentes, minando o propósito e eficiência de sua reunião.

A solução é simples: gaste um pouco de tempo antes de
agendar reuniões de projeto para ter noção das agendas atuais dos membros
importantes.

Mais importante ainda, encontre o máximo de disponibilidade comum
e útil, e escolha uma oportunidade. Não vá até o extremo de permitir que os
participantes votem entre múltiplas oportunidades – isto pode levar a uma
diferença com aqueles que tiveram suas propostas de oportunidade negadas. Em
vez disso, seja competente e escolha uma oportunidade com a qual você sabe que
todos podem arcar. Você pode ajustá-la depois, caso necessário. Além disso,
certifique-se de publicar os horários de reunião de sua equipe para que os
outros não agendem nada sobre ela acidentalmente.

Além disso, uma dica para o sábio: agende reuniões
antes do almoço, se possível. As pessoas são geralmente mais produtivas e existe
uma possibilidade maior delas aparecerem mais cedo. Reuniões após o almoço,
muitas vezes, vão de encontro com a lentidão de barrigas cheias e competem com
as prioridades e dramas agregados durante a primeira parte do dia. As reuniões
que ocorrem logo após o almoço, ou ao final do dia de trabalho, podem ser as
menos frequentadas e as menos produtivas.

Nº4: Os usuários tiveram pouco (ou
nenhum) envolvimento precoce
Qualquer um participando de uma aula mesmo que básica
de TI na faculdade é ensinado a envolver os usuários precocemente ao lançar
qualquer projeto ou processo de tomada de decisão. É por isso que é tão
surpreendente ver projetos grandes e complexos quase que completamente
concluídos antes que os usuários sejam trazidos para fornecerem seu conselho. Já vi muitos projetos grandes e em evolução saírem completamente do trilho depois dos usuários contarem aos lideres que um processo em particular, que não tem funcionado, também não funcionará bem depois de alterado pelo projeto.

Certifique-se de que usuários reais, ou seus
defensores, sejam convidados para o projeto a partir do inicio. É preciso
tê-los logo no primeiro dia. Quanto mais envolvimento você tiver por parte dos
usuários, maior será sua chance de sucesso. Caso seu projeto cubra vários
departamentos, certifique-se de ter um usuário representante de cada
departamento. Além disso, certifique-se de que os usuários que foram convidados
para participar estejam abertos aos objetivos do projeto e sintam que eles
podem expressar  suas verdadeiras opiniões.

Envolver usuários precocemente
normalmente resulta em uma aceitação mais rápida e melhor caso problemas
apareçam ou caso mudanças impopulares de processo sejam necessárias.

Nº 5: O projeto usa as
especificações mínimas de hardware
Nada acaba com o sucesso de um projeto como comprar o
hardware mínimo.

Os fornecedores são notórios por tentar manter o custo
de um projeto baixo ao vender um hardware inferior ao necessário para os
melhores resultados. Os fornecedores muitas vezes oferecem uma especificação
“mínima” e o hardware recomendado para compra. Lideres inteligentes de projeto
irão além até mesmo das especificações recomendadas de hardware, caso algo
ocorra, pelo menos os fornecedores e seus clientes não estarão apontando seus
dedos para as decisões de compra de hardware orientadas a baixo custo. Além
disso, certifique-se de que todo o hardware e software comprados sejam
compatíveis e testados uns com os outros. Você não quer que nenhum lado aponte
culpados precocemente caso algo dê errado.

Às vezes o segredo está nos detalhes quando o assunto
é comprar tecnologia. Por exemplo, caso um fornecedor diga que possui muita
experiência com a execução do MySQL no Linux, tome cuidado em exigir que o
MySQL funcione no Windows. O fornecedor pode dizer que pode fazê-lo, mas que
pode não ter muita experiência com isso. Caso você desvie do que o fornecedor
recomenda, certifique-se de obter a aceitação do fornecedor por escrito. Além
disso, nunca é demais verificar com os clientes anteriores que compartilharam
uma configuração semelhante a fim de saber o lado bom e o ruim de como as
coisas ocorreram caso eles tenham se desviado, ainda que pouco, das
especificações recomendadas.

Nº 6: Os testes estão em segundo
plano
Os testes são essenciais para o sucesso de um projeto.
Seja ele um teste de unidade (que testa uma faceta do sistema) ou testes
integrados (que testa todos os componentes, incluindo sistemas de interface
existentes). Os testes devem ser feitos pelos funcionários atuais junto com um
plano de testes. O plano de testes deve incluir todos os depoimentos, passo a
passo, que os testadores devem fazer. E você deve detalhar, antecipadamente,
como deve ser a aparência dos resultados.

Os dados de teste e processos devem avaliar todos os
cenários, incluindo os bons e os ruins. Às vezes, os resultados de dados ruins
conhecidos são mais interessantes do que aqueles de um resultado desejado. Os
testes devem incluir testes de carregamento para ver como o sistema e a rede
responde a utilização pesada. Os testadores devem compreender os resultados
esperados, e deve ser esperado que eles reportem todos os desvios.

Nº7: Não existe nenhum plano de
recuperação no caso de uma falha
Apesar de nossos melhores esforços, os planos nem
sempre ocorrem como esperado. Todo líder de projeto precisa saber qual será a
aparência do resultado final – e quando será a hora de admitir a falha e
começar novamente. Todo projeto deve ter um plano secundário de
lançamento caso o fracasso se torne a única opção.

Muitos eventos de lançamento são orientados pela
crença de que “nada pode dar errado”. Os lideres desses projetos muitas vezes
falham em garantir que boas cópias de segurança sejam feitas e verificadas.
Eles não desenvolvem protocolos para definir o sucesso, e nem esboçam antecipadamente
qual seria a aparência de uma falha. Eles não preparam a equipe para o que
fazer diante de um erro no lançamento. Muitos projetos completamente novos alcançam
um obstáculo fatal apenas para descobrir que não podem voltar atrás, graças a um
planejamento pobre.

Com algumas exceções, os projetos devem ter planos
para falhas, e, quando o fracasso for grande demais, devem permitir o retorno
para o sistema anterior. Claro, falhar é vergonhoso e ninguém quer ter planos
para tal acontecimento. Mas não ser capaz de recuperar-se durante uma falha de
serviço acaba com uma carreira.

Tornar a diretoria ciente de que você possuía um plano
secundário e que seguiu ele até sua meta quando o fracasso ocorreu é uma forma
de ganhar elogios. Deixar que um evento de inatividade perdure por muito tempo
à medida que você explica para a administração que não existe uma forma de
voltar e que o caminho à frente não tem uma aparência muito boa é uma conversa
completamente diferente. Planeje obter sucesso, mas também possua um plano para
o caso de um fracasso.

Nº 8: As recomendações dos
especialistas foram rejeitadas sem que os resultados fossem testados
Existem pessoas que pedem por conselhos de
especialistas e não dão ouvidos a eles, e então escolhem um caminho diferente –
sempre. E depois reclamam quando algo não funciona corretamente.

Não seja essa pessoa. Não deixe que essa pessoa tome
grandes decisões em sua equipe. Está tudo bem pedir por conselhos de
especialistas e depois fazer algo diferente. Isso faz parte da natureza humana,
e é muitas vezes o sinal de um bom líder. Apenas não o faça compulsivamente.
Mais importante ainda, se você for contra as recomendações e o resultado não
funcionar, não culpe o consultor.

Desviar das recomendações do fornecedor ou consultor
significa testar os resultados de sua mudança antes de lançar o projeto. Até
mesmo caso o fornecedor ou consultor concorde com seu desvio da recomendação
deles, certifique-se de que a mudança seja testada. Muitos projetos falharam depois dos lideres de projeto “realizarem algumas pequenas mudanças” que deixaram os
fornecedores e consultores profundamente contrariados. Você
ficaria surpreso com quantos especialistas permanecem em silêncio em frente de
clientes que parecem saber mais do que os experientes
consultores. Todo mundo quer ser amigo. Todo mundo espera que funcione.

Não tenha esperanças. Teste. E dê ouvidos a seus
especialistas na maioria das vezes.

Nº 9: A data de lançamento é em um
final de semana ou feriado
Muitos lideres de projeto planejam eventos de
lançamento para finais de semana ou feriados, devido as menores chances de interrupção
de serviço para funcionários ou clientes. Enquanto louváveis, essas
oportunidades também tendem a ser os momentos em que o suporte tecnológico é
mais difícil de ser contatado. Você pode ter seu fornecedor primário no local,
mas o suporte tecnológico terceiro pode estar fechado ou ocupado (e pode não
estar retornando ligações em tempo hábil), e o mesmo pode ocorrer com sua
equipe. Conversar com o especialista em base de dados
pelo telefone enquanto ele está de férias com sua família nunca é a melhor
opção.

Nº 10: As expectativas não foram
definidas
Quando um novo sistema está substituindo um sistema
antigo, é útil para todos compreender as novas expectativas. Como o novo
sistema irá se comportar? O que mudou nas transações e nos tempos de transação?
Para quem os usuários finais devem ligar caso encontrem problemas? Quando tempo
a equipe de solução de problemas estará presente durante o lançamento? Um novo sistema
sempre irá frustrar as pessoas, mas, caso você defina expectativas realistas e
dê para as pessoas opções de suporte acelerado, os problemas tendem a sumir de
modo mais rápido e você termina com clientes mais satisfeitos em pouco tempo.

Nº 11: Economia na formação
Não sei dizer quantos lideres de projeto irão
descontar do orçamento de treinamento quando tiverem de encarar custos extras. Ou quantos líderes presunçosos alegam que o sistema é tão simples que os usuários não precisam de
treinamento. Caso você escute, “treinaremos parte da equipe com metade das
aulas e assim eles poderão treinar os outros”, ou “nossos usuários são muito
bons em aprender, eles podem compreender este novo sistema em apenas alguns
dias”, você saberá que está a caminho do fracasso. Não são apenas os usuários
que precisam de treinamento, mas os lideres de projeto, os solucionadores de
problemas e a equipe de funcionários do suporte. Esteja preparado para atrasar
o projeto caso o treinamento apropriado não seja dado.