Se você se lembrar, que recentemente publicou o anúncio da RAIFHACK hackathon , que teve lugar on-line em novembro 14-15 , juntamente com a equipe russa Hackers. Parece que este é um hackathon comum. Mas tinha de tudo: negação, raiva, barganha, depressão, aceitação, piadas e, claro, memes.
A agenda principal da RAIFHACK era criar soluções para pequenas e médias empresas em duas vertentes:
- Saber que o cliente e o concorrente trata do uso de dados. Os participantes desenvolveram um produto no paradigma Data as a Service com base em dados anônimos de clientes.
- “Pagar é fácil” significa usar a API de pagamento rápido. Eles ofereceram soluções úteis para clientes empresariais com base na API SBP do Raiffeisenbank, que simplificará o trabalho com os clientes.
Sobre temas e o próprio hackathon
O atendimento às pequenas e médias empresas é uma área prioritária do nosso banco.
Monitoramos as solicitações dos clientes nesta área e tentamos apresentar imediatamente novos serviços para eles. Estamos falando de soluções de TI padronizadas e flexíveis. Por exemplo, nos tornamos líderes na implementação do sistema de pagamento rápido (FPS) em nossos produtos. Esta é uma das primeiras soluções no mercado russo que permite faturar os clientes diretamente do smartphone do vendedor.
Se falamos de produtos no paradigma Data as a Service, o pano de fundo é o seguinte: em 2019, após vários desenvolvedores personalizados com parceiros de programas de fidelidade, obtivemos a seguinte imagem: a empresa está perfeitamente ciente da falta de informações objetivas sobre seus clientes em um ambiente competitivo real.
Outras pesquisas levaram à criação de nosso produto Data as a Service, semelhante ao modelo SaaS. No seu âmbito, já foram implementados vários business cases, que se baseiam no cruzamento de dados de compras de clientes e dados de comportamento e interesses dos clientes nas redes sociais. Mas essa análise não é o limite, e estamos interessados em quaisquer ideias nesse sentido.
Formato, registro, cronograma
Na RAIFHACK, decidimos não seguir o hackathon clássico, quando as equipes recebem uma tarefa e 24-48-72 horas para concluí-la. Queríamos que os participantes mergulhassem no produto desde o início. Então o CJM era assim:
- registrar-se como uma equipe;
- familiarize-se com a tarefa da pista e envie sua ideia de produto;
- qualificar-se para a final;
- obtenha um conjunto de dados e acesse a API no final, finalize o produto e apresente uma demonstração.
O tópico do hackathon era restrito, mas recebemos mais de 900 registros individuais, mais de 100 decisões de equipe na fase de seleção e 28 equipes chegaram à final.
Talvez a etapa de seleção seja sempre o gargalo de qualquer competição. Sempre haverá projetos de que você mais gostou e projetos que não chegaram ao júri ou não os convenceram. Assim foi conosco - e isso causou um tsunami. A negação começou quando anunciamos os resultados da fase de qualificação.
Tendo recebido 60 ideias na trilha de DaaS e 51 no SBP, começamos a avaliar as aplicações. As soluções foram acompanhadas por mentores de acompanhamento: no mínimo mercearia e técnica + adicional. Já na fase de seleção, avaliamos a viabilidade da solução - por exemplo, na pista DaaS, o componente DS tinha um peso enorme, razão pela qual muitas equipes receberam uma pontuação muito baixa nesta parte. Essas avaliações geraram muita raiva. Para além do facto de alguns projectos terem sido vistos por um maior número de mentores, outros por um número menor e os que despertaram mais interesse receberam uma classificação superior. Em geral, isso corresponde a uma situação real quando uma startup apresenta uma ideia a um investidor.
Não sem reações emocionais :)
Não vamos fingir que somos brancos e fofos - também tínhamos um baseado. Os resultados foram resumidos à pressa e a fórmula era banal em uma das tabelas. Como resultado, lançamos os resultados com um erro. Obrigado aos participantes por perceberem isso, embora seja uma pena. Então, colocamos mais 5 equipes na final da categoria SBP e fomos corretamente repreendidos com a frase "bang-bang - e em produção!"
Você pode discutir interminavelmente sobre o sistema de avaliação de soluções prontas. Temos uma visão, alguns participantes têm outra. A raiva gerou comentários raivosos, memes e desmotivadores (sic!).
Na fase de negociação, apareceu uma petição no change.org para o cancelamento dos resultados do hackathon e até mesmo um convite a todos aqueles que não chegaram à final para se reunirem no Discord para um comício e organizarem seus arremessos independentes. Prevendo a próxima etapa, um dos participantes criou um bot no Telegram para prestar assistência psicológica às vítimas de arbitrariedade judicial.
Apesar de tudo, a final aconteceu e aconteceu de 14 a 15 de novembro. A programação estava extremamente apertada e esperávamos que uma a três equipes simplesmente não chegassem ao fim - isso é normal para tais hackathons. Surpreendentemente, todos nós chegamos ao fim!
Hackathon, codificação e hardcore
O cronograma do hackathon é difícil, o conjunto de dados é enorme, demorou muito para ser cortado e até 3 pontos de controle por mentores e não testados pelas equipes de API. Os participantes tinham que se conectar e entregar o que tinham, caso contrário, a equipe seria removida à distância.
Dividimos todos os pontos de verificação em 3 fases:
- ideia e plano de implementação;
- rascunho de protótipo;
- edição do protótipo + discussão da apresentação.
Cada ponto de verificação é uma demonstração do progresso do desenvolvimento e do recebimento de feedback de dois mentores em uma chamada de 15 a 20 minutos. Um mentor foi responsável pelo produto, o segundo pela componente técnica do projeto. Com base nos resultados da chamada, os mentores decidiram se deveriam ignorar a equipe ou não. Essa abordagem ajudou a planejar melhor o trabalho dos participantes, deu retrospectivas regulares e equipes sincronizadas, e foi mais fácil para os mentores nesse formato acompanhar o progresso.
A grade de pontos de verificação do lado dos mentores era parecida com esta:
Na verdade, os mentores fizeram uma façanha e trabalharam nesse ritmo durante todo o fim de semana. Eles incentivaram as equipes e mantiveram contato com elas. Os próprios participantes notaram isso já no final do hackathon: “Excelente! Os mentores olharam de fora e realmente nos ajudaram a tornar o projeto melhor. Respostas muito detalhadas e amigáveis. "
Algumas equipes enfrentaram problemas técnicos, outras ficaram paralisadas com ideias e uma delas foi totalmente abandonada por dois participantes, incluindo o líder da equipe. Esta equipe tem apenas um desenvolvedor e um designer de 14 anos. Sim, o participante mais jovem da hackatona tinha 14 anos. Era Sveta Simak, ela é de São Petersburgo e todo o evento estava na liderança em nossa lista não oficial do "Prêmio Simpatia Organizacional".
Demonstração e argumentos de venda
Todos assistiram à demonstração. Desta vez decidimos não dividir as atuações e ouvir todas as equipes em uma única transmissão. Foi um experimento e acabou não sendo o mais bem-sucedido, é verdade. Nós mesmos admitimos: 28 apresentações seguidas é demais. Recebemos cinco propostas para dividir as performances em palcos, mas a maioria delas estava bastante interessada em assistir a projetos de outras pessoas.
Nem todas as apresentações correram bem. O tempo era muito apertado: exatamente 5 minutos para um discurso e 2 minutos para perguntas. Em um momento crucial, uma das equipes perdeu totalmente a Internet. Mas todo mundo fez isso, e foi muito legal e interessante! Uma equipe até alugou um "brinde" de venda especial para a apresentação na final!
A avaliação foi feita em uma escala de 10 pontos. O júri teve que se esforçar para destacar os melhores projetos. A escolha foi feita não apenas por um princípio matemático, mas também do ponto de vista de um investidor que vai investir neste ou naquele projeto. Portanto, além dos coeficientes, havia também um fator como a subjetividade, no nível de "gostei - não gostei". Isso permite aproximar as condições do hackathon das condições de uma incubadora de empresas, quando os autores de uma ideia precisam não apenas apresentá-la, mas mostrar sua viabilidade e comprovar subjetivamente suas perspectivas.
Quem ganhou? A seguir, contaremos sobre os projetos que ganharam em suas áreas.
Vencedor do DaaS - Equipe "DS29"
A essência do projeto: um serviço para um conjunto de assinaturas de clientes empresariais do banco com a formação de uma oferta baseada nas transações dos clientes.
Objetivo do projeto: desenvolver um produto no paradigma “Data as a Service” baseado em dados sobre clientes e suas transações.
Como resolvemos o problema: criamos o "PRime" - um serviço de assinatura dos clientes empresariais do banco aos usuários finais. Este é um sistema flexível de grupos de assinaturas, que é formado com base nos dados do cliente sobre as transações, o que permitirá que o banco, os clientes e os usuários finais fiquem no escuro e gastem seu tempo com mais eficiência.
Aqui você pode baixar a apresentação do projeto.
« , , :) , , . , » — , .
« : - , , », — , Data Scientist.
— «LIFE Laboratory»
A essência do projeto: um aplicativo que permite a uma empresa usar o telefone como terminal, processando os pedidos dos clientes por meio de uma interface web.
A tarefa do projeto: desenvolvimento de um sistema para pagamentos rápidos e convenientes através do SBP do banco com a possibilidade de utilizar o módulo NFC de um smartphone - um dispositivo que está sempre à mão.
Perspectivas: desenvolvimento de um verdadeiro site e aplicativo que permitirá aos clientes empresariais oferecerem uma cooperação mutuamente benéfica.
Como resolvemos o problema:implementou a aplicação “NFC for SFP”, que recebe da operadora um código QR com dados incorporados para pagamento. O cliente recebe através de NFC os dados que lhe permitem seleccionar a sua candidatura bancária, bastando depois premir o botão “confirmar pagamento”. Em uma situação normal, o courier deve levar um terminal de pagamento com ele; a maioria dos modelos de tais dispositivos são bastante pesados e inconvenientes, além de caros. É muito mais fácil usar um smartphone com um módulo NFC.
Para o projeto, foram desenvolvidos tanto a própria aplicação como o serviço web, ou melhor, a interface web da aplicação. A interface web da aplicação destina-se ao operador, no qual se forma a encomenda do cliente, é gerado um código QR para pagamento, após o qual tudo é transmitido ao estafeta.
Aqui você pode baixar a apresentação do projeto.
« 500 «», , . , , , , , », — , backend-.
Todas as apresentações das equipes podem ser vistas e avaliadas aqui , e aqui também acontece a cerimônia de premiação .
O prêmio total foi de 500.000 rublos . Em cada faixa para o primeiro lugar, um prêmio em dinheiro de 150.000 rublos foi pago por equipe, e um pacote estendido de mercadorias com a marca de nosso banco foi apresentado. Em segundo lugar, foram pagos 100.000 rublos. Para o terceiro lugar, cada participante recebeu airpods e mercadorias. Todas as outras equipes receberam produtos e nossa gratidão ilimitada por sua participação, e apresentamos chinelos de marca ao criador da petição em change.org, o que o deixou muito feliz :)
Nos vemos no próximo RAIFHACK!