Quem nunca ficou perdido com alguma dessas situações, que atire a primeira pedra:
- Os usuários estão reportando um incidente crítico e massivo e que segundo eles afeta 100% da área, mas os monitoramentos e alarmes existentes demonstram que está tudo bem;
- Você precisa saber quem fez a alteração de um parâmetro, mas não consegue identificar;
- É preciso saber que parâmetros foram alterados num determinado período para tentar associá-los a um sintoma existente mas você não tem a menor idéia se houve alguma alteração;
- Você tem um incidente reportado por um usuário que simplesmente diz que houve um “erro de TI” mas não te dá detalhes sobre esse erro;
- Você precisa substituir um módulo ou um sistema inteiro e na análise de gaps não consegue identificar quem usa e se ainda usa determinados módulos/telas/relatórios do sistema legado;
- Você precisa investir em treinamento e reciclagem de boas práticas com os usuários finais do sistema, mas não sabe onde estão as principais falhas;
- Você precisa priorizar correções de problemas (causa raiz), mas não tem métricas precisas sobre os problemas existentes, a não ser pelos incidentes reportados em seu Service Desk.
Quem tem um pouco mais de vivência em TI, certamente já passou alguma dessas situações e gastou um bom tempo tentando identificar, justificar e implantar alguma coisa por justamente não ter os “FATOS E DADOS” nas mãos.
Infelizmente grande parte das pessoas ao se deparar com situações como essa acaba culpando alguém que no passado deixou de fazer o que tinha que ser feito (para evitar isso) e gasta um tempão buscando alternativas para trabalhar sem essa informação. O esforço é imenso. Todos nós sabemos.
Porém o que nunca observamos é que muitas das vezes dentro desse mesmo trabalho em que estamos com um problema assim (alguém não fez o que tinha que ser feito), ficamos tão focados em resolver essa situação estressante que deixamos de cuidar para que nós mesmos não deixemos esse tipo de abacaxi para o colega que num futuro (distante ou próximo) terá que lidar com algo assim.
Por esse motivo é que mando essa sugestão: Cuidado, o mundo dá voltas. Cuide da rastreabilidade.
Cuidar da rastreabilidade é algo organizacional e não pode estar isolado numa determinada área de TI e nem da empresa.
Para cuidar da rastreabilidade de maneira eficiente, é preciso conscientizar o demandante de qualquer necessidade sistêmica, para que ele defina juntamente com o time de mapeamento de processos da empresa (ou com o analista de negócios ou de processos que faz esse tipo de papel) para que todas as exceções do sistema, todas as modificações de parâmetros sistêmicos, todas as mensagens de alerta, falha, perguntas e toda navegação pelos módulos e telas do sistema sejam logadas adequadamente.
Isso sem esquecer que todos envolvidos na cadeia de desenvolvimento dentro de TI, desde a área de arquitetura de TI, que vai definir as estruturas e padrões de rastreabilidade que devem ser usadas nas manutenções corretivas e evolutivas dos sistemas, até a equipe que vai cuidar da homologação do sistema devem manter isso em mente: RASTREABILIDADE.
Essa consciência, com certeza, irá diminuir o esforço e o estresse futuro ao enfrentar situações como as citadas no inicio do texto.
Hoje você está desenvolvendo, mapeando processos ou é usuário de um sistema. Amanhã, você pode estar no suporte, em um outro desenvolvimento, precisando efetuar um treinamento ou qualquer outra atividade que envolva tais informações e irá sentir falta dessa boa prática.
Por isso meu amigo, volto a dizer:
TOME CUIDADO. O MUNDO DÁ VOLTAS. CUIDE DA RASTREABILIDADE!
Olá Maurício
Excelente artigo.
Dentre os vinte e poucos princípios ISO, coloco sempre a rastreabilidade entre os 5 mais importantes. Essenciais.
Parabéns.
O Véio
Bom dia Mauricio. Gostei do conteúdo escrito. Gostaria de saber como gravar a rastreabilidade do usuário depois do sistema pronto. Tem algum link !
att,
Fernando