Cómo hackear un Hackathon: Pitch Perfect

(El artículo principal y los enlaces a las otras publicaciones sobre Hackathon 101 e Industria están vinculados aquí)

No confío en las personas que participan en concursos solo para participar y hacer los números. ¿Qué sentido tiene? Si va a dedicar tiempo, y en este caso un fin de semana, a algo, entonces también podría ir a toda máquina y sacar algo de eso. Al final del día, mientras que nadie pierde realmente, definitivamente hay ganadores y en esta publicación compartiré algunos de mis enfoques que me han servido bien.

Agrim, ¿qué construyo?

Una gran parte del éxito del hackathon (y del producto) tal vez esté determinado por el problema que decidió abordar y cómo lo resolvió. Examinemos ambas áreas.

¿Qué problema deberías resolver?

Esta es ciertamente una pregunta difícil; Hay muchas personas en este mundo que se hacen esta pregunta mientras intentan construir sus nuevas empresas, preguntándose si lo que están trabajando es importante y vale la pena resolverlo, si es que es un problema.

Así es como lo hago: tuve la suerte de estar en un plan de estudios universitario que enfatizaba la importancia del pensamiento de diseño. En pocas palabras, el pensamiento de diseño conduce un enfoque basado en soluciones para resolver problemas complejos, especialmente aquellos que están mal definidos o son desconocidos. Ahora puede elegir rascarse su propio picor o elegir un nuevo dominio para resolver, pero el siguiente proceso funcionará de la misma manera.

El proceso de pensamiento de diseño

Empatizarse

Con demasiada frecuencia somos culpables de construir una solución sin pensar mucho en las cosas que vienen antes: por qué lo estamos haciendo, para quién lo hacemos, qué hará realmente, hará lo que pretende hacer y para audiencia correcta Gran parte de esto se basa en la falta de empatía por el problema. Dejamos que nuestras propias suposiciones dicten cuál es el problema, y ​​eso está mal. Me enfrenté a esto de primera mano cuando estaba tratando de construir una solución para ayudar a los discapacitados visuales a navegar de forma independiente. Lo asumo:

  • En primer lugar, esto es un problema porque los perros guía son caros y tener un ayudante es problemático,
  • En segundo lugar, evitar obstáculos es el mayor problema a resolver,
  • Por último, un dispositivo portátil como Google Glass podría deshacerse del bastón.

Me equivoqué en los tres aspectos.

El primer punto para aliviar al ayudante, si bien es cierto, no era una preocupación apremiante que requeriría interferencia tecnológica. El segundo punto sobre la evitación de obstáculos no fue el mayor problema; La detección de semáforos fue probablemente un desafío mayor dado que la caña cubría la mayoría de los obstáculos dentro del alcance. El último punto fue severo porque supuse que el reemplazo tecnológico es fácil. No puedes cambiar dramáticamente la forma de vida de una persona; los discapacitados visuales están acostumbrados a usar sus marcadores de bastón y pavimento táctil, por lo que cualquier innovación tecnológica nueva debe basarse en esto, no reemplazarlo por completo.

¿Cómo remediamos esto? Salir y hablar con la gente es la forma más segura de saber más porque obtienes información directa sobre los usuarios y sus necesidades. Pude arreglar mi producto para ayudar a los discapacitados visuales porque realmente hablé con alguien que vive estos desafíos día a día.

Pero, ¿qué pasa si no puedes hablar con la audiencia correcta durante un hackathon? El tiempo es corto y tal vez no estás en el lugar correcto para conocer a estas personas. Tienes que improvisar y extraer información que te ayudará a definir objetivamente un problema que valga la pena resolver. El fin de semana pasado estaba trabajando en un hackathon que quería que "resolviéramos para la India". Este es un gran tema; India no tiene escasez de problemas, cada uno más importante que el anterior, y enmarcarlo efectivamente es un desafío en sí mismo, y mucho menos intentar resolverlo. Decidimos ayudar a las personas empleadas en el sector industrial y planteamos el problema para abordar la fatiga. ¿Por qué?

  • India es lo peor cuando se trata de accidentes industriales,
  • Los indios tienen una fuerte dependencia de los empleos industriales para ganarse la vida y,
  • Hay pruebas significativas disponibles de que la fatiga y los déficits de sueño causan accidentes / percances e incluso muertes en varias líneas de trabajo, como conducir camiones a larga distancia u operar maquinaria pesada, ambas líneas de trabajo riesgosas con turnos largos que hacen que sus empleados sean propensos a la fatiga y la pérdida. atención.

Ahora, no hay forma de verificar personalmente nada de esto; Depende de los datos y hechos públicos disponibles para elaborar una narración, pero al menos esta información crea suficiente empatía para definir un problema que vale la pena resolver.

Definir

No importa cuánto te hayas convencido, definitivamente vas a apresurarte en la fase de Empatizar. Simplemente no hay tiempo suficiente para duplicar / triplicar las reclamaciones. Sin embargo, si juegas bien tus cartas, tendrás suficiente información para trabajar. Trabajemos con nuestro ejemplo anterior sobre fatiga. Hemos establecido que se requiere un entorno de trabajo más seguro (reclamo 1) y una de las formas de hacerlo sería abordar la fatiga (reclamo 3). Nuestra definición del problema se basará en esto:

"Necesitamos un sistema de monitoreo de fatiga para ayudar a crear un ambiente de trabajo más seguro y productivo".

Ahora, puede optar por examinar cualquier otro problema dentro de este dominio y eso es perfectamente válido. Solo asegúrese de que su definición se base en reclamos que haya establecido como parte de su trabajo preliminar inicial. Haga un seguimiento con heurística simple para configurar la siguiente fase del proceso:

  • ¿Para quién estamos haciendo esto? En este caso principalmente para los empleados pero también para los empleadores.
  • ¿Como haremos esto?
  • ¿Cuál es nuestra medida de éxito?
  • ¿CUÁL ES LA CLAVE DE LA QUE DEPENDE SU PRODUCTO?

Idear

Aquí es cuando comienzas a responder el "cómo". Es decir, ahora que tiene toda su información, ¿qué va a construir? Para nuestro caso, ¿deberíamos construir un sistema de monitoreo? ¿O una alarma para el empleado? En cada caso, ¿cuál es nuestra medida de éxito: despertar al conductor? Datos de registro para el empleador? Lo más importante, ¿de qué depende todo esto?

Los hackatones son extrañamente eficientes en la validación y creación de productos. Solo hay una cantidad finita de cosas que puede probar y mostrar en, digamos, 3 minutos, por lo que debe elegir la más importante. En nuestro ejemplo, es el sistema de monitoreo de fatiga porque todos los demás aspectos del producto (los registros, la alarma) dependen del funcionamiento de la detección de fatiga. Por lo tanto, debe compilarlo y asegurarse de que funcione para su demostración. Si falla, el resto del producto ya no es convincente.

Demasiadas veces, los equipos estropean la única característica principal que mantiene unido el producto o crean 17 características diferentes ("hinchazón de características") que confunden a los jueces porque pierden el mensaje que el equipo estaba dirigiendo. Es una cosa muy simple: haz una o dos cosas y hazlas muy bien. Es el sello distintivo de todos los excelentes productos. Los hackatones no son diferentes.

Prototipo / Prueba

Ahora es el momento de construir. Elija sus herramientas para el comercio (en nuestro caso, utilizamos OpenCV y dlib para la detección de puntos clave) y comencemos a construir. Puede encontrarse dibujando bocetos / prototipos de papel primero antes del producto real y eso está bien. Úselos para rebotar entre sus etapas de ideación / definición / empatía y, si es posible, aproveche la ayuda de mentores y expertos en el evento para brindarle más información. Su solución se desarrollará y "limpiará", después de lo cual puede llegar al negocio. Combiné las fases de Prototipo y Prueba porque los lanzamientos de hackathon terminan con un prototipo, pero si alguna vez tienes ganas de extender la vida útil del proyecto más allá de las 24 horas, entonces tendrás que probar explícitamente con tu audiencia de elección.

¿Cómo se resuelve un problema en un hackathon?

Hemos aprendido cómo elegir un problema que valga la pena resolver y cómo funciona en un hackathon. Pero ahora a detalles: ¿qué te hará ganar un hackathon? En un mundo ideal, un servicio electrónico, un portal o una solución de baja tecnología podría proporcionar beneficios a millones de personas, pero nunca ganaría en un hackathon. ¿Por qué? Porque no tiene rigor técnico. Definitivamente hay un trabajo que implica, sin duda, pero nunca le dará el aplauso por la elegancia de la solución o la atención que necesita generar en los grandes hackatones. Aprendí esto de la manera difícil.

Siempre construyes para la demo. Siempre.

En HackingEDU decidimos construir este portal encantador donde todo lo que el usuario vio fue una forma de lenguaje natural que decía "Quiero aprender sobre X y tengo Y minutos disponibles". Se resolvió un problema muy claro sobre las personas que no tienen tiempo para aprender cosas y la multiplicidad de información en internet. Nuestra solución marcaría y elegiría los mejores enlaces que valen su tiempo. Todo funcionó y se veía bonito.

Excepto que había 140 equipos en la sala y era un diseño de estilo de exhibición. Los jueces y los equipos clamaban en mesas que tenían grandes exhibiciones o múltiples monitores o dispositivos como auriculares VR, mientras que nuestra mesa tenía un triste MacBook con una ventana de navegador abierta. No hubo valor de choque para nuestro hack. Entonces, incluso cuando intenté vender el producto a quien fuera que lo visitaba, supe que estaba trabajando contra la corriente; el tiempo de atención de los visitantes fue de apenas unos segundos y no fue un producto que, al menos con una mirada limitada, los hizo decir "Holy F * ck".

Naturalmente, no ganamos. ¿Podríamos haber hecho una escena de eso? Seguramente. Desde ese evento, he sido más claro en la fase final de un hackathon: la ejecución. No solo crea "un" producto. Te recuerdas que, después de todo, es un espectáculo y un espectáculo. Las personas deben estar impresionadas, independientemente de si lo lanzas bien o no. Ya sea que se trate de un mashup de API o una solución legítima para moldear el mundo, su valor de choque es lo único que puede causar una impresión inmediata incluso antes de que haya tenido la oportunidad de explicarlo. Toma esto en serio.

Usando tu tiempo sabiamente en un hackathon

El tiempo es una mercancía finita en un hackathon. Crees que estarás listo para salir una vez que tus paquetes hayan terminado de instalarse y aumenten: la mitad del hackathon ha terminado. Te estás quedando dormido, la comida no se servirá por otras dos horas, alguien ha robado el suministro del evento de Red Bull y ahora tienes sueño, eres miserable y no has trabajado.

Por favor, no dejes que esta sea tu historia.

En un hackathon de 24 a 48 horas, nunca necesitará todo el tiempo proporcionado. A menos que esté en la búsqueda de publicar una aplicación lista para producción con el código adecuado, lista para salir al mercado en el momento en que finalice el hackathon, entonces, seguro, continúe. Pero construir una prueba de concepto no debería matarte.

Aquí hay algunas cosas que debes hacer:

  1. Sé dueño de tu responsabilidad. Si viene solo como desarrollador / diseñador, tenga todas sus herramientas instaladas y listas para usar. Kits de inicio, software, lo que creas que podrías necesitar. Sí, es una lista no exhaustiva pero, para mi vida, nunca quiero ver a otra persona descargando y compilando software tan grande como OpenCV el día del evento. Es doloroso mirarlo. Hazlo en casa, resuelve tus errores y prepárate para trabajar. Si viene en equipo, decida en qué herramientas / hardware planea trabajar y prepárelos con anticipación.
  2. Tome en serio el proceso de pensamiento de diseño. Le ayudará a exprimir fácilmente las preguntas correctas para responder y, posteriormente, dividir las tareas de manera efectiva entre los miembros de su equipo.
  3. La asignación de tareas y la responsabilidad son primordiales. Sepa antes de saltar quién va a hacer qué. Si alguien necesita trabajar como PM para mantener unido al equipo, hágalo. Por lo general, me encargo de ese papel por varias razones:
  • Nos mantiene en mensaje si puedo controlar lo que estamos construyendo y por qué lo estamos haciendo,
  • Nos permite hacer un seguimiento de qué tan lejos estamos en un momento dado y ajustar los objetivos en consecuencia,
  • Nos permite ser colectivamente claros sobre cuáles son las características prioritarias y cuáles son las características de estiramiento (descartables que se ven bien / agregan chispa pero no son esenciales para la demostración).

Me gusta dirigir un barco apretado para mi tripulación de hackathon o estar en uno. Establecer marcadores de tiempo para los objetivos permite que todos tengan mucho tiempo para descansar y recuperarse.

Clavar el éxito cada vez: un enfoque contraintuitivo

Habiendo pasado suficiente tiempo en el juego, mucho de esto es una segunda naturaleza; Por lo general, tengo un equipo estable con el que compito y tenemos claro lo que debemos hacer en términos de ideación y ejecución. Sin embargo, es posible que aún no te consiga una victoria. Algunos enfoques contraintuitivos:

  1. Construir con nueva tecnología. Todos están creando aplicaciones móviles / aplicaciones web en hackathons. No hay forma de distinguirse activamente de los demás. Sí, soy despectivo, especialmente teniendo en cuenta las cosas que ahora puede hacer con dispositivos móviles y web, pero el 70–80% de los piratas informáticos no están utilizando esto. Hemos recurrido a utilizar activamente nuevas tecnologías como Computer Vision o aprendizaje automático demostrable (no lo suficiente como para reclamar el aprendizaje automático :)) en todos nuestros nuevos proyectos o hardware si el hackathon lo exige. No muchas personas pueden replicarlo y casi siempre somos memorables al final del evento.
  2. Crea tu producto final y lanza para golpear los marcadores de evaluación. Si un hackathon califica el rigor técnico al 40% y la idea al 10%, sabrá que puede construir cualquier cosa loca siempre que sea novedoso y creativo, independientemente del impacto. Si el enfoque se invierte, es decir, la idea es del 40%, la técnica es del 10%, entonces sabrá que insistir en cómo sus redes neuronales son excelentes no le dará una victoria. Hablar sobre el problema, el contexto, por qué es importante, cómo lo resuelve y cómo lo hace mejor que el status quo será el factor decisivo.

Conclusión

Wow, otra publicación larga en la misma noche. Debería haber hecho esto mucho antes.

He compartido contigo lo que sé sobre los hackatones. Cómo decido qué construir, cómo administramos el tiempo, cómo nos aseguramos de que al menos ganemos algo. Deseo sinceramente que quien lea esto lo encuentre útil y gane hackatones utilizando algo que podría haber escrito aquí.

Comentarios / comentarios bienvenidos! Estoy disponible en Twitter y Facebook.