Onde nascem as crises e os incidentes?

Há algum tempo atrás, conversava com um grupo de gestores de serviços em TI, experientes e com uma enorme vivência de mercado sobre os incidentes como um todo.

Falávamos sobre o momento que nasce a crise, o envolvimento das áreas, as conferências realizadas entre os profissionais de vários segmentos, o acionamento das equipes de operações, entre tantos outros fatores envolvidos no contexto.

E nesta conversa e troca de informações, um de desses gestores comentava sobre alguns absurdos que em sua vasta experiência, vivenciava diariamente. Até ai, sabemos que existem atitudes que ocorrem no nosso dia a dia, nada ortodoxas ou que não seriam as melhores soluções a serem tomadas naquele momento.

Mas o problema se agrava quando conceitos básicos como processos, atividades e procedimentos não são claros para alguns profissionais. Ou outros que não conseguem ainda entender a diferença entre gerenciamento e governança, misturando os conceitos e atribuindo atividades, além de papéis e responsabilidades de forma errada. Ou mais agravante: uma gama enorme de profissionais que não dão a devida importância a boas práticas, metodologias e frameworks, mais do que testados e validados não apenas por institutos renomados, mas por uma comunidade internacional, que juntos nos deixaram uma diretriz, um caminho a ser seguido para facilitar nossas tomadas de decisões, soluções e atividades, gerando uma melhor qualidade e um melhor serviço e valor para nossos clientes.

E ai, começam as confusões: os acordos de níveis de serviços e operacionais são quebrados, os indicadores quase explodem de tão vermelhos que ficam, as acusações entre as áreas surgem quase que imediatamente e por falta de alinhamento e até conhecimento em alguns momentos, impactamos o negócio, gerando um stress absurdo entre os envolvidos direta e indiretamente, além de custos adicionais e desnecessários para a instituição. Mas a questão que gostaria de trazer para nossa reflexão é… Será que poderíamos evitar tudo isto?

A verdade é que tudo isto poderia ser evitado se entendêssemos onde realmente nascem os incidentes e tomássemos alguns pequenos cuidados, indo diretamente na raiz e não estarmos sempre dando razão e importância à causa.

A visão, estratégia e planejamento mal elaborados

Sempre ouvimos frases como “os usuários nunca sabem realmente o que querem” em nosso cotidiano. Muitas vezes isto é uma desculpa dada por algo que deixamos de realizar e para não assumirmos o próprio erro, culpamos os mesmos por algo que seria nossa responsabilidade. Mas em certas situações esta frase e muitas outras com a mesma conotação, tornam-se a mais pura verdade. E porque disto? Porque em muitos momentos, a visão da área de negócios não se faz clara e objetiva. Em outras palavras, nossos clientes querem algo para otimizar suas atividades ou mesmo melhorar sua capitação e rendimentos, mas eles próprios ou não sabem bem o que querem ou não conseguem se expressar devidamente. E por estarem tanto em uma situação como outra, a visão do negócio torna-se obscura ou incompleta. E uma visão incompleta, faz com que tanto a estratégia como o planejamento adotado também sejam incompletos. E isto acaba por refletir na solução final, pois os levantamentos de requisitos de negócios serão realizados encima desta visão, desta estratégia e posterior planejamento. E levantamentos de requisitos de negócios errôneos, irão refletir em todos os processos subsequentes. Seguindo nossa linha de raciocínio, muitos incidentes surgem na operação porque a visão, estratégia e planejamento que nasceram no próprio segmento de negócio, não foram claras o suficiente.

Uma análise sistêmica equivocada

Por não ter uma visão, estratégia e planejamentos claros e objetivos, os problemas que começaram neste ciclo de vida do serviço, propagam-se para a análise sistêmica. É neste momento que o analista de sistemas irá sentar-se com o analista de negócios ou de requisitos para entender primeiramente seu negócio e depois suas necessidades, traduzindo seus requisitos de negócios, para requisitos funcionais e técnicos. E se este levantamento foi incompleto ou mal elaborado, isto irá refletir no desenho da solução. Não precisamos nem aprofundarmos muito em nosso raciocínio para sabermos o que ocorrerá quando esta solução entrar no ambiente de produção: crise, seguida de Incidentes.

Uma arquitetura incompleta, um desenvolvimento precário

Em algumas empresas, será o próprio analista de sistemas que irá desenhar a arquitetura da solução e até mesmo codificá-la, escolhendo o melhor ambiente (linguagem, suíte de desenvolvimento, banco de dados, etc.). Mas muitas organizações tem o papel do arquiteto de soluções ou arquiteto de sistemas. Ele será o responsável em pegar a análise feita anteriormente (funcional, orientada a aspectos ou objetos, etc.) e baseado nos requisitos levantados, transformá-los em uma linguagem técnica, elaborando a melhor solução para o ambiente da organização ou do cliente. Mas se a análise sistêmica foi mal feita, quer por falta de requisitos ou por clareza no levantamento feito junto às áreas de negócio, teremos com certeza uma solução que não atenderá aos requisitos de negócio.

E um desenho mal elaborado ou incompleto, gerará um desenvolvimento a altura: falho e incompleto. E este quadro se agrava, quando a solução que já está desenhada e encontra-se no momento de transição, onde está sendo construída e testada, tem que voltar no ciclo de desenho ou mesmo no ciclo de estratégia, pois se descobre através de erros nos testes ou em deployments realizados, que os requisitos de negócio e de sistemas não batem.

E quando vemos o prazo da entrega final se aproximando, o desenvolvimento da solução entra num momento caótico, pois as equipes envolvidas são obrigadas a realizarem horas e mais horas adicionais de trabalho, aumentando o custo da solução para a empresa e gerando o que vemos quase que diariamente: Configurações de ambientes mal elaboradas e realizadas, erros banais durante a codificação, profissionais estressados com ânimos a flor da pele e a solução proposta, que deveria gerar valor para o negócio, transforma-se em total insatisfação para o cliente final, gerando crises e constantes incidentes, quando esta entra no ambiente de produção.

O caos da operação

Aqui já entremos no ciclo quase que diário de muitas organizações: Soluções em produção mal elaboradas, cheias de falhas e gerando incontáveis incidentes. Nesta fase, as áreas de negócio já não se encontram amistosas e a TI torna-se a culpada de tudo. Até fatos ou situações corriqueiras que são responsabilidades de outros segmentos ou áreas da empresa, tornam-se responsabilidades da TI, que se encontra mal vista por todos.

Quando entramos neste ciclo, muitas vezes nos sentimos com as mãos totalmente amarradas, pois devido à correria do dia a dia e até a dinâmica do negócio, não temos nem tempo, nem recursos e muito menos orçamento hábil para consertarmos o estrago realizado. Até porque neste momento, a solução pode estar tão fora de sincronia com o negócio que não valeria mais a pena rever processos, procedimentos e atividades, mas simplesmente obsoletarmos toda a solução e começarmos uma nova. Mas é claro que isto não ocorre e ficamos em uma eterna sustentação de algo que poderia ter sido evitado se observássemos um pouco melhor, cada uma das fases ou ciclos que citamos até o momento.

Poderia continuar explanando outras situações, em maiores ou menores detalhes e que nos levam a constantes crises e incidentes, mas queria apenas compartilhar um pouco da troca de experiências que tivemos neste período de tempo.

Acredito que não apenas nós vivenciamos situações como estas, mas muitos profissionais também as vivem. Situações que por descuido, mau planejamento, pressa ou mesmo falta de experiência e maturidade, nos levam a colocar em nossos ambientes de produção ou de nossos clientes, soluções que deveriam colaborar com a capitação do negócio e a geração de valor e não gerar o caos que vemos no dia a dia. Pense sobre isto e até o nosso próximo bate-papo.

Por: Wagner Vieira,  CI-SCS, COBIT®, ITILOSA®, ITILRCV®, ITILSOA®, ITSM20FB,  Business Analyst | Technical Leader | ITSM Specialist

Tecnológo em Processamento de Dados pela FIAP e Pós-Graduado em Gestão de Serviços em TI pela Daryus DM Business School, com mais de 20 anos de experiência profissional