¿A qué tipo de grupo sueles asistir en los hackathons? Inicialmente dijimos que el equipo ideal está formado por cinco personas: un gerente, dos programadores, un diseñador y un comercializador. Pero la experiencia de nuestros finalistas demostró que se puede ganar un hackathon con un pequeño equipo de tres personas. De los 26 equipos que ganaron la final, 3 compitieron y ganaron con mosqueteros. Cómo lo hicieron - sigue leyendo.
Hablamos con los capitanes de los tres equipos y nos dimos cuenta de que su estrategia tiene mucho en común. Los héroes de esta publicación son los equipos PLEXeT (Stavropol, nominación del Ministerio de Telecomunicaciones y Comunicaciones Masivas), “Composite Key” (Tula, nominación del Ministerio de Información y Comunicaciones de la República de Tartaristán) y Jingu Digital (Ekaterimburgo, nombramiento del Ministerio de Industria y Comercio). Para aquellos que estén interesados, debajo del gato se esconde una breve descripción de los comandos.
Descripciones de comandosPLEXET
El equipo está formado por tres personas: un desarrollador (web, C++, competencias de seguridad de la información), un diseñador y un director. No nos conocíamos antes del hackathon regional. El equipo fue formado por el capitán basándose en los resultados de las pruebas en línea.
Clave compuesta
El equipo cuenta con tres compañeros desarrolladores: fullstack con diez años de experiencia en TI, backend y dispositivos móviles, y backend centrado en bases de datos.
Jingu Digital
El equipo está formado por dos programadores: backend y AR/Unity, además de un diseñador que también era responsable de la gestión del equipo. Ganado en la nominación del Ministerio de Industria y Comercio.
Elija una tarea que se acerque a sus competencias
¿Recuerdas que había una rima como “club de teatro, club de fotografía y yo también quiero cantar”? Creo que mucha gente está familiarizada con este sentimiento: cuando todo lo que te rodea es interesante, quieres mostrarte de una manera nueva en tu dirección y probar una nueva industria/área de desarrollo. La elección aquí depende únicamente de los objetivos de su equipo y de su voluntad de asumir riesgos. ¿Puede aceptar su error si de repente, en medio del hackathon, se da cuenta de que no es realista resolver este problema? Los experimentos en la categoría "No soy bueno en desarrollo móvil, pero ¿qué diablos es?" no son para todos. ¿Eres el tipo de aficionado?
Artem Koshko (), comando “Clave compuesta”: “Inicialmente planeamos probar algo nuevo. En la etapa regional, probamos varios paquetes Nuget, que nunca conseguimos, y Yandex.Cloud. Al final, implementamos CockroachDB en Kubernetes e intentamos implementar migraciones usando EF Core. Algunas cosas salieron bien, otras no tanto. Así que aprendimos cosas nuevas, nos probamos y nos aseguramos de la confiabilidad de enfoques probados”..
Cómo elegir una tarea si tus ojos se desvían:
- Piense qué competencias se necesitan para resolver este caso y si todos los miembros del equipo las tienen.
- Si le faltan competencias, ¿puede compensarlas? (idee otra solución, aprenda rápidamente algo nuevo)
- Realice una breve investigación del mercado para el que fabricará un producto.
- Calcule la competencia: ¿a qué rama/empresa/tarea irá la mayor parte de la gente?
- Responde la pregunta: ¿qué es lo que más te motivará?
Oleg Bakhtadze-Karnaukhov (), comando PLEXeT: “Tomamos la decisión de hacer una escala de diez horas en el aeropuerto; justo en el momento del aterrizaje, llegó a nuestro correo una lista de rutas y una breve descripción de las tareas. Inmediatamente identifiqué cuatro tareas que me interesaban como programador y para las cuales el plan de acción después del inicio era claro: qué se debe hacer y cómo lo haremos. Luego evalué las tareas de cada miembro del equipo y evalué el nivel de competencia. Como resultado, elegimos entre las tareas de Gazprom y del Ministerio de Telecomunicaciones y Comunicaciones Masivas. El padre de nuestro diseñador trabaja en petróleo y gas; lo llamamos y le hicimos preguntas sobre la industria. Al final nos dimos cuenta de que sí, es interesante, pero no podremos ofrecer nada fundamentalmente nuevo y definitivamente no podremos igualar las competencias, porque hay demasiadas especificidades de la industria que deben tenerse en cuenta. cuenta. Al final nos arriesgamos y salimos a la primera pista”.
Diana Ganieva (), equipo de Jingu Digital: “En la etapa regional tuvimos una tarea relacionada con la agricultura, y en la final, AR/VR en la industria. Fueron elegidos por todo el equipo para que cada uno pudiera desarrollar sus habilidades. Luego eliminamos lo que no nos pareció tan interesante”.
Haz tu tarea
Y no estamos hablando ahora de preparación de código; generalmente no tiene sentido hacerlo. Se trata de comunicación dentro del equipo. Si aún no han jugado juntos, no han aprendido a entenderse y llegar a un acuerdo, reunirse un par de veces antes y simular un hackathon, o al menos llamarse para hablar sobre los puntos principales, piense a través de un plan de acción y discutir las fortalezas y debilidades de cada uno. Incluso puedes encontrar algún caso e intentar resolverlo, al menos esquemáticamente, en el nivel de "cómo llegar del punto A al punto B".
Durante este párrafo, corremos el riesgo de captar desventajas en el karma y los comentarios, diciendo, cómo es posible, no entiendes nada, pero ¿qué pasa con la emoción, el impulso, la sensación de que ahora nacerá un prototipo del primordial? caldo (hola, lecciones de biología).
Sí, pero.
La improvisación y el impulso sólo son buenos cuando se convierten en sólo una ligera desviación de la estrategia; de lo contrario, los riesgos son demasiado grandes como para dedicar tiempo a limpiar el caos y corregir errores, en lugar de trabajar, comer o dormir.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: “No conocía a ninguno de los miembros de mi equipo antes de la competencia; los seleccioné e invité en función de sus competencias y evaluaciones en la etapa de prueba en línea. Cuando ganamos el hackathon regional y nos dimos cuenta de que todavía teníamos que ir juntos a Kazán y terminar el proyecto del hackathon en Stavropol, decidimos reunirnos y entrenar. Antes de la final nos encontramos dos veces: encontramos un problema aleatorio y lo resolvimos. Algo así como un campeonato de casos. Y ya en esta etapa vimos un problema en la comunicación y distribución de tareas: mientras Polina (diseñadora) y Lev (gerente) pensaban en el estilo corporativo, las características del producto, buscaban datos de mercado, yo tenía mucho tiempo libre. Entonces nos dimos cuenta de que necesitábamos asumir una nominación más difícil (no estoy alardeando, la mayoría de las veces nos topamos con tareas relacionadas con la web, pero para mí son solo una o dos) y necesito involucrarme más en los procesos de trabajo. . Como resultado, en la final, durante la investigación preliminar, me dediqué al modelado matemático y al desarrollo de algoritmos”.
Artem Koshko, equipo de clave compuesta : “Nos preparamos más mentalmente, no se habló de preparar un código. Ya habíamos asignado roles en el equipo de antemano: los tres somos programadores (tenemos una pila completa y dos backends, además sé un poco sobre desarrollo móvil), pero estaba claro que alguien tendría que hacerse cargo del roles de diseñador y gerente. Así, sin saberlo, me convertí en líder de equipo, me probé como analista de negocios, orador y creador de presentaciones. Creo que si no hubiésemos hablado de esto con antelación, no habríamos podido gestionar el tiempo correctamente y no hubiéramos llegado a la defensa final”.
Diana Ganieva, Jingu Digital: “No nos preparamos para el hackathon porque creemos que los proyectos de hack deben realizarse desde cero, eso es justo. De antemano, en la etapa de selección de pistas, teníamos un concepto general de lo que queríamos hacer"..
No puedes trabajar solo con desarrolladores
Diana Ganieva, equipo de Jingu Digital: “Tenemos tres especialistas en diferentes campos en nuestro equipo. En mi opinión, esta es la composición ideal para un hackathon. Cada uno está ocupado con sus propios asuntos y no hay superposición ni división de tareas. Una persona más sería superflua”.
Las estadísticas muestran que la composición media de nuestros equipos es de 4 a 5 personas, incluido (en el mejor de los casos) un diseñador. En general, se acepta que es necesario fortalecer el equipo con desarrolladores de diferentes tipos para poder agregar a la base de datos y sorprender con una "máquina" si sucede algo. En el mejor de los casos, todavía llevan consigo un diseñador (¡no te ofendas, te queremos!), la presentación y las interfaces no se dibujarán solas al final. El papel de gerente se descuida aún más a menudo; normalmente esta función la asume el capitán del equipo, un desarrollador a tiempo parcial.
Y esto es fundamentalmente incorrecto.
Artem Koshko, equipo de clave compuesta: “En algún momento lamentamos no haber incorporado al equipo a un especialista especializado. Si bien de alguna manera pudimos hacer frente al diseño, fue difícil con el plan de negocios y otras cosas estratégicas. Un ejemplo sorprendente es cuando fue necesario calcular el público objetivo y el volumen de mercado, TAM, SAM”.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: “La contribución del desarrollador al producto está lejos del 80% del trabajo, como comúnmente se cree. No se puede decir que a los muchachos les resultó más fácil: casi la mayor parte de las tareas recaían en ellos. Mi código sin interfaces, presentaciones, videos, estrategias es solo un conjunto de símbolos. Si hubiera habido más desarrolladores en el equipo en lugar de ellos, probablemente lo habríamos logrado, pero todo habría parecido menos profesional. Especialmente la presentación es, en general, la mitad del éxito, según me parece. Durante la defensa y luego en la vida real, después de un par de minutos, nadie tendrá tiempo de comprender si su prototipo realmente funciona. Si te dejas llevar por los esquemas, nadie te escuchará. Si se excede con el texto, todos entenderán que usted mismo no sabe qué es importante en su producto, cómo presentarlo y quién lo necesita”.
Gestión del tiempo y relajación.
¿Recuerdas cómo en dibujos animados infantiles como “Tom y Jerry” los personajes se ponían cerillas debajo de los párpados para evitar que se cerraran? Los participantes inexpertos (o demasiado entusiastas) del hackathon tienen el mismo aspecto.
En un hackathon, es fácil perder el contacto con la realidad y el sentido del tiempo: el ambiente es propicio para la codificación desenfrenada, sin pausas para descansar, dormir, jugar en la sala de juegos, comunicarse con socios o asistir a clases magistrales. Si tratas esto como si fuera el Campeonato Mundial o los Juegos Olímpicos, entonces sí, tal vez así es como deberías comportarte. No precisamente.
Artem Koshko, equipo de clave compuesta: “Tomamos mucho chak-chak, mucho; se construyó una torre en el medio de nuestra mesa, mantenía nuestra moral alta y nos daba carbohidratos en el momento adecuado. Descansábamos y trabajábamos casi todo el tiempo juntos y no descansábamos por separado. Pero durmieron de manera diferente. A Andrey (desarrollador fullstack) le gusta dormir durante el día, a Denis y a mí nos gusta dormir por la noche. Por eso trabajaba más con Denis durante el día y con Andrey por la noche. Y dormía durante los descansos. No teníamos ningún sistema de trabajo ni de fijación de tareas, sino que todo era espontáneo. Pero esto no nos molestó, porque nos entendemos bien y nos complementamos. Ayudó que seamos colegas y nos comuniquemos estrechamente. Soy el antiguo pasante de Andrey y Denis llegó a la empresa como mi pasante”.
Y aquí, por cierto, está la misma montaña chak-chak.
Casi todos los participantes que entrevistamos mencionaron la gestión competente del tiempo como el principal criterio para el éxito en el hackathon. ¿Qué significa? Distribuye las tareas para tener tiempo para dormir y comer, y las tareas no se completan de manera regular. todo se derrumbó, pero a un ritmo que resulte cómodo para cada miembro del equipo.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT"Nuestro objetivo no era trabajar tantas horas como fuera posible, sino seguir siendo productivo el mayor tiempo posible. Aunque dormíamos entre 3 y 4 horas al día, parecía que lo conseguíamos. Podríamos ir a la sala de juegos o pasar el rato en los stands de nuestros socios y reservar un tiempo normal para la comida. El segundo día intentamos relevar a Lev tanto como fuera posible para que pudiera dormir lo suficiente y tener tiempo de ponerse en orden antes de la actuación. Los ensayos del hackathon nos ayudaron, porque ya entendíamos cómo distribuir las tareas y la sincronización de la rutina diaria: comíamos, dormíamos y estábamos despiertos al mismo tiempo. Como resultado, funcionaron como un solo mecanismo”.
No sabemos cómo este equipo logró que Agomoto's Eye asistiera al hackathon, pero al final incluso lograron grabar un video sobre el proyecto y preparar un folleto.
Algunos consejos para gestionar el tiempo en un hackathon:
- Vaya de grande a pequeño: divida las tareas en bloques pequeños.
- Un hackathon es un maratón. ¿Qué es lo más importante en un maratón? Intenta correr al mismo ritmo, de lo contrario te caerás al final de la distancia. Intente trabajar aproximadamente con la misma intensidad y no se esfuerce hasta el agotamiento.
- Piensa de antemano cuáles serán las tareas de cada participante y cuánto tiempo le llevará. Te ayudará a evitar sorpresas cuando falte media hora para la fecha límite y no tengas un gran trabajo listo.
- Verifique las coordenadas para ajustar el alcance de las tareas. ¿Sientes que vas bien e incluso te queda tiempo? Genial, puedes gastarlo en dormir o finalizar tu presentación.
- No te obsesiones con los detalles, trabaja a grandes rasgos.
- Es difícil tomar un descanso del trabajo, así que reserva un tiempo específicamente para dormir, relajarte o relajarte. Puedes configurar alarmas, por ejemplo.
- Tómese el tiempo para preparar y ensayar su discurso. Esto es obligatorio para todos y siempre. Hablamos de esto en uno de los anteriores. .
Y también existe esta opinión alternativa. ¿Qué opción prefieres: torturar mediante codificación o guerra con guerra y almorzar según un horario?
Diana Ganieva, equipo de Jingu Digital: “Cada persona en nuestro equipo es responsable de una cosa, no había nadie que nos reemplazara, por lo que no podíamos trabajar por turnos. Cuando ya no nos quedaban fuerzas, dormíamos tres horas, dependiendo de la cantidad de trabajo que aún le quedaba al participante. No hubo absolutamente ningún tiempo para pasar el rato, no perdemos un tiempo precioso en esto. La productividad se vio favorecida, aunque con poco sueño y golosinas con té, sin bebidas energéticas ni café”.
Escondidos debajo del corte hay varios enlaces útiles si desea profundizar en el tema de la gestión del tiempo. Te resultará útil en la vida cotidiana; cree en el autor de esta publicación, que siempre llega tarde :)
Para los conquistadores del tiempo — Un director de proyectos de Kaspersky Lab recopiló técnicas eficaces de gestión del tiempo en el blog Netology:
— Un buen artículo para principiantes sobre Cossa:
Intenta destacar
Arriba escribimos sobre el equipo que hizo una donación para proteger el proyecto. Eran los únicos en su pista y estamos seguros de que entre los más de 3500 participantes no había otros como ellos.
Por supuesto, esta no fue la razón principal de su victoria, pero definitivamente trajo una ventaja adicional: al menos, la simpatía de los expertos. Puedes destacar de diferentes maneras: algunos de nuestros ganadores comienzan cada actuación con una broma sobre cómo hicieron una bomba (equipo Sajarov, ¡hola!).
No nos detendremos en esto en detalle, simplemente compartiremos un caso del equipo de PLEXeT: creemos que es digno de convertirse en una broma sobre el hijo de una amiga de su madre.
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: “Nos dimos cuenta de que estábamos por delante y decidimos que sería genial llegar a la predefensa con una caja de transferencia. El proyecto tiene muchos detalles técnicos, explicaciones de algoritmos, que no están incluidos en la presentación en absoluto. Pero quiero mostrarlo. Los expertos apoyaron la idea e incluso ayudaron a optimizarla. Ni siquiera miraron la primera versión; dijeron que nunca leerían un cuadro así. Éramos los únicos en defensa”.
Es probable que algo salga mal y está bien.
En un hackathon, como en la vida cotidiana, siempre hay lugar para errores. Aunque parezca que has pensado en todo, ¿quién de nosotros no ha llegado tarde a un avión/examen/boda simplemente porque los coches decidieron quedarse atascados en un atasco, la escalera mecánica se estropeó y se olvidó el pasaporte? ¿en casa?
Oleg Bakhtadze-Karnaukhov, equipo PLEXeT: “Polina y yo pasamos toda la noche haciendo una presentación, pero al final se olvidaron de cargarla en la computadora del salón donde se realizó la defensa. Intentamos abrirlo desde una unidad flash y el antivirus percibe el archivo como un virus y lo elimina. Como resultado, logramos que todo comenzara solo un minuto antes del final de nuestra actuación. Logramos mostrar el video, pero aún así estábamos muy molestos. Una historia similar nos pasó durante la predefensa. Nuestro prototipo no arrancó, las computadoras de Polina y Lev se congelaron y, por alguna razón, dejé la mía en el hangar donde estaba 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 ningún producto. Teniendo en cuenta que muchos participantes percibieron mi trabajo con modelos matemáticos como "él está sentado, dibujando algo, sin mirar la computadora", la situación no era muy buena.
Sonará cursi, pero lo único que puedes hacer en esta situación es exhalar. Ya sucedió. No, no eres el único, todos meten la pata. Incluso si esto es un error fatal, es una experiencia. Y piense también, ¿la persona que lo está evaluando considerará este caso como un fraude?
Comparte en los comentarios con qué composición te sientes más cómoda trabajando en un hackathon (tanto personas como especialistas) y cómo construyes procesos en equipo.
Fuente: habr.com