Você não precisa ler uma datasheet para tocar bem um projeto de IoT. Você precisa definir o escopo com honestidade, sequenciar o trabalho para que as partes arriscadas apareçam cedo, e fazer as perguntas certas às pessoas certas antes que o dinheiro saia do caixa. Os gerentes de projeto que penam com IoT em geral são os que tratam isso como um rollout de software com alguns sensores pendurados. Os que dão certo tratam o projeto como uma obra física que por acaso produz dados, e gastam energia justamente nas partes que nenhum engenheiro faz por eles: requisitos, alinhamento, risco e fornecedores.
Este guia é para o PM sem bagagem em hardware que acabou de receber um projeto de IoT e um prazo. Ele cobre como definir o escopo do trabalho, como quebrá-lo em fases com prazos que você consegue defender, onde você pessoalmente agrega mais valor, e as perguntas que evitam que o projeto descarrile.
Defina o escopo pelo resultado, não pela tecnologia
A forma mais rápida de perder o controle de um projeto de IoT é começar pelo dispositivo. Comece pela decisão que os dados devem sustentar. Uma equipe de facilities não quer leituras de temperatura, quer saber quais freezers estão prestes a falhar antes que o estoque estrague. Um operador de frota não quer pings de GPS, quer faturar os clientes com precisão e despachar o veículo mais próximo. Escreva o resultado em uma frase que um dono de negócio assinaria embaixo, e depois trabalhe de trás para frente até o que precisa ser medido, com que frequência, e quem age sobre isso.
Você consegue definir esse escopo sem saber como um sensor funciona. As perguntas são operacionais, não técnicas. Que decisão muda quando o dado chega? Quão fresco o dado precisa ser para que essa decisão ainda faça sentido? Quem vê o dado, e em que formato? O que acontece quando um dispositivo fica em silêncio? Responda a isso e você terá definido o projeto. A equipe de engenharia traduz suas respostas em hardware e firmware, e esse é o trabalho dela, não o seu.
A armadilha a evitar é o escopo que cresce um sensor por vez. Sempre tem alguém querendo adicionar uma leitura só porque o dispositivo tecnicamente consegue capturá-la. Segure a linha no resultado que você escreveu. Dado extra sobre o qual ninguém age é custo sem retorno, e é a coisa mais fácil do mundo de aprovar numa reunião.
Organize o trabalho em fases
Projetos de IoT fracassam quando pulam de uma apresentação de slides para mil dispositivos em campo. A solução é avançar por fases, cada uma desenhada para eliminar um tipo específico de risco antes de gastar mais.
A descoberta vem primeiro. Você confirma o resultado, escolhe as métricas, e deixa a equipe técnica validar se a medição é sequer viável no seu ambiente. Isso é majoritariamente reuniões e um pouco de teste de bancada, e dura algumas semanas.
O piloto é a fase que se paga. Você coloca um pequeno número de dispositivos reais em um local real e prova que a cadeia inteira funciona: do dispositivo à conectividade, à plataforma, até a pessoa que age sobre o dado. Um piloto se mede em semanas, não em meses, e é onde você descobre as coisas que nenhum plano prevê. O gateway não pega sinal no porão. O sensor lê bem até a doca de carga cobri-lo de poeira. O alerta dispara às 3 da manhã e ninguém está de plantão. Melhor descobrir isso com dez dispositivos do que com dez mil.
O rollout limitado amplia o piloto para uma fatia mais completa do ambiente real, com sites e condições suficientes para expor a variabilidade que o piloto não mostrou. A produção completa é a implantação em escala, depois que as fases anteriores pararam de te surpreender. Operação não é uma fase que termina, é o estado contínuo em que o projeto vive após o lançamento, e precisa de um responsável e de um orçamento desde o início.
Resista a qualquer pressão para pular da descoberta direto para a produção. As fases existem para converter incógnitas em custos conhecidos enquanto a conta ainda é pequena.
Seja honesto sobre prazos
Stakeholders seniores querem uma data. Em vez disso, dê a eles um formato, e explique por que o formato é a resposta honesta. Um piloto fica de pé em algumas semanas. Um rollout limitado adiciona de semanas a meses, dependendo de quantos sites e de quanta instalação física estão envolvidos. A produção completa roda em meses, e a distância entre piloto e produção quase sempre é maior do que as pessoas esperam, porque escalar expõe uma variabilidade site a site que um único piloto bem-comportado escondeu.
A razão pela qual prazos de IoT atrasam raramente é o software. É o mundo físico. Licenças, acesso ao site, eletricistas, fixação, zonas mortas de conectividade, e dispositivos que se comportam diferente em campo do que na mesa. Reserve folga para o trabalho físico, segure a linha de um piloto antes da produção, e você vai assumir datas que de fato consegue cumprir.
Onde você agrega mais valor
O trabalho de engenharia não é seu para fazer, e tentar fazê-lo é como o PM sem perfil técnico perde credibilidade. Seu valor está em quatro lugares que decidem se o projeto vai pro ar.
Requisitos é o primeiro. Você é quem consegue sentar com a área de negócio e cravar o que o projeto precisa fazer, numa linguagem contra a qual a equipe técnica consiga construir. Um documento de requisitos claro previne mais retrabalho do que qualquer ferramenta.
Alinhamento de stakeholders é o segundo, e é constante. Projetos de IoT tocam operações, TI, financeiro e, muitas vezes, um cliente. Mantê-los apontados para o mesmo resultado é um trabalho que só um PM faz bem.
Risco é o terceiro. Você é a pessoa que acompanha o que pode dar errado e qual é o plano quando der. Conectividade, falha de dispositivo, dado sobre o qual ninguém age, um fornecedor que perde uma data. Nomear os riscos cedo e atribuir responsáveis é o seu trabalho.
Gestão de fornecedores é o quarto. Você vai trabalhar com fornecedores de hardware, um provedor de conectividade, uma plataforma e, possivelmente, um integrador. Mantê-los dentro do escopo, das datas e de interfaces claras entre as partes deles é trabalho de PM puro, e não exige um diploma de engenharia para ser bem feito.
As perguntas a fazer
Boas perguntas compensam bastante a falta de conhecimento técnico. Faça estas aos seus fornecedores antes de assumir compromisso. Qual é o seu lead time real de hardware, incluindo os meses ruins? O que acontece com os meus dados se eu parar de pagar você? Como os dispositivos são atualizados em campo depois de instalados? Como é o suporte às 2 da manhã quando um site cai? Quem é dono da integração com os meus sistemas atuais, você ou eu?
Faça um conjunto parecido à sua própria equipe. Qual é a maior incógnita técnica, e como testamos isso no piloto? Que parte disso nenhum de nós já fez antes? Se o piloto falhar, como vamos saber, e qual é o plano B? As respostas mostram onde o projeto está frágil enquanto você ainda tem tempo de fazer algo a respeito.
As armadilhas que pegam a maioria das equipes
Alguns erros aparecem em quase todo projeto de IoT problemático. As equipes tratam o projeto como puro software e esquecem que hardware tem lead time, falha fisicamente e se comporta diferente entre sites. Subestimam a variabilidade de campo e assumem que um bom local de piloto representa todos os locais. Pulam o piloto para economizar semanas e pagam por isso muitas vezes em produção. E orçam o projeto como uma construção única, sem orçamento de operação, então ele apaga um ano após o lançamento, quando ninguém é dono de mantê-lo rodando.
Cada um desses é uma falha de planejamento, não técnica, o que significa que cada um é seu para evitar.
Como uma plataforma gerenciada reduz o que você tem de assumir
Toda parte de um sistema de IoT que a sua equipe constrói do zero é uma parte que a sua equipe terá de operar, proteger e consertar para sempre. Uma plataforma de aplicação gerenciada como a TagoIO tira do seu colo os dashboards, a gestão de dispositivos, o armazenamento de dados, os alertas e as APIs, ficando por cima da conectividade dos dispositivos para que a sua equipe entregue uma aplicação em vez de manter uma stack rodando. Para um PM sem perfil técnico, isso importa porque reduz a superfície técnica pela qual você responde. Há menos backend customizado para escopar, menos peças móveis para manter vivas em operação, e um caminho mais curto do piloto à produção.
Também ajuda nas partes do seu trabalho que não são engenharia. A TagoIO é certificada ISO 27001 e alinhada ao GDPR, o que te dá uma resposta defensável quando o financeiro ou um cliente pergunta sobre segurança e tratamento de dados. O TagoRUN permite que um integrador entregue um portal white-label como um trabalho de configuração em vez de uma construção. O TagoCore cobre o processamento na borda em código aberto quando você precisa dele. Nada disso elimina a necessidade de escopar, sequenciar e gerenciar o projeto. Elimina uma camada de risco técnico que, de outra forma, você carregaria sozinho.
