Construyendo un Hackathon Mejor: Cuatro Principios Básicos del LiveOps Hack Day
Keith McFarlane, arquitecto jefe Keith McFarlane, arquitecto jefe

Recientemente celebramos nuestro undécimo evento LiveOps Hack Day, y fue algo especial; una serie de ideas realmente interesantes cobraron vida en tan solo 24 horas gracias a los esfuerzos de algunos equipos e individuos muy apasionados y dedicados. Algunos de los trucos que se mostraron en el momento de la demostración fueron:

  • Pivot to Video: el equipo involucrado en este encontró una manera de mover una conversación de chat de agente en vivo al mundo del video usando tokbox.
  • Visualización multicanal: nuestro equipo de informes presentó una nueva forma de ver los flujos de trabajo superpuestos que maneja un agente mientras maneja varios elementos de trabajo simultáneamente.
  • Agent Telephony in-Browser: el ingeniero mostró la integración de nuestra aplicación de panel de teléfono de agente con TwilioEl cliente basado en JavaScript de , que permite llamadas de voz usando solo una PC.
  • Flujo de llamadas programable: algunos de nuestros ingenieros de plataforma encontraron una forma ingeniosa de controlar las funciones granulares de telefonía a través de la API REST.
Este es solo un subconjunto de los proyectos completados esta vez; estos y otros pueden convertirse en productos en un futuro no muy lejano.

Hemos trabajado para mejorar el Hack Day a lo largo de los años desde que celebramos el primer evento, y aunque hemos realizado muchos cambios incrementales, también hemos identificado un conjunto de principios básicos que pueden hacer o deshacer el evento dependiendo de qué tan de cerca se sigan.

1) Los grandes hacks vienen del corazón, no del backlog

Con demasiada frecuencia, he visto a ingenieros o gerentes de productos tratar de usar el Hack Day como una excusa para acelerar sus artículos pendientes favoritos. Si bien esto ciertamente logra algo útil, anula el verdadero propósito del evento: la innovación. Los desarrolladores deberían usar este tiempo para perseguir sus sueños de software más salvajes y probar nuevas tecnologías. Lo mismo es cierto para los gerentes de producto; deben asociarse con desarrolladores para integrarse con otros servicios web de formas inesperadas, o intentar definir e implementar una idea que parecería arriesgada en circunstancias normales. Debería ser una oportunidad para la exploración, no los negocios habituales en un orden ligeramente diferente.

Para los desarrolladores, elegir un elemento de la cartera de pedidos como su proyecto de hack day es esencialmente ignorar las prioridades del equipo de gestión de productos. Piense en todo el pensamiento y la discusión que se han llevado a cabo para obtener el orden correcto de las historias para su scrum, y luego imagine ignorar todo ese trabajo y seleccionar historias al azar. Está claro que lo primero es preferible a lo segundo.

Hack Day se trata de permitir que surjan grandes ideas de lugares inesperados. Sin énfasis en la búsqueda de nuevas ideas en lugar de las existentes, pierde la mayor parte de su valor.

2) Foco, foco, foco; fluencia de alcance mata hacks muertos

Si bien cualquier idea nueva debería ser un juego justo para el día de la piratería, he notado que los mayores éxitos provienen de esfuerzos pequeños y enfocados que tienen como objetivo completar una función menor pero valiosa, o demostrar un concepto grande a través de un ejemplo bien definido que es de alcance limitado. A menudo, proyectos como este pueden lograr el éxito temprano y luego agregar funciones a medida que el tiempo lo permita. Además, debido a que las condiciones de victoria están bien definidas, el equipo puede abandonar el truco si resulta demasiado complejo y cambiar su enfoque a otra idea.

Todos los desarrolladores tienen "grandes conceptos" dando vueltas en la cabeza; desafortunadamente, estos pueden ser los más difíciles de construir, incluso en forma limitada, como parte del Hack Day. Si desea llevar a cabo con éxito uno de estos grandes esquemas en forma de pirateo, atraiga a más personas a la discusión y encuentre una pequeña pieza del rompecabezas que se mantenga bien por sí misma, pero que aún así entienda su punto.

3) A veces se necesita un pueblo para crear un hack

Ciertos hacks están tan claramente definidos y tienen un alcance limitado que un solo desarrollador puede hacerlos realidad a tiempo; sin embargo, a pesar de lo complejos que son la mayoría de los servicios web, es mucho más común que cualquier pirateo realmente interesante requiera los esfuerzos de varios expertos en la materia en varias plataformas diferentes.

En el fondo, los hackatones son eventos sociales, y tienen tanto que ver con el trabajo en equipo y la moral como con la innovación. Si está organizando un evento Hack Day, proporcione un foro para la formación de equipos antes del evento en sí; Hemos realizado una reunión de "reclutamiento" previa al Hack-Day durante varios años en LiveOps, generando combinaciones de equipos que podrían no ocurrir dentro del flujo normal del trabajo del proyecto y fomentando mayores interacciones entre los equipos a largo plazo.

4) El despliegue es la mejor recompensa

Sí, es importante ofrecer algún tipo de premio tangible al "mejor truco", aunque todos los que quieran un iPad probablemente ya tengan uno. Sin embargo, no todos los desarrolladores tienen una idea de producto propia que funcione como una función en producción; muchos ingenieros pueden trabajar para habilitar las visiones de los gerentes de productos durante años sin que sus propias nociones innovadoras vean la luz del día. Si los hacks se muestran prometedores como productos, o si se pueden usar de inmediato, deben pasar rápidamente a producción por el bien de la empresa y como recompensa para los ingenieros involucrados.

Todas las empresas de software (no solo las nuevas empresas web) deben realizar hackatones regulares para generar innovación, aumentar la motivación y mejorar las líneas de comunicación entre los equipos. Sin embargo, al igual que con cualquier actividad de la empresa, existen formas más efectivas y menos efectivas de realizarla. Realice un seguimiento de lo que funciona y lo que no funciona, realice mejoras con el tiempo y escuche los comentarios de los participantes. Aunque los principios anteriores han funcionado muy bien para nosotros en LiveOps, lo más probable es que desarrolle un conjunto de pautas que funcionen mejor para su organización con el tiempo.