Gerência de Projetos

Ξ 1 comentário

Gestão de Problemas tem que ser pra valer!

publicado por Mauricio Veneroso

A disseminação das boas práticas de gestão de incidentes e de problemas publicadas e mantidas pelo ITIL são uma mão na roda para quem não quer perder tempo em ter que reinventá-las. Quando se fala em padronização do tratamento dos incidentes, gerenciamento de suas métricas, tendências e aderência aos níveis de serviço contratados, há material de referência de sobra.

A gestão de problemas, que tem o propósito de evitar problemas e seus respectivos incidentes resultantes de acontecerem, eliminar incidentes recorrentes e minimizar o impacto de incidentes que não podem ser evitados, é bem completa, mas ainda falta enfatizar a adoção de uma entrega importantíssima e que traz benefícios futuros e definitivos que não são tão imediatistas quanto os utilizados normalmente.

No mapeamento do problema, muitas equipes de TI (tanto as que desenvolvem aplicações proprietárias, quanto as que desenvolvem pacotes de software comercializados no mercado) preocupam-se apenas com a elaboração do documento de análise de causa raiz (RCA). E os resultados dessa análise da “causa raiz” são comumente classificados como um bug em determinada linha de código de algum objeto sistêmico, ou como um problema de processo ou treinamento do usuário final, ou até mesmo como um item de configuração, dentre possíveis outros.

O “problema” nessa abordagem, é que apesar de passar uma impressão de resolver definitivamente a situação, em diversos times de TI essas avaliações têm ficado restritas ao imediatismo do incidente no ambiente de produção, naquele problema que está causando aquela anomalia e em que é preciso estancar e corrigir para não acontecer mais. Corrigir o bug sistêmico, reforçar e aplicar um novo treinamento, adaptar um procedimento qualquer ou mudar um item de configuração são os únicos “artefatos” que a abordagem de gestão de problemas adotada por esses times entrega atualmente.

Uma nova postura diante da gestão de problemas, para as equipes que ainda trabalham assim, seria entregar não só esses “artefatos” que garantem que as transações de negócio voltem a acontecer de maneira correta, mas também, que no processo de RCA (Root Cause Analisys), o foco dessas equipes fosse a identificação e mapeamento de qual parte do processo de desenvolvimento sistêmico que causou verdadeiramente aquela anomalia, ou seja, a verdadeira “causa raiz”. Fazer o processo de análise de causa raiz, perguntando se o usuário demandante “pediu” o que realmente precisava. Se pediu certo, mas o requisito foi escrito de maneira errada? Se o produto final foi desenvolvido conforme o requisito? Se havia documentação suficiente do sistema que está sendo alterado para proporcionar um entendimento correto da mudança que está sendo feita? Se a arquitetura da solução foi desenhada corretamente? Se os testes foram suficientes? Se a solução atende à todos os mercados que o produto atua? Ou se tal anomalia foi implantada em produção com o consentimento da área usuária (homologação indevida)?

Acrescentar esse mapeamento no processo de RCA resolveria o grande problema das equações dos Business Plans dos projetos, no qual o custo para a qualidade almejada nunca consegue aprovação necessária por falta de justificativa, por falta de argumentos.  Essa abordagem seria a saída para escapar desse círculo vicioso e para aumentar a qualidade das entregas dessas TIs de maneira definitiva.

Enquanto essas equipes não começarem a mapear em que etapa do processo de demanda e desenvolvimento dos sistemas está ocorrendo a verdadeira falha, elas nunca encontrarão a “causa raiz” real dos problemas e não poderão analisar, classificar e nem estimar o prejuízo para sua área e para o próprio negócio e mercado que atendem, quando se fala em problemas existentes. O ônus dessas falhas continuará sendo atribuído para essas próprias TIs.

Começar a fazer a gestão de problemas com esse prisma, dará mais argumentos para que essas equipes de TI,  as empresas e o mercado que elas atendem, cheguem à um consenso sobre onde a qualidade deve ser aprimorada e passem a considerar as melhorias necessárias para diminuir os custos de indisponibilidade sistêmica, falhas de processo, bugs e itens de configuração indevidos eliminando o sentimento de culpa que essas equipes de TI carregam quando se fala em “Erro do sistema”.

Autor

Mauricio Veneroso tem mais de 20 anos de experiência na área de TI sendo mais da metade no mercado de telecomunicações. Trabalhou em diversos projetos de desenvolvimento de sistemas. Nos últimos 5 anos sua atuação tem sido voltada para ITSM atuando como Consultor de TI, estruturando equipes de suporte, níveis de serviço e definindo processos de melhoria contínua redefinindo inclusive metodologias de desenvolvimento de sistemas, participando da elaboração de SoWs, RFPs e RFIs para assegurar transições para os times de produção, suporte e sustentação de sistemas com o menor impacto possível para as áreas usuárias e para os times de suporte.

Mauricio Veneroso

Comentários

1 Comment

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes