Que tipo de grupo adoita asistir aos hackathons? Inicialmente, afirmamos que o equipo ideal está formado por cinco persoas: un xestor, dous programadores, un deseñador e un comerciante. Pero a experiencia dos nosos finalistas demostrou que é posible gañar un hackathon cun pequeno equipo de tres persoas. Dos 26 equipos que gañaron a final, 3 competiron e gañaron con mosqueteiros. Como o fixeron - segue lendo.
Falamos cos capitáns dos tres equipos e decatámonos de que a súa estratexia ten moito en común. Os heroes desta publicación son os equipos PLEXeT (Stavropol, nomeamento do Ministerio de Telecomunicacións e Comunicacións Masivas), "Chave Composta" (Tula, nomeamento do Ministerio de Información e Comunicacións da República de Tartarstán) e Jingu Digital (Ekaterimburgo, nomeamento do Ministerio de Industria e Comercio). Para aqueles que estean interesados, escóndese unha breve descrición dos comandos baixo o gato.
Descricións de comandosPLEXeT
O equipo ten tres persoas: un programador (web, C++, competencias de seguridade da información), un deseñador e un xestor. Non nos coñeciamos antes do hackathon autonómico. O equipo foi reunido polo capitán en función dos resultados das probas en liña.
Chave composta
O equipo ten tres compañeiros de desenvolvemento: fullstack con dez anos de experiencia en TI, backend e móbil, e backend con foco en bases de datos.
Jingu dixital
O equipo está formado por dous programadores: backend e AR/Unity, así como un deseñador que tamén era responsable da xestión do equipo. Gañada na candidatura do Ministerio de Industria e Comercio
Escolle unha tarefa que se aproxime ás túas competencias
Lembras que había unha rima "club de teatro, club de fotografía, e eu tamén quero cantar"? Creo que moitas persoas están familiarizadas con este sentimento: cando todo o que te rodea é interesante, queres mostrarte dun xeito novo na túa dirección e probar unha nova industria/área de desenvolvemento. A elección aquí depende só dos obxectivos do teu equipo e da vontade de asumir riscos: podes aceptar o teu erro se de súpeto, no medio do hackathon, te das conta de que non é realista resolver este problema? Os experimentos na categoría de "Non son bo no desenvolvemento móbil, pero que diaños é?" non son para todos. Vostede é o tipo de afeccionado?
Artem Koshko (), comando "Clave composta": "Inicialmente tiñamos pensado probar algo novo. Na fase rexional, probamos varios paquetes nuget, que nunca chegamos, e Yandex.Cloud. Ao final, implementamos CockroachDB en Kubernetes e tentamos realizar migracións nel usando EF Core. Algunhas cousas saíron ben, outras non tanto. Así que aprendemos cousas novas, probámonos e asegurámonos da fiabilidade dos enfoques comprobados"..
Como elixir unha tarefa se os teus ollos vagan:
- Pense en que competencias son necesarias para resolver este caso e se as teñen todos os membros do equipo
- Se non tes competencias, podes compensalas (procura outra solución, aprende algo novo rapidamente)
- Realiza unha breve investigación do mercado para o que vai facer un produto
- Calcula a competencia: a que pista/empresa/tarefa acudirá máis xente?
- Responde á pregunta: que é o que máis che vai impulsar?
Oleg Bakhtadze-Karnaukhov (), comando PLEXeT: "Tomamos unha decisión sobre unha escala de dez horas no aeroporto: xusto no momento do aterraxe, chegou ao noso correo unha lista de pistas e breves declaracións de tarefas. Inmediatamente identifiquei catro tarefas que me interesaban como programador e para as que o plan de acción despois do comezo estaba claro: o que hai que facer e como o imos facer. Despois avaliei as tarefas de cada membro do equipo e avaliei o nivel de competición. Como resultado, escollemos entre as tarefas de Gazprom e as do Ministerio de Telecomunicacións e Comunicacións de masas. O pai do noso deseñador traballa en petróleo e gas; chamámoslle e fixémoslle preguntas sobre a industria. Ao final, decatámonos de que si, é interesante, pero non poderemos ofrecer nada fundamentalmente novo e definitivamente non poderemos igualar as competencias, porque hai demasiadas especificidades do sector que hai que ter en conta. conta. Ao final arriscámonos e fomos á primeira pista”.
Diana Ganieva (), equipo Jingu Digital: “Na fase autonómica tivemos unha tarefa relacionada coa agricultura, e nas finais - AR/VR na industria. Foron elixidos por todo o equipo para que cada persoa puidese darse conta das súas capacidades. Despois eliminamos o que non nos pareceu tan interesante".
Fai os deberes
E non estamos a falar de preparación de código agora; xeralmente é inútil facelo. Trátase de comunicación dentro do equipo. Se aínda non xogaron xuntos, non aprenderon a entenderse e chegar a un acordo, reúnense un par de veces antes e simulan un hackathon, ou polo menos chámanse para falar dos puntos principais, pensen mediante un plan de acción e discutir os puntos fortes e débiles dos outros. Incluso podes atopar algún caso e tentar resolvelo, polo menos de forma esquemática, no nivel de "como ir do punto A ao punto B".
Durante este parágrafo, corremos o risco de coller inconvenientes no karma e comentar, dicindo, como é posible, non entendes nada, pero que pasa coa emoción, o impulso, a sensación de que agora nacerá un prototipo do primordial. caldo (ola, clases de bioloxía).
SI, PERO.
A improvisación e a condución son boas só cando se converten só nunha lixeira desviación da estratexia; se non, os riscos son demasiado grandes para pasar o tempo limpando o caos e corrixindo erros, en lugar de traballar, comer ou durmir.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: "Non coñecía a ningún dos membros do meu equipo antes da competición; seleccionei e invitei en función das súas competencias e avaliacións na fase de probas en liña. Cando gañamos o hackathon rexional e nos demos conta de que aínda tiñamos que ir xuntos a Kazán e rematar o proxecto de hackathon en Stavropol, decidimos que nos xuntaríamos e adestraríamos. Antes da final, reunímonos dúas veces: atopamos un problema aleatorio e resolveuno. Algo así como un campionato de casos. E xa nesta fase vimos un problema na comunicación e distribución de tarefas - mentres Polina (deseñador) e Lev (xerente) estaban a pensar no estilo corporativo, características do produto, buscando datos de mercado, eu tiña moito tempo libre. Así que decatámonos de que tiñamos que asumir unha nominación máis difícil (non me presumo, atopámonos sobre todo con tarefas relacionadas coa web, pero para min son só unha ou dúas) e teño que involucrarme máis nos procesos de traballo. . Como resultado, nas finais, durante a investigación preliminar, dediqueime ao modelado matemático e ao desenvolvemento de algoritmos".
Artem Koshko, equipo de clave composta : "Preparámonos máis mentalmente; non se falaba de preparar un código. Xa tiñamos asignados papeis no equipo con antelación: todos somos programadores (temos unha pila completa e dous backends, ademais sei un pouco sobre o desenvolvemento móbil), pero estaba claro que alguén tería que asumir o funcións de deseñador e xestor. Foi así como, sen que eu o saiba, me convertín en xefe de equipo, probei a min mesmo como analista de negocios, orador e creador de presentacións. Creo que se non faláramos disto de antemán, non teriamos sido capaces de xestionar o tempo correctamente e non chegariamos á defensa final".
Diana Ganieva, Jingu Digital: "Non nos preparamos para o hackathon, porque cremos que os proxectos de hackeo deben facerse desde cero, é xusto. Antes, na fase de selección de pistas, tiñamos un concepto xeral do que queriamos facer”.
Non podes traballar só con programadores
Diana Ganieva, equipo Jingu Digital: “Temos tres especialistas en diferentes campos no noso equipo. Na miña opinión, esta é a composición ideal para un hackathon. Todo o mundo está ocupado co seu propio negocio e non hai superposición nin división de tarefas. Unha persoa máis sería superflua".
As estatísticas demostraron que a composición media dos nosos equipos é de 4 a 5 persoas, incluíndo (no mellor dos casos) un deseñador. En xeral, acéptase que é necesario reforzar o equipo con desenvolvedores de diferentes bandas, para poder engadir á base de datos e sorprender cunha "máquina" se ocorre algo. Ao mellor, aínda levan un deseñador consigo (non te ofendas, querémoste!), a presentación e as interfaces non se debuxarán por si mesmas, ao final. O papel dun xestor é descoidado aínda máis a miúdo; normalmente esta función é asumida polo capitán do equipo, un programador a tempo parcial.
E isto é fundamentalmente incorrecto.
Artem Koshko, equipo de clave composta: "Nalgún momento, lamentamos non incorporar ao equipo un especialista especializado. Aínda que dalgún xeito puidemos facer fronte ao deseño, foi difícil co plan de negocio e outras cousas estratéxicas. Un exemplo rechamante é cando foi necesario calcular o público obxectivo e o volume de mercado, TAM, SAM”.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: "A contribución do desenvolvedor ao produto dista moito do 80% do traballo, como se cre habitualmente. Non se pode dicir que fose máis doado para os mozos: case todo o groso das tarefas recaía sobre eles. O meu código sen interfaces, presentacións, vídeos, estratexias é só un conxunto de símbolos. Se houbera máis desenvolvedores no equipo no canto deles, probablemente o conseguiriamos, pero todo parecería menos profesional. Especialmente a presentación é xeralmente a metade do éxito, como me parece. Durante a defensa e despois na vida real nun par de minutos, ninguén terá tempo de entender se o teu prototipo realmente funciona. Se te deixas levar polos esquemas, ninguén te escoitará. Se vas demasiado lonxe co texto, todos entenderán que ti mesmo non sabes o que é importante no teu produto, como presentalo e quen o necesita".
Xestión do tempo e relaxación
Lembras como nos debuxos animados da infancia como "Tom e Jerry" os personaxes poñían mistos debaixo das pálpebras para evitar que se pechen? Os participantes de hackaton sen experiencia (ou demasiado entusiastas) parecen máis ou menos igual.
Nunha hackathon, é fácil perder o contacto coa realidade e a sensación do tempo: a atmosfera propicia unha codificación desenfreada sen descansos, durmir, xogar na sala de xogos, comunicarse cos socios ou asistir a clases maxistrais. Se tratas isto como os Campionatos do Mundo ou os Xogos Olímpicos, entón si, quizais sexa así como deberías comportarte. En realidade non.
Artem Koshko, equipo de clave composta: "Tivemos moito chak-chak, moito: construíuse unha torre no medio da nosa mesa, mantivo a nosa moral alta e deunos carbohidratos no momento adecuado. Descansamos e traballamos case todo o tempo xuntos, e non descansamos por separado. Pero durmían doutro xeito. A Andrey (desenvolvedor fullstack) gústalle durmir durante o día, a Denis e a min gústanos durmir pola noite. Polo tanto, traballei máis con Denis durante o día e con Andrey pola noite. E durmía nos recreos. Non tiñamos ningún sistema de traballo nin de fixación de tarefas, senón que todo era espontáneo. Pero isto non nos molestou, porque nos entendemos ben e complementamos. Axudounos a ser compañeiros e a comunicarnos de preto. Son o antigo pasante de Andrey e Denis chegou á empresa como o meu pasante.
E aquí, por certo, está a mesma montaña chak-chak.
Case todos os participantes que entrevistamos sinalaron a xestión do tempo competente como o principal criterio de éxito no hackathon. Qué significa? Repartes as tarefas para que teñas tempo para durmir e comer, e as tarefas non se realizan de forma regular. todo se derrubou, pero a un ritmo cómodo para cada membro do equipo.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT'O noso obxectivo non era traballar o maior número de horas posible, senón seguir sendo produtivos o maior tempo posible. Aínda que durmíamos 3-4 horas ao día, parecíamos ter éxito. Poderiamos ir á sala de xogos ou pasar un rato nas casetas dos nosos socios e reservar o tempo normal para a comida. O segundo día, intentamos aliviar o máximo posible a Lev para que puidese durmir o suficiente e ter tempo para poñerse en orde antes da actuación. Axudáronnos os ensaios de hackathon, xa que xa entendiamos como repartir as tarefas, e a sincronización da rutina diaria -comíamos, durmíamos e estabamos espertos ao mesmo tempo-. Como resultado, funcionaron como un único mecanismo”.
Non sabemos como este equipo conseguiu que o Ollo de Agomoto chegase ao hackathon, pero ao final ata conseguiron rodar un vídeo sobre o proxecto e preparar un folleto.
Algúns consellos para xestionar o tempo nun hackathon:
- Pasa de grande a pequeno: divide as tarefas en pequenos bloques.
- Un hackathon é un maratón. Que é o máis importante nun maratón? Tenta correr ao mesmo ritmo, se non, caerás ao final da distancia. Intente traballar aproximadamente á mesma intensidade e non esgotarse.
- Pensa con antelación cales serán as tarefas de cada participante e canto tempo lle levará. Axudarache a evitar sorpresas cando o prazo remate a media hora e non tes un gran traballo preparado.
- Comprobe as coordenadas para axustar o alcance das tarefas. Sentes que vai ben e aínda che queda tempo? Genial: podes gastalo en durmir ou finalizar a túa presentación.
- Non te enganches aos detalles, traballa a grandes rasgos.
- É difícil facer un descanso do traballo, así que reserva un tempo específicamente para durmir, relaxarse ou relaxarse. Podes configurar alarmas, por exemplo.
- Dedique tempo a preparar e ensaiar o seu discurso. Isto é obrigatorio para todos e sempre. Disto falamos nunha das anteriores .
E tamén está esta opinión alternativa. Para que opción estás: tortura por codificación ou guerra coa guerra e xantar nun horario?
Diana Ganieva, equipo Jingu Digital: “Cada persoa do noso equipo é responsable dunha cousa, non había ninguén que nos substituíse, polo que non podíamos traballar por quendas. Cando non quedaban absolutamente forzas, durmimos tres horas, dependendo do traballo que lle quedaba ao participante. Non houbo absolutamente tempo para saír, non perdemos un tempo precioso nisto. A produtividade foi apoiada, aínda que cun sono curto, e as golosinas con té, sen bebidas enerxéticas nin café.
Ocultos baixo o corte hai varias ligazóns útiles se queres mergullo no tema da xestión do tempo. Será útil na vida cotiá - crea o autor desta publicación, que sempre chega tarde :)
Para os conquistadores do tempo — Un xestor de proxectos de Kaspersky Lab recompilou técnicas eficaces de xestión do tempo no blog de Netology:
— Un bo artigo para principiantes sobre Cossa:
Intenta destacar
Arriba escribimos sobre o equipo que fixo un folleto para protexer o proxecto. Eran os únicos na súa pista, e estamos seguros de que entre os máis de 3500 participantes non había outros coma eles.
Por suposto, este non foi o motivo principal da súa vitoria, pero definitivamente trouxo unha vantaxe adicional, polo menos, a simpatía dos expertos. Podes destacar de diferentes xeitos: algúns dos nosos gañadores comezan cada actuación cunha broma sobre como fixeron unha bomba (equipo Sakharov, ola!).
Non nos detendremos sobre isto en detalle, senón que simplemente compartiremos o caso do equipo PLEXeT: pensamos que merece converterse nunha broma sobre o fillo do amigo da súa nai.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: "Dámonos conta de que estabamos por diante da curva e decidimos que sería xenial chegar á predefensa cun caso de transferencia. O proxecto ten moitos detalles técnicos, explicacións de algoritmos, que non se inclúen en absoluto na presentación. Pero quero demostralo. Os expertos apoiaron a idea e incluso axudaron a optimizala. Nin sequera miraron a primeira versión, dixeron que nunca lerían un cadro así. Eramos os únicos en defensa".
Algo vai ir mal, e iso está ben.
Nun hackathon, como na vida común, sempre hai lugar para os erros. Aínda que pareza que pensaches en todo, quen de nós non chegou tarde a un avión/examen/voda simplemente porque os coches decidiron quedar atrapados nun atasco, a escaleira mecánica decidiu avariar e o pasaporte quedou esquecido. na casa?
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: “Pola e mais eu pasamos toda a noite facendo unha presentación, pero ao final esquecéronse de subilo ao ordenador do salón onde tivo lugar a defensa. Tentamos abrilo desde unha unidade flash, e o antivirus percibe o ficheiro como un virus e elimínao. Como resultado, conseguimos que todo comezase só un minuto antes do final da nosa actuación. Conseguimos mostrar o vídeo, pero aínda estabamos moi molestos. Unha historia semellante pasounos durante a predefensa. O noso prototipo non comezou, os ordenadores de Polina e Lev conxeláronse e, por algún motivo, deixei o meu no hangar onde estaba a nosa pista. E aínda que os expertos viron o noso traballo pola mañá, parecíamos un equipo de excéntricos cun folleto, palabras bonitas, pero sen produto. Tendo en conta que moitos participantes percibían o meu traballo sobre modelos matemáticos como "el está sentado, debuxando algo, sen mirar o ordenador", a situación non era moi boa".
Soará cursi, pero todo o que podes facer nesta situación é respirar. Xa pasou. Non, non es o único, todo o mundo se puta. Aínda que este sexa un erro fatal, é unha experiencia. E pensa tamén, a persoa que te está a avaliar considerará este caso un fakap?
Comparte nos comentarios que composición te sentes máis cómodo traballando nun hackathon (tanto persoas como especialistas) e como creas procesos nun equipo.
Fonte: www.habr.com