👨‍👧‍👦 🙄 🤟🏾 Moscú hackear viajes a través de los ojos de los participantes 🍐 🤶🏻 🗡️

Los equipos de TI de Aeroclub en el viaje de Moscú

¡Hola! Probablemente hayas escuchado sobre el primer hackathon en Rusia sobre el tema de la digitalización de la industria del turismo. La empresa AeroClub IT estuvo representada por dos equipos a la vez, y logramos no solo pasar un buen rato, sino también desarrollar proyectos prototipo, probar nuestro formato de trabajo inusual y comunicarnos con otros participantes. Under the cut: ¡la historia de uno de nuestros equipos!

Al realizar la solicitud, fue necesario elegir una de las 10 tareas propuestas (pistas). Estos fueron casos de compañías tan conocidas como MegaFon, Facebook, PANORAMA 360, MTS Startup Hub, Aeroexpress, Pushkin Museum, Tsaritsyno Park, Discover Moscow, City of Discoveries y Russpass.

Solicitamos la participación de dos equipos a la vez: "Equipo 73" en la pista "Aeroexpress" y "Nuevos horizontes" en "Tsaritsyno" . El primero fue elegido porque está cerca del campo de actividad de nuestra empresa (soluciones de software B2B), y en caso de victoria podríamos continuar con la cooperación y el desarrollo. El segundo: los chicos que querían escapar de las tareas cotidianas y probar algo nuevo.

En el chat general del evento, dijeron que se enviaron 1241 solicitudes (tanto de equipo como individuales) y, como ya habrán adivinado, ¡pasamos la selección! Y nuestros dos equipos!
Lo único que quedaba era participar en el hackathon mismo.

Hackathon

Todo estaba como siempre en el sitio: registro, área de refrigerios, mesas con números de equipo.
A las 9:30 se llevó a cabo una breve apertura: unas palabras de los organizadores, el inicio solemne del hackathon y el trabajo comenzó. A continuación, hablaremos en nombre de los participantes del equipo Team 73, que asumió la tarea de Aeroexpress.

Al principio, hablamos con los mentores: aprendimos lo que les gustaría ver en la decisión, cuáles son los matices y a qué dar preferencia. Los equipos se sorprendieron un poco cuando resultó que no se proporcionarían los recursos prometidos. De acuerdo con la descripción de la tarea, podríamos obtener la API, el alojamiento, el nombre de dominio y el certificado de Aeroexpress para el proyecto. Como explicaron los mentores, la API no puede proporcionar por razones de seguridad, pero en realidad no explicaron el resto. Afortunadamente, teníamos una "opción de copia de seguridad": alojamiento personal. Como resultado, salvó nuestra posición.

Decisión

El principal problema que debía resolverse era la automatización de la venta de boletos para Aeroexpress para personas jurídicas. personas. Investigamos un poco sobre el proceso actual y estábamos, por decirlo suavemente, en estado de shock. Como aprendimos de una oferta pública para entidades legales , primero se envía una carta de aceptación de la compañía del cliente como una solicitud para el número requerido de boletos, indicando los detalles de la compañía. A continuación, se paga la factura y, lo que es más importante, de alguna manera, los boletos se reciben en forma de archivo protegido con contraseña. Ese es, como entiendes, el nivel mínimo de automatización.

Dibujamos CJM (mapa de viaje del cliente), elegimos la funcionalidad mínima necesaria y pensamos en el diseño. En algún momento, razonamos de la siguiente manera: cada equipo, de una forma u otra, mostrará aproximadamente las mismas soluciones: registro de personas jurídicas. personas, compra de boletos, facturación, etc. Para destacar de alguna manera, tenías que encontrar algo especial. Como mínimo, necesita un buen diseño, luego, en el contexto general, nuestra solución será un poco más notable. Afortunadamente, hay una diseñadora en nuestro otro equipo, y ella nos ayudará con esto. Pero necesitabas algo más, algo completamente inusual para B2B. Y luego decidimos agregar integración con Alice, la asistente de voz de Yandex.

Hubo varias razones: la principal: tenemos algo de experienciatrabaje con ella para hacer rápidamente un prototipo más o menos útil. Otro: el B2B, por regla general, está asociado con algo aburrido y formal, y obtener tickets a través de una columna parlante es algo nuevo. Además, tenemos dos desarrolladores de back-end, y trabajar juntos en el mismo proyecto no es muy conveniente, y en paralelo haremos tanto la funcionalidad principal como la adicional.
Comenzaré con la solución principal: Aeroexpress Wholesale Portal. Según nuestra idea, consta de dos partes: el front-end y, por supuesto, el back-end.

Interfaz

Nuestro front-end es un adherente de Angular, de ahí la elección de este marco particular. Angular "listo para usar" proporciona un buen entorno inicial, en el que no tiene que preocuparse por la configuración, el enrutamiento y la conexión al backend: esto es lo que necesita el hackathon. Además, nuestro desarrollador ha estado trabajando con él durante mucho tiempo y ha acumulado varias de sus bibliotecas con las que puede ahorrar un poco de tiempo en el hackathon.

Como resultado, obtuvimos esa interfaz:

Intentamos hacer que la apariencia sea moderna, elegante, manteniendo los colores de Aeroexpress.

Aquí hemos implementado la siguiente funcionalidad:

Buscar nombre de la empresa por TIN
Registro de una empresa y una persona de contacto con una indicación del volumen aproximado de ventas de boletos por mes.
Autorización de empleados de la empresa
Orden de entradas
Cantidad de próximos viajes
Historia de pedidos
Cuenta personal del gerente Aeroexpress

Intentamos que el registro de la empresa sea lo más simple posible en el portal: su representante solo necesita conocer el TIN de lo legal. personas e ingréselo en el campo apropiado. Si el nombre que aparece es apropiado, puede continuar. El registro en el portal es simultáneamente una solicitud de cooperación con Aeroexpress. Los mentores sugirieron que sería más fácil para ellos considerar tales solicitudes si los representantes indicaran el volumen aproximado de ventas de boletos por mes, para esto agregamos un campo apropiado.

A primera vista, puede parecer que no se ha hecho mucho, pero nuestra solución tiene un diseño muy bonito y bien diseñado. Fue hecho desde cero, sin usar plantillas preparadas. Según la experiencia previa, los hackatones a menudo ganaban decisiones que no estaban tan bien resueltas, pero "envueltas en un hermoso empaque", y esta vez decidimos confiar en una apariencia hermosa. Mirando hacia el futuro, diré que los mentores estaban encantados con nuestro diseño, pero juzgaron las soluciones precisamente por la cantidad de funciones implementadas y las perspectivas futuras de aplicar la solución (que algunos equipos pensaron bien).

Backend

Nuestros dos desarrolladores de back son expertos en corte (escriben en C #), por lo tanto, el back también se basa en .net core. Se eligió la versión 2.1, porque las aplicaciones en ella definitivamente se elevan en un hosting de respaldo, y es peligroso experimentar con un hackathon: puede perder tiempo y quedarse sin una solución. Tenemos la API web habitual, con blackjack y DI.
Aquí hemos hecho todo lo necesario para el "frente":

Buscar información de la empresa por TIN
Registro de la empresa y su persona de contacto.
Autenticación de contraseña
Autorización de token de portador
Obteniendo información del usuario
Obtener la lista de empleados de la empresa del usuario actual
Crear orden
Enviar un ticket por correo después de crear un pedido
Enviar un ticket por correo al usuario solicitado (para integración externa)
Obtener información sobre todos los boletos de la compañía
Listado de pedidos
Listado de empresas registradas

De interesante: integración con la búsqueda de organizaciones por TIN o BIN en Dadata , para un fácil registro de personas jurídicas . caras. En resumen, el backend recibe una solicitud de "buscar una empresa" con el TIN proporcionado y envía esta información a la API del servicio. En respuesta, si se encuentra la empresa, obtenemos información al respecto: un nombre corto (damos la respuesta) y detalles. Es útil guardar los datos obtenidos en algún lugar, porque serán útiles en la formación de cuentas: será suficiente para que el usuario verifique su corrección, lo cual es mucho más fácil que "conducir" por su cuenta.

Habilidad de asistente de voz

Las habilidades para los asistentes suelen ser servicios web que funcionan con un protocolo específico de solicitud y respuesta. Como ya se mencionó, elegimos la integración con Alice como complemento de la solución principal. Puede obtener más información sobre el protocolo para trabajar con él en la documentación , y también en el último artículo sobre habilidades . En nuestro caso, el servicio web de habilidades también se basó en .net core.

El usuario debe sentirse cómodo interactuando con la habilidad, como si estuviera hablando con su amigo cercano. Para hacer esto, como mínimo, es necesario mantener el contexto de la conversación, comprender de qué tipo de objeto está hablando el usuario y responder sobre el tema. Si el usuario se desvía del propósito del diálogo, debe poder devolverlo al camino correcto. Y todo esto debería suceder no más de 3 segundos: es la cantidad de tiempo que la plataforma Yandex.Dialog le brinda la capacidad de responder. Si la respuesta no se recibe en el tiempo asignado, el diálogo finalizará y se le informará al usuario que la habilidad no responde y es poco probable que quiera volver a ella nuevamente.

Puede hacer frente a esta tarea con la ayuda de varios servicios diseñados para mantener un diálogo con el usuario. Ya teníamos algo de experiencia con Dialogflow.de Google, así que lo elegí. Por lo menos, hay una alternativa de Rusia para él: Aimylogic de JustAI, pero aún no he tenido que trabajar con ella.

En nuestro caso, se supone un diálogo bastante simple: el usuario solicita enviarle un ticket, y si inmediatamente nombra su nombre, lo enviamos. Si no, especificamos el nombre completo y ya estamos enviando.

Refinando un nombre de usuario a toda costa

Aclaración del nombre de usuario a cualquier costo

En nuestra opinión, lo más difícil en esta tarea es obtener el nombre del usuario. Si no están nombrados, debe obtenerlos de alguna manera del usuario y solo entonces realizar la acción deseada. Afortunadamente, DF (Dialogflow) le permite hacer esto fuera de la caja.
Para hacer esto, en la intención (Intención), en la que se supone que se debe recibir el nombre, debe agregar frases de entrenamiento que contengan el nombre completo y marcarlas para que esta información caiga en el parámetro de intención correspondiente. Si se reconoce el nombre, el parámetro contendrá este valor.

Frases de entrenamiento marcadas

Parámetros de intención

De lo contrario, debe obtener estos parámetros a cualquier costo. Para hacer esto, marque el parámetro con el nombre completo como obligatorio (una marca en la columna "Obligatorio") y especifique frases aclaratorias para él ("Avisos"). Ahora, si es necesario, DF los devolverá en respuesta. Y si se reconoce el nombre, entonces las respuestas habituales para esta intención, así como la acción ("Acción").

Frases aclaratorias

Respuestas habituales

Entonces todo es simple: si se recibe el nombre de la acción y la respuesta del DF tiene todos los parámetros necesarios, realizamos esta acción y pasamos la respuesta al usuario. Si no, envíe el texto de aclaración.

Para enviar tickets, la habilidad debe cumplir una solicitud al backend de nuestro portal con el título de autorización y el nombre del usuario en el cuerpo. La compañía estará determinada por el título y por el nombre es fácil encontrar al usuario correcto. En la vida, el título se puede obtener al autorizar la habilidad, pero en el hackathon simplemente lo "codificamos" para ahorrar tiempo. Con un nombre completo es un poco más complicado.

Puede usar los nombres reconocidos en DF, pero hay un pequeño problema: si el usuario se llama a sí mismo no en el caso nominativo, entonces este parámetro también se escribirá en el parámetro. En el backend, los nombres de usuario se escriben en forma normal (en el caso nominativo), y una falta de coincidencia ortográfica hará que sea difícil de encontrar.

¡Y aquí notamos que en la solicitud de Alice vienen nombres reconocidos, normalizados y grabados en campos separados!

Nombre reconocido

Desafortunadamente, la NLU de Yandex-dialogs no se adapta muy bien a nombres más complejos, por ejemplo Mamedov Polad Murtuza oglu, pero esta opción también es adecuada para la demostración en un hackathon.

Como resultado, obtuvimos dicha cadena:

Diagrama de consulta

Al final del hackathon, teníamos las tres partes de nuestra solución listas, que mostramos a los mentores. Por su reacción, fue difícil decir si les gustó nuestro desarrollo o no, pero, como más tarde aprendimos de una conversación personal, una demostración de integración con Alice definitivamente tuvo el efecto sorpresa esperado.

También se llevó a cabo una comisión técnica durante el trabajo: cada equipo tenía que proporcionar acceso a sus repositorios y hacer "compromisos" en ellos al menos una vez por hora. Además, a veces representantes de la comisión vinieron a nosotros y discutieron la solución que se está desarrollando. Por cierto, puedes encontrar su impresión del hackathon aquí .

Ganadores

Después de los discursos de los oradores invitados, comenzaron los lanzamientos finales de los equipos que ganaron en una tarea u otra. El equipo AeroTeam ganó la pista Aeroexpress. Como nos dijeron más tarde los mentores (también son el jurado), fue este equipo el que tuvo el concepto más pensado para el desarrollo posterior de la solución, y los muchachos tomaron en cuenta y trabajaron en algunos puntos que incluso los propios clientes no pensaron (desafortunadamente, no mencionaron cuáles). Para la victoria, nos faltaron algunos detalles que son realmente interesantes para los mentores desde el punto de vista comercial. Eligieron una solución que fue suficientemente desarrollada para comenzar su desarrollo "en este momento", lo que significa que fueron muy objetivos en su decisión, y esto es genial.

Como más tarde aprendimos de una conversación con los participantes de AeroTeam, se reunieron en un equipo desordenado: aprendieron sobre el hackathon de fuentes completamente diferentes, de alguna manera entraron en el chat general del evento, y allí se unieron. Había tres personas en AeroTeam. En algún momento, también se les ofreció un diseñador de experiencia de usuario, pero se negaron y lo hicieron bastante bien sin este papel. Los muchachos no tenían requisitos previos especiales para la victoria (por ejemplo, en forma de trabajo preliminar), y lograron hacer un trabajo tan poderoso que, en mi opinión, merecía una victoria.

Nuestro otro equipo, desafortunadamente, tampoco subió al escenario con un lanzamiento, lo que significa que ella no ganó en su pista, pero contaremos esta historia en otra ocasión. Mientras tanto, ¿quién se convirtió en el súper ganador del hackathon? Esta nominación fue otorgada al equipo, que, según el jurado, tomó la mejor decisión entre todos los ganadores en una categoría u otra: Golden PSG. Trabajaron en una tarea desde la plataforma de observación Panorama 360.. En la asignación, se asumió que los visitantes del sitio serían fotografiados contra un "chromakey" (lienzo simple), elegirían otro fondo colorido e imprimirían la foto de inmediato. Los chicos fueron más allá, y su solución le permite eliminar cualquier fondo (y programáticamente es mucho más difícil de hacer que eliminar el mismo color) alrededor del objeto principal (persona), y reemplazarlo por otro. En nuestra opinión, esta decisión también es digna de victoria.

Los participantes mismos son estudiantes del departamento de presupuesto de ITMO. Como dijeron los chicos en una conversación personal, siempre estaban en el sitio, por la noche no iban a ninguna parte y "araron" durante casi 26 horas de cada 30 (de forma intermitente, por supuesto). Ya tenían experiencia participando en hackatones, pero el premio se está tomando por primera vez.

recomendaciones

En primer lugar, vale la pena dedicar más tiempo a la implementación de la decisión principal, para que el jurado pueda "tocarla", verla en vivo en el prototipo, y no en maquetas y palabras. También vale la pena considerar nuevas perspectivas para el desarrollo del proyecto. En igualdad de condiciones, los jueces pueden dar preferencia a una decisión que cumpla no solo con la tarea actual, sino también con los objetivos del cliente.

Sin embargo, si puede destacarse de alguna manera: para hacer un diseño hermoso o para implementar una idea inusual, definitivamente vale la pena usarlo. Según la experiencia de participar en otras competiciones, esto puede ayudar a ganar, si no en el principal, al menos en la nominación adicional, por ejemplo, para recibir un "premio de espectador", si lo hay. O los participantes y los jueces simplemente serán recordados por su enfoque inusual.

Antes del evento, vale la pena llevar a cabo una investigación del negocio del cliente para conocer mejor su "dolor" y encontrar algo para eliminarlo. Las ideas y los pequeños desarrollos no son una "solución preparada", por lo que las reglas del hackathon no serán violadas, y habrá más tiempo en la competencia misma.

No debe confiar en la provisión de recursos por parte del cliente, incluso si se prescribe en la tarea. En general, uno siempre debe estar bien preparado para un hackathon: aumentar la infraestructura mínima necesaria, considerar la publicación de un proyecto, investigar la API de los servicios necesarios y similares. Definitivamente vale la pena considerar una solución a un problema como su propio acceso a Internet, ya que la mayoría de estos eventos tienen dificultades con esto. Aquí, por ejemplo, la mayoría de las veces no había una conexión estable. La ironía es que el símbolo del hackathon era un dinosaurio fuera de línea, que se puede ver en Chrome cuando no tienes Internet.

Me gustaría señalar por separado la organización del hackathon: en general, fue en su mejor momento. Cada etapa tuvo lugar a tiempo, en el sitio también estaba en orden completo: había suficiente comida para todos, había muchos bocadillos. El segundo día, en teoría, era posible llegar a la parte pública después del registro preliminar, pero, como resultado, cualquiera podía llegar allí. ¡Una pequeña fiesta con un grupo musical y una mesa de buffet también fue un éxito! Expresamos nuestra gratitud y respeto a los organizadores. Nuestra calificación, cuatro de cada cinco dinosaurios verdes, ¡había algo por lo que luchar!

Ese fue el truco de viaje de Moscú para nosotros: algo en nuestra solución fue malo y algo bueno. En cualquier caso, tendremos en cuenta nuestros errores y los recordaremos en la próxima competencia. En general, ¡participar en un hackathon, especialmente en un equipo de colegas, es genial! Para nosotros, no solo fue una experiencia dorada, sino también el mejor trabajo en equipo. Jugamos muy bien, hicimos locuras sin dormir ni descansar. Estábamos convencidos de que podemos trabajar productivamente en tareas complejas en poco tiempo y en una situación estresante. ¡Lo principal es disfrutar el proceso!

Si está interesado en los detalles técnicos de la implementación de nuestra solución, escriba en los comentarios, con gusto le informaremos.
No digas adiós, nos vemos en el centro
Equipo 73 Equipo, Aero Club IT

Los equipos de TI de Aeroclub en el viaje de Moscú

Moscú hackear viajes a través de los ojos de los participantes