Que tipo de grupo você costuma frequentar hackathons? Inicialmente, afirmamos que a equipe ideal é composta por cinco pessoas – um gestor, dois programadores, um designer e um profissional de marketing. Mas a experiência dos nossos finalistas mostrou que é possível vencer um hackathon com uma pequena equipe de três pessoas. Das 26 equipes que venceram a final, 3 competiram e venceram com mosqueteiros. Como eles fizeram isso - continue lendo.
Conversamos com os capitães das três equipes e percebemos que a estratégia deles tem muito em comum. Os heróis deste post são as equipes PLEXeT (Stavropol, nomeação do Ministério das Telecomunicações e Comunicações de Massa), “Chave Composta” (Tula, nomeação do Ministério da Informação e Comunicações da República do Tartaristão) e Jingu Digital (Ekaterinburg, nomeação do Ministério da Indústria e Comércio). Para quem estiver interessado, uma breve descrição dos comandos está escondida abaixo do gato.
Descrições de comandosPLEXeT
A equipe conta com três pessoas – um desenvolvedor (web, C++, competências em segurança da informação), um designer e um gerente. Não nos conhecíamos antes do hackathon regional. A equipe foi montada pelo capitão com base nos resultados dos testes online.
Chave composta
A equipe conta com três colegas desenvolvedores – fullstack com dez anos de experiência em TI, backend e mobile, e backend com foco em bancos de dados.
Jingu Digital
A equipe é formada por dois programadores – backend e AR/Unity, além de um designer que também foi responsável pela gestão da equipe. Ganhou na nomeação do Ministério da Indústria e Comércio
Escolha uma tarefa que esteja próxima de suas competências
Você se lembra que existia uma rima “clube de teatro, clube de fotografia, e eu também quero cantar”? Acho que muitas pessoas estão familiarizadas com esse sentimento - quando tudo ao seu redor é interessante, você quer se mostrar de uma nova maneira em sua direção e experimentar uma nova indústria/área de desenvolvimento. A escolha aqui depende apenas dos objetivos de sua equipe e da disposição de correr riscos - você conseguirá aceitar seu erro se de repente, no meio do hackathon, perceber que não é realista resolver esse problema? Experimentos na categoria “Não sou bom em desenvolvimento mobile, mas o que diabos é isso?” não são para todos. Você é o tipo de amador?
Artem Koshko (), comando “Chave composta”: “Inicialmente planejamos tentar algo novo. Na fase regional, tentamos vários pacotes nuget, que nunca tivemos oportunidade, e Yandex.Cloud. No final, implantamos o CockroachDB no Kubernetes e tentamos fazer migrações nele usando o EF Core. Algumas coisas correram bem, outras nem tanto. Assim, aprendemos coisas novas, testamos a nós mesmos e garantimos a confiabilidade de abordagens comprovadas.”.
Como escolher uma tarefa se seus olhos vagarem:
- Pense em quais competências são necessárias para resolver este caso e se todos os membros da equipe as possuem
- Se você não tiver competências, você pode compensá-las (inventar outra solução, aprender algo novo rapidamente)
- Faça uma breve pesquisa do mercado para o qual você estará fabricando um produto
- Calcule a concorrência - para qual curso/empresa/tarefa irá a maioria das pessoas?
- Responda à pergunta: o que mais o motivará?
Oleg Bakhtadze-Karnaukhov (), comando PLEXeT: “Tomamos a decisão de fazer uma escala de dez horas no aeroporto - logo no momento do pouso, uma lista de trilhas e breves declarações de tarefas chegaram pelo correio. Identifiquei imediatamente quatro tarefas que eram interessantes para mim como programador e para as quais o plano de ação após o início era claro - o que precisa ser feito e como o faremos. Depois avaliei as tarefas de cada membro da equipe e avaliei o nível de competição. Como resultado, escolhemos entre as tarefas da Gazprom e do Ministério das Telecomunicações e Comunicações de Massa. O pai do nosso designer trabalha com petróleo e gás; ligamos para ele e fizemos perguntas sobre o setor. No final, percebemos que sim, é interessante, mas não seremos capazes de oferecer nada fundamentalmente novo e definitivamente não seremos capazes de igualar as competências, porque há muitas especificidades do setor que precisam ser levadas em consideração conta. No final, arriscamos e fomos para a primeira pista.”
Diana Ganieva (), Equipe Jingu Digital: “Na fase regional tivemos uma tarefa relacionada com a agricultura, e nas finais - AR/VR na indústria. Eles foram escolhidos por toda a equipe para que cada pessoa pudesse perceber suas habilidades. Depois eliminamos o que não achamos tão interessante.”
Faça sua lição de casa
E não estamos falando sobre preparação de código agora – geralmente é inútil fazer isso. É uma questão de comunicação dentro da equipe. Se vocês ainda não jogaram juntos, não aprenderam a se entender e chegar a um acordo, reúnam-se algumas vezes com antecedência e simulem um hackathon, ou pelo menos liguem para conversar sobre os pontos principais, pense através de um plano de ação e discutir os pontos fortes e fracos de cada um. Você pode até encontrar algum caso e tentar resolvê-lo - pelo menos esquematicamente, no nível de “como ir do ponto A ao ponto B”.
Ao longo deste parágrafo, corremos o risco de pegar pontos negativos no carma e comentários, dizendo, como é possível, você não entende nada, mas e a excitação, o impulso, a sensação de que agora vai nascer um protótipo do primordial caldo (olá, aulas de biologia).
Sim mas.
A improvisação e o impulso só são bons quando se tornam apenas um ligeiro desvio da estratégia - caso contrário, os riscos são demasiado grandes para gastar tempo a limpar o caos e a corrigir erros, em vez de trabalhar, comer ou dormir.
Oleg Bakhtadze-Karnaukhov, equipe PLEXeT: “Não conhecia nenhum dos membros da minha equipe antes da competição; selecionei-os e convidei-os com base nas suas competências e avaliações na fase de testes online. Quando vencemos o hackathon regional e percebemos que ainda tínhamos que ir juntos para Kazan e terminar o projeto do hackathon em Stavropol, decidimos que iríamos nos reunir e treinar. Antes da final, nos encontramos duas vezes - encontramos um problema aleatório e o resolvemos. Algo como um campeonato de casos. E já nesta fase vimos um problema de comunicação e distribuição de tarefas - enquanto a Polina (designer) e o Lev (gerente) pensavam no estilo corporativo, nas características do produto, procuravam dados de mercado, eu tinha muito tempo livre. Então percebemos que precisávamos assumir uma nomeação mais difícil (não estou me gabando, apenas nos deparamos principalmente com tarefas relacionadas à web, mas para mim são apenas uma ou duas) e preciso estar mais envolvido nos processos de trabalho . Como resultado, nas finais, durante a pesquisa preliminar, estive envolvido na modelagem matemática e no desenvolvimento de algoritmos.”
Artem Koshko, equipe de chave composta : “Nos preparamos mais mentalmente, não se falava em preparar um código. Já havíamos atribuído funções na equipe com antecedência - nós três somos todos programadores (temos um full stack e dois backends, além de saber um pouco sobre desenvolvimento mobile), mas estava claro que alguém teria que assumir o papéis de designer e gerente. Foi assim que, sem que eu soubesse, me tornei líder de equipe, tentei ser analista de negócios, palestrante e criador de apresentações. Acho que se não tivéssemos conversado sobre isso com antecedência, não teríamos conseguido administrar o tempo corretamente e não teríamos chegado à defesa final.”
Diana Ganieva, Jingu Digital: “Não nos preparamos para o hackathon porque acreditamos que projetos de hack devem ser feitos do zero – isso é justo. De antemão, na fase de seleção das faixas, tínhamos um conceito geral do que queríamos fazer".
Você não pode trabalhar apenas com desenvolvedores
Diana Ganieva, equipe da Jingu Digital: “Temos três especialistas em diferentes áreas em nossa equipe. Na minha opinião esta é a composição ideal para um hackathon. Todos estão ocupados com seus próprios negócios e não há sobreposição ou divisão de tarefas. Mais uma pessoa seria supérflua.”
As estatísticas mostram que a composição média das nossas equipas é de 4 a 5 pessoas, incluindo (na melhor das hipóteses) um designer. É geralmente aceito que é necessário fortalecer a equipe com desenvolvedores de diferentes matizes - para poder tanto adicionar ao banco de dados quanto surpreender com uma “máquina” caso algo aconteça. Na melhor das hipóteses, eles ainda levam um designer com eles (não se ofenda, nós amamos você!), a apresentação e as interfaces não se desenham sozinhas, no final. O papel de gerente é negligenciado com ainda mais frequência - geralmente essa função é assumida pelo capitão da equipe, um desenvolvedor de meio período.
E isso está fundamentalmente errado.
Artem Koshko, equipe de chave composta: “Em algum momento lamentamos não ter trazido um especialista especializado para a equipe. Embora de alguma forma tenhamos conseguido lidar com o design, foi difícil com o plano de negócios e outras coisas estratégicas. Um exemplo marcante é quando foi necessário calcular o público-alvo e o volume de mercado, TAM, SAM.”
Oleg Bakhtadze-Karnaukhov, equipe PLEXeT: “A contribuição do desenvolvedor para o produto está longe de 80% do trabalho, como comumente se acredita. Não se pode dizer que foi mais fácil para os rapazes - quase toda a parte das tarefas cabia a eles. Meu código sem interfaces, apresentações, vídeos, estratégias é apenas um conjunto de símbolos. Se houvesse mais desenvolvedores na equipe em vez deles, provavelmente teríamos conseguido, mas tudo teria parecido menos profissional. Principalmente a apresentação geralmente é metade do sucesso, como me parece. Durante a defesa e depois na vida real, em alguns minutos, ninguém terá tempo de entender se o seu protótipo realmente funciona. Se você se deixar levar por esquemas, ninguém vai te ouvir. Se você exagerar no texto, todos vão entender que você mesmo não sabe o que é importante no seu produto, como apresentá-lo e quem precisa dele.”
Gerenciamento de tempo e relaxamento
Lembra como em desenhos infantis como “Tom e Jerry” os personagens colocavam fósforos sob as pálpebras para evitar que fechassem? Participantes inexperientes (ou excessivamente entusiasmados) do hackathon têm a mesma aparência.
Em um hackathon, é fácil perder o contato com a realidade e a noção do tempo - a atmosfera é propícia à codificação desenfreada, sem pausas para descanso, sono, brincadeiras na sala de jogos, comunicação com parceiros ou participação em master classes. Se você trata isso como o Campeonato Mundial ou as Olimpíadas, então sim, talvez seja assim que você deva se comportar. Na verdade.
Artem Koshko, equipe de chave composta: “Tomamos muito chak-chak, muito - uma torre dele foi construída no meio da nossa mesa, manteve nosso moral alto e nos deu carboidratos na hora certa. Descansamos e trabalhamos juntos quase o tempo todo, e não descansamos separadamente. Mas eles dormiam de forma diferente. Andrey (desenvolvedor fullstack) gosta de dormir durante o dia, Denis e eu gostamos de dormir à noite. Por isso, trabalhei mais com o Denis durante o dia e com o Andrey à noite. E ele dormia durante os intervalos. Não tínhamos nenhum sistema de trabalho ou definição de tarefas, pelo contrário, tudo era espontâneo. Mas isso não nos incomodou, porque nos entendemos bem e nos complementamos. Ajudou o fato de sermos colegas e nos comunicarmos de perto. Sou ex-estagiário do Andrey e o Denis veio para a empresa como meu estagiário.”
E aqui, aliás, está a mesma montanha chak-chak.
Quase todos os participantes entrevistados apontaram o gerenciamento competente do tempo como o principal critério para o sucesso no hackathon. O que isso significa? Você distribui tarefas para ter tempo para dormir e comer, e as tarefas não são concluídas de maneira regular. tudo desabou, mas em um ritmo confortável para cada membro da equipe.
Oleg Bakhtadze-Karnaukhov, equipe PLEXeT"Nosso objetivo não era trabalhar tantas horas quanto possível, mas permanecer produtivo pelo maior tempo possível. Embora dormíssemos de 3 a 4 horas por dia, parecíamos ter conseguido. Poderíamos ir para a sala de jogos ou passear nos estandes de nossos parceiros e reservar o horário normal para a alimentação. No segundo dia, tentamos aliviar o Lev o máximo possível para que ele dormisse o suficiente e tivesse tempo de se recuperar antes da apresentação. Os ensaios do hackathon nos ajudaram, pois já entendíamos como distribuir tarefas, e a sincronização da rotina diária - comíamos, dormíamos e estávamos acordados ao mesmo tempo. Como resultado, eles funcionaram como um mecanismo único.”
Não sabemos como essa equipe conseguiu levar o Olho de Agomoto para o hackathon, mas no final eles ainda conseguiram gravar um vídeo sobre o projeto e preparar uma apostila.
Algumas dicas para gerenciamento de tempo em um hackathon:
- Vá do grande ao pequeno - divida as tarefas em pequenos blocos.
- Um hackathon é uma maratona. Qual é a coisa mais importante em uma maratona? Tente correr no mesmo ritmo, caso contrário você cairá no final da distância. Tente trabalhar aproximadamente na mesma intensidade e não se esforce até a exaustão.
- Pense com antecedência quais serão as tarefas de cada participante e quanto tempo isso levará. Isso o ajudará a evitar surpresas quando faltar meia hora para o prazo e você não tiver um grande trabalho pronto.
- Verifique as coordenadas para ajustar o escopo das tarefas. Você sente que está indo bem e ainda tem tempo sobrando? Ótimo - você pode gastá-lo dormindo ou finalizando sua apresentação.
- Não se preocupe com detalhes, trabalhe em linhas gerais.
- É difícil fazer uma pausa no trabalho, então reserve um tempo específico para dormir, relaxar ou relaxar. Você pode definir alarmes, por exemplo.
- Reserve um tempo para preparar e ensaiar seu discurso. Isso é obrigatório para todos e sempre. Falamos sobre isso em um dos anteriores .
E há também esta opinião alternativa. Qual opção você prefere - tortura por codificação ou guerra com guerra e almoço dentro do horário?
Diana Ganieva, equipe da Jingu Digital: “Cada pessoa da nossa equipe é responsável por uma coisa, não havia ninguém para nos substituir, então não podíamos trabalhar em turnos. Quando não havia mais forças, dormíamos três horas, dependendo da quantidade de trabalho que ainda restava ao participante. Não houve absolutamente nenhum tempo para sair, não perdemos tempo precioso com isso. A produtividade foi apoiada, embora com sono curto, e guloseimas com chá – sem bebidas energéticas ou café.”
Escondidos sob o corte estão vários links úteis se você quiser se aprofundar no tópico de gerenciamento de tempo. Vai ser útil no dia a dia - acredite no autor deste post, que está sempre atrasado :)
Para os conquistadores do tempo — Técnicas eficazes de gerenciamento de tempo foram coletadas no blog Netology por um gerente de projeto da Kaspersky Lab:
— Um bom artigo para iniciantes no Cossa:
Tente se destacar
Acima escrevemos sobre a equipe que fez uma apostila para proteger o projeto. Eles foram os únicos em sua trajetória e temos certeza de que entre os mais de 3500 participantes não houve outros como eles.
É claro que este não foi o principal motivo da vitória, mas definitivamente trouxe uma vantagem adicional - pelo menos, a simpatia dos especialistas. Você pode se destacar de diferentes maneiras - alguns dos nossos vencedores começam cada apresentação com uma piada sobre como fizeram uma bomba (equipe Sakharov, olá!).
Não vamos nos alongar sobre isso, mas simplesmente compartilharemos um caso da equipe PLEXeT - achamos que vale a pena virar piada sobre o filho da amiga de uma mãe.
Oleg Bakhtadze-Karnaukhov, equipe PLEXeT: “Percebemos que estávamos à frente e decidimos que seria legal entrar na pré-defesa com um caso de transferência. O projeto possui muitos detalhes técnicos, explicações de algoritmos, que não constam de forma alguma na apresentação. Mas eu quero mostrar isso. Os especialistas apoiaram a ideia e até ajudaram a otimizá-la. Eles nem olharam a primeira versão, disseram que nunca leriam tal pintura. Éramos os únicos na defesa.”
Algo está fadado a dar errado e está tudo bem.
Num hackathon, como na vida normal, sempre há espaço para erros. Mesmo que pareça que você já pensou em tudo, quem entre nós não se atrasou para um avião/exame/casamento simplesmente porque os carros resolveram ficar presos no trânsito, a escada rolante resolveu quebrar e o passaporte foi esquecido em casa?
Oleg Bakhtadze-Karnaukhov, equipe PLEXeT: “Polina e eu passamos a noite inteira fazendo uma apresentação, mas no final esqueceram de colocar no computador do salão onde aconteceu a defesa. Tentamos abri-lo a partir de uma unidade flash USB e o antivírus percebe o arquivo como um vírus e o exclui. Como resultado, conseguimos começar tudo apenas um minuto antes do final da nossa apresentação. Conseguimos mostrar o vídeo, mas ainda estávamos muito chateados. Uma história semelhante aconteceu conosco durante a pré-defesa. Nosso protótipo não ligou, os computadores de Polina e Lev travaram e, por algum motivo, deixei o meu no hangar onde estava nossa pista. E embora os especialistas tenham visto nosso trabalho pela manhã, parecíamos uma equipe de excêntricos com uma apostila, palavras bonitas, mas sem produto. Considerando que muitos participantes perceberam meu trabalho com modelos matemáticos como “ele está sentado, desenhando alguma coisa, sem olhar para o computador”, a situação não era muito boa”.
Pode parecer piegas, mas tudo o que você pode fazer nessa situação é expirar. Já aconteceu. Não, você não é o único, todo mundo estraga tudo. Mesmo que seja um erro fatal, é uma experiência. E pense também, quem está avaliando você vai considerar esse caso um fakap?
Compartilhe nos comentários qual composição você se sente mais confortável trabalhando em um hackathon (tanto de pessoas quanto de especialistas) e como você constrói processos em equipe.
Fonte: habr.com