Principais riscos na gestão de projetos de TI

O crescimento da demanda por projetos de TI (Tecnologia da Informação), em todos os setores de negócios, é um fato inquestionável, e com ela os Gerentes de Projeto estão tendo que aprimorar suas técnicas, adaptando-as a nova realidade indo de acordo com os requisitos legais deste negócio.

Em meio a forte crise e ameaças constantes aos postos de trabalho, afirma-se que o setor de TI se mantém em perfeita movimentação, com oferta de trabalho em todos os seus setores, mas claro, justifica-se esta demanda por profissionais cada vez mais qualificados e principalmente, aptos a fazer a gestão desses serviços e ser muito eficaz nas entregas, agregando valor á empresa em pequeno e médio prazo.

Tratando-se de boas práticas, o PMBOK segue com força, ainda que ultrapassado devido ao dinamismo para este tipo de escopo, mas quando se trata de organizacional, ainda é o método mais recomendado. A Metodologia Scrum Agile, ou simplesmente Metodologias ágeis, avançam nos processos de gestão de TI justamente por responder a esse dinamismo. No Scrum, os projetos são dividos em ciclos (geralmente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado, ou seja, é a tela com suas devidas funcionalidades.

Desta forma quando o assunto são Riscos nos projetos de TI, antes de qualquer coisa, pensa-se no método ideal para trata-los e não ficar simplesmente revisando tabelas, ou enviando intermináveis e-mails em que são identificados os riscos, mas sim tratá-los.

Entre os principais e mais repetidos riscos em projetos de TI estão o que cito riscos profissionais e não tecnicamente, propriamente dito, ou seja, o risco inicia na má condução do processo, este sim resulta em falhas técnicas altamente letais ao contrato. São eles:

1. Definição de escopo

• Mapeamento de processos – O que o cliente espera do sistema está devidamente legal? Atende a diretrizes exigidas em órgãos superiores? Na maioria das vezes o ótimo é inimigo do bom quando se trata de desenhar essas necessidades conformes. A falha do GP em definir com o cliente e usuário final a real necessidade dentro de requisitos legais é o início dos problemas, que consequentemente irá refletir, direto, no QA e possivelmente na aceitação da funcionalidade no ato de entrega. É extremamente necessário, nesta fase, mapear o processo atual do cliente e o esperado, seja através de uma ERN (especificação de requisitos de negócios) ou fluxograma, devidamente validado por todos. Por melhor e mais experiente que seja o GP se pular esta etapa, a garantia de insucesso é enorme, podendo impactar no prazo e principalmente, nos custos finais e contratuais do projeto. O GP não deve, em hipótese alguma, deixar lacunas para a alteração de escopo.
• Levantamento de requisitos – esta fase abrange dois momentos. 1º levantar requisitos de negócios (ERN-especificação de requisitos de negócios), ou seja, identificar todos os pontos em que este projeto, como produto, irá agregar lucros ao cliente. 2º levantar requisitos funcionais (EF-especificação funcional) onde, o GP deverá discriminar atentamente com a equipe de desenvolvedores, como este sistema será codificado, se o processo de back-end (programação) está conforme a necessidade final do cliente. Se pular esta etapa, problemas de QA, retrabalho, não aceitação do produto, e também podendo impactar no prazo e principalmente, nos custos finais e contratuais do projeto, caso o cliente deseja manter este profissional ou até mesmo a fábrica de software no desenvolvimento. Por isso, faz-se necessário detalhar este item numa cláusula contratual única.
• Definição de envolvidos – Outro erro do GP de TI é envolver somente os principais envolvidos e esquecer totalmente do usuário final, aquele que irá ter sua rotina totalmente ligada ao serviço desenvolvido. Se pular esta etapa, também correrão sérios riscos de impactar no QA, prazo e principalmente, nos custos finais e contratuais do projeto.

2. Eficácia nas entregas

• Gestão do trabalho da equipe local e home – O dinamismo e total acesso do GP à sua equipe, o alinhamento da demanda, suas peculiaridades quando ausentes o induzem ao erro de, verificar o trabalho somente na fase de testes, que na maioria das vezes acontece ao mesmo tempo do cliente. O GP de TI é completamente dinâmico, presente, ainda que parte da equipe esteja geograficamente longe.
• QA (Quality Assurance) – processo de entrega das demandas no ambiente de testes que devem garantir que os produtos e serviços finais atendam ao nível de qualidade exigida. Fase mais complexa de todo o processo. É necessário que o GP desenhe, planeje, discuta e oriente a todos de como os testes serão realizados. O desenvolvedor precisa ter a cultura de verificar o que esta sendo feito, se está conforme, e para isso, o contato do GP é imprescindível, pois todo e qualquer erro pode e deve ser ajustado imediatamente visando à integridade da imagem da empresa.
• Aceitação por parte do cliente – inteiramente ligada ao QA. É a sequência dos testes internos, também chamados de pré-homologação. É o momento em que o cliente valida ou não o que foi desenvolvido. Se o GP não fez seus testes antes, ele estará contribuindo em grande parte com o retrabalho, aumento de prazos e possíveis custos no projeto.

3. Pleitos

• Alteração de escopo – fase em que o comercial da projetista se deleita ou surta de vez, pois é muito comum o cliente, ao se deparar com os pré-testes, concluir que “precisa de mais uma ação”, “mais um relatório” ou “mais um botão”. Lembrando que toda e qualquer funcionalidade gera custos. Por isso, o GP deve desenhar e questionar o processo, as reais necessidades deste cliente e evitar este constrangimento de aumentar o escopo, agregar valores extras, etc.
• Negociação de serviço fora de escopo – momento de grande estresse em todo projeto. Na maioria das vezes encerra-se a discussão com o famoso “nem eu e nem você, vamos ao meio termo”. Prejuízo total da projetista, pois todos sabemos que os desenvolvedores não trabalham somente 8 h/dia, e que as empresas tem altos custos com Hora Extra devido a alta complexidade de programar. Ou seja, se o GP não for eficaz no levantamento do escopo, ele será o maior contribuinte para toda essa situação que certamente resultará em perdas financeiras para a projetista.
• Revisão do processo – diante de toda e qualquer resistência do cliente na aceitação dos serviços durante os testes, é obrigação do GP dicutir o escopo fechado, verificar as falhas que porventura burlaram o QA e resultaram na necessidade de revisar o processo. Por isso, é necessário estar sempre atento às leis, normas, revisões, etc. Garantir que pelo menos até a entrega não haverá riscos de alteração na demanda.
• Congelamento do projeto – em último caso, mas muito provável que ocorra, principamente em tempos de crise. Ou seja, caso isso venha a se consolidar, é obrigação do GP estar documentado de que durante o processo não houve falhas no desenvolvimento. Portanto, identificou-se a necessidade de “desacelerar”, que a decisão parta do cliente. SEMPRE.

A citação deste grupo de riscos recorrentes não significa que pára por aí, devemos sempre pensar nos riscos técnicos, que serão citados em outro artigo.

Sobre a Colunista: Sandra Santos é Mestre em Direção de projetos pela Universidade Miguel de Cervantes. Administradora, formada na Universidade Estácio de Sá, com segunda graduação em Processos Gerenciais pela universidade Metodista de São Paulo; MBA em gerenciamento de projetos pela AVM Cândido Mendes; MBA em petróleo e gás pela AVM Cândido Mendes; Atualmente é graduanda do curso Análise e Desenvolvimento de Sistemas. Possui especialização em docência para nível superior pela FGV; Atua como consultora das ferramentas de gestão Primavera, MS Project e SGI. Atua no desenvolvimento de processos de gestão, preparação para auditorias internas e administração contratual de projetos no setor de óleo e gás e Governança de TI. Co-autora dos Livros Ser Mais com Equipes de Alto Desempenho, Damas de Ouro, Editora Ser Mais.

E-mail de contato: ssantosdesouza@gmail.com.

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.