Tecnologia

As falhas na gestão da tecnologia da informação

A empresa na qual você trabalha possui um sistema satélite, utilizado para o acompanhamento de uma área de negócios de alta criticidade que dá problemas constantes de travamento, demora em executar fechamento, apresenta erros nos relatórios, etc. A equipe de TI é sempre envolvida e todos já sabem que os problemas se devem a baixa qualidade do código, ao excessivo número de “gambiarras” já aplicadas à programação e ao banco de dados do sistema por meio dos famosos “puxadinhos”, que ora resolvem uma emergência, mas em geral acabam gerando efeitos colaterais destrutivos.

Diversos desenvolvedores e analistas já propuseram solução, que é jogar tudo fora e começar do zero. Há anos que se fala no projeto de substituição do sistema, inclusive o programador que se demitiu na semana passada, havia sido contratado há dois anos com a proposta de desenvolver um novo sistema, com enormes desafios, etc. Mas a realidade é que, devido à contenção de gastos, ao orçamento limitado, o alto volume de demandas corriqueiras e o fato de que as “gambiarras” vêm “resolvendo” os problemas emergenciais, nunca houve alguém dentro da organização que peitasse a substituição do sistema.

No último episódio, o relatório contábil que tinha de ser entregue à Receita Federal atrasou por conta de erros nos relatórios e um excessivo número de horas para processar e reprocessar o volume de informações do mês. Como consequência a empresa perdeu os prazos legais e quase perdeu a concessão para funcionar e ainda teve de pagar milhares de reais em multas, além de ter que fechar um acordo extremamente oneroso com o governo.

Este ônus chegou rapidamente às mãos do presidente da empresa, que convocou uma reunião de emergência com os chefões de TI e Contábil e ficou extremamente furioso ao saber que o problema de sistema já era conhecido a cerca de três anos e nada foi feito para mitigar os riscos conhecidos. Após o clima esquentar entre a área de TI e contábil a fim de determinar de quem era a culpa, o presidente ordenou que o sistema atual deveria ser substituído em 30 dias, antes do próximo período de fechamento.

Imediatamente o CIO convocou consultorias de TI, contratando mais de 20 profissionais, entre programadores e analistas. Ao todo foram contratadas quatro consultorias, sendo uma delas na Argentina, para um projeto desafiador com o prazo para conclusão de 24 dias (ou 4 semanas). Os profissionais que já atuam no sistema atual não foram envolvidos para não prejudicar a operação do dia a dia e a área de negócios não foi sequer envolvida no projeto dada a urgência. Foi marcada a primeira reunião, presencial e por telefone (já que uma das consultorias era de outro país) e definiu-se que não havia tempo hábil para documentar o projeto, razão pela qual foi enviado o instalador da aplicação problemática para as quatro consultorias de forma que elas tomassem conhecimento do sistema que iria ser substituído e já começassem o trabalho. O diretor foi muito claro durante a reunião ao informar que o projeto deveria começar IMEDIATAMENTE e que o prazo já estava contando.

De posse do sistema antigo, todas as consultorias o instalaram e após uma semana, na primeira reunião de acompanhamento do projeto do novo sistema, onde o diretor esperava já ter algo funcionando, observou-se que:

A consultoria situada em outro país ainda estava tentando traduzir as telas e mensagens do sistema antigo e não tinha sequer iniciado o projeto;
Duas consultorias chegaram a conclusão que deveriam começar pelo “motor financeiro” do sistema e, portanto ambas estavam fazendo a mesma coisa;
A quarta consultoria já tinha 80% do sistema pronto para ser apresentado, mas ao validar o trabalho percebeu-se que eles não compreenderam o escopo do projeto e nada do que foi feito pôde ser aproveitado.

Passados os 30 dias não havia sequer consenso sobre qual time faria o que. Após outros dois anos de projeto, alocação de mais mão de obra e substituição de alguns líderes de TI, a primeira versão do novo sistema foi implantada, atendendo apenas 80% da necessidade da área de negócios, que sequer foi consultada sobre o que poderia ser aprimorado em seu processo.

A histórica acima é bastante exagerada, mas retrata situações que podem ocorrer em empresas (em geral de grande porte), onde a área de TI é grande e tentativas de implementação de metodologias acabam suplantadas pelo “nosso jeito” de fazer as coisas acontecerem.

Vamos então analisar algumas das falhas neste projeto e ver algumas dicas para uma boa condução de projeto.

1 – Medo de tomar decisão

Quando se trata de tomar decisão que envolve alto risco (ex.: completa substituição de um sistema em produção), ou uma decisão que envolve um alto investimento (ex.: custo para desenvolver um sistema a partir do zero), muitos gestores travam e postergam a decisão com medo de suas consequências.

Não tenha medo de propor mudanças e de tomar decisões. Em geral, por pior e mais bravo que seja o presidente ou responsável por sua organização, se você juntar argumentos suficientes que demonstrem que o risco/custo de não tomar decisão é maior que o risco/custo de fazer, ainda que contra a vontade dele, você vai acabar conquistando o apoio dos responsáveis por aprovar orçamento e alocação de recursos.

Busque tomar as decisões antes que seja tarde de mais, em nosso exemplo, demorou três anos e a decisão só foi tomada após a incidência de um desastre.

2 – Não perca o amigo para ganhar uma discussão

Durante a reunião, observa-se que tanto a área contábil quando a área de TI discutiam calorosamente para determinar quem era o culpado. Talvez naquele momento o culpado nem fosse tão importante quanto a solução. Mais importante do que determinar de quem era a culpa era resolver o problema que causara milhares de reais em multas e de fato, para qualquer bom gestor, ele já sabia que a culpa era de ambas as partes. De TI porque sabia do risco e não escalou o problema e da área de negócios que também já sabia dos problemas e aceitava os “puxadinhos” como solução.

O ideal em situações de discussão, é interromper a fala e se propor a estudar e avaliar o que de fato ocorreu, mostrando que o foco deve ser a solução do problema. A posteriore, talvez seja interessante conversar com a outra área e acordar que a culpa é dos dois e assumirem juntos o erro, mas com o foco na solução, sempre!

3 – 9 mulheres grávidas não fazem filho em um mês

Se você perdeu o momento e o incidente crítico já ocorreu, não saia desesperado querendo consertar do dia para a noite o que não foi consertado em três anos, por maior que seja o seu orçamento e a pressão dos top gestores.

Atue em duas frentes:

Como mitigar imediatamente o risco de novos incidentes?
Crie um plano de projeto para a completa substituição do sistema e coloque-o em prática.

Esteja preparado e com um excelente plano de ação e argumentos para convencer e ganhar o apoio dos top managers no sentido de inicialmente atuar para mitigar os riscos e impactos dos erros conhecidos causados pelo sistema atualmente em produção. Eventualmente será necessário alocar mais recursos e alterar o horário de trabalho de outros para assessorar a área de negócios e identificar com a maior agilidade qualquer possibilidade de erro e intervir para que não se torne um problema. Talvez a troca de servidores por máquinas mais rápidas poderá trazer um ganho de curto prazo e também pode ser considerado.

4 – Cachorro que tem dois donos morre de fome

A divisão de tarefas e o paralelismo na execução são imprescindíveis para a rápida conclusão de um projeto, mas se você não planejar as atividades, definir muito claramente qual o caminho crítico e distribuir as tarefas ordenadamente, não irá funcionar e você ainda correrá o risco de que uma parte do projeto siga padrões de desenvolvimento diferente de outras, o que aumentará os riscos e os custos de manutenção futuros, sem contar que poderá ter duas equipes fazendo exatamente o mesmo trabalho.

Ao dividir tarefas, certifique-se de que cada equipe tenha o apoio de um arquiteto do projeto (ou semelhante), responsável por definir e assegurar que as boas práticas estejam sendo seguidas e siga o plano de projeto, assegure-se também de que as atividades se complementam e em hipótese nenhuma mais de uma equipe seja responsável pela mesma entrega.

Se o “entregável” é algo maior, pode ser fatiado de forma que cada equipe entregue uma parte desse todo, mas jamais as duas equipes devem ser responsáveis por um mesmo “entregável” maior. Este é talvez um dos pontos que geram o maior atrito, pois começam as disputas de poder, de melindres e vaidades que comprometem severamente o projeto. Se possível, trabalhe com um arquiteto em um nível de staff, ligado diretamente ao gerente de projetos e no qual todas as equipes se reportam para as decisões técnicas e metodologia de desenvolvimento.

5 – Quem não se comunica se trumbica

Como gerente do projeto você deve delinear um plano de comunicação constante, que vai muito além de reuniões semanais por telefone ou envio de atas e memorandos.

Uma boa comunicação deve garantir que todos estão alinhados ao projeto, todos sabem na ponta da língua qual o seu papel dentro do projeto e o que a empresa espera dele em relação a prazos, qualidades e expectativas. Eu, particularmente, aconselho o uso de um sistema de informação de projeto, que pode ser o próprio Sharepoint da Microsoft, mas também há outras opções no mercado, inclusive algumas gratuitas.

O cliente ou departamento também deve estar alinhado e toda e qualquer alteração que ocorrer e que afetar preço, qualidade, escopo ou cronograma deve ser muito bem alinhada com o cliente, afinal, o que é acordado não é errado. Natural que ninguém vai gostar de ouvir que o projeto está atrasado, mas é melhor avisar com um mês de antecedência do que na data prevista para a entrega. Dependendo do fator que está gerando o atraso, o próprio cliente pode intervir junto aos fornecedores e até mesmo atuando em outras áreas com a finalidade de auxiliar e garantir que o projeto volte ao rumo.

Muitos gestores acreditam que podem recuperar o prazo com horas extras e supressão de artefatos e que é melhor não alertar o cliente sobre o risco de atraso para não causar pânico. Independente do atraso, as ações demonstradas modificam qualidade e custo no projeto, então alerta: eu sugiro que, desde a elaboração do cronograma, o cliente já saiba de forma transparente que há tempo alocado para mitigação de riscos e se o atraso atual consegue ser compensado pelo tempo alocado para mitigação, então aceito que você trabalhe internamente para recolocar o projeto de volta nos trilhos sem alardear, mas se não for este o caso, é preferível ser transparente e envolver o cliente.

Haverá os clientes que não aceitarão tempo alocado para mitigação de riscos, alegando principalmente que se há mais tempo, então haverá menos pressão para a entrega e consequentemente o projeto irá atrasar ainda mais. Infelizmente a cultura local acaba dando subsídios para este tipo de argumento, mas não aceite simplesmente. Sugira a criação e a divulgação para a equipe do cronograma sem o tempo alocado para mitigação, mas defina com o cliente os milestones baseados no cronograma com a previsão de tempo para mitigação.

Existem muitos outros pontos que poderiam ser abordados neste cenário proposto, mas espero ter listado acima alguns deles. O grande segredo de qualquer gestor ou metodologia de gerenciamento de projetos, por mais simples que seja, é ser racional. Então se prepare e faça as coisas que parecem sensatas, com os pés no chão e sem invenções mirabolantes, que o sucesso na gestão de projetos acontece. [Webinsider]

…………………………

Leia também:

…………………………

Conheça os cursos patrocinadores do Webinsider

Digitalks – Marketing digital para profissionais – digitalks.com.br
Ecommerce School – Especializada em comércio eletrônico, redes sociais e marketing digital – ecommerceschool.com.br/webinsider/
TreinaWeb – Cursos de Tecnologia da Informação – treinaweb.com.br/cursos-online

Acompanhe o Webinsider no Twitter e no Facebook.

Renato Ucha

Renato Ucha é formado em administração de empresas, especializado em gestão de projetos. Possui vasta experiência na área, além de dar palestras e escrever sobre o assunto.