No hace falta leer una hoja de datos para dirigir bien un proyecto de IoT. Hace falta definir su alcance con honestidad, ordenar el trabajo para que las partes arriesgadas salgan a la luz pronto, y hacerles las preguntas correctas a las personas correctas antes de que salga el dinero. Los project managers que sufren con IoT suelen ser los que lo tratan como el despliegue de un software con unos cuantos sensores acoplados. Los que tienen éxito lo tratan como un proyecto físico que, además, produce datos, y dedican su energía a las partes que ningún ingeniero puede hacer por ellos: requisitos, alineación, riesgo y proveedores.
Esta guía es para el PM sin experiencia en hardware al que acaban de entregarle un proyecto de IoT y una fecha de entrega. Explica cómo definir el alcance del trabajo, cómo dividirlo en fases con plazos que pueda defender, dónde aporta usted más valor, y las preguntas que evitan que un proyecto se descarrile.
Defina el resultado, no la tecnología
La forma más rápida de perder el control de un proyecto de IoT es empezar por el dispositivo. Empiece por la decisión que se supone que los datos deben respaldar. Un equipo de instalaciones no quiere lecturas de temperatura, quiere saber qué congeladores están a punto de fallar antes de que se eche a perder la mercancía. Un operador de flotas no quiere señales de GPS, quiere facturar a sus clientes con precisión y enviar el vehículo más cercano. Escriba el resultado en una frase que un responsable de negocio firmaría, y luego retroceda hasta qué hay que medir, con qué frecuencia y quién actúa en consecuencia.
Puede definir esto sin saber cómo funciona un sensor. Las preguntas son operativas, no técnicas. ¿Qué decisión cambia cuando llegan los datos? ¿Qué tan recientes deben ser los datos para que esa decisión siga teniendo sentido? ¿Quién los ve, y en qué formato? ¿Qué pasa cuando un dispositivo deja de responder? Responda a eso y habrá definido el proyecto. El equipo de ingeniería traduce sus respuestas a hardware y firmware, que es su trabajo, no el suyo.
La trampa que debe evitar es el alcance que crece sensor a sensor. Siempre hay alguien que quiere añadir una lectura porque el dispositivo técnicamente puede captarla. Manténgase firme en el resultado que escribió. Los datos extra sobre los que nadie actúa son coste sin retorno, y son lo más fácil del mundo de aceptar en una reunión.
Estructure el trabajo en fases
Los proyectos de IoT fracasan cuando saltan de una presentación a mil dispositivos en campo. La solución es avanzar por fases, cada una diseñada para eliminar un tipo concreto de riesgo antes de gastar más.
El descubrimiento va primero. Confirma el resultado, elige las métricas y deja que el equipo técnico valide si la medición es siquiera factible en su entorno. Esto son sobre todo reuniones y un poco de pruebas de laboratorio, y dura unas semanas.
El piloto es la fase que se gana su lugar. Coloca un número reducido de dispositivos reales en una ubicación real y demuestra que toda la cadena funciona: del dispositivo a la conectividad, a la plataforma, a la persona que actúa sobre los datos. Un piloto se mide en semanas, no en meses, y es donde se descubre lo que ningún plan predice. El gateway no tiene señal en el sótano. El sensor lee bien hasta que el muelle de carga lo cubre de polvo. La alerta salta a las 3 de la madrugada y no hay nadie de guardia. Mejor descubrir eso con diez dispositivos que con diez mil.
El despliegue limitado amplía el piloto a una porción más completa del entorno real, con suficientes ubicaciones y condiciones para exponer la variabilidad que el piloto no detectó. La producción plena es el despliegue a escala una vez que las fases anteriores han dejado de sorprenderle. La operación no es una fase que termina, es el estado estable en el que vive el proyecto tras el lanzamiento, y necesita un responsable y un presupuesto desde el principio.
Resista cualquier presión por saltar del descubrimiento directamente a la producción. Las fases existen para convertir incógnitas en costes conocidos mientras la factura todavía es pequeña.
Sea honesto con los plazos
Los responsables de alto nivel quieren una fecha. Deles en su lugar una forma, y explique por qué esa forma es la respuesta honesta. Un piloto se puede montar en unas pocas semanas. Un despliegue limitado añade de semanas a meses según cuántas ubicaciones haya y cuánta instalación física implique. La producción plena se cuenta en meses, y la distancia entre piloto y producción casi siempre es mayor de lo que la gente espera, porque escalar expone la variabilidad ubicación por ubicación que una única sede de piloto, limpia, había ocultado.
La razón por la que los plazos de IoT se alargan rara vez es el software. Es el mundo físico. Permisos, acceso a las instalaciones, electricistas, montaje, zonas sin cobertura, y dispositivos que se comportan en campo de forma distinta a como lo hacen sobre un escritorio. Reserve holgura para el trabajo físico, mantenga la exigencia de un piloto antes de producción, y se comprometerá a fechas que de verdad podrá cumplir.
Dónde aporta usted más valor
El trabajo de ingeniería no le corresponde, e intentar hacerlo es la forma en que los PM sin perfil técnico pierden credibilidad. Su valor está en cuatro lugares que deciden si el proyecto sale adelante.
Los requisitos son el primero. Usted es quien puede sentarse con el negocio y concretar qué debe hacer el proyecto, en un lenguaje contra el que el equipo técnico pueda construir. Un documento de requisitos claro evita más retrabajo que cualquier herramienta.
La alineación de los interesados es el segundo, y es constante. Los proyectos de IoT tocan operaciones, IT, finanzas y a menudo a un cliente. Mantenerlos apuntando al mismo resultado es un trabajo que solo un PM hace bien.
El riesgo es el tercero. Usted es la persona que sigue qué podría salir mal y cuál es el plan cuando ocurre. Conectividad, fallo de dispositivos, datos sobre los que nadie actúa, un proveedor que incumple una fecha. Nombrar los riesgos pronto y asignarles responsables es su trabajo.
La gestión de proveedores es el cuarto. Trabajará con suministradores de hardware, un proveedor de conectividad, una plataforma y posiblemente un integrador. Exigirles alcance, fechas e interfaces claras entre sus piezas es trabajo de PM en toda regla, y no requiere un título de ingeniería para hacerlo bien.
Las preguntas que hay que hacer
Las buenas preguntas compensan buena parte del conocimiento técnico que falta. Plantéeselas a sus proveedores antes de comprometerse. ¿Cuál es su plazo real de entrega de hardware, incluidos los malos meses? ¿Qué pasa con mis datos si dejo de pagarles? ¿Cómo se actualizan los dispositivos en campo una vez instalados? ¿Cómo es el soporte a las 2 de la madrugada cuando una ubicación se queda a oscuras? ¿Quién es responsable de la integración con mis sistemas existentes, usted o yo?
Plantéele un conjunto paralelo a su propio equipo. ¿Cuál es la mayor incógnita técnica, y cómo la probamos en el piloto? ¿Qué parte de esto no ha hecho ninguno de nosotros antes? Si el piloto fracasa, ¿cómo lo sabremos, y cuál es el plan de respaldo? Las respuestas le dicen dónde es frágil el proyecto mientras aún tiene tiempo de hacer algo al respecto.
Los errores que atrapan a la mayoría de los equipos
Unos pocos errores aparecen en casi todos los proyectos de IoT con problemas. Los equipos lo tratan como un proyecto de software puro y olvidan que el hardware tiene plazos de entrega, falla físicamente y se comporta distinto según la ubicación. Subestiman la variabilidad de campo y dan por hecho que una buena ubicación de piloto representa a todas las demás. Se saltan el piloto para ahorrar semanas y lo pagan multiplicado en producción. Y presupuestan el proyecto como una construcción puntual sin partida para operaciones, así que se apaga un año después del lanzamiento cuando nadie se hace cargo de mantenerlo en marcha.
Cada uno de estos es un fallo de planificación, no técnico, lo que significa que cada uno es suyo de prevenir.
Cómo una plataforma gestionada reduce lo que tiene que asumir
Cada parte de un sistema de IoT que su equipo construye desde cero es una parte que su equipo tiene que operar, asegurar y reparar para siempre. Una plataforma de aplicaciones gestionada como TagoIO le quita de encima los dashboards, la gestión de dispositivos, el almacenamiento de datos, las alertas y las APIs, situándose sobre la conectividad de los dispositivos para que su equipo entregue una aplicación en lugar de mantener una pila completa. Para un PM sin perfil técnico, eso importa porque reduce la superficie técnica de la que es responsable. Hay menos backend a medida que dimensionar, menos piezas móviles que mantener vivas en operaciones, y un camino más corto del piloto a la producción.
También ayuda con las partes de su trabajo que no son ingeniería. TagoIO cuenta con la certificación ISO 27001 y está alineado con el GDPR, lo que le da una respuesta defendible cuando finanzas o un cliente pregunten por la seguridad y el tratamiento de los datos. TagoRUN permite que un integrador entregue un portal de marca blanca como una tarea de configuración en lugar de un desarrollo. TagoCore cubre el procesamiento en el borde de código abierto cuando lo necesite. Nada de esto elimina la necesidad de definir el alcance, ordenar y gestionar el proyecto. Elimina una capa de riesgo técnico que de otro modo cargaría usted solo.
