Definitivamente algo saldrá mal, y eso está bien: cómo ganar un hackathon con un equipo de tres

¿Qué composición sueles ir a los hackatones? Inicialmente, declaramos que el equipo ideal consta de cinco personas: un gerente, dos programadores, un diseñador y un vendedor. Pero la experiencia de nuestros finalistas demostró que puedes ganar un hackathon con un pequeño equipo de tres. De los 26 equipos que ganaron la final, 3 compitieron y ganaron con los mosqueteros. ¿Cómo tuvieron éxito? Siga leyendo.



Hablamos con los capitanes de los tres equipos y nos dimos cuenta de que sus estrategias de comportamiento tienen mucho en común. Los héroes de esta publicación son los equipos PLEXeT (Stavropol, nominación del Ministerio de Comunicaciones y Medios de Comunicación), Composite Key (Tula, nominación del Ministerio de Informatización y Comunicaciones de la República de Tatarstán) y Jingu Digital (Ekaterimburgo, nominación del Ministerio de Industria y Comercio). Para aquellos que estén interesados, una breve descripción de los equipos estaba oculta debajo de cat.

Elija una tarea que esté cerca de sus competencias.

¿Recuerdas que había una rima "círculo de drama, círculo en la foto y también quiero cantar cazando"? Creo que muchas personas están familiarizadas con este sentimiento: cuando todo lo que me rodea es interesante, quiero mostrarme de una manera nueva y sentir la nueva industria / esfera de desarrollo. La elección aquí depende solo de los objetivos de su equipo y su disposición a asumir riesgos: ¿puede aceptar su error si de repente se da cuenta en medio del hackatón de que sacar esta tarea no es realista? Experimentos de la categoría de "No hurgo en el desarrollo móvil, pero qué demonios no son bromas": un aficionado. ¿Eres el aficionado?

Artem Koshko ( ashchuk ), equipo de “Clave compuesta” : “Inicialmente planeamos probar algo nuevo. En la etapa regional, probaron varios paquetes nuget, a los que no llegaron las manos, y Yandex.Cloud. En la final, implementamos CockroachDB en Kubernetes, intentamos realizar migraciones a él usando EF Core. Algo salió bien, algo no tan bueno. Así que ambos aprendimos cosas nuevas, nos pusimos a prueba y nos aseguramos de la fiabilidad de los enfoques probados " .

Cómo elegir una tarea si se te escapan los ojos:

• Piense qué competencias se necesitan para resolver este caso y si todos los miembros del equipo las tienen
• Si las competencias no son suficientes, ¿puede compensarlas? (Encuentre una solución diferente, aprenda cosas nuevas rápidamente)
• Realice una breve descripción del mercado para el que hará el producto
• Calcule la competencia: a qué pista / empresa / tarea irá la mayoría de las personas
• Responda la pregunta: ¿qué lo conducirá más?

Oleg Bakhtadze-Karnaukhov ( PLEXeT ), equipo de PLEXeT : “Tomamos una decisión sobre un traslado de diez horas en el aeropuerto, justo al momento del aterrizaje, una lista de pistas y breves formulaciones de tareas cayeron en nuestro correo. Inmediatamente identifiqué cuatro cosas en las que yo, como programador, estoy interesado y que entiendo el plan de acción después del comienzo: lo que hay que hacer y cómo lo haremos. Luego estimó las tareas de cada miembro del equipo y evaluó el nivel de competencia. Como resultado, elegimos entre las tareas de Gazprom y el Ministerio de Comunicaciones. El padre de nuestro diseñador trabaja con la industria del petróleo y el gas. Lo llamamos y le hicimos preguntas sobre la industria. Como resultado, nos dimos cuenta de que sí, es interesante, pero no podemos ofrecer algo fundamentalmente nuevo y no podremos sacarlos en términos de competencias, porque hay demasiados detalles de la industria para considerar. Como resultado, se arriesgaron y fueron a la primera pista ”.

Diana Ganieva ( dirilean ), equipo de Jingu Digital: “En la etapa regional, teníamos una tarea relacionada con la agricultura, y en las finales: AR / VR en la industria. Fueron elegidos por todo el equipo para que cada persona pudiera darse cuenta de sus habilidades. Después de examinar lo que nos pareció no tan interesante ".

Hacer la tarea

Y no estamos hablando de la preparación de código en este momento; hacer esto generalmente no tiene sentido. Se trata de la comunicación del equipo. Si aún no has jugado, no has aprendido a entenderte y a estar de acuerdo, reúnete un par de veces de antemano y modela un hackathon, o al menos ponte en contacto para hablar sobre los puntos principales, pensar un plan de acción y discutir las fortalezas y debilidades de cada uno. Incluso puede encontrar un caso e intentar resolverlo, al menos esquemáticamente, al nivel de "cómo llegar del punto A al punto B".

Para este párrafo, corremos el riesgo de atrapar las desventajas en el karma y los comentarios, diciendo que no entiendes nada, pero qué pasa con la emoción, el impulso, la sensación de que un prototipo nacerá del caldo primario (hola, lecciones de biología).

Sí, pero

La improvisación y el impulso son buenos solo cuando se convierten en una pequeña desviación de la estrategia; de lo contrario, los riesgos son demasiado grandes para pasar el tiempo acumulando caos y arreglando errores, en lugar de trabajar, comer o dormir.

Oleg Bakhtadze-Karnaukhov, equipo de PLEXeT : “No conocía a ninguno de los miembros de mi equipo antes de la competencia: los seleccioné e invité en función de las competencias y evaluaciones en la etapa de las pruebas en línea. Cuando ganamos el hackathon regional y nos dimos cuenta de que todavía teníamos que ir juntos a Kazan y terminar el proyecto de hackathon en Stavropol, decidimos que nos prepararíamos y entrenaríamos. Nos reunimos dos veces antes de la final: encontramos una tarea aleatoria y la resolvimos. Algo así como un campeonato de casos. Y ya en esta etapa vimos un problema en la comunicación y la asignación de tareas, mientras que Polina (diseñadora) y Lev (gerente) estaban pensando en el estilo corporativo, las características del producto, buscando datos del mercado, tenía mucho tiempo libre. Entonces nos dimos cuenta de que necesitamos tomar la nominación más complicada (no me jacto, en su mayoría nos encontramos con tareas relacionadas con la web, y la obtuve para una o dos) y necesito involucrarme más en los procesos de trabajo. Como resultado, al final durante la revisión preliminar, participé en el modelado matemático, desarrollando algoritmos ".

Artyom Koshko, equipo de "Clave compuesta" : "Nos estábamos preparando más mentalmente, ni siquiera estábamos hablando de la preparación del código. También distribuimos roles en el equipo por adelantado: los tres programadores (tenemos una pila completa y dos backends, además estoy un poco revolviendo en el desarrollo móvil), pero estaba claro que alguien tendría que asumir los roles de diseñador y gerente. Entonces, sin ser notado por mí mismo, me convertí en un líder de equipo, me probé como analista de negocios, orador y creador de presentaciones. Creo que si no hubiéramos dicho esto por adelantado, no podríamos asignar el tiempo correctamente y no habríamos llegado a la defensa final ".

Diana Ganieva, Jingu Digital: “No nos preparamos para el hackathon, porque creemos que los proyectos de hack deberían hacerse desde cero, eso es honesto. De antemano, en la etapa de selección de pistas, teníamos un concepto general de lo que queremos hacer " .

En algunos desarrolladores no van

Diana Ganieva, equipo de Jingu Digital : “Tenemos tres especialistas en el equipo en diferentes campos. En mi opinión, esta es la composición perfecta para un hackathon. Todos están ocupados con sus propios negocios y no hay intersecciones y tareas compartidas. Otra persona sería superflua ".

Las estadísticas han demostrado que la composición promedio de nuestros equipos es de 4 a 5 personas, de las cuales (en el mejor de los casos) es un diseñador. En general, se cree que debe fortalecer el equipo con desarrolladores de diferentes bandas, para poder sorprender tanto a la base como a la "máquina". En el mejor de los casos, todavía llevan al diseñador con ellos (¡no se ofendan, los amamos!). La presentación y las interfaces no se procesarán al final. El rol del gerente se descuida aún más a menudo, por lo general, esta función es asumida por el capitán del equipo, desarrollador a tiempo parcial.
Y esto es fundamentalmente incorrecto.

Artem Koshko, equipo de “Clave compuesta” : “En algún momento, lamentamos no haber incluido un especialista en el equipo. Si aún pudimos hacer frente al diseño de alguna manera, entonces fue difícil lidiar con el plan de negocios y otras cosas estratégicas. Un ejemplo vívido es cuando era necesario calcular el público objetivo y el tamaño del mercado, TAM, SAM ".

Oleg Bakhtadze-Karnaukhov, equipo de PLEXeT : “La contribución del desarrollador al producto está lejos del 80% del trabajo, como comúnmente se cree. Esto no quiere decir que fue más fácil para los chicos: casi toda la gama principal de tareas recaía en ellos. Mi código sin interfaces, presentaciones, videos, estrategias es solo un conjunto de personajes. Si hubiera más desarrolladores en el equipo en lugar de ellos, probablemente lo hubiéramos hecho, pero todo habría parecido menos profesional. Especialmente la presentación es generalmente la mitad del éxito, como me parece. Durante la defensa y luego en la vida real en un par de minutos, nadie tendrá tiempo para entender si su prototipo realmente funciona. Si te dejas llevar por los esquemas, nadie te escuchará. Llegas demasiado lejos con el texto: todos entenderán que tú mismo no sabes qué es lo más importante en tu producto, cómo enviarlo y quién lo necesita ".

Gestión del tiempo y descanso.

¿Recuerdas cómo en los dibujos animados, como los héroes de Tom y Jerry, ponían fósforos debajo de los párpados para que no cerraran? Los participantes de hackathon sin experiencia (o demasiado entusiastas) también se ven aproximadamente iguales.

En el hackathon, es fácil perder el contacto con la realidad y el sentido del tiempo: la atmósfera es propicia para la codificación desenfrenada sin descansos para descansar, dormir, revolcarse en el tonto en la sala de juegos, hablar con compañeros o asistir a clases magistrales. Si lo tratas como una Copa del Mundo o una Olimpiada, entonces sí, quizás valga la pena comportarse. En realidad no

Artyom Koshko, equipo de Composite Key : “Teníamos mucho chuck-chuck, mucho: en el centro de nuestra mesa se construyó una torre, nos apoyó el espíritu de lucha y lo apoyó con carbohidratos en el momento adecuado. Descansamos y trabajamos juntos casi todo el tiempo, individualmente no descansamos. Pero dormían de diferentes maneras. A Andrey (desarrollador fullstack) le gusta dormir durante el día, a Denis y a mí nos gusta dormir por la noche. Por lo tanto, trabajé más con Denis durante el día y con Andrey por la noche. Y dormía en descansos. No teníamos ningún tipo de sistema de trabajo y configuración de tareas; más bien, todo fue espontáneo. Pero esto no nos molestó, porque nos entendemos y nos complementamos bien. Ayudó que somos colegas y nos comuniquemos de cerca. Soy un ex interno de Andrey, y Denis vino a la compañía como mi interno ".

Y aquí, por cierto, está la misma montaña de chak-chak.



La gestión competente del tiempo de casi todos los participantes que entrevistamos llamaron el criterio principal para el éxito en el hackathon. ¿Qué significa esto? Distribuye las tareas de tal manera que tenga tiempo para dormir y comer, y las tareas se realizan no en un modo arrugado , sino a un ritmo que sea cómodo para cada miembro del equipo.


Oleg Bakhtadze-Karnaukhov, equipo de PLEXeT : “ Nuestra tarea no era trabajar tantas horas como fuera posible, sino seguir siendo productivos el mayor tiempo posible. Aunque dormimos 3-4 horas al día, parece que hemos tenido éxito. Podríamos ir a la sala de juegos o pasar el rato en los puestos de los socios, reservar un tiempo normal para la comida. El segundo día, tratamos de descargar a Leo tanto como sea posible para que durmiera lo suficiente y se las arreglara antes de la presentación. Los ensayos de Hackathon nos ayudaron, ya que ya entendíamos cómo distribuir las tareas y sincronizar la rutina diaria: comíamos, dormíamos y estábamos despiertos al mismo tiempo. Como resultado, funcionaron como un mecanismo único ".

No sabemos cómo este equipo logró arrastrar Agomoto's Eye al hackathon, pero al final incluso lograron filmar un video sobre el proyecto y preparar un folleto.

Algunos consejos de gestión del tiempo de hackathon:

• Pase de tareas grandes a pequeñas: supere tareas en bloques pequeños.
• Hackathon es un maratón. ¿Qué es lo más importante en un maratón? Intenta correr a un ritmo uniforme, de lo contrario caerás al final de la distancia. Trate de trabajar con aproximadamente la misma intensidad y no se agote.
• Piense de antemano qué se incluirá en las tareas de cada participante y cuánto tiempo dedicará a ello. Ayudará a evitar sorpresas cuando falte media hora para la fecha límite, y no tenga un gran trabajo listo.
• Verifique las coordenadas para ajustar el volumen de tareas. ¿Sientes que te va bien e incluso el tiempo se acaba? Excelente: puede gastarlo en un sueño o finalizar una presentación.
• No vaya en ciclos en detalles, trabaje con trazos anchos.
• Es difícil separarse del trabajo, por lo tanto, reserve un tiempo especial para dormir, descansar o aburrirse. Puede configurar alarmas, por ejemplo.
• Tómese el tiempo para preparar y ensayar el discurso. Es una necesidad para todos y siempre. Hablamos de esto en una de las publicaciones anteriores.

Y hay una opinión tan alternativa. ¿Qué opción tienes: tortura por codificación o guerra por guerra y almuerzo a tiempo?

Diana Ganieva, equipo de Jingu Digital : "Cada persona en el equipo es responsable de una cosa, no había nadie para reemplazarnos, por lo que no podíamos trabajar por turnos. Cuando no quedaba absolutamente ninguna fuerza, dormían durante tres horas, dependiendo de la cantidad de trabajo que le quedaba al participante. No hubo tiempo para pasar el rato, no estamos perdiendo un tiempo precioso en esto. La productividad se mantuvo, aunque sea breve, pero un sueño, y golosinas con té, sin bebidas energéticas ni café ".

Ocultaron varios enlaces útiles debajo del corte, si desea profundizar en el tema de la gestión del tiempo. Será útil en la vida cotidiana: cree al autor de esta publicación, que siempre llega tarde :)

Intenta destacarte

Arriba, escribimos sobre el equipo que hizo el trato para proteger el proyecto. Estaban tan solos en su camino, y estamos seguros de que entre más de 3500 participantes no hubo más.
Por supuesto, esto no se convirtió en la razón principal de su victoria, pero una ventaja adicional definitivamente trajo, al menos, la simpatía de los expertos. Puede destacarse de diferentes maneras: nuestros ganadores solo comienzan cada actuación con una broma de que hicieron una bomba (equipo de Sakharov, ¡hola!).

No nos detendremos en esto en detalle, sino que simplemente compartiremos el caso del equipo PLEXeT: nos parece que es digno de convertirse en una broma sobre el hijo de la novia de su madre.

Oleg Bakhtadze-Karnaukhov, equipo de PLEXeT: “ Entendimos que estábamos adelantados y decidimos que sería genial venir a la pre-defensa con un folleto. El proyecto tiene muchos detalles técnicos, explicaciones de los algoritmos, que están completamente ausentes en la presentación. Y quiero mostrarlo. Los expertos apoyaron la idea e incluso ayudaron a optimizar. Ni siquiera miraron la primera opción, dijeron que nunca leerían ese lienzo. Estábamos tan solos en las defensas ”.

Algo definitivamente saldrá mal, y eso está bien

En el hackathon, como en la vida ordinaria, siempre hay espacio para jambas. Incluso si parece que has previsto todo, ¿cuál de nosotros no llegó tarde al avión / examen / boda simplemente porque los autos decidieron quedarse atascados en el embotellamiento, la escalera mecánica - para descomponerse y el pasaporte - para olvidar en casa?

Oleg Bakhtadze-Karnaukhov, equipo de PLEXeT: “Hice una presentación toda la noche con Polina, pero al final se olvidaron de cargarla en una computadora en el pasillo donde se realizó la defensa. Estamos tratando de abrirlo desde una unidad flash, y el antivirus percibe el archivo como un virus y lo elimina. Como resultado, logramos comenzar todo solo un minuto antes del final de nuestro desempeño. Logramos mostrar el video, pero todavía muy molesto. Una historia similar nos sucedió en la defensa previa. Nuestro prototipo no se inició, las computadoras de Polina y Leo se colgaron, y por alguna razón dejé la mía en el hangar donde se encontraba nuestra pista. Y aunque los expertos vieron nuestro trabajo por la mañana, parecíamos un equipo de excéntricos con un folleto, hermosas palabras, pero sin un producto. Teniendo en cuenta que muchos participantes percibieron mi trabajo en modelos de maquetas como "sentado en algo, dibujando, sin mirar la computadora", la situación no era muy buena ".

Sonará trillado, pero todo lo que puedes hacer en esta situación es exhalar. Ya ha sucedido No, ustedes no son los únicos; todos cortan. Incluso si esto es un error fatal, es la experiencia. Y piénselo, pero ¿la persona que lo evalúa considerará este caso un fakap?

Comparta en los comentarios qué composición le resulta más cómoda para trabajar en el hackathon (tanto en personas como en especialistas) y cómo construir procesos en un equipo.