Hack de viagens em Moscou através dos olhos dos participantes

Equipes de TI da Aeroclub em Moscou viajam hack

Olá! Você provavelmente já ouviu falar sobre a primeira hackathon na Rússia sobre o tema da digitalização da indústria do turismo. A empresa Aero Club IT foi representada por duas equipes ao mesmo tempo, e conseguimos não apenas nos divertir, mas também desenvolver projetos de protótipos, experimentar um formato de trabalho incomum e nos comunicar com outros participantes. Sob o corte - a história de uma de nossas equipes!

Na inscrição, foi necessário escolher uma das 10 tarefas propostas (trilhas). Foram casos de empresas conhecidas como MegaFon, Facebook, PANORAMA 360, MTS Startup Hub, Aeroexpress, Museu Pushkin, Tsaritsyno Park, Discover Moscow, Cidade dos Descobrimentos e Russpass.

Nós solicitamos a participação de duas equipes ao mesmo tempo: "Equipe 73" na pista "Aeroexpress" e "Novos horizontes" em "Tsaritsyno" . O primeiro foi escolhido por estar próximo ao campo de atividade de nossa empresa (soluções de software B2B) e, em caso de vitória, poderíamos continuar com a cooperação e o desenvolvimento. O segundo - os caras que queriam fugir das tarefas diárias e tentar algo novo.

No bate-papo geral do evento, eles disseram que 1241 inscrições foram enviadas (por equipe e individual) e, como você já deve imaginar, passamos na seleção! E as nossas duas equipes!
A única coisa que restava era participar da própria hackathon.

Hackathon


Tudo estava como de costume no site: registro, área de lanches, mesas com números de equipe.
Às 9h30, ocorreu uma pequena abertura: algumas palavras dos organizadores, o início solene do hackathon e o trabalho começou. Em seguida, falaremos em nome dos participantes da equipe Team 73, que assumiu a tarefa da Aeroexpress.

No início, conversamos com os mentores: aprendemos o que eles gostariam de ver na decisão, quais são as nuances e o que dar preferência. As equipes ficaram um pouco surpresas quando descobriu que os recursos prometidos não seriam fornecidos. De acordo com a descrição da tarefa, poderíamos obter a API Aeroexpress, hospedagem, nome de domínio e certificado para o projeto. Como os mentores explicaram, a API não pode fornecer por razões de segurança, mas eles realmente não explicaram o resto. Felizmente, tivemos uma "opção de backup" - hospedagem pessoal. Como resultado, ele salvou nossa posição.

Decisão


O principal problema que precisava ser resolvido foi a automação da venda de ingressos do Aeroexpress para pessoas jurídicas. pessoas. Fizemos algumas pesquisas sobre o processo atual e ficamos, para dizer o mínimo, em choque. Conforme aprendemos com uma oferta pública para pessoas jurídicas , primeiro uma carta de aceitação é enviada pela empresa cliente como uma solicitação do número necessário de tickets, indicando os detalhes da empresa. Em seguida - a fatura é paga e, mais importante, de alguma forma, os tickets são recebidos na forma de um arquivo protegido por senha. Esse é, como você entende, o nível mínimo de automação.

Esboçamos o CJM (mapa de jornada do cliente), escolhemos a funcionalidade mínima necessária e pensamos no design. Em algum momento, argumentamos da seguinte maneira: cada equipe, de uma forma ou de outra, mostrará aproximadamente as mesmas soluções: registro de pessoas jurídicas. pessoas, compra de ingressos, cobrança e assim por diante. Para se destacar de alguma forma, você tinha que criar algo especial. No mínimo, você precisa de um bom design e, no contexto geral, nossa solução será um pouco mais visível. Felizmente, existe um designer em nossa outra equipe e ela nos ajudará com isso. Mas você precisava de algo mais, algo completamente incomum para B2B. E então decidimos adicionar integração com Alice, a própria assistente de voz da Yandex.

Havia várias razões: a principal - temos alguma experiênciatrabalhe com ela para criar rapidamente um protótipo mais ou menos útil. Outro - o B2B, por regra, está associado a algo chato e formal, e obter tickets através de uma coluna de discussão é algo novo. Além disso, temos dois desenvolvedores de back-end, e juntar o mesmo projeto não é muito conveniente e, em paralelo, criaremos a funcionalidade principal e a funcionalidade adicional.
Vou começar com a solução principal - Aeroexpress Wholesale Portal. De acordo com a nossa ideia, consiste em duas partes: o front-end e, é claro, o back-end.

A parte dianteira


Nosso front-end é um aderente do Angular, daí a escolha dessa estrutura específica. O Angular "pronto para uso" fornece um bom ambiente inicial, no qual você não precisa se preocupar com configuração, roteamento e conexão com o back-end - é disso que o hackathon precisa. Além disso, nosso desenvolvedor trabalha com ele há muito tempo e acumulou várias de suas bibliotecas com as quais você pode economizar um pouco de tempo na hackathon.

Como resultado, obtivemos esse frontend:


Tentamos tornar a aparência moderna, elegante, mantendo as cores do Aeroexpress.

Aqui, implementamos a seguinte funcionalidade:

  1. Procurar nome da empresa por TIN
  2. Registro de uma empresa e uma pessoa de contato com uma indicação do volume aproximado de vendas de ingressos por mês.
  3. Autorização de funcionário da empresa
  4. Pedido de ingresso
  5. Número de próximas viagens
  6. Histórico de pedidos
  7. Conta pessoal do gerente da Aeroexpress

Tentamos tornar o registro da empresa o mais simples possível no portal: seu representante precisa apenas conhecer o NIF do legal. pessoas e insira-o no campo apropriado. Se o nome que aparecer for apropriado, você poderá continuar. O registro no portal é simultaneamente um pedido de cooperação com o Aeroexpress. Os mentores sugeriram que seria mais fácil considerar essas solicitações se os representantes indicassem o volume aproximado de vendas de ingressos por mês, para isso, adicionamos um campo apropriado.

À primeira vista, pode parecer que pouco foi feito, mas nossa solução tem um design muito bonito e bem projetado. Foi feito do zero, sem o uso de modelos prontos. De acordo com a experiência anterior, os hackathons geralmente obtinham decisões que não eram tão bem elaboradas, mas “embrulhadas em embalagens bonitas”, e dessa vez decidimos confiar em uma aparência bonita. Olhando para o futuro, direi que os mentores ficaram encantados com nosso design, mas julgaram as soluções precisamente pelo número de funções implementadas e pelas perspectivas futuras de aplicar a solução (que algumas equipes pensaram bem).

Processo interno


Ambos os desenvolvedores anteriores são sharpists experientes (eles escrevem em C #), portanto, o back também é baseado no núcleo .net. A versão 2.1 foi escolhida porque os aplicativos nela definitivamente aumentam em uma hospedagem de backup e é perigoso experimentar uma hackathon - você pode perder tempo e ficar sem solução. Temos o habitual web-api, com blackjack e DI.
Aqui fizemos todo o necessário para a "frente":

  1. Pesquise informações da empresa por TIN
  2. Registro da empresa e sua pessoa de contato
  3. Autenticação de senha
  4. Autorização de token do portador
  5. Obtendo informações do usuário
  6. Obtendo a lista de funcionários da empresa do usuário atual
  7. Criar pedido
  8. Enviar um ticket por correio após criar um pedido
  9. Enviando um ticket por correio ao usuário solicitado (para integração externa)
  10. Obtendo informações sobre todos os tickets da empresa
  11. Pedidos de listagem
  12. Listando empresas registradas

De interessante - integração com a busca de organizações por TIN ou BIN em Dadata , para fácil registro de pessoas jurídicas. rostos. Em resumo, o back-end recebe uma solicitação de “encontrar uma empresa” com o TIN fornecido e envia essas informações para a API de serviço. Em resposta, se a empresa for encontrada, obtemos informações sobre ela: um nome abreviado (damos a resposta) e detalhes. É útil salvar os dados obtidos em algum lugar, porque eles serão úteis na formação de contas: será suficiente para o usuário verificar sua exatidão, o que é muito mais fácil do que “dirigir por conta própria”.

Habilidade do Assistente de Voz


As habilidades dos assistentes geralmente são serviços da Web que funcionam com um protocolo de solicitação e resposta específico. Como já mencionado, escolhemos a integração com Alice como complemento da solução principal. Você pode aprender mais sobre o protocolo para trabalhar com ele na documentação e também no artigo mais recente sobre habilidades . No nosso caso, o serviço web de habilidades também foi baseado no núcleo .net.

O usuário deve se sentir à vontade interagindo com a habilidade, como se estivesse conversando com um amigo próximo. Para fazer isso, no mínimo, é necessário manter o contexto da conversa, entender de que tipo de objeto o usuário está falando e responder sobre o tópico. Se o usuário se desviar do objetivo do diálogo, será necessário retorná-lo ao caminho certo. E tudo isso deve acontecer não mais que 3 segundos - é quanto tempo a plataforma Yandex.Dialog oferece a capacidade de responder. Se a resposta não for recebida no prazo estipulado, o diálogo será encerrado, e o usuário será informado de que a habilidade não está respondendo e é improvável que você queira voltar a ela novamente.

Você pode lidar com esta tarefa com a ajuda de vários serviços projetados para manter um diálogo com o usuário. Já tivemos alguma experiência com o Dialogflow.do Google, então escolheu. No mínimo, existe uma alternativa da Rússia para ele - Aimylogic da JustAI, mas ainda não tive que trabalhar com isso.

No nosso caso, supõe-se um diálogo bastante simples: o usuário pede para enviar um ticket e, se ele imediatamente nomeou seu nome, nós o enviamos. Caso contrário, especificamos o nome completo e já estamos enviando.

Refinando um nome de usuário a todo custo

Esclarecimento do nome de usuário a qualquer custo

Em nossa opinião, a coisa mais difícil nesta tarefa é obter o nome do usuário. Se eles não forem nomeados, você precisará obtê-los de alguma forma do usuário e somente então executar a ação desejada. Felizmente, o DF (Dialogflow) permite que você faça isso imediatamente.
Para fazer isso, na intenção (Intenção), na qual o nome deve ser recebido, você precisa adicionar frases de treinamento contendo o nome completo e marcá-las para que essas informações caiam no parâmetro de intenção correspondente. Se o nome for reconhecido, o parâmetro conterá esse valor.

Frases de treinamento marcadas

Frases de treinamento marcadas

Parâmetros de intenção

Parâmetros de intenção

Caso contrário, você precisará obter esses parâmetros a qualquer custo. Para fazer isso, marque o parâmetro com o nome completo como obrigatório (uma marca na coluna “Necessário”) e especifique frases de esclarecimento para ele (“Prompts”). Agora, se necessário, o DF os devolverá em resposta. E se o nome for reconhecido - então as respostas usuais para essa intenção, bem como a ação ("Ação").

Frases esclarecedoras

Frases esclarecedoras

Respostas comuns

Respostas usuais

Então tudo é simples: se o nome da ação for recebido e a resposta do DF tiver todos os parâmetros necessários, executamos essa ação e passamos a resposta ao usuário. Caso contrário, envie o texto de esclarecimento.

Para enviar tickets, a habilidade deve atender a uma solicitação ao back-end do nosso portal com o cabeçalho da autorização e o nome do usuário no corpo. A empresa será determinada pelo título e pelo nome é fácil encontrar o usuário certo. Na vida, o título pode ser obtido mediante a autorização da habilidade, mas no hackathon nós apenas o "codificamos" para economizar tempo. Com um nome completo é um pouco mais complicado.

Você pode usar os nomes reconhecidos no DF, mas há um pequeno problema: se o usuário não se chamar no caso nominativo, esse parâmetro também será gravado no parâmetro. No back-end, os nomes de usuário são escritos na forma normal (no caso nominativo), e uma incompatibilidade ortográfica dificultará a localização.

E aqui percebemos que no pedido de Alice vêm nomes reconhecidos, normalizados e registrados em campos separados!

Nome reconhecido

Nome reconhecido

Infelizmente, o NLU dos diálogos Yandex não lida muito bem com nomes mais complexos, por exemplo, Mamedov Polad Murtuza oglu, mas essa opção também é adequada para demonstração no hackathon.

Como resultado, obtivemos essa cadeia:

Gráfico de consulta

Diagrama de consulta

No final do hackathon, tínhamos todas as três partes de nossa solução prontas, que mostramos aos mentores. Pela reação deles, foi difícil dizer se eles gostaram do nosso desenvolvimento ou não, mas, como aprendemos mais tarde em uma conversa pessoal, uma demonstração de integração com Alice definitivamente teve o efeito esperado.

Uma comissão técnica também ocorreu durante o trabalho: cada equipe teve que fornecer acesso a seus repositórios e fazer "confirmações" neles pelo menos uma vez por hora. Além disso, algumas vezes representantes da comissão vieram até nós e discutiram a solução que estava sendo desenvolvida. A propósito, você pode descobrir a impressão deles sobre o hackathon aqui .

Vencedores


Após os discursos dos palestrantes convidados, começaram os arremessos finais das equipes que venceram em uma tarefa ou outra. A equipe do AeroTeam venceu a pista do Aeroexpress. Como os mentores nos disseram mais tarde (eles também são o júri), foi essa equipe que teve o conceito mais pensado para o desenvolvimento da solução, e os funcionários levaram em conta e trabalharam em alguns pontos que nem os próprios clientes pensaram (infelizmente, não mencionaram quais). Para a vitória, faltam alguns detalhes que são realmente interessantes para os mentores do ponto de vista comercial. Eles escolheram uma solução suficientemente desenvolvida para iniciar seu desenvolvimento "agora", o que significa que eles foram muito objetivos em sua decisão, e isso é ótimo.

Como aprendemos mais tarde em uma conversa com os participantes do AeroTeam, eles se reuniram em uma equipe confusa: eles aprenderam sobre o hackathon de fontes completamente diferentes, de alguma forma entraram no bate-papo geral do evento e lá se uniram. Havia três pessoas no AeroTeam. Em algum momento, eles também receberam um designer de UX, mas eles se recusaram e foram bem gerenciados sem essa função. Os caras não tinham pré-requisitos especiais para a vitória (por exemplo, na forma de algumas bases) e conseguiram fazer um trabalho tão poderoso que, na minha opinião, merecia merecer uma vitória.

Infelizmente, nossa outra equipe também não subiu ao palco com um arremesso, o que significa que ela não venceu em sua pista, mas contaremos essa história outra vez. Enquanto isso, quem se tornou o super vencedor do hackathon? Essa indicação foi dada à equipe, que, segundo o júri, tomou a melhor decisão entre todos os vencedores de uma categoria ou de outra - o Golden PSG. Eles trabalharam em uma tarefa do deck de observação do Panorama 360.. Na tarefa, assumiu-se que os visitantes do site seriam fotografados contra uma “chromakey” (tela simples), escolheriam outro fundo colorido e imprimiriam a foto imediatamente. Os caras foram além, e sua solução permite remover qualquer plano de fundo (e de maneira programática é muito mais difícil do que remover a mesma cor) ao redor do objeto principal (pessoa) e substituí-lo por outro. Em nossa opinião, essa decisão também é digna de vitória.

Os próprios participantes são estudantes do departamento de orçamento do ITMO. Como os rapazes disseram em uma conversa pessoal, eles estavam sempre no site, à noite eles não iam a lugar nenhum e foram "lavrados" por quase 26 horas em 30 (intermitentemente, é claro). Eles já tinham experiência em participar de hackathons, mas o prêmio está sendo recebido pela primeira vez.

achados


Antes de tudo, vale a pena dedicar mais tempo à implementação da decisão principal, para que o júri possa tocá-la, vê-la ao vivo no protótipo, e não em maquetes e palavras. Também vale a pena considerar novas perspectivas para o desenvolvimento do projeto. Sendo outras coisas iguais, os juízes podem dar preferência a uma decisão que cumpre não apenas a tarefa atual, mas também os objetivos do cliente.

No entanto, se você pode se destacar de alguma forma - para criar um design bonito ou implementar uma idéia incomum, isso definitivamente vale a pena usar. Com a experiência de participar de outras competições, isso pode ajudar a ganhar, se não no principal, e pelo menos na indicação adicional - por exemplo, para receber um "prêmio de espectador", se houver. Ou os participantes e juízes serão simplesmente lembrados por sua abordagem incomum.

Antes do evento, vale a pena realizar algumas pesquisas sobre os negócios do cliente para conhecer melhor sua "dor" e criar algo para eliminá-la. Ideias e pequenos desenvolvimentos não são uma "solução pronta", portanto, as regras do hackathon não serão violadas e haverá mais tempo na própria competição.

Você não deve confiar na provisão de recursos pelo cliente, mesmo que seja prescrito na tarefa. Em geral, deve-se estar sempre bem preparado para um hackathon: aumentar a infraestrutura mínima necessária, considerar a publicação de um projeto, pesquisar a API dos serviços necessários e assim por diante. Definitivamente, vale a pena considerar uma solução para um problema como o seu próprio acesso à Internet, pois a maioria desses eventos tem dificuldades. Aqui, por exemplo, na maioria das vezes não havia conexão estável. A ironia é que o símbolo da hackathon era um dinossauro offline, que pode ser visto no Chrome quando você não tem Internet.

Eu gostaria de observar separadamente a organização do hackathon: em geral, foi o melhor. Cada etapa acontecia dentro do prazo, no próprio local também estava em ordem total: havia comida suficiente para todos, havia muitos lanches. No segundo dia, em teoria, era possível chegar à parte pública após o registro preliminar, mas, como resultado, qualquer um podia chegar lá. Uma pequena festa com um grupo musical e uma mesa de buffet também foi um sucesso! Expressamos nossa gratidão e respeito aos organizadores. Nossa classificação - quatro dos cinco dinossauros verdes - então havia algo pelo que lutar!

Esse foi o truque de viagem para Moscou para nós: algo em nossa solução estava ruim e algo estava bom. De qualquer forma, levaremos em conta nossos erros e os lembraremos na próxima competição. Em geral, participar de um hackathon, especialmente em uma equipe de colegas, é ótimo! Para nós, não foi apenas uma experiência de ouro, mas também a melhor formação de equipe. Jogamos muito bem, fizemos loucuras sem dormir e descansar. Estávamos convencidos de que podemos trabalhar produtivamente em tarefas complexas em pouco tempo e em uma situação estressante. O principal é aproveitar o processo!

Se você estiver interessado nos detalhes técnicos da implementação de nossa solução - escreva nos comentários, teremos o prazer de informar.
Não diga adeus, vejo você no centro
Equipe 73 Equipe, Aero Club IT

Equipes de TI da Aeroclub em Moscou viajam hack

All Articles