Entendendo a gestão de projetos de TI Eunápolis, Bahia

Compreenda a importância da gestão de projetos de TI. O executivo de TI Paulo Farias classifica a demanda de serviços desse departamento. Ele também descreve quais são as regras que reduzem os riscos operacionais e mantém o faturamento.

Expert Tecnologia de Informação
(71) 3271-5517
av Tancredo Neves, 1632 sl 1312 Caminho das Árvores
Salvador, Bahia

Dados Divulgados por
Companhia de Processamento de Dados do Salvador
(71) 3245-5883
r Macapá, 271 Ondina
Salvador, Bahia

Dados Divulgados por
Informática Aplicada Projeto Desenvolvimento Gerenciamento Ltda
(71) 3341-3151
av Tancredo Neves, 805 s 902 Caminho das Árvores
Salvador, Bahia

Dados Divulgados por
Auriga Informática e Serviços
r Itatuba, 201 s 1501 Parque Bela Vista
Salvador, Bahia

Dados Divulgados por
Frenesi BBS
(71) 3243-6013
Pc Tupinambás, 2 Comércio
Salvador, Bahia

Dados Divulgados por
DATAPREV-Empresa de Processamento de Dados da Previdência Social
(71) 3321-8800
r José Gonçalves, 120 Centro
Salvador, Bahia

Dados Divulgados por
Milsoft Informática
(71) 3242-5322
Lad Funil, 169 to Barbalho
Salvador, Bahia

Dados Divulgados por
Ampulheta Consultoria e Serviços de Processamento de Dados
(71) 3341-6011
r Ewerton Visco, 342 s 307 Caminho das Árvores
Salvador, Bahia

Dados Divulgados por
Nível 03 Processamentos e Transmissão de Dados
(71) 3241-5862
r Visc do Rosário, 4 sl 801 Comércio
Salvador, Bahia

Dados Divulgados por
MI-Montreal Informática
(71) 3271-5242
av Tancredo Neves, 1632 st 517 sl 515 sc 516 Caminho das Árvores
Salvador, Bahia

Dados Divulgados por
Dados Divulgados por

Entendendo a gestão de projetos de TI

A governança de pequenas demandas de TI é sempre um processo difícil de implementar porque o conflito de interesses é constante, existe uma expectativa de execução imediata por parte do cliente e invariavelmente a demanda é superior a capacidade de entrega. Tudo isso dificulta o processo de decisão. Por sua vez, os gestores de TI buscam sem sucesso uma fórmula para equacionar o problema mas o resultado na grande maioria é decepcionante. Entender o porquê ajudará na definição da melhor solução.

As empresas classificam as demandas pelo esforço ou investimento com o objetivo de facilitar a decisão e encaminhá-las nos fluxos apropriados. O critério de tamanho varia bastante: horas, custos, tempo total de execução ou quantidade de recursos críticos. As demandas de maior investimento são gerenciadas por comitês que criticam e priorizam os principais projetos da companhia e normalmente envolvem representantes de cada área. As menores seguem dois processos distintos quanto a capacidade de entrega de TI: execução imediata e necessidade de priorização. As demandas de execução imediata tais como o suporte a cliente podem ser operacionalizadas por meio de um service center com SLA e são executadas pela ordem de chegada e severidade, impacto. Aquelas que exigem para a sua execução recursos escassos, críticos, necessitam de alguma forma de avaliação e priorização antes de serem executadas.

Exemplos de demandas pequenas que invariavelmente possuem recursos críticos são as correções de softwares, alterações de infraestrutura, pequenas melhorias de aplicação, atualizações de software e hardware. Estas chegam através de vários canais: help-desk, service desk, call-center, reuniões ou e-mail. E o solicitante pressiona TI para que as suas demandas sejam atendidas imediatamente. Mas como unidade de serviços não tem a capacidade de execução imediata, ela torna-se um gargalo e surge inevitavelmente a questão "do que executar primeiro". Então, alguém sugere utilizarmos o mesmo tipo de governança dos grandes projetos para que as áreas de negócio priorizem todas as demandas pequenas a TI.

A premissa para priorizarmos uma atividade é o seu entendimento prévio. Portanto, se vamos utilizar o mesmo modelo de gestão das "grandes" demandas, teremos que avaliar 100% das demandas que caiam na nossa "caixa postal". Contudo, o grande volume de demandas pequenas dificulta a implementação do mesmo modelo de priorização de demandas grandes pois o custo total de avaliação é grande se compararmos ao seu custo total de execução. E muitas vezes a avaliação é feita por um time diferente da execução, portanto perde-se o esforço de avaliação se a demanda não for priorizada. Como consequência, a qualidade da avaliação tende a ser precária com o passar do tempo e a priorização deslocada do negócio. O volume elevado de demandas advoga a favor das decisões arbitrárias.

Mesmo que ainda seja possível avaliar todas as demandas, o processo de governança típico de TI exige um alinhamento entre todas as áreas que competem entre si pela execução. Estas não dispõem de tempo e recursos necessários para participar de todas as reuniões de alinhamento necessárias para priorizar execuções. Na prática, profissionais menos qualificados são despachados para "defender os interesses" da área e munidos de pouca informação. Com o tempo, o resultado é o mesmo: baixo nível de alinhamento e qualificação das demandas. 

Podemos concluir que o grande volume de demandas pequenas resulta num alto custo de avaliação versus execução e num baixo nível de alinhamento com o negócio. Tudo isso implica um processo de decisão incerto, confuso e não transparente para quem participa. Rapidamente percebe-se a falta de robustez do processo e começa uma nova temporada de pressões, falácias e tentivas de furar a fila. O gestor das demandas é obrigado a executar por ordem de chegada ou por quem grita mais e procura uma alternativa mais rápida, mais alinhada com o negócio e menos arriscada.

Como não há tempo hábil para avaliarmos, alinharmos e priorizarmos todas as demandas com o negócio, precisamos de um guia, de uma referência, para podermos alinhar as nossas decisões aos objetivos gerais da empresa. Uma das formas possíveis é construirmos um conjunto simples de regras para a tomada de decisão a partir de uma argumentação de negócio. Este critério deve reflitir o modus operandi de uma área de produtos, de vendas ou de um sócio. Como os objetos da nossa discussão são as pequenas demandas de TI e não vamos argumentar com base em demandas específicas, podemos classificá-las e priorizá-las pelo tipo de impacto no negócio. Esta simplicação não leva em consideração a ordem de grandeza do impacto, nem a sua urgência, mas é suficiente para estabelecermos algumas regras genéricas.

Toda demanda gera um impacto no negócio: problemas de hardwaregeram interrupções de serviço; bugs de aplicação são erros de faturamento, problemas na qualidade de serviço; a falta de um disco de 145Gb para backup é Risco Operacional; um pequeno acréscimo de software pode significar uma melhoria no produto com aumento de receita; a falta de uma informação pode resultar em multas devido ao não atendimento a regulamentação, etc. Como base neste mapeamento, podemos classificar as demandas da seguinte forma:


  • Melhorar a Qualidade dos Serviços.


Exemplos: melhorar o SLA, diminuir tempo de resposta, fornecer informaçôes adicionais.

  • Manter a Operação.



Exemplos: aumentar a disponibilidade, corrigir bug em produção, remediar um incidente, eliminar instabilidades, problemas de segurança.


  • Melhorar os Produtos.



Exemplos: novas funcionalidades, novo design.


  • Atender a Regulamentação.



Exemplos: mudanças na regulamentação do Banco Central; Receita Federal; Cálculo de impostos;


  • Atender ao Compliance



Exemplos: Sanções internacionais, políticas internas, mudança de relatórios internos.


  • Atender a Justiça



Exemplos: ordens judiciais, ações movidas por clientes finais.


  • Manter o Faturamento.



Exemplos: corrigir o faturamento, mudar regras, eliminar processos manuais de faturamento.


  • Reduzir o Risco Operacional.


Exemplos: eliminar processos manuais, eliminar vulnerabilidades, pequenas alterações na infraestrutura.

Toda empresa cria, entrega e fatura os seus produtos. Portanto, interrupções de serviços ou instabilidades que impeçam a entrega do produto ou a prestação do serviço põem em risco a empresa, pois esta necessita manter um fluxo contínuo de receitas para sobreveviver e crescer. Os problemas na operação interrompem imediatamente este ciclo pois o produto deixa de atingir o seu propósito. Qualquer melhoria não pode ter uma prioridade maior pois não faz sentido melhorar um processo, reduzir o risco operacional ou acrescentar algo num produto que não roda, que não para em pé. 

Regra 1: Manter a Operação. 

Um problema no cálculo de impostos, uma falha na tranferência de arquivos para a prefeitura ou a falta de atendimento a normas federais pode resultar numa multa elevada ou a perda de uma licença. Da mesma forma que manter a operação é vital para o negócio, atender a regulamentação é uma questão de vida ou morte, pois muitos produtos não podem operar se não atenderem a regulamentações específicas do seu mercado. A falta de atendimento a liminares de clientes finais tem o mesmo nível de prioridade pois podem causar a paralisação legal da prestação do serviço, do produto. O Compliance também regulamenta o modus operandi do produto e representa a vontade final do acionista. Todas essas limitações do produto devem ser atendidas ao mesmo tempo que opera. Caso contrário, o produto deixa de existir e passa para a ilegalidade.

Qualquer atividade que garanta a existência legal do produto tem prioridade em relação a atividades de melhoria e redução de risco operacional. Pois não é lógico melhorar ou vender aquilo que está fora do contexto que foi originalmente criado.

Regra 2: Atender a Justiça, Regulamentação e Compliance

A ausência da informação sobre a ordem de gradeza do impacto dificulta a escolha entre a correção de problemas no faturamento, melhorias da qualidade de serviço ou produto e a redução de riscos operacionais. Pois todas demandas envolvem perdas de receitas reais ou potenciais. Os problemas de faturamento são desatrosos pois o impacto financeiro pode ser grande quando demoramos muito tempo para corrigir um problema. E como consequência, a falta de caixa nos impede de executar outras demandas. Por sua vez, problemas de qualidade de serviço e no produto podem reduzir o faturamento e comprometer a imagem da empresa a curto prazo.

A maioria das perdas causadas por uma falha de faturamento são imediatas enquanto que melhorias não executadas geram um impacto no futuro. O mesmo raciocínio é válido para as ações que reduzem o risco operacional e que possam ser realizadas de forma mais planejada. Estas reduzem problemas potenciais e não imediatos.

A necessidade imediata da correção de problemas de faturamento e a dependência para a geração de caixa para as outras demandas implicam a sua priorização. 

Regra 3: Manter o Faturamento.

Entre melhorar os produtos e serviços e reduzir o risco operacional, sempre opta-se pela melhoria em detrimento da redução do risco. Pois o Risco pode ser administrado mais facilmente enquanto possibilidade. Isto não quer dizer que todo risco tenha uma baixa prioridade. Casos específicos como High-Risks devem ser executados imediatamente. Todavia, na maioria dos casos, podemos administrá-los e executá-los de forma planejada, o que não pode significar o seu eterno adiamento.

Regra 4: Melhorar os Produtos e a Qualidade de Serviços

Ordenando-se as classificações, segundo o argumentação acima, obtemos:


  • Manter a Operação.

  • Atender a Justiça, Regulamentação e Compliance

  • Manter o Faturamento.

  • Melhorar os Produtos e a Qualidade de Serviços

  • Reduzir o Risco Operacional.



Na falta de uma definição do negócio com relação a prioridade, executamos as demandas que mantêm a operação, atendemos a regulamentação e e o compliance, corrigimos os problemas de faturamento, melhoramos o produto e a qualidade de serviços, e por último diminuimos o risco operacional.

Essas regras não são sob hipótese alguma uma prescrição do que deve ser feito, um dogma de fé ou algo lavrado em pedra. E tampouco substituem uma priorização realizada pelo negócio. Mas existem várias ocasiões onde não há tempo hábil para um alinhamento formal com o negócio, e nesses casos, TI tem que tomar decisões que impactam a empresa. O desenvolvimento de um critério racional é melhor que a sua ausência e nos ajuda a pensar sobre as particularidades desta problemática, de forma a construir uma argumentação sólida e introduzir o bom senso no processo.

Paulo Farias Castro Filho

Executivo de TI com experiência em serviços financeiros e internet. Escritor de vários livros e artigos sobre tecnologia.

Clique aqui para ler este artigo na Artigonal.Com