RAIFHACK: La historia del Hackathon que pudo





Si recuerdas, recientemente publicamos el anuncio del hackathon RAIFHACK , que tuvo lugar en línea del 14 al 15 de noviembre junto con el equipo de Russian Hackers. Parecería que este es un hackathon ordinario. Pero lo tenía todo: negación, enfado, regateo, depresión, aceptación, bromas y, por supuesto, memes.



La agenda principal de RAIFHACK fue crear soluciones para pequeñas y medianas empresas en dos vías:



  • Sepa que el cliente y la competencia se trata del uso de datos. Los participantes desarrollaron un producto en el paradigma de datos como servicio basado en datos de clientes anónimos.
  • « — » — API . - API , .




Dar servicio a las pequeñas y medianas empresas es una prioridad para nuestro banco.



Supervisamos las solicitudes de los clientes en esta área e intentamos presentarles de inmediato nuevos servicios. Estamos hablando de soluciones de TI estandarizadas y flexibles. Por ejemplo, nos hemos convertido en líderes en la implementación del sistema de pago rápido (FPS) en nuestros productos. Esta es una de las primeras soluciones en el mercado ruso que permite facturar a los clientes directamente desde el teléfono inteligente del vendedor.



Si hablamos de productos en el paradigma de Datos como servicio, entonces el trasfondo es el siguiente: en 2019, después de numerosos desarrolladores personalizados con socios de programas de lealtad, obtuvimos la siguiente imagen: la empresa es muy consciente de la falta de información objetiva sobre sus clientes en un entorno competitivo real.



La investigación adicional ha llevado a la creación de nuestro producto de datos como servicio, similar al modelo SaaS. En su marco, ya se han implementado varios casos de negocio, los cuales se basan en la intersección de datos sobre compras de clientes y datos sobre el comportamiento e intereses de los clientes en redes sociales. Pero tal análisis no es el límite, y estamos interesados ​​en cualquier idea en esta dirección.



Formato, registro, cronograma



En la organización RAIFHACK, decidimos no seguir el clásico hackathon, cuando los equipos reciben una tarea y 24-48-72 horas para completarla. Queríamos que los participantes se sumergieran en el producto desde el principio. Entonces el CJM fue así:



  • registrarse como un equipo;
  • familiarícese con la tarea de la pista y envíe su idea de producto;
  • calificar para la final;
  • obtenga un conjunto de datos y acceda a la API al final, finalice el producto y presente una demostración.


El tema del hackathon fue limitado, pero recibimos más de 900 registros individuales, más de 100 decisiones de equipo en la etapa de selección y 28 equipos llegaron a la final.



Quizás la etapa de selección siempre será el cuello de botella de cualquier competencia. Siempre habrá proyectos que te gustaron más y proyectos que no lo lograron o no convencieron al jurado. Así fue con nosotros, y esto provocó un tsunami. La negación comenzó cuando anunciamos los resultados de la ronda de clasificación.



Habiendo recibido 60 ideas en la pista DaaS y 51 en el SBP, comenzamos a evaluar las aplicaciones. Las soluciones fueron observadas por mentores de pista: al menos comestibles y técnico + adicional. Ya en la etapa de selección, evaluamos qué tan factible era la solución; por ejemplo, en la pista de DaaS, el componente DS tenía un peso enorme, por lo que muchos equipos recibieron una puntuación muy baja en esta parte. Estas valoraciones han generado mucha ira. Además del hecho de que algunos proyectos fueron vistos por un mayor número de mentores, otros por un número menor y los que despertaron un mayor interés recibieron una calificación más alta. En general, esto corresponde a una situación real en la que una startup presenta una idea a un inversor.





No sin reacciones emocionales :)



No pretendamos que somos blancos y esponjosos, también teníamos un porro. Los resultados se resumieron a toda prisa y la fórmula era trillada en una de las tablas. Como resultado, implementamos los resultados con un error. Gracias a los participantes por darse cuenta de esto, aunque sea una pena. Así que llevamos a 5 equipos más a la final de la categoría SBP, y fuimos reprendidos con razón con la frase "bang-bang - ¡y en producción!"



Puede discutir interminablemente sobre el sistema de evaluación de soluciones listas para usar. Tenemos una visión, algunos participantes tienen otra diferente. La ira generó comentarios enojados, memes y desmotivadores (¡sic!).







En la etapa de negociación, apareció una petición en change.org para la cancelación de los resultados del hackathon e incluso una invitación a todos aquellos que no llegaron a la final a reunirse en Discord para un mitin y organizar sus presentaciones independientes. Prediciendo la siguiente etapa, uno de los participantes creó un bot de Telegram para brindar asistencia psicológica a las víctimas de arbitrariedad judicial.







Pese a todo, la final tuvo lugar y se celebró del 14 al 15 de noviembre. El calendario era extremadamente apretado y esperábamos que de uno a tres equipos simplemente no llegaran al final; esto es normal para tales hackatones. Sorprendentemente, ¡todos llegamos al final!



Hackathon, codificación y hardcore



El cronograma del hackathon es difícil, el conjunto de datos es enorme, requirió muchos recortes y hasta 3 puntos de control por parte de los mentores y no probados por los equipos de API. Los participantes debían conectarse y entregar lo que tenían, de lo contrario el equipo se retiraba de la distancia.



Dividimos todos los puntos de control en 3 etapas:



  • idea y plan de implementación;
  • proyecto de prototipo;
  • edición del prototipo + discusión de la presentación.


Cada punto de control es una demostración del progreso del desarrollo y la recepción de comentarios de dos mentores en una llamada de 15 a 20 minutos. Un mentor fue responsable del producto, el otro del componente técnico del proyecto. Basándose en los resultados de la llamada, los mentores decidieron si dejar de lado al equipo o no. Este enfoque ayudó a planificar mejor el trabajo de los participantes, brindó retrospectivas periódicas y equipos sincronizados, y fue más fácil para los mentores en este formato rastrear el progreso.



La cuadrícula de puntos de control del lado de los mentores se veía así:







De hecho, los mentores hicieron una hazaña y trabajaron a ese ritmo todo el fin de semana. Animaron a los equipos y se mantuvieron en contacto con ellos. Los propios participantes ya lo notaron al final del hackathon: “¡Excelente! Los mentores miraron desde fuera y realmente nos ayudaron a mejorar el proyecto. Respuestas muy detalladas y amigables ".







Algunos equipos enfrentaron problemas técnicos, otros se quedaron con ideas y uno de ellos en el proceso fue abandonado por completo por dos participantes, incluido el líder del equipo. A este equipo solo le quedan un desarrollador y un diseñador de 14 años. Sí, el participante más joven en el hackathon tenía 14 años. Fue Sveta Simak, ella es de San Petersburgo y todo el evento estuvo a la cabeza de nuestra lista no oficial de "Premio Organizational Sympathy".



Demo y lanzamientos



Todos llegaron a la demostración. Esta vez decidimos no dividir las actuaciones y escuchamos a todos los equipos en una sola transmisión. Fue un experimento y resultó no ser el más exitoso, es cierto. Nosotros mismos lo admitimos: 28 presentaciones seguidas es demasiado. Recibimos cinco propuestas para dividir las actuaciones en escenarios, pero la mayoría estaban bastante interesadas en ver los proyectos de otras personas.



No todas las actuaciones salieron bien. El tiempo fue muy ajustado: exactamente 5 minutos para un discurso y 2 minutos para preguntas. En un momento crucial, uno de los equipos perdió Internet por completo. Pero todos lo hicieron, ¡y fue realmente genial e interesante! ¡Un equipo incluso alquiló un "agarre" de vending especialmente para la presentación en la final!



La evaluación se realizó en una escala de 10 puntos. El jurado tuvo que esforzarse mucho para destacar los mejores proyectos. La elección se hizo no solo por un principio matemático, sino también desde el punto de vista de un inversor que va a invertir dinero en tal o cual proyecto. Por lo tanto, además de los coeficientes, también había un factor como la subjetividad, en el nivel de "me gustó, no me gustó". Esto permite acercar las condiciones del hackathon a las condiciones de una incubadora de empresas, cuando los autores de una idea no solo necesitan presentarla, sino mostrar su viabilidad y probar sus perspectivas a nivel subjetivo.



¿Quien ganó? A continuación, te contaremos los proyectos que ganaron en sus áreas.



Ganador de DaaS - Equipo "DS29"







La esencia del proyecto: un servicio para un grupo de suscripciones de clientes comerciales del banco con la formación de una oferta basada en las transacciones de los clientes.



Objetivo del proyecto: desarrollar un producto en el paradigma “Data as a Service” basado en datos sobre clientes y sus transacciones.



Cómo resolvimos el problema: creamos "PRime", un servicio de suscripción desde los clientes comerciales del banco hasta los usuarios finales. Se trata de un sistema flexible de grupos de suscripción, que se forma sobre la base de los datos de los clientes sobre las transacciones, lo que permitirá al banco, los clientes y los usuarios finales permanecer en la oscuridad y dedicar su tiempo de manera más eficiente.







Aquí puedes descargar la presentación del proyecto.



« , , :) , , . , » — , .


« : - , , », — , Data Scientist.


— «LIFE Laboratory»







La esencia del proyecto: una aplicación que permite a una empresa utilizar un teléfono como terminal, procesando los pedidos de los clientes a través de una interfaz web.



La tarea del proyecto: desarrollo de un sistema de pagos rápidos y convenientes a través del SBP del banco con la capacidad de utilizar el módulo NFC de un teléfono inteligente, un dispositivo que está siempre a mano



Perspectivas: desarrollo de un sitio web real y una aplicación que permitirá a los clientes comerciales ofrecerse una cooperación mutuamente beneficiosa.







Cómo resolvimos el problema:Implementó la aplicación "NFC for SFP", que recibe del operador un código QR con datos incrustados para el pago. El cliente recibe datos vía NFC que le permiten seleccionar su aplicación bancaria, luego de lo cual solo tiene que presionar el botón “confirmar pago”. En una situación normal, el mensajero debe llevar consigo un terminal de pago; la mayoría de los modelos de estos dispositivos son bastante pesados ​​e inconvenientes, además de costosos. Es mucho más fácil usar un teléfono inteligente con un módulo NFC.



Para el proyecto se ha desarrollado tanto la aplicación en sí como el servicio web, o más bien la interfaz web de la aplicación. La interfaz web de la aplicación está destinada al operador, en el que se forma el pedido del cliente, se genera un código QR para el pago, luego de lo cual todo esto se transmite al mensajero.







Aquí puedes descargar la presentación del proyecto.



« 500 «», , . , , , , , », — , backend-.


Todas las presentaciones de los equipos se pueden ver y evaluar aquí , y aquí también está la ceremonia de premiación .



El fondo total de premios fue de 500.000 rublos . En cada pista, para el primer lugar, se pagó un premio en efectivo de 150.000 rublos por equipo y se presentó un paquete extendido de productos de la marca de nuestro banco. Para el segundo lugar, se pagaron 100.000 rublos. Para el tercer lugar, cada participante recibió airpods y merchandising. Todos los demás equipos recibieron merchandising y nuestra gratitud ilimitada por su participación, y presentamos pantuflas con la marca al creador de la petición en change.org, con lo que estaba muy contento :) ¡







Nos vemos en el próximo RAIFHACK!



All Articles