Existe una gran confusión acerca de lo que debería hacer una prueba de concepto (POC) en el mundo de IoT. Por supuesto, el objetivo principal de la etapa de POC es evaluar el concepto del producto: ¿brinda los principales beneficios y el objetivo comercial general? A menudo también es deseable:
° probar la aceptación del usuario en este punto,
° evaluar la probabilidad de cualquier certificación necesaria; y
° identifique cualquier problema que pueda poner en peligro la aceptación o certificación del usuario.
Sin embargo, dado que esta es la primera manifestación física del dispositivo conectado, la primera vez que su idea salta del plano de dibujo a la realidad física, es tentador dejarse llevar creando un POC detallado que incorpora muchos aspectos diferentes del producto. Esta es una ruta a costos innecesarios.
Desde el punto de vista de Sigfox, creemos que el objetivo principal del POC es probar cualquier ‘cantidad desconocida’ en el diseño general de la solución IoT. Esto significa limitar su POC al mínimo que necesite para probar. Por supuesto, este enfoque ‘básico’ puede ser decepcionante. Pero es una disciplina importante de dominar, una que contribuirá significativamente al éxito general y a la rentabilidad de su proyecto. Nuestra experiencia nos ha demostrado que lograr esta etapa correcta puede ahorrarle dinero y acelerar el tiempo de comercialización, lo que resulta en una ventaja competitiva vital.
Lo que sigue es una descripción de lo que creemos que son los requisitos previos esenciales que le permitirán adoptar exitosamente este enfoque de creación de ventaja competitiva para su prueba de concepto.
Requisito previo n. ° 1: comprender los riesgos del enfoque POC
El riesgo de mantener el POC al mínimo es que no prueba exhaustivamente las características y funciones necesarias. Por lo tanto, es vital que tenga una comprensión muy clara de:
° su visión general del producto
° un buen brief
° una clara especificación
° objetivos claros
° ROI validado
Si tiene todas estas cosas, puede omitir el POC por completo y pasar a la pre-serie, ahorrando así tiempo y dinero. Por supuesto, esto es deseable, pero no siempre es posible. Puede ser que tenga aspectos técnicos específicos de su diseño que requieran una mayor validación. En tal situación, deberá desarrollar un modelo POC.
Requisito previo n. ° 2: despojar a su POC del mínimo indispensable
Para mantener bajos los costos y reducir el tiempo dedicado a la POC, es vital reducir su POC al mínimo. Pregúntese: ¿qué necesitamos probar con este POC? Limite su POC para responder esa pregunta. De lo contrario, corre el riesgo de confundir la evaluación con comentarios irrelevantes o datos que no aseguran una toma de decisiones efectiva.
Reduzca el POC al mínimo para que pueda enfocarse en el punto funcional o técnico particular o ROI que permanece sin confirmar. No se sienta tentado a complicar el diseño más allá de lo absolutamente necesario.
Requisito previo n. ° 3: Mire a las soluciones existentes para desprenderse aún más
Una manera directa de reducir la complejidad del POC es mirar los productos existentes y los componentes que ya están probados. Esto puede incluso significar mirar a otros sectores o verticales para ver cómo su problema se resuelve con otras soluciones y productos. Mantenga una mente abierta y explore cómo otras personas han resuelto su problema técnico, funcional o de ROI en particular. Si no necesita construirlo, no lo haga.
Requisito previo n. ° 4: un gerente de proyecto fuerte
El POC es la primera vez que tendrá en sus manos una manifestación física de su dispositivo. Este es un momento emocionante. Es demasiado tentador dejarse llevar por la creación de una versión de “todo cantando, bailando” de su POC, especialmente para equipos de proyectos sin experiencia. Sin embargo, esto simplemente creará tiempo y gastos innecesarios.
Un gerente de proyecto efectivo puede hacer la diferencia aquí. La elección de un gerente de proyecto con una sólida experiencia comercial ayudará a garantizar que el equipo de POC se centre únicamente en las métricas comercialmente importantes y valiosas. Un gerente de proyecto fuerte hará cumplir el enfoque de mantener un límite estricto en los requisitos y las especificaciones del POC. De lo contrario, se corre el riesgo de probar algo “diferente” y arrojar datos que no están directamente relacionados con su objetivo de POC o, lo que es peor, demostrar falsamente el éxito o el fracaso.
Un gerente de proyecto fuerte también trabajará para ayudar a todo el equipo a mantenerse enfocado en el objetivo de maximizar los beneficios utilizando el POC para probar los esqueletos del concepto de producto y mantener esta etapa de POC tan simple pero efectiva como sea posible. Como hemos discutido, esta es la mejor ruta para el éxito del proyecto; minimizando el tiempo de comercialización y brindando una ventaja competitiva asociada.
Requisito previo n. ° 5: pasar directamente a la serie de preproducción si es posible
Pasar de su panel de diseño directamente a su serie de preproducción es la extensión lógica de minimizar el alcance de su POC. Por lo tanto, vale la pena considerar si puede omitir la fase POC en su totalidad.
En última instancia, si puede probar el concepto sin invertir en un modelo POC, puede pasar directamente a la serie de pre-producción basada completamente en la especificación de su producto, objetivos claramente establecidos y ROI validado. Si se realiza correctamente, este enfoque le permitirá omitir el elemento POC que consume mucho tiempo del proyecto y generar el máximo beneficio y el tiempo óptimo de comercialización.
Sin embargo, este enfoque no está exento de riesgos. Si tiene la intención de adoptar este enfoque de ahorro de tiempo, es vital que tenga una idea muy clara de los objetivos de su proyecto, las especificaciones del producto y un ROI claramente validado. Necesitarás un enfoque aún más claro en:
° su visión general del producto
° un buen brief
° una clara especificación
° objetivos claros
° ROI validado
Si no define la especificación con suficiente detalle o no demuestra el ROI de manera efectiva antes de comenzar, o no comprende y define claramente cada uno de estos elementos, corre el riesgo de crear una pre serie que no cumple funciones importantes, beneficios o ROI. Se arriesga a necesitar reiteraciones. Esto requerirá que regrese al tablero de dibujo y vuelva a crear el modelo de pre-serie, eliminando así todos los beneficios que ha logrado omitiendo la etapa POC.
Está claro: necesita todos tus elemento en fila antes de pasar directamente a pre-series sin una etapa POC. Sin embargo, si es posible, esta es la opción deseable.
