Este pasado fin de semana he participado en el Hackathon organizado por el SIGTE OpenApps4Geo. En esta entrada voy a explicar cómo he preparado en concreto este hackathon y el resultado final que he obtenido.

En primer lugar, el hackathon lo he hecho en remoto, es decir, desde mi casa y he participado solo. Normalmente a los hackathones a los que me he apuntado he participado en equipo, en este también existía la posibilidad pero no ha surgido.

 

1. ¿Qué hacer antes del hackathon?

 
El hackathon empezó un jueves y terminaba un domingo. El objetivo era crear aplicaciones móviles con componente geográfica utilizando open data. En mi caso sólo pude dedicar dos días a trabajar en la aplicación.

Bien, lo primero a decidir fue ¿qué voy a hacer? o formulado de otra manera ¿qué puedo hacer?

Normalmente tengo una idea clara de lo que quiero hacer, SIEMPRE reutilizando alguna librería o proyecto con la que tengo experiencia. A parte de eso, lo que suelo hacer es buscar qué datos interesantes hay por ahí.

En esta ocasión, mi idea era trabajar en un pequeño juego que tenía en mente desde hace tiempo y al que le faltaba un pequeño empujón. Decidí además buscar la mezcla perfecta de tecnologías que domino: Android, GIS, webapps, Javascript
 
En resumen lo que hay que hacer antes del hackathon es:

  • Buscar una idea que encaje con el objetivo del hackathon, si no hay ideas se pueden buscar datos para que esta fluya.
  • A ser posible reutilizar algún proyecto medio empezado o librería que dominemos. Nunca hacer experimentos, sólo desarrollar con lo que somos auténticos expertos.

 

2. ¿Cómo planificar el hackathon?

 
En esto sí que suelo utilizar alguna metodología ‘ágil’ que me funciona. A veces lo que hago es crear un pequeño panel de Kanban, no hace falta nada demasiado sofisticado, simplemente una hoja donde escribir es suficiente.

En esta ocasión como participaba yo sólo me dediqué a poner en un papel el conjunto mínimo de tareas para llegar al final del hackathon con mi aplicación terminada y, ojo, muy importante, una estimación pesimista de cuanto nos va a costar cada tarea.

Obviamente, en un periodo corto de tiempo como es el de un hackathon no vamos a tener demasiado tiempo para lucirnos, así que hay que ir al grano, para estos casos viene bien leer algo sobre “Productos mínimos viables

La de abajo fue mi planificación, terminé todas las tareas excepto una que la vi técnicamente inviable y otra que no era necesaria para crear el Producto mínimo viable que estaba buscando.

 

hackathon-plan

 

3. Durante el hackathon

 
En esto sí que soy muy estricto. Un hackathon es lo que es, desarrollar en muy poco de tiempo una aplicación/prototipo con una temática.

Así que, sabiendo que la variable tiempo es fija, la idea es pasar el máximo número posible de horas delante del ordenador (sin volvernos locos, ni perder a nuestras familias o pareja). En este caso fueron unas 20 horas.

Realmente, lo que me gusta de este tipo de eventos es lo enfocado que puedes llegar a estar. Estoy seguro que el trabajo que he hecho en estas 20 horas no las hago en 40 sentado en mi silla de la oficina. También es cierto, que mantener ese ‘enfoque’ en el tiempo es imposible, y que en los hackathones se buscan sobre todo pruebas de concepto o prototipos desechables, con lo que no se suelen tener tanto en cuenta los detalles, sino que el resultado sea llamativo.

 

4. ¿Cómo entregar tu aplicación?

 
Para mí esta es la cosa más importante y la que intento cuidar siempre al máximo. Por mucho trabajo que hayas realizado o consideres que tu trabajo es bueno, lo tiene que valorar alguien ajeno a ti. Así que, hay que intentar ponérselo fácil y hacerlo lo más atractivo posible.

Respecto a este tema hay 3 cosas que siempre hago:

  • Entregar siempre una aplicación o prototipo funcionando. Si es una web, que esté en Internet, nada de ejecuciones en ‘localhost’. Si es una aplicación para Android, publicada en el Play Store.
  • Cuidar el aspecto visual y a ser posible la UX. Darle un poco de cariño a las interfaces de usuario, dentro de lo posible. Para estos casos conviene tirar de alguna plantilla. Si participamos en equipo, lo mejor es que una persona se dedique exclusivamente a temas de diseño.
  • Hacer que tu aplicación sea auto-descriptiva. En ocasiones no tienes la posibilidad de contar al jurado de que va tu aplicación, así que lo mejor es preparar un vídeo o una web (basta con una landing page) en el que de un vistazo te hagas una idea del objetivo de la aplicación y el trabajo que hay detrás.

En esta ocasión preparé un vídeo corto de 2 minutos donde se ve claramente la aplicación funcionando en distintos entornos:
 

 

5. Después del hackathon

 
Después del hackathon, lo raro es continuar con el trabajo realizado. El resultado de un hackathon normalmente es un prototipo, algo original o visual que más tarde se va a desechar, no algo realmente usable. Hasta ahora nunca he continuado el trabajo tras un hackathon.

Lo que sí suelo hacer es dedicar algo de tiempo a diseminar los resultados.

3 ejemplos de diseminación del resultado de un hackathon

  • Si has utilizado datos de algún organismo público, puede estar bien hacérselo saber.
  • Si has utilizado datos de un sector donde hay cierto interés, puedes hacerte eco en las redes sociales para conseguir algo de viralidad.
  • Mover el resultado del hackathon por medios de información. Normalmente, estos no hacen ascos a cualquier noticia relacionada con tecnología.

Por último, otra cosa importante tras el hackathon es medir el impacto de tu aplicación. Si has llegado a un prototipo que has podido publicar en una web o en una tienda de aplicaciones, es buena idea medir el impacto de ese prototipo: número de visitas, número de descargas, impacto en redes sociales y si además puedes obtener feedback, ya no necesitas nada más.

En definitiva, el trabajo de dos días, puede convertirse en algo más importante que un proyecto en el que llevas trabajando años.

Por cierto, aquí el resultado final, WiW