¿Por qué una startup de hardware necesita un hackathon de software?

En diciembre pasado, celebramos nuestro propio hackathon de startups con otras seis empresas de Skolkovo. Sin patrocinadores corporativos ni apoyo externo, reunimos a doscientos participantes de 20 ciudades de Rusia gracias a los esfuerzos de la comunidad de programación. A continuación les contaré cómo lo logramos, qué obstáculos encontramos en el camino y por qué inmediatamente comenzamos a colaborar con uno de los equipos ganadores.

¿Por qué una startup de hardware necesita un hackathon de software?Interfaz de la aplicación que controla los módulos Watts Battery de los finalistas del track “Wet Hair”

Inmobiliaria

Nuestra empresa Watts Battery crea centrales eléctricas portátiles modulares. El producto es una central eléctrica portátil de 46x36x11 cm, capaz de producir de 1,5 a 15 kilovatios por hora. Cuatro de estos módulos pueden cubrir el consumo de energía de una pequeña casa de campo durante dos días.

Aunque comenzamos a enviar muestras de producción el año pasado, según todos los informes, Watts Battery es una startup. La empresa fue fundada en 2016 y desde el mismo año es residente del Clúster de Tecnologías Energéticamente Eficientes de Skolkovo. Hoy tenemos 15 empleados y una enorme acumulación de cosas que nos gustaría hacer en algún momento, pero en este momento no hay tiempo para eso.

Esto también incluye tareas puramente de software. ¿Por qué?

La tarea principal del módulo es proporcionar un suministro de energía equilibrado e ininterrumpido a un coste óptimo. Si experimenta un corte de energía debido a razones fuera de su control, siempre debe tener una reserva para alimentar completamente la carga de red requerida durante el corte. Y cuando el suministro de energía es bueno, puedes utilizar energía solar para ahorrar dinero.

La opción más sencilla es que puedes cargar la batería del sol durante el día y utilizarla por la noche, pero exactamente al nivel necesario para que en caso de apagón no te quedes sin electricidad. Por lo tanto, nunca se encontrará en una situación en la que encendió la iluminación con una batería toda la noche (porque es más barato), pero por la noche se fue la electricidad y su refrigerador se descongeló.

Está claro que una persona rara vez es capaz de predecir con gran precisión la cantidad de electricidad que necesita, pero un sistema armado con un modelo predictivo sí puede hacerlo. Por tanto, el aprendizaje automático como tal es una de nuestras áreas prioritarias. Es solo que actualmente estamos enfocados en el desarrollo de hardware y no podemos asignar suficientes recursos a estas tareas, que es lo que nos llevó al Startup Hackathon.

Preparación, datos, infraestructura.

Como resultado, tomamos dos caminos: análisis de datos y sistema de gestión. Además del nuestro, hubo siete temas más de colegas.

Si bien no se ha determinado el formato del hackathon, pensamos en crear “nuestra propia atmósfera”, con un sistema de puntos: los participantes hacen algunas cosas que nos parecen difíciles e interesantes y reciben puntos por ello. Teníamos muchas tareas. Pero mientras construíamos la estructura del hackathon, otros organizadores pidieron que todo tuviera una forma común, lo cual hicimos.

Luego llegamos al siguiente esquema: los chicos hacen un modelo basado en sus datos, luego reciben nuestros datos, que el modelo no había visto antes, los aprende y comienza a predecir. Se suponía que todo esto se podría hacer en 48 horas, pero para nosotros este fue el primer hackathon con nuestros datos y es posible que hayamos sobreestimado los recursos de tiempo o el grado de preparación de los datos. En los hackatones especializados en aprendizaje automático, ese cronograma sería la norma, pero el nuestro no fue así.

Descargamos el software y hardware del módulo tanto como fue posible e hicimos una versión de nuestro dispositivo específicamente para el hackathon, con una interfaz interna muy simple y comprensible que cualquier desarrollador podría soportar.

Para la pista basada en el sistema de control, existía la opción de crear una aplicación móvil. Para evitar que los participantes se devanen los sesos sobre cómo debería verse y pierdan más tiempo, les proporcionamos un diseño de la aplicación, súper liviano, para que aquellos que lo deseen puedan simplemente "estirar" las funciones que necesitan en él. . Para ser honesto, no esperábamos ningún dilema moral aquí, pero uno de los equipos lo tomó de tal manera que limitábamos su imaginación, queríamos obtener una solución lista para usar de forma gratuita y no probarla. en la práctica. Y se fueron.

Otro equipo decidió crear una aplicación completamente diferente desde cero y todo salió bien. No insistimos en que la aplicación fuera exactamente así, sólo necesitábamos que contuviera algunos elementos que demostraran el nivel técnico de la solución: gráficos, analíticas, etc. El diseño terminado también fue una pista.

Dado que analizar un módulo de Watts Battery en vivo en un hackathon llevaría demasiado tiempo, les dimos a los participantes una porción de datos ya preparados durante un mes tomados de los módulos reales de nuestros clientes (que cuidadosamente anonimizamos de antemano). Como era junio, no había nada que incorporara cambios estacionales en el análisis. Pero en el futuro les agregaremos datos externos, como características estacionales y climáticas (hoy en día, este es el estándar de la industria).

No queríamos crear expectativas poco realistas entre los participantes, por eso en el anuncio del hackathon dijimos directamente: el trabajo será lo más parecido posible al trabajo de campo: datos ruidosos y sucios que nadie preparó especialmente. Pero esto también tuvo un lado positivo: en aras de la agilidad, estuvimos en contacto constante con los participantes y modificamos rápidamente la tarea y las condiciones de admisión (más sobre esto a continuación).

Además, les dimos a los participantes acceso a Amazon AWS (tan activamente que Amazon nos bloqueó una región, descubriremos qué hacer al respecto). Allí puede implementar infraestructura para Internet de las cosas y, basándose incluso en plantillas simples de Amazon, crear una solución completa en un día. Pero al final absolutamente cada uno siguió su camino, haciendo todo por su cuenta al máximo. Al mismo tiempo, algunos lograron cumplir el plazo, otros no. Un equipo, Nubble, usó Yandex.cloud, alguien lo mencionó en su hosting. Incluso estuvimos dispuestos a regalar dominios (los tenemos registrados), pero no sirvieron.

Para determinar los ganadores en la vía analítica, planeamos comparar los resultados, para lo cual preparamos métricas numéricas. Pero al final no fue necesario hacerlo, ya que por diversos motivos tres de los cuatro participantes no llegaron a la final.

En cuanto a la infraestructura del hogar, el Tecnoparque de Skolkovo nos ayudó proporcionándonos (gratis) una de sus acogedoras salas modulares con un videowall para presentaciones y un par de salas más pequeñas para un área de recreación y para organizar el catering.

Analítica

Tarea: un sistema de autoaprendizaje que identifica anomalías en el consumo y funcionamiento del módulo a partir de datos de control. Deliberadamente mantuvimos la redacción lo más general posible para que los participantes pudieran trabajar con nosotros para pensar qué se podría hacer con base en los datos disponibles.

Especificidad: La más compleja de las dos pistas. Los datos industriales tienen algunas diferencias con los datos de sistemas cerrados (por ejemplo, marketing digital). Aquí es necesario comprender la naturaleza física de los parámetros que se intenta analizar; mirar todo como series numéricas abstractas no funcionará. Por ejemplo, la distribución del consumo eléctrico a lo largo del día. Es como un ritual: la afeitadora eléctrica se enciende por la mañana entre semana y la batidora los fines de semana. Luego la esencia de las anomalías mismas. Y no olvides que Watts Battery está destinada a uso personal, por lo que cada cliente tendrá sus propios rituales y un modelo universal no funcionará. Encontrar anomalías conocidas en los datos ni siquiera es una tarea; crear un sistema que busque de forma autónoma anomalías no etiquetadas es otra cuestión. Después de todo, cualquier cosa puede ser una anomalía, incluido el insidioso factor humano. Por ejemplo, en nuestros datos de prueba hubo un caso en el que el usuario forzó el sistema a entrar en modo batería. Sin ningún motivo, los usuarios a veces hacen esto (haré una reserva de que este usuario está probando el módulo para nosotros y es por esta razón que tiene acceso al control manual de modos; para otros usuarios el control es completamente automático). Como es fácil de predecir, en tal situación la batería se descarga de forma bastante activa y, si la carga es grande, la carga finalizará antes de que salga el sol o aparezca otra fuente de energía. En tales casos, esperamos ver algún tipo de notificación de que el comportamiento del sistema se ha desviado del normal. O la persona se fue y se olvidó de apagar el horno. El sistema ve que normalmente a esta hora del día el consumo es de 500 vatios, pero hoy, 3,5 mil, ¡una anomalía! Como Denis Matsuev en el avión: "No entiendo nada sobre motores de avión, pero en el camino el motor sonó diferente".

¿Por qué una startup de hardware necesita un hackathon de software?Gráfico de un modelo predictivo en la red neuronal de código abierto Yandex CatBoost

¿Qué necesita realmente la empresa?: sistema de autodiagnóstico dentro del dispositivo, análisis predictivo, incluso sin infraestructura de red (como muestra la práctica, no todos nuestros clientes tienen prisa por conectar las baterías a Internet; para la mayoría, es suficiente que todo funcione de manera confiable), identificación de anomalías, cuya naturaleza aún no conocemos, un sistema de autoaprendizaje sin profesor, clustering, redes neuronales y todo el arsenal de métodos analíticos modernos. Necesitamos entender que el sistema comenzó a comportarse de manera diferente, incluso si no sabemos qué ha cambiado exactamente. En el hackathon en sí, fue muy importante para nosotros ver que hay personas que están listas para ingresar al análisis industrial o que ya lo están, y están buscando nuevas áreas para aplicar sus habilidades. Al principio me sorprendió que hubiera tantos solicitantes: después de todo, se trata de una cocina muy específica, pero poco a poco, de los cuatro participantes, excepto uno, abandonaron, así que hasta cierto punto todo encajó.

¿Por qué no es factible en esta etapa?: El principal problema con las tareas de minería de datos es la falta de datos. Hoy en día hay varias docenas de dispositivos Watts Battery en funcionamiento en todo el mundo, pero muchos de ellos no están conectados a la red, por lo que nuestros datos aún no son muy diversos. Apenas logramos identificar dos anomalías, y ocurrieron en prototipos: las baterías industriales Watts funcionan de manera bastante estable. Si tuviéramos un ingeniero interno de aprendizaje automático y supiéramos que sí, esto se puede extraer de estos datos, pero queremos obtener una mejor calidad de predicción, sería una historia. Pero hasta el momento no hemos hecho nada con estos datos. Además, esto requeriría una inmersión profunda de los participantes en las particularidades del funcionamiento de nuestro producto; un día y medio no es suficiente para ello.

¿Cómo lo decidiste?: No establecieron de inmediato la tarea final exacta. En cambio, durante las 48 horas enteras, estuvimos dialogando con los participantes, descubriendo rápidamente qué pudieron obtener y qué no. Sobre esta base y con un espíritu de compromiso, se concluyó la tarea.

¿Qué obtuviste como resultado?: los ganadores de la pista pudieron limpiar los datos (al mismo tiempo encontraron las "características" de calcular algunos parámetros que nosotros mismos no habíamos notado antes, ya que no usamos algunos de los datos para resolver nuestros problemas) , resaltar las desviaciones del comportamiento esperado de los módulos Watts Battery y configurar un modelo predictivo que pueda predecir el consumo de energía con un alto grado de precisión. Sí, esto es sólo una etapa de viabilidad en el desarrollo de una solución industrial; luego serán necesarias semanas de arduo trabajo técnico, pero incluso este prototipo, creado directamente durante el hackathon, puede formar la base de una solución industrial real, lo cual es raro.

La principal conclusión: Según los datos que tenemos, es posible configurar análisis predictivos, lo asumimos, pero no teníamos los recursos para verificarlo. Los participantes del hackathon probaron y confirmaron nuestra hipótesis, y continuaremos trabajando con los ganadores de la pista en esta tarea.

¿Por qué una startup de hardware necesita un hackathon de software?Gráfico de un modelo predictivo en la red neuronal de código abierto Facebook Prophet

Consejos para el futuro: al elaborar una tarea, es necesario tener en cuenta no sólo la hoja de ruta de producción, sino también el interés de los participantes. Dado que nuestro hackathon no tiene premios en efectivo, jugamos con la curiosidad natural de los científicos de datos y el deseo de resolver problemas nuevos e interesantes en los que nadie ha mostrado nada todavía o en los que pueden mostrarse mejores que los resultados existentes. Si toma en cuenta de inmediato el factor de interés, no tendrá que cambiar su enfoque en el camino.

Управление

Tarea: (aplicación) que gestiona una red de módulos Watts Battery, con cuenta personal, almacenamiento de datos en la nube y seguimiento de estado.

Especificidad: en este tema no buscábamos ninguna solución técnica nueva; por supuesto, tenemos nuestra propia interfaz de usuario. Lo elegimos para el hackathon para demostrar las capacidades de nuestro sistema, sumergirnos en él y comprobar si la comunidad está interesada en el tema del desarrollo de sistemas inteligentes y energías alternativas. Posicionamos la aplicación móvil como una opción, puedes hacerlo o no a tu discreción. Pero en nuestra opinión, esto muestra bien cómo las personas lograron organizar el almacenamiento de datos en la nube, con acceso desde varias fuentes diferentes a la vez.

¿Qué necesita realmente la empresa?: una comunidad de desarrolladores que propondrán ideas de negocios, probarán hipótesis y crearán herramientas de trabajo para su implementación.

¿Por qué no es factible en esta etapa?: El volumen del mercado es todavía demasiado pequeño para la formación orgánica de una comunidad de este tipo.

¿Cómo lo decidiste?: Como parte de un hackathon, llevamos a cabo una especie de estudio físico para ver si era posible idear no solo características, sino también modelos de negocio completos en torno a nuestro producto tan específico. Además, para que las personas capaces de implementar un prototipo puedan hacer esto, después de todo, aquí, no quiero ofender a nadie, este no es el nivel de programar un LED parpadeante en Arduino (aunque esto se puede hacer con innovaciones) , aquí se requieren habilidades bastante específicas: desarrollo de sistemas backend y frontend, comprensión de los principios de la construcción de sistemas escalables de Internet de las cosas.

*Discurso de los ganadores del segundo track*

¿Qué obtuviste como resultado?: dos equipos propusieron ideas de negocio completas para su trabajo: uno se centró más en el segmento ruso y el otro en el extranjero. Es decir, al final no solo contaron cómo se les ocurrió la aplicación, sino que esencialmente comenzaron a hacer negocios en torno a Watts. Los chicos describieron cómo ven el uso de Watts en varios modelos de negocios, proporcionaron estadísticas, mostraron qué regiones tienen qué problemas, qué leyes se adoptan y dónde, describieron la tendencia global: extraer bitcoins no está de moda, está de moda extraer kilovatios. Se optó deliberadamente por las energías alternativas, lo que nos gustó mucho. El hecho de que los participantes, además, hayan podido crear una solución técnica funcional sugiere que pueden iniciar una startup por su cuenta.

La principal conclusión: Hay equipos dispuestos a tomar Watts Battery como base de su modelo de negocio, desarrollarlo y convertirse en socios/compañeros de la empresa. Algunos de ellos incluso saben cómo identificar el MVP de una idea de negocio y trabajar en él primero, algo que hoy en día falta en toda la industria. La gente no sabe cuándo detenerse, cuándo lanzar una solución al mercado, aunque sea temprano, pero funciona. De hecho, la etapa de pulir la solución a menudo no termina, técnicamente la solución cruza la línea de complejidad razonable, ingresa al mercado sobrecargada, ya no está claro cuál era la idea original, cuál es el objetivo del cliente, qué modelos de negocio son. incluido. Como en el chiste sobre Akunin, que escribió otro libro mientras firmaba el anterior para alguien. Pero aquí se hizo en su forma más pura: aquí hay un gráfico, aquí hay un contador, aquí hay indicadores, aquí hay una predicción; eso es todo, no se necesita nada más para ejecutarlo. Con esto podrás acudir a un inversor y recibir dinero para iniciar un negocio. Aquellos que encontraron este equilibrio salieron de la pista como ganadores.

Consejos para el futuro: en el próximo hackathon (lo estamos planeando) en marzo de este año), quizás tenga sentido experimentar con hardware. Tenemos nuestro propio desarrollo de hardware (una de las ventajas de Watts), controlamos completamente la producción y las pruebas de todo lo que hacemos, pero no tenemos suficientes recursos para probar algunas hipótesis de "hardware". Es muy posible que en la comunidad de programadores de sistemas y de bajo nivel y desarrolladores de hardware haya quienes nos ayuden con esto y en el futuro se conviertan en nuestros socios en esta área.

personas

En el hackathon esperábamos más a aquellos que quisieran probarse a sí mismos en un nuevo campo (por ejemplo, graduados de varias escuelas de programación) que a aquellos que se especializan en este tipo de desarrollo. Pero aun así esperábamos que antes del hackathon hicieran un poco de trabajo preparatorio, leyeran sobre cómo se predice el consumo de energía en general y cómo funcionan los sistemas de Internet de las cosas. Para que todo el mundo venga no sólo por diversión, en busca de datos y tareas interesantes, sino también para una inmersión previa en el tema. Por nuestra parte entendemos que para ello es necesario publicar previamente los datos disponibles, su descripción y requisitos más precisos para el resultado, publicar módulos API, etc.

Todos tenían aproximadamente el mismo nivel tecnológico, más o menos las mismas capacidades. En este contexto, el nivel de armonía no fue el último factor. Varios equipos no dispararon porque no podían dividirse claramente en áreas de trabajo. También hubo aquellos en los que una persona hizo todo el desarrollo, el resto estaba ocupado preparando la presentación, en otros, a alguien le encargaron tareas que estaba haciendo, probablemente por primera vez en su vida.

La mayoría de los participantes eran jóvenes, lo que no significa que no hubiera ingenieros y desarrolladores de aprendizaje automático entre ellos. La mayoría venía en equipos, prácticamente no había individuos. Todo el mundo soñaba con ganar, alguien quería encontrar un trabajo en el futuro, alrededor del 20% ya lo ha encontrado, creo que esta cifra irá creciendo.

No teníamos suficientes expertos en hardware, pero esperamos compensarlos en el segundo hackathon.

Progreso del hackatón

Como escribí anteriormente, pasamos la mayor parte de las 48 horas del hackathon con los participantes y, monitoreando sus éxitos en los puntos de control, intentamos adaptar la tarea y las condiciones para aceptar la primera pista analítica para que, por un lado, los participantes Pudimos completarlo en el tiempo restante y, por otro lado, fue de nuestro interés.

La última aclaración sobre la tarea se hizo alrededor del último puesto de control, el sábado por la tarde (la final estaba prevista para el domingo por la noche). Simplificamos todo un poco más: eliminamos el requisito de volver a calcular el modelo con datos nuevos, dejando los datos con los que los equipos ya estaban trabajando. Comparar métricas ya no nos dio nada, ya tenían resultados listos según los datos disponibles, y al segundo día los muchachos ya estaban cansados. Por eso decidimos torturarlos menos.

Sin embargo, tres de cada cuatro participantes no llegaron a la final. Un equipo ya se dio cuenta al principio de que estaba más interesado en el track de nuestros compañeros, el otro, justo antes de la final, se dio cuenta de que durante el proceso de procesamiento habían filtrado los datos necesarios antes de tiempo y se negaron a presentar su trabajo.

El equipo de “21 (Wet Hair Effect)” participó en ambas pistas hasta el final. Querían cubrir todo a la vez: aprendizaje automático, desarrollo, aplicaciones y sitios web. Hasta que los amenazamos con retirarse en el último momento, creían que estaban haciendo todo a tiempo, aunque ya en el segundo punto de control era obvio que con lo principal, el aprendizaje automático, no podían lograr avances significativos: en general, hicieron frente a El segundo bloque, pero no podía predecir el consumo de electricidad, no estaba listo. Como resultado, cuando determinamos la tarea mínima para calificar para la primera, todavía eligieron la segunda pista.

Fit-predict tenía una composición equilibrada diseñada para el análisis de datos, por lo que pudieron superarlo todo. Se notó que los chicos estaban interesados ​​en “tocar” datos industriales reales. Inmediatamente se concentraron en lo principal: analizar, limpiar los datos, solucionar cada anomalía. El hecho de que hayan podido construir un modelo funcional durante el hackathon es un gran logro. En la práctica laboral, esto suele llevar semanas: mientras se limpian los datos, mientras se profundiza en ellos. Por lo tanto, definitivamente trabajaremos con ellos.

En la segunda vía (gestión), esperábamos que todos hicieran todo en medio día y vinieran a pedir para hacer la tarea más difícil. En la práctica, apenas tuvimos tiempo de completar la tarea básica. Trabajamos en JS y Python, lo que refleja el estado actual de la industria.

Aquí también los resultados se lograron mediante equipos bien coordinados en los que se construyó la división del trabajo, estaba claro quién hacía qué.

El tercer equipo, FSociety, parecía tener una solución, pero al final decidieron no mostrar su desarrollo, dijeron que no consideraban que funcionara. Respetamos esto y no discutimos.

El ganador fue el equipo "Strippers from Baku", que supo detenerse, no para perseguir "baratijas", sino para crear un MVP que no se avergüenza de mostrar y que está claro que puede desarrollarse y escalarse aún más. Inmediatamente les dijimos que no estábamos demasiado interesados ​​en oportunidades adicionales. Si quieren registrarse mediante código QR, reconocimiento facial, déjeles primero hacer gráficos en la aplicación y luego asumir los opcionales.

En esta pista, “Wet Hair” entró con confianza a la final y discutimos una mayor cooperación con ellos y “Hustlers”. A este último ya lo hemos conocido en el nuevo año.

Espero que todo salga bien y esperamos verlos a todos en el segundo hackathon en marzo.

Fuente: habr.com

Añadir un comentario