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