O dia do lançamento parece o fim do projeto. Os dispositivos estão reportando, os dashboards estão verdes, o cliente assinou o termo de aceite e a equipe de implantação segue para o próximo trabalho.
Quem herda o sistema não participou da construção. Essas pessoas não escolheram o limite de 7.5 no alerta do tanque, não sabem por que doze dispositivos têm a tag “piloto”, e o alerta de bateria baixa que dispara às 2h da manhã vai para um engenheiro que saiu do projeto em março. Seis meses depois, ninguém consegue dizer quantos dispositivos ainda estão reportando. É assim que uma implementação em funcionamento apodrece. Nada quebra; o conhecimento que a mantinha de pé vai embora aos poucos, a cada pessoa que sai.
O que resolve é um pacote de transferência e um período de transferência, preparados antes do lançamento em vez de montados de memória depois. É esse o pacote que vemos funcionar em implementações na TagoIO, seja a equipe de operações o pessoal do cliente ou o próprio plantão de suporte do integrador.
Comece com um mapa de responsabilidades
A maioria das transferências falha em uma pergunta que ninguém fez: quem é responsável por cada parte do sistema. Monte uma tabela de uma página com uma pessoa nomeada (não uma caixa de e-mail de equipe) em cada linha:
- Devices: quem adiciona, substitui e desativa, e quem é chamado quando um deles para de enviar dados
- Dashboards e o portal TagoRUN: quem muda o que os usuários finais veem
- Alertas: quem recebe cada Action, quem pode mudar um limite
- Usuários: quem cria e remove usuários do TagoRUN e suas permissões
- Faturamento e limites: quem acompanha o uso dos serviços e aprova mudanças de plano
- Código: quem responde pelo Payload Parser e por cada script de Analysis
Se uma linha não tem nome, a transferência não terminou. Se todas as linhas trazem o nome do líder da implantação, isso não é uma transferência.
Troque logins compartilhados por acesso de verdade
O atalho mais comum no lançamento é um único login de administrador compartilhado pela equipe de operações. Funciona por uma semana e depois vira um rastro impossível de seguir: ninguém sabe quem mudou o limite e, quando alguém sai, você não consegue revogar o acesso dessa pessoa sem bloquear todo mundo.
Crie usuários do TagoRUN para a equipe de operações e use políticas de Access Management para dar a cada função o acesso de que ela precisa: um técnico de campo vê a lista de dispositivos e o dashboard de saúde das unidades dele, um supervisor pode reconhecer alertas e editar limites em um formulário, um administrador cria usuários. Escreva as políticas com base em tags de dispositivo (unidade, cliente) e não em IDs de dispositivo, assim elas continuam valendo quando o dispositivo número 300 entrar no ano que vem. Deixe o console do Admin para quem constrói e mantenha a lista de usuários do Admin curta e registrada.
Escreva um runbook para cada alerta recorrente
Um alerta sem runbook é ruído com data e hora. Para cada Action que notifica uma pessoa, escreva uma entrada curta: o que o alerta significa em linguagem simples, o que checar primeiro, o que fazer se a checagem confirmar o problema, e quando e para quem escalar. Isso vai ser lido às 2h da manhã, no celular, então seja breve.
Depois ajuste o roteamento das Actions. Uma Action da TagoIO pode enviar e-mail, SMS ou notificação push para usuários do TagoRUN, ou chamar uma Analysis, então um alerta de gateway offline aciona o técnico de plantão enquanto um aviso de consumo vai para o responsável pelo faturamento. Revise todas as listas de destinatários durante a transferência, porque quase sempre a equipe de implantação ainda está nelas.
Monte a visão de saúde dos dispositivos que a operação abre todo dia
A equipe de implantação sabe que a frota está saudável porque viu cada dispositivo entrar no ar. A equipe de operações precisa dessa confiança em uma tela: um dashboard de saúde, separado do que os usuários finais veem, com o horário do último envio por dispositivo, o nível de bateria quando o hardware manda esse dado e a contagem de dispositivos offline por mais tempo do que uma janela definida.
Na TagoIO isso normalmente é um Blueprint Dashboard guiado por tags de dispositivo, então um único dashboard cobre todas as unidades, com um widget de tabela ordenado pelo último envio para os dispositivos calados subirem ao topo. Adicione uma Action que dispara quando um dispositivo fica em silêncio por mais tempo do que o intervalo esperado; esse alerta sozinho pega bateria morta, gateway trocado de lugar e atualização de firmware esquecida. Se a tela levar mais de um minuto para ser lida, simplifique.
Documente a lógica que vive no código
O limite é 7.5 porque o engenheiro de processo do cliente disse que 8 era tarde demais e 7 gerava alarme falso em julho. Esse raciocínio só existe na memória de alguém, a menos que esteja escrito ao lado do valor. Comente cada fator de escala e cada conversão de unidade no Payload Parser. Dê a cada script de Analysis um cabeçalho que diga o que o dispara, o que ele lê e escreve, e quem pediu por ele. Onde os limites ficam em parâmetros do dispositivo ou em um formulário do dashboard, mantenha uma tabela com os valores atuais e o motivo de cada um.
Registre as convenções de nomes: como os dispositivos são nomeados, quais tags são obrigatórias (unidade, cliente, modelo de hardware, data de instalação), como o parser nomeia as variáveis. Metade da frota com a tag Site A e a outra metade com site_a quebra toda política e todo filtro de Blueprint que dependem disso.
Defina como as mudanças acontecem
Implementações não ficam do tamanho com que nasceram. Alguém vai adicionar uma unidade, trocar o modelo de sensor ou pedir um alerta novo. Sem um processo de mudanças, cada um desses casos vira uma ligação para a equipe de implantação, e a operação aprende a contornar o sistema em vez de trabalhar por dentro dele.
O processo cabe em uma página: como adicionar um dispositivo (qual Connector e Network, quais tags, como confirmar que ele aparece no dashboard de saúde), como pedir mudança de limite e quem aprova, como criar um usuário do TagoRUN e o que ainda depende da equipe de implantação. Mantenha um registro de mudanças, mesmo que seja um documento compartilhado, para que, quando algo quebrar em outubro, alguém consiga ver o que mudou em setembro.
Agende uma revisão mensal
Custos e limites vão mudando sem ninguém notar. Dispositivos são adicionados, uma Analysis roda com mais frequência, cinquenta usuários abrem um dashboard com um período longo e o consumo de Data Input e Data Output do Profile se aproxima do limite do plano. Coloque uma revisão mensal de 30 minutos na agenda do responsável pelo faturamento: confira o uso dos serviços em relação ao plano, confirme se a configuração de Data Retention ainda atende ao que o cliente precisa, conte os dispositivos que não reportam há 30 dias e passe pelos itens abertos no registro de mudanças. Integradores que ficam eles mesmos com a operação já fazem isso como parte de um serviço recorrente; é essa revisão que mantém um serviço gerenciado lucrativo em vez de uma sangria lenta.
Acompanhe por duas semanas antes de sair
O pacote acima é necessário e não suficiente. Documento se lê uma vez; hábito se cria fazendo. Nas duas semanas seguintes ao lançamento, a equipe de operações conduz o sistema com a equipe de implantação ainda de plantão: é ela quem trata cada alerta, adiciona o próximo dispositivo, roda a primeira revisão mensal. A equipe de implantação responde às dúvidas e, mais útil do que isso, corrige o que os documentos deixaram de fora enquanto o conhecimento está fresco.
Encerre com uma reunião curta: repasse o mapa de responsabilidades mais uma vez, confirme que cada alerta disparou em teste e chegou à pessoa certa, depois retire a equipe de implantação das listas de destinatários e de qualquer acesso ao Admin de que ela não precise mais. É aí que o projeto termina.
Checklist de transferência
- Mapa de responsabilidades com uma pessoa nomeada em cada linha
- Usuários do TagoRUN e políticas de Access Management por função; logins compartilhados removidos
- Entrada de runbook para cada Action que notifica uma pessoa; destinatários verificados
- Dashboard de saúde (último envio, bateria, contagem de offline) com alerta de dispositivo em silêncio
- Comentários no Payload Parser e no código de Analysis; tabela de limites; convenções de tags
- Processo de mudanças em uma página e um registro de mudanças
- Revisão mensal cobrindo uso, retenção e dispositivos offline
- Período de acompanhamento de duas semanas com uma reunião de encerramento
