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 hardware geram 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.
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.
