¿Quieres conocer la opinión de los organizadores de «Digital Breakthrough» sobre cómo fue el concurso? En esta publicación no habrá nada sobre la magnitud, el libro de récords, los personajes importantes, los soluciones únicas y la impecable organización. Hablaremos de nuestros principales errores — créenos, no fueron pocos. Pero equivocarse es normal, especialmente si aprendemos de esos errores.
Empecemos desde el principio
Campaña de solicitudes
En lugar de mil solicitudes hay mil preguntas
Seamos sinceros: al principio nos enfrentamos a un problema, nuestra audiencia no entendía del todo cómo funcionaban los hackatones; había muchos novatos entre los participantes que no estaban familiarizados con este formato. Les interesaba la mecánica de la realización de estos eventos, los sistemas de evaluación de proyectos, los criterios para la selección del consejo de expertos y mucho más. Así que, durante las primeras semanas de la campaña de solicitudes, no recogíamos registros, sino una gran cantidad de preguntas sobre varios temas — a menudo ni siquiera relacionadas con el concurso en sí.
De esto aprendimos que antes de lanzar la recogida de solicitudes, es necesario comunicarse mucho con los posibles participantes — sumergirlos en la especificidad del evento y responder a preguntas sobre todas las etapas que vendrán.
En general, es esencial trabajar de manera más activa con la comunidad tecnológica, que está más interesada no en los últimos logros de las empresas asociadas, sino en las noticias sobre el progreso del concurso — ¿por qué eligieron el formato de hackatón? ¿Cómo se adapta a nuestro concurso? ¿Cómo será la prueba en línea? Vaya, la prueba en línea ha comenzado — ¿qué se hace a continuación? Espera, no entiendo — hice el test, pero no hay resultados. ¿Cuándo habrá? ¿Y qué tareas habrá en las etapas regionales? ¿Quién las establece? ¿Y quién estará en el consejo de expertos? ¿Cómo se seleccionaron?
Y así sucesivamente.
La lección principal: no es suficiente simplemente decir: «Hola, somos un concurso para gerentes, especialistas en IT y diseñadores. Participa pronto. Ah, por cierto, será en formato de hackatón». Es necesario explicar todo en detalle y por etapas.
Prueba en línea
¿Errores en las pruebas o diferentes personas entendiendo mal la tarea?
En la etapa de pruebas en línea, nuestras redes sociales se inundaron de mensajes descontentos sobre errores en las tareas. El problema era que los mismos textos de las tareas eran percibidos de manera diferente por especialistas de distintas áreas. Todo dependía de cómo llegaron a la profesión: si se formaron de manera autodidacta o contaban con amplios conocimientos académicos y una educación formal. La percepción de la semántica y la lingüística varía considerablemente entre ellos, lo que debía tenerse en cuenta al elaborar las pruebas.
La principal lección: la próxima vez planeamos reunir grupos focales regionales compuestos por especialistas de diferentes perfiles. Ellos ayudarán a formular tareas específicas para cada región.
Etapas regionales
En verano hay que descansar
El primer error fue elegir el verano para llevar a cabo las etapas regionales — la temporada de vacaciones y vacaciones estudiantiles, por lo que en algunas ciudades participaron muy pocas personas en el hackatón.
Por esta razón, tuvimos que reducir el número de nominaciones, lo que obligó a los equipos a renunciar a aquellas tareas que inicialmente querían resolver. Sin embargo, en aquellas ciudades donde no había tantos participantes, se lograron resolver todas las tareas con gran éxito y demostraron que se pueden hacer buenas soluciones con un grupo reducido. Así ocurrió, por ejemplo, en Yakutsk y Veliky Novgorod — allí llegaron a la final todos los equipos que inicialmente participaron en el hackatón.
La principal lección: ¿Y si no en verano?
Particularidades de cada región
Las condiciones en las que se llevaron a cabo los hackatones regionales dependían en gran medida del socio local que apoyaba el concurso. Por lo tanto, en algunos lugares fue mejor, mientras que en otros, fue peor. No todos entendían la especificidad de este tipo de eventos y por qué la gente trabaja 24/7, duerme en puff o tiendas de campaña, y se alimenta de bollos de la cafetería. Por eso, hubo algunos fallos en ciertos aspectos.
Expresamos un gran agradecimiento a las universidades — nos ayudaron con el lugar, expertos, invitación de medios de comunicación y la recopilación de participantes. Trabajar con ellos nos ayudó a entender mejor la especificidad de las regiones — en el futuro, esto hará que nuestra colaboración sea más efectiva.
La principal lección: en la próxima temporada es necesario organizar el trabajo en las regiones con más detalle y confiar más en nosotros mismos y nuestra experiencia, en lugar de depender de los socios locales.
En las regiones se percibe la información de manera diferente.
Los canales de atracción de participantes en ciudades de un millón de habitantes y en regiones funcionan de manera completamente diferente. Por ejemplo, en Moscú y San Petersburgo, basta con lanzar publicidad en redes sociales y hacer 'siembra' en grupos donde se encuentra la audiencia objetivo, mientras que en las regiones, el boca a boca y los llamados a participar por parte de 'influencers' locales (administraciones regionales, bloggers, universidades, comunidades de TI) funcionan de manera más efectiva.
La principal lección: aumentar la cantidad de canales a través de los cuales trabajaremos con la audiencia. Atraer más líderes de opinión, bloggers locales.
Confundieron con formulaciones vagas de las tareas.
¿Qué puede frustrar e incluso enojar más a los participantes de un hackatón? Por supuesto, tareas aburridas y poco elaboradas. En la fase regional y final, los equipos se quejaron de que las formulaciones de las tareas a menudo no sonaban claras ni transparentes.
A lo largo del concurso, siempre tratamos de seguir la regla: plantea la tarea de manera adecuada => obtén una solución de calidad. Pero admitimos que no siempre fue así. En condiciones donde había muchas tareas y para cada una se proporcionaban sus propios conjuntos de datos… sucedieron fallos. Pero todo se compensó con la ayuda de expertos que no se alejaron ni un paso de los equipos, respondieron todas las preguntas y trabajaron todos los aspectos de los proyectos. Esto fue lo que influyó en la calidad de los prototipos que resultaron.
La principal lección: Para la formulación de tareas, contaremos con la ayuda de especialistas que entienden profundamente las tecnologías con las que los participantes deberán trabajar. Por ejemplo, si planteamos una tarea sobre el desarrollo de una aplicación de AR para interiores, necesitaremos un experto que ya haya utilizado la realidad aumentada para soluciones similares.
Intenté no escribir mucho, pero aún así me parece que la entrada resultó bastante larga. Las demás características de unRAID son bastante simples de configurar, sobre todo porque todo se configura con el ratón.
«¡Hola! Pronto será el hackatón, pero no nos han enviado las entradas», o problemas de logística.
A algunos participantes se les envió tarde la información sobre cómo se organizará su transporte hacia la final. Esto provocó una avalancha de preguntas, y nosotros, como organizadores, nos vimos bajo un verdadero bombardeo. No vamos a trasladar la culpa a nadie; el equipo del proyecto, sin duda, es responsable de todos los retrasos. La mayoría de las veces, estos estuvieron relacionados con que en muchos casos pedimos ayuda a las regiones, pero cada una pudo organizar la logística en diferentes tiempos. En el futuro, planearemos asignar más tiempo para esto.
La principal lección: Es necesario informar constantemente a los participantes sobre en qué etapa se encuentra la compra de boletos, la reserva de hoteles y otras operaciones. Esto les ayudará a estar más tranquilos y simplemente esperar a que les lleguen los documentos anhelados por correo.
Y, por supuesto, Guinness
Inicialmente, no teníamos como objetivo entrar en el Libro de los récords Guinness. Pero durante las etapas regionales empezamos a darnos cuenta de que teníamos todas las posibilidades, y más cerca de la final decidimos: '¡Lo haremos, colegas!'. Todo iba muy bien, hasta que los representantes del Libro de los récords Guinness anunciaron que los participantes del hackatón debían permanecer en el lugar todo un día laboral (12 horas) sin salir. Solo podían abandonar el lugar durante 40 minutos. Esto afectó el modo estándar de organización de la alimentación y el régimen de acceso, lo que provocó la indignación de los participantes.
La principal lección: Ahora preguntaremos de inmediato sobre todas las dificultades que puedan surgir de diversas actividades en el marco del concurso, e informaremos a los participantes sobre ellas por adelantado.
Compartan en los comentarios, ¿qué errores más se han notado en la organización del concurso? ¡Siempre estamos listos para trabajar en la mejora de resultados!
Fuente: habr.com
