Seja proativo sempre que você encontrar um deles – ou simplesmente se afaste. Sua carreira depende disso.
ROGER A. GRIMES, INFOWORLD/EUA
17 de maio de 2013 - 11h35
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.
Fonte: Computerworld
http://computerworld.uol.com.br/gestao/2013/05/17/veja-11-dicas-para-avaliar-riscos-dos-projetos-de-ti/
Canal Taitell
