Por que os chefes ameaçam e fazem piadas sem graça?

Alguns profissionais que ocupam posições de liderança comportam-se de forma autoritária para conseguir resultados mais rapidamente diante das contingências de TI. Ameaças diretas ou ironias tornam-se corriqueiras na ocorrência de qualquer urgência, importante ou não. Estas fazem parte do modus operandi do gestor que fica preso ao hábito da punição para obter um comportamento desejado dos seus subordinados. Mas ao longo prazo a sua equipe perde performance e se ele vacilar, o seu emprego.

Os líderes da tecnologia da informação lidam no dia-a-dia com um ambiente hostil. Devido a grande dependência de TI, as demandas são sempre superior a capacidade de entrega. Como consequência, o gestor se vê pressionado pelas áreas de negócio que cobram mais resultados e falaciam o tempo todo. Quando o seu repertório acaba, só resta pressionar os colaboradores por resultados imediatos, repassando na mesma intensidade a pressão das áreas de negócios. Neste momento, nasce o ditador.

Infelizmente, a forma mais eficiente de obter resultados no curto prazo é por meio da liderança autocrática. Nesta, existe apenas uma única opinião e os subordinados concentra-se em interpretá-la e executá-la. Os que não concordam prontamente e questionam são ameaçados e entram na lista dos bodes expiatórios. O gestor de TI ao ver o seu pedido atendido, mantém este modus operandi que vira um hábito e entende que este método molda mais rapidamente o comportamento da equipe e gasta menos tempo com a gestão de pessoal, aumentando assim a sua própria produtividade.

Esta gestão é com frequência composta de ameaças diretas ou por meio de ironias que sinalizam punições ou a perda de privilégios. Tudo isso aumenta o clima de tensão da equipe que não tem para onde extravassar, aumentando o estresse e a insatisfação de todos. Os colaborados gradativamente perdem a sua motivação pelo trabalho e em alguns casos, a auto-estima. A equipe que já não pode ser muito criativa, perde a produtividade e começa a adquirir resiliência às ameaças do chefe, passando a não responder ao seu estímulo. Assim, a rotatividade aumenta e instaura-se um clima que pode levar a demissão do gestor.

Quem já tem uma certa kilometragem, certamente já trabalhou com alguém que tenha este perfil - eu já perdi as contas dos chefes autoritários que tive. É realmente um situação de estresse ininterrupta. Tive um colega meio depressivo cujo chefe tinha o hábito de querer provar que ele não tinha conhecimento algum, mesmo sendo um especialista e um ótimo profissional. Um estudo realizado pelo Journal of Epidemiology and Community Health menciona que empregos com alto nível de exposição a ameaças de colegas, chefes ou clientes, aumentam em cerca de 50% o risco de depressão e 30% o risco de distúrbio relacionados ao estresse. Imagine, o impacto na produtividade e qualidade do trabalho. Em razão da criticidade do tema, foram aprovadas várias leis a nível municipal, estadual e federal no Brasil que visam coibir esta prática. A própria CLT já prevê a indenização por falta grave do empregador, inclusive ações categorizadas como assédio moral.

Observe que no dia-a-dia acontecem muitas situações de estresse com o seu chefe e colegas de trabalho. O que é normal. Muitas vezes, recorrem-se a ironia, por exemplo, durante as discussões mais acaloradas. Todavia, a situação, é diferente e pontual. Vocês está tendo um diálogo mesmo que o seu chefe não concorde com nada que você diga naquela conversa específica. O que não é normal é a repetição contínua de um mesmo comportanemto do seu chefe contra você. Ameças, piadas sobre a qualidade do seu trabalho, humilhações são exemplos de assédio moral que nada contribuem para a melhoria do trabalho e das relações dentro das empresas.

Um fato é certo com relação a esse processo: o comportamento do seu chefe é também moldado pelas suas respostas. Se o seu comportamento for o medo e atendimento cego as suas demandas sem questionamentos, ele manterá o seu comportamento pois conseguiu o que queria. A melhor saída é provocar discussões e demonstrar que a equipe tem conhecimento suficiente para encontrar soluções melhores e que estão em “sintonia” com a sua proposta. Tudo isso de uma forma amadurecida para fazer ele pensar que ele provocou este debate e criou um ambiente melhor de trabalho. Por exemplo, se o seu chefe determinar algo na sua coordenação de projetos de sistemas sem lhe consultar e de forma ameaçadora, proponha uma mudanda na metodologia e discuta com todos com base na sua “demanda”. Pois ele está, provavelmente, tentando fazer as coisas darem certo da maneira errada e cabe a equipe educá-lo.

Um alerta sobre chefes ditadores: tenham cuidado para não bater de frente e virar obstáculo. Estes, muitas vezes, são valorizados dentro da empresa pois são agente de mudanças e produzem resultados no curto prazo, normalmente não sustentáveis. Quanto às piadas sem graças, estas fazem parte da estratégia do seu chefe de assediar ou, provavelmente, usa as piadas sem graça para suavizar o impacto das ameaças e estragar o dia daqueles que possuem senso de humor.

Por que o estudo dos fundamentos é importante para as técnicas de TI?

Um dos meios de adquirir a excelência como profissional de TI é buscar melhorias na técnica. O programador procura codificar em menos tempo e com melhor qualidade mudando o método de trabalho; o especialista em redes melhora a performance; o gerente de projetos cria metodologias da sua indústria para minimizar os riscos do projeto. Cada um dentro da sua especialidade, estuda o que faz e muda a técnica para melhorá-la, alterando as atividades, as ferramentas e as pessoas que a executam. Todavia, a melhoria da técnica em si não é o único caminho para melhorar o serviço final que é prestado. Muitas vezes, devemos fazer uma mudança radical na forma de trabalho, questionando a técnica no seu fundamento. Questionar e saber o porquê da técnica é tão importante quanto saber executá-la com perfeição. Pois podemos modificá-la na estrutura, melhorando rapidamente o resultado.

Um bom exemplo desse argumento são as técnicas que maximizam a localização de sites pelos buscadores. Meta-tags, conteúdos e cadastro de palavra-chaves são técnicas que utilizam o conhecimento de como funcionam os buscadores. Estes por sua vez são estruturados em razão do comportamento do internauta ao pesquisar uma informação. Portanto, para que as técnicas funcionem, é importante que capturemos o comportamento do consumidor. Se o site divulga serviços, pesquisamos quais são as suas necessidades e como eles buscam a informação. A partir desse fundamento voltamos à técnica e mudamos o contéudo do site, que passa a ficar mais direcionado para quem busca o produto.

Este processo de regressão pode nos levar até um princípio. Por exemplo, quando nos defrontamos com um problema na nossa infraestrutura, podemos nos perguntar se realmente existe uma causa para o problema em questão. Os manuais de qualidade prescrevem várias metodologias para encontrar a causa raiz de problemas. Mas será que pode haver um evento sem causa externa? A resposta é não. Todo evento tem uma causa. Esta é a base do pensamento científico e isto é declarado como um princípio, uma verdade primeira, que não se pode demonstrar. O princípio da causalidade declara que se existe um objeto ou evento, algo o fez existir. Portanto, se houver um problema num sistema, algo o provocou. Este mesmo princípio por sua vez não restringe a quantidade de causas de um problema. Isto é exatamente o que acontece em TI: muitos problemas tem múltiplas causas, o que torna mais difícil a identificação e a resolução. Muitos profissionais esquecem isso com frequência e são vítimas de ocorrências com mais de um causa, levanto muito tempo para detectar a segunda e portanto para remediar o problema. Entender este fundamento, por mais óbvio que pareça, ajuda a melhorar a técnica de remediação de incidentes – o Incident Management.

Uma técnica pode ter mais de um conceito que a fundamenta como no caso do Incident Management. Este é fundamentado por vários conceitos tais como Riscos Operacionais, gestão de problemas, princípio da causalidade, resiliência de infraestrutura, etc. O inverso também é verdadeiro: um fundamento pode embasar mais de um técnica. O conceito de qualidade como expectativa do cliente embasa as correções de softwares, SLAs e pesquisas de qualidade. Abaixo alguns exemplos de fundamentos relacionados às técnicas.

Gestão de Incidentes
Gestão de Problemas, Análise de Causas Raízes, Riscos Operacionais, Princípio da Causalidade, Resiliência.

Redução do tempo das filas telefônicas

Teoria das Filas, SLA, Service Management, Business Process Management, Expectativa de Clientes.

Melhoria da Performance de Redes
Monitoração de Serviços, Planejamento de Experimentos, Distribuição de Poisson, Camada OSI.

Manutenção de Aplicações
Quality Assurance, CMMI, Qualidade como Expectativa do Cliente, Time to Market, Maturidade de processos.

DMZ
Rede na internet, Segurança da Informação, Risco Operacional, Detecção de Intrusão, Topologia de redes.


A técnica pode ser algo complexo como implementar e suportar uma DMZ, zona desmilitarizada. Neste tipo de rede, todos os servidores possuem endereço válido e são acessíveis pela internet, provendo serviços de banco de dados, aplicações, etc. Em razão do maior risco de ataque, esta rede é cercada de vários restrições de segurança tais como domínio isolado e firewalls. Ou seja, a necessidade de termos uma rede com aplicações e dados na internet é uma condição suficiente para a existência de DMZs. É uma condição suficiente mas mas não é obrigatória. O fundamento – necessidade de uma rede aberta para a internet - explica a possibilidade da sua existência mas não a sua obrigatoriedade. Este mesmo raciocínio é válido para todas as técnicas. O fundamento justifica a sua existência mas a utilização de uma técnica específica é contingente, não obrigatória. Portanto, toda técnica pode ser eliminada, melhorada e substituída por outra.

Além de melhorar o seu trabalho, o estudo dos fundamentos também ajuda o profissional durante debates. Questões sobre soluções, gestão de projetos, serviços e abordagem de problemas são exemplos de discussões avançadas que fazem parte do dia-a-dia. Sem fundamentar as premissas, fica difícil argumentar; sem entender o fundamento de quem argumenta, é impossível contra-argumentar. E só nos resta ouvir, ficar com cara de paisagem e aceitar os argumentos daqueles que se preparam melhor e estudaram todos os fundamentos da técnica.

Por que alguns profissionais de TI adquirem experiência mais rapidamente?

Um profissional de TI experiente é alguém que tem excelência em tudo que faz. É alguém capaz de tomar decisões rapidamente, entender um problema, intuir e agir produzindo um resultado muito bom sem demandar um grande esforço. Parece algo inato e difícil de conseguir, mas na realidade não é. Os mais experientes tem uma postura e método diferentes daqueles que evoluem muito pouco e não sabem o porquê.

A experiência em si é a presença do profissional em várias situações do trabalho: crises de infraestrutura, negociações com fornecedores, problemas com prazo e escopo de projetos, clientes problemáticos, quedas de performance, bugs de software, problemas de requisitos, etc. O contato com esses objetos e as suas representações na nossa mente é que determinam a experiência. A experiência proporciona informações que podem nos fazer melhorar. Podem porque não necessariamente nos fazem melhorar. Para melhorarmos, esta deve ser acompanhada por algo que nos torne excelente. Algo que dependa exclusivamente do profissional. Quando pensamos após uma experiência, estocamos mais um episódio da nossa vida. A sua análise crítica permite o estoque de novos conhecimentos. Ficamos assim mais sábios. Mais na frente, diante de uma experiência semelhante, sacamos o episódio e todo o conhecimento resultante da crítica, e o aplicamos da melhor forma possível diante da situação.

Há algum tempo, enviei uma comunicação sobre uma mudança num sistema que afetaria um cliente. O conteúdo descrevia o que estava sendo feito para minimizar os riscos. Sem perceber, mencionei as ações a serem feitas a posteriori e recebi uma resposta agradecendo pela antecipação aos problemas. A palavra “antecipação” ficou gravada na minha memória e literalmente "caiu a ficha". Percebi que sempre explicitar nas comunicações os próximos passos, mesmo que replanejados no futuro, aumenta a percepção de controle e de uma melhor gestão. Pois a atividade parece ser conduzida por alguém com uma maior bagagem, alguém mais experiente. Guardei esta técnica e atualmente faço isso sem perceber em todas as minhas comunicações. Ou seja, a experiência só foi útil porque decidi mudar e explorar a forma da minha comunicação.

Os profissionais experientes utilizam o dia-a-dia para explorar ao máximo as suas experiências. Por exemplo, durante um problema na performance de um banco de dados, um técnico interage com uma solução de storage. Este poderia resolver o problema acionando o fornecedor - previsto em contrato - sem explorar o que aconteceu em detalhes. Mas pode aproveitar a oportunidade para entender o problema técnico e todos os conceitos, comparar com outras soluções, identificar problemas semelhantes em outro hardware. Pode também explorar os eventos da ocorrência tais como o tempo de identificação do problema, a cortesia no atendimento, o SLA, etc. A crítica da técnica e do episódio podem ser tão detalhadas e aprofundadas quanto se queira, e quanto mais se explora, mais conhecimento profissional se adquire. A crítica do episódio, sequência de eventos, tem um outro produto: o contexto.

O contexto de uma determinado episódio é o conjunto de todas as circunstâncias que o cercam. É por exemplo, o fato do cliente ter razão ou não, ou se está apenas argumentando; é entender que existe uma questão política; é perceber que o problema é de definição e não de execução ou admitir que você está errado e se posicionar como tal. O profissional experiente entende melhor o contexto e o seu curso de ação é baseado neste entendimento. Por exemplo, a comunicação detalhada das causas raízes de um problema de infraestrutura se aplica dentro de TI, mas o bom senso recomenda reduzir o volume de informações para comunicações externas a TI. Nesse caso, vale a regra: quanto menos informação, melhor. Pois o cliente interno desconhece a tecnologia e provavelmente qualquer crítica será destrutiva e só amplificará o problema. O que é adequado para um contexto, pode não ser para outro. Capturar esses nuances não é tarefa fácil e requer muita análise crítica e comparação com conceitos existentes.

Os profissionais experientes entendem melhor todas as variantes da mesma situação e as associam aos conceitos. Problemas são associados a gestão de crises e análise de causa raiz. Quedas de performance são associadas a plano de capacidade, SLA e equipes de alta performance. Problemas de projetos são associados a gestão de escopo, a gestão de prazo e custos. É sempre possível associar alguma situação a um conceito e resgatá-la no futuro. A associação com o conceito permite uma comparação entre as melhores práticas e a ação. O profissional experiente faz isso num piscar de olhos, resgatando os seus antigos episódios e conceitos relacionados.

Podemos concluir que um profissional de TI experiente não é necessariamente alguém "velho" pois a experiência vem muito mais da reflexão do que da kilometragem. Este parece possuir um estoque de conhecimentos interminável pois está sempre aprendendo com todas as situações. Explora a técnica em detalhes ao mesmo tempo que determina o contexto de cada situação de trabalho. Mentalmente associa as situações aos conceitos e os desvios desses batimentos determinam as suas ações. Lê bastante mas entende que a leitura por si só não é origem do conhecimento mas somente a reflexão sobre o que lê e a sua utilização prática faz dele um pessoa mais experiente.

Por que as demandas sempre superam a capacidade de TI?

O Homem sempre buscou na técnica um atalho para as suas realizações. E, por meio da Tecnologia, como ciência da técnica, pressiona o aumento da produção. Como consequência, os ambientes mercadológico, regulatório, competitivo, político e social forçam as empresas a desenvolver novos produtos, a reduzir custos e a melhorar. Estas forças produzem um grande volume de demandas a TI, que se vê obrigada a executar num cenário crescente de demandas, a defender a sua capacidade e a recusar demandas maliciosas das áreas de negócio. Estas forças, de origem externas e internas, resultam num desvio contínuo entre a demanda e a capacidade de TI.

O Governo muda a forma e as alíquotas de impostos, altera informações obrigatórias, cria interfaces com os orgãos federais e reduz cada vez mais o tempo para o mercado se adaptar a novas regulamentações, gerando projetos obrigatórios que furam a fila dos planejados. Enquanto isso, os clientes ameaçam trocar de fornecedor se a empresa não melhorar os níveis de serviço, a concorrência lança produtos que temos que copiar ou melhorar e os acionistas pressionam o compliance para exigir a automatização dos principais controles. Todas essas forças motrizes têm duas características em comum: tem origem externa e não são controláveis. A empresa é obrigada a executar projetos para sobreviver e não pode evitar, ou não há razão para tal, que as demandas externas existam. O passo seguinte é transferir a demanda na mesma intensidade para TI.

Além das forças externas, existe uma série de demandas internas que contribuem para aumentar o desvio entre a demanda e a capacidade: projetos de redução de custos, de transformação da tecnologia, iniciativas da própria área, segurança de informação, revisões da arquitetura, projetos globais, etc. Apesar de competirem com os projetos externos pelos mesmos recursos, são bem mais gerenciáveis e possuem uma prioridade mais baixa. Dessa forma, são as primeiras demandas a ir ao matadouro.

Para complementar o cenário, ineficiências de ambos os lados descolam a demanda da capacidade. Problemas na gestão de TI reduzem a capacidade de entrega (vide artigo do mesmo autor: por que as áreas de tecnologia são consideradas gargalos na maioria das empresas?); do lado da demanda, solicitações mal estruturadas e maliciosas sufocam TI. Abaixo alguns exemplos:

• Uso da capacitação de TI: como TI possui um conhecimento dos processos críticos, a área cliente demanda apenas com o objetivo de agregar este conhecimento ao seu projeto, que não decola ou passa a não envolver tecnologia. Uma idéia de 1h de um gestor de produtos pode gerar 100h de avaliação de um analista de sistema ou de negócios.

• Falta de conhecimento da tecnologia: o desconhecimento dos conceitos e da técnica por parte de quem demanda sobrecarrega TI com pre-análises. Pois esta tem sempre o ônus da prova da viabilidade técnica e financeira dos produtos. O projeto é viável até que TI demonstre o contrário.

• TI como desculpa para a não-entrega: a área de negócio demanda com a expectativa de receber um não como resposta e com o objetivo de utilizá-la para justificar um atraso, um problema no cliente ou a inviabilidade de um projeto, que muitas vezes poderia ser resolvido com uma abordagem de processo, comercial ou treinamento(vide artigo do mesmo autor: Aprenda a defender-se contra as falácias dos clientes) .

• Incerteza sobre a Capacidade de Entrega de TI: é razoável afirmar que existe sempre uma dificuldade técnica na medição da capacidade de entrega de TI. Esta dificuldade é decorrente da complexidade do ambiente tecnológico e das variações de desempenho entre os profissionais diante dessa complexidade. Esta incerteza faz com que projetos aparentemente simples sejam complexos, e vice-versa. Em decorrência disso, as áreas demandantes têm dificuldade de saber e confiar na capacidade declarada de TI. E com o objetivo de medi-la, pressionam pelo aumento de entregas.

• Diferenças entre o Time to Market e prazos de entregas de TI: como os clientes pressionam por produtos de entrega imediata, o tempo de execução de um projeto de TI é normalmente superior a expectativa da empresa, que reflete a expectativa do mercado. Existe portanto um alto risco de haver mudanças de escopo durante a execução. Essas mudanças geram retrabalhos e reduzem a capacidade de TI.

Todas essas demandas e suas ineficiências pressionam TI a aumentar a sua capacidade por meio da força-bruta: aumento do número de colaboradores, fornecedores, SLA, etc. E como as áreas que demandam também ajudam a justificar o aumento de capacidade, estas percebem o aumento e demandam mais para utilizar este incremento de capacidade a favor do negócio. O raciocínio inverso é verdadeiro. Se a capacidade ociosa não for rapidamente preenchida, as áreas de negócio vão pressionar a estrutura para ser mais eficiente e cortar custos, reduzindo assim a capacidade.

Pelo que foi argumentado, é razoável afirmar que a demanda por projetos será sempre superior a capacidade de entrega de TI. Isto não implica que a execução de projetos seja ineficiente. A eficência da área está relacionada com a capacidade de entrega versus recursos da área e não com o desvio entre a demanda e capacidade - falácia muito usada contra TI. Podemos considerar que este desvio é um ponto de operação da empresa e é restrito pelo seu fôlego financeiro e operacional.

Como consequência desse desvio inexorável, devemos alocar esforços na gestão de demandas de projetos e não tentar impedir a sua existência. Ou seja, devemos cooperar mas evitar que demandas não maduras ou maliciosas cheguem as fases de detalhamento, reduzindo a capacidade de TI. Como não é possível atender tudo, sempre haverá alguém descontente pois a sua demanda não foi atendida. Podemos concluir também que a pressão maior será sempre das demandas externas. As internas, relevadas a um segundo plano, serão sempre as mais sacrificáveis. Nesta problemática, o papel de TI é aumentar sempre a eficiência de sua entrega, gerenciar as demandas na origem, demonstrar a sua capacidade e explicar como funciona a produção de projetos mesmo para aqueles que usam TI como desculpa para não entregar.

(Contato: pfariascf@gmail.com, http://www.pensarsobretecnologia.com.br/)

Gestão de Pequenas Demandas 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 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.

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.

(Contato: pfariascf@gmail.com, http://www.pensarsobretecnologia.com.br/)