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/)

Transfira o risco para longe de TI

As áreas de tecnologia da informação normalmente assumem riscos desnecessários devido a ausência de instrumentos para transferir ou compartilhar riscos com outras áreas. O desconhecimento desses processos e do conceito de risco aumenta o custo operacional e diminue a qualidade do serviço, pois necessitam administrar um estoque sempre crescente de problemas potenciais.

Risco é a possibilidade da ocorrência de eventos que causem perdas ou flutuações em receitas futuras. É tudo aquilo que pode gerar perdas para a organização tais como riscos de falhas em infraestruturas, problemas em aplicações, atrasos e quebras do orçamento de projetos, etc. Para minimizar o possível impacto financeiro, os manuais de gestão risco prescrevem metodologias de mitigação de risco. Mas a sua minimização ou eliminação muitas vezes não é tecnicamente ou financeiramente viável, e como os manuais de sobrevivência ensinam, se não é possível resolver um problema, transfira para o vizinho.

A transferência formal do risco ocorre quando uma parte contrata um terceiro para assumir ou dividir o risco. Um bom exemplo disso ocorre na terceirização de serviços de desenvolvimento de software ou na gestão de infraestrutura. No outsourcing, uma empresa especializada é capaz de lidar mais facilmente com o risco pois possui uma maior escala e conhecimento que a contratante.

O caso oposto ocorre quando não existe um relacionamento formal entre as partes. Este é o caso de consultas a especialistas dentro da organização. A apreciação por parte de um terceiro divide o risco técnico do projeto, da solução, e também o minimiza.

Em muitos casos, o risco é mais sutil e está presente na tomada de descisão diária. A compra de um novo equipamento ou software fora de um padrão, por exemplo, pode gerar um problema grave de arquitetura. O alinhamento prévio com o seu par, chefe ou colega divide o risco com a estrutura da empresa. O risco deixa de ser apenas do profissional, da área, do departamento e passa a ser de todos envolvidos no processo de comunicação.

Da mesma forma que faz sentido a transferência do risco para fora, é lógico rejeitá-lo ou criar dificuldades quando vem de fora. Muitas vezes as áreas de negócio aumentam o risco das áreas de tecnologia através de soluções adquiridas do mercado. Certa vez hospedei um servidor com uma solução tipo caixa-preta adquirida durante uma negociação com um cliente pela área comercial. Como não havia manutenção na aplicação, houve vários problemas de disponibilidade após a implementação do sistema. E naturalmente ninguém se lembrava de quem houvera comprado e forçado a implementação "guela abaixo" de TI. O produto foi desativado depois de uma série de tentativas sem sucesso de melhorar a arquitetura da solução e literalmente foi redesenhado. A área de negócio não estava ciente dos riscos operacionais ou não se importava com eles, pois após o fechamento do negócio, "o risco passou a ser da área de TI e não da área comercial". Na época, lamentei de não ter um meio para vincular a área comercial à solução e desejava algum instrumento que permitisse operar o produto mas ao mesmo tempo mantivesse o risco da solução com a área de negócio.

Memos de riscos, cartas de compliance ou cartas de riscos são instrumentos que formalizam e declaram para a organização o aumento do risco operacional devido ao descumprimento de um padrão ou norma. Se uma área de produtos desejar implementar uma solução que aumente em demasiado o risco, esta deverá assumir o risco e a área de TI deve emitir um documento contra a área que deve assinar e devolver a TI. Outra forma de não aceitar prontamente o risco é levá-lo em consideração na elaboração do SLA. Quanto maior o risco operacional, piores devem ser os níveis de serviço vendidos por TI.

Na verdade, o Risco Operacional é de toda a empresa. Assim a estratégia de transferir o risco parece ser um contra-senso pois o risco é corporativo e não de uma área, de um profissional. Mas é TI que absorve o primeiro impacto e responde por qualquer problema, da mesma forma que o jurídico responde por um problema legal ou o RH por um passivo trabalhista. Por sua vez, as áreas de negócio muitas vezes desconhecem os riscos tecnológicos ou comportam-se como tal. Transferir formalmente o risco as obriga a uma reavaliação interna do projeto, da idéia. E na eventualidade de um problema, as partes que "sabiam do risco" vão se voluntariar a resolvê-lo pois são sócias do empreendimento e de qualquer problema que venha a ocorrer.

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

Aprenda a defender-se contra as falácias dos clientes

Quem trabalha com tecnologia já participou de uma reunião onde argumentaram algo injusto ou falso e de difícil refutação. "Vamos perder o cliente se não foi feito a entrega conforme estabeleço", "a área de tecnologia sempre atrasa. Este é apenas um caso", etc. Esses são exemplos de argumentos utilizados por aqueles que precisam vencer uma discussão sem necessariamente ter razão. Quando um executivo de vendas afirma que vai perder um cliente se não for feita uma entrega conforme o acordado, ele argumenta via força-bruta. Não importa se você tem razão, se o erro foi dele ou se realmente o cliente pode cancelar o contrato, a argumentação tem o objetivo de persuadir a qualquer custo e a maioria das pessoas não se prepara para vencer um debate, uma discussão, quiçá, para defender-se. Este tipo de argumento é conhecido como falácia.

Falácias são argumentos com falhas lógicas e de difícil comprovação, onde as conclusões não derivam logicamente das premissas mas são extremamente eficazes durante uma discussão. Para nos defender, devemos entendê-las, classificá-las e para cada uma, receitar um antídodo específico.

Apelo a força

A falácia que utiliza a força-bruta é chamado de apelo a força. O argumentador utiliza sua posição privilegiada de cliente ou hierárquica, para persuadir o adversário guela abaixo, a vítima, com apelos a clientes, a cargos, ou a risco da punição pelo alto escalação. Essas controvérsias chegam a ser repetitivas na comunicação corporativa e são são difíceis de contra-argumentar. Pois você está embaixo da colina e a carga vem de cima.

A melhor defesa é contra-atacar com outro apelo a força através da autoridade técnica ou normativa de outros departamentos que suportam TI. Áreas de compliance, Controles internos, Security Operations e Arquitetura produzem restrições legais, políticas, normas, controles e padrões tecnológicos que podem ser sabiamente utilizados. Esses instrumentos são excelentes ferramentas de defesa durante as reuniões pois foram ratificados por áreas com grande autonomia dentro da corporação.

Desvio Insolente

Uma falácia muito usada pelos cara-de-paus é o desvio insolente. Durante uma discussão acalorada, uma pessoa percebendo que vai ser derrotada, muda de foco e contrói um argumento contra o adversário com pouca relação ao assunto anterior. Presenciei certa vez um vendedor falhar na implementação de um produto. E para se defender, acusou TI de uma falha no sistema do produto. Apesar de ter cometido um erro de processo, responsabilizou o sistema-produto que nada tinha haver com a sua falha. O analista do sistema começou a defender o sistema e depois de um tempo, ninguém se lembrava da discussão original. O vendedor habilmente mudou o assunto pois tinha argumentos contra o sistema em estoque suficiente para vencer esta nova discussão.

A melhor defesa é expor educadamente o estratagema, voltar à discussão anterior de forma madura e deixar o seu oponente numa saia justa.

Conclusão irrelevante

Devido a um incidente na infra-estrutura, certa vez um gerente da conta me solicitou uma carta assinada por TI relatando o incidente e assumindo a responsabilidade pelo problema. Como entendia que esta era uma função da área de relacionamento e não de TI, mencionei que o melhor seria que a minha área relatasse o problema e este fizesse a comunicação para o cliente. O gerente da conta argumentou: o problema foi de tecnologia e a área de TI é a única que conseguesse descrever o problema, dessa forma esta deve comunicar o problema ao cliente por meio de uma carta, descrevendo o incidente e a sua solução.

A falácia de conclusão irrelevante ocorre quando a conclusão apresentada não deriva logicamente das premissas. A conclusão mais imediata das premissas: "o problema foi de tecnologia" e "TI é a única área que consegue descrever o problema" é que "o problema deve ser descrito por TI (comunicado)". A conclusão "TI deve comunicar o problema ao cliente" não é uma conclusão válida pois não se pode concluir logicamente das premissas e nem é razoável concluí-la. Foi um erro proposital, uma armadilha e só cai quem quer ou quem está distraído.

Falsa causa

A falsa causa ocorre quando alguém identifica erroneamente uma causa de um determinado evento, estabelecendo uma relação de causa e efeito que nunca ocorreu mas que aparentemente faz sentido. Eventos que por coincidência ocorreram próximos no tempo ou no espaço são associados e uma teoria é contruída com base na premissa que a relação existiu, desviando o foco da investigação, da identificação e da solução do problema. Com frequência, desviar a atenção é objetivo do argumentador, para que tenha tempo hábil de resolver o problema sem que alguém perceba enquanto responsabiliza alguém ou algo de não possa se defender ou que seja de causa maior.

Presenciei gestores relacionando problemas que aconteceram mas que não causaram atrasos em cronograma de projetos, alegando problemas em fornecedores que nunca existiram ou culpando estagiários que sempre falham quando os responsáveis não aparecem e as constantes falhas dos profissionais que já deixaram a empresa e portanto não podem se defender. Muitas vezes, a falsa causa é usada nas comunicações a clientes mascarando o que efetivamente aconteceu e que por algum motivo poderia expor ou aumentar o risco da empresa.

Se você é a vítima de uma falsa causa e tiver a oportunidade de se defender, o melhor é coletar o maior número possível de informações, investigar a fundo, contar com apoio dos seus pares e declarar publicamente o resultando da investigação, da análise, e relacionar claramente a sequência de eventos com evidências, dados, que não deixem margem alguma para questionamentos.

Generalização apressada

Muitas vezes generalizamos algo com base em casos sem nos dar conta que esta indução pode não estar certa se os casos que tomamos como usuais, comuns, sejam casos particulares, específicos. Este falha acontece durante processos investigativos de problemas operacionais quando se coleta evidências, em avaliações de fornecedores e da prestação de serviços de áreas de suporte. Como TI é essencialmente uma área de suporte, somos os alvos prediletos da Generalização apressada.

Contra-argumentamos através da exposição de casos que não se encaixam na generalização, que quebram a regra. Se o negócio argumentar que sempre atrasamos, mostramos que 70% não atrasam mas 90% mudam a data de entrega por mudanças de escopo, por exemplo. Portanto, trata-se de um problema de mudança de escopo. Se houve queda de serviços num mês e for argumentado que a disponibilidade da infra-estrutura é muito baixa, mostramos a disponibilidade do ano, mês a mês, ou a média do ano. Como as pessoas inferem mal, fica fácil defender-se se você tem a informação na mão, de forma acessível. Caso contrário, qualquer resposta será vazia, sem conteúdo e só confirma para os demais ouvintes a veracidade dos fatos.

Falácia do Acidente

A Falácia do Acidente é o inverso da Generalização Apressada e ocorre quando aplicamos uma regra genérica para um caso específico que é na realidade uma exceção a regra. O acidente ocorreu devido a falta de entendimento do contexto específico.

Para ilustrar, "sabemos que a terceirização de serviços reduz custos". Todavia, muitas empresas se surpreendem com o aumento de seu custo operacional após a terceirização e não compreendem o que aconteceu. Participei de uma terceirização de RH cujo custo operacional aumentou depois de seis meses pelo simples fato da empresa estar represando a demanda pela falta de recursos. A escalabilidade do terceiro permitiu um aumento do volume de atendimento e como consequência houve um aumento do custo total, frustando o planejamento financeiro. O melhor entendimento do contexto da empresa - demanda represada e necessidade de reduzir custos - teria permitido a construção de um Business Case mais conservador e mais focado na melhoria do serviço.

Saber defender-se

Saber defender-se não implica que não possamos assumir os nossos problemas. Pois os problemas não se resolvem por si só, e a falta de um responsável só atrasa a solução. Defender-se tem haver com a definição precisa da responsabilidade no problema. Defender-se é se livrar das inúmeras armadilhas que surgem nas reunião de trabalho, nas conferências e nos e-mails. Todas essas ciladas de argumentos falsos só visam aumentar a nossa culpabilidade, o nosso escopo no problema. O conhecimento aprofundado dessas falácias nos mantêm dentro da nossa fronteira de responsabilidades e educa os nossos clientes internos.

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

Por que as áreas de tecnologia são consideradas gargalos na maioria das empresas?

Gargalos são restrições lógicas - regulamentação, compliance - ou físicas - pessoas, espaço - de processos que limitam o desempenho da organização e tornam a vida daqueles que demandam um inferno. Como toda organização tem pelo menos uma restrição que limita a performance, existe sempre a possibilidade da área de tecnologia ser o gargalo. E esta possui com frequência gargalos em todos os seus processos. Muitos dos quais são gerados desnecessariamente pela própria área ou são específicos da técnica, da tecnologia da informação.

A Tecnologia da Informação é complexa e a sua incerteza aumenta muito o risco daqueles que executam e planejam TI. Portanto, um processo tecnológico tem maior possibilidade de falhar quando comparado a similares de outras áreas de suporte como a jurídica e contábil, por exemplo. Essas falhas se somam e geram no dia-a-dia gargalos pontuais que desgastam o relacionamento com os clientes:

• Ausência de padrões de arquitetura que tarda a escolha de soluções. Exemplo: elaboração de soluções para produtos.


• Desvio contínuo entre a capacidade de entrega e demanda que causa demora no início das execuções. Exemplo: manutenção de software.
  


• Projetos de alto risco que surpreendem os clientes internos com falhas técnicas. Exemplo: problemas de comunicação entre middleware.
  


• Processos lentos de suporte que atrasam e infernizam o usuário. Exemplos: instalação de software.
  


• Processos restritivos de segurança que engessam atividades supostamente simples. Exemplos: liberação de acessos.


• Demora na avaliação de soluções que reduz a competitividade da área de vendas. Exemplo: suporte para a área comercial na elaboração de propostas.


• Business cases parados no financeiro sem o cliente ficar sabendo. Exemplo: propostas de novos produtos.


• Falta de definição dos serviços de TI que dificulta a início do serviço. Exemplo: como fazer para solicitar a compra de um software.

A análise detalhada dos problemas indica que eles têm em comum a má gestão de processos, inclusive de riscos, e a falta de comunicação. A percepção de gargalo aumenta muito quando TI não informa com quem está a demanda. Pois o usuário busca sem sucesso a situação do seu pedido, do seu projeto, e o fluxo de trabalho não comunicado vira gargalo.

Os problemas relacionados à gestão da tecnologia pesam na percepção de gargalo, mas existe um outro fato relevante: o volume de demandas geralmente é superior, e muito, a capacidade de entrega de TI, pois tudo depende de tecnologia. Os gargalos são uma consequência dessa diferença. Muitas ideias de produtos ou melhorias acabam não se convertendo em projetos devido a restrições de capacidade interna. Porém, se a gestão é eficiente, o gargalo encontra-se na área financeira que não libera mais recursos ou infraestrutura, mais capacidade. Isto é difícil de demonstrar pois as áreas usuárias sempre tem a sensação de que TI trabalha com capacidade ociosa.

Podemos concluir que as particularidades de TI quando mal gestionadas e o grande desvio entre a demanda e capacidade de entrega causam uma percepção de gargalo na maioria das empresas. Todavia, estes dois ingredientes alimentam as desculpas dos profissionais que demandam e não conseguem entregar devido a suas próprias falhas ou gargalos. Os mal profissionais utilizam os gargalos de TI como causa para as suas deficiências. Esta confusão proposital é uma falácia chamada de falsa causa e é comumente aplicada contra as áreas de tecnologia. Mas só cai nela quem quer.

Apesar de não haver uma pesquisa sobre o tema, é razoável considerar que a maioria das empresas consideram as áreas de tecnologia como gargalos. Como a dependência das empresas com relação a tecnologia aumenta ano após ano, a percepção só tende a aumentar se nada for feito para administrá-los. A gestão de gargalos é tema do meu próximo artigo.

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

Pensar sobre Tecnologia

Amigos,

Criei este blog para compartilhar algumas idéias que tenho sobre tecnologia e para pensarmos sobre vários temas.
Mande comentários.
um abraço para vocês

Paulo Farias Castro Filho