Mi experiencia en el Startup Weekend Tenerife
Durante los días 1, 2 y 3 de febrero tuve la oportunidad de participar en el Startup Weekend Tenerife. Es posible que no sepas lo que es un Startup Weekend (SW), pero es un concepto muy sencillo que puedes aprender en su propia web. Pude proponer mi idea, formar un equipo fantástico e incluso al final tuvimos la suerte de ganar. Te daré algunos consejos y te contaré algunas cosas que pude aprender, te podría resultar útil si decides participar en el futuro ;-)
 |
| Que buenas las caras de @carlosble, @yurenaghm y @chozero cuando me vieron con un lanyard de Visual Studio ... tranquilos chicos sigo siendo un javero convencido :-P |
La preparación es muy importante
Cuando hablo de preparación no me refiero a que trabajes en tu idea, sino a documentarte sobre este tipo de eventos, las cosas que han funcionado o que han fallado a participantes anteriores y a como extraer el máximo valor de la experiencia.
En mi caso personal hay una parte que ya había aprendido debido a mi conocimiento sobre las técnicas de desarrollo ágil, esto es útil en el apartado de ejecución técnica, pero todavía tenía algunas lagunas en aspectos más de negocio. Recuerda que no solo quieres tener un mínimo producto viable para la presentación final, también quieres validar la idea de negocio. En este apartado me resultó bastante útil haber leído The Lean Startup y Startup Weekend (el libro).
 |
| Alguna bibliografía interesante de cara al evento |
Por otro lado, es muy importante que lleves tus herramientas preparadas, ya sea para trabajar en la idea que propones como para trabajar en ideas de otras personas, los desarrolladores deberíamos tener las herramientas a punto y listas para empezar a producir valor. En mi caso personal el uso de JavaScript, con Node.js en servidor y Backbone.js en cliente, ha funcionado muy bien y ha permitido que el resto de desarrolladores del equipo se integre fácilmente.
Obtén la versión básica de tu idea
El primer día del evento tienes que presentar tu idea al resto de participantes y formar un equipo. Pues tanto para cautivar a esas personas que quieres que formen parte de tu equipo, como para llegar a tener un mínimo producto viable (MVP) al final del fin de semana, debes pensar en una versión básica de la idea.
 |
| Unos wireframes en papel fueron más que suficiente para que el equipo supiese cual era el objetivo del fin de semana |
Deja que las cosas sigan su cauce
Este punto es muy personal y discutible, en general cada persona lo puede haber vivido a su manera o tiene su propio modo de gestionar. En mi caso particular pude formar un gran equipo, bastante técnico en cierta medida, por lo que decidí no participar como desarrollador y centrarme en la parte de negocio y coordinación del equipo.
Solo hubo que enfocar a todo el equipo en cual era el objetivo y los tres o cuatro hitos que queríamos ir alcanzando a lo largo del fin de semana y tanto el equipo de desarrollo como el de diseño lo fueron haciendo sin ninguna necesidad de ir controlándolos. En cada hito comentábamos lo que teníamos y si algo no iba bien o necesitaba más tiempo entre todos encontrábamos una solución más adecuada.
Cualquiera que sepa un poco de metodología ágil podría haber visto dos conceptos muy sencillos nada más entrar en la habitación. Primero, utilizábamos un tablón Kanban para controlar el estado del equipo, las tareas en desarrollo y el avance del "product backlog". Segundo, cada componente del equipo era responsable de la tarea que llevaba a cabo y tenía poder decisión sobre la misma (empowerment), lo cual no quiere decir que no se tomasen decisiones en equipo.
 |
| Con este pedazo equipo no hacia falta ningún tipo de control :-) |
Solo hubo que enfocar a todo el equipo en cual era el objetivo y los tres o cuatro hitos que queríamos ir alcanzando a lo largo del fin de semana y tanto el equipo de desarrollo como el de diseño lo fueron haciendo sin ninguna necesidad de ir controlándolos. En cada hito comentábamos lo que teníamos y si algo no iba bien o necesitaba más tiempo entre todos encontrábamos una solución más adecuada.
Cualquiera que sepa un poco de metodología ágil podría haber visto dos conceptos muy sencillos nada más entrar en la habitación. Primero, utilizábamos un tablón Kanban para controlar el estado del equipo, las tareas en desarrollo y el avance del "product backlog". Segundo, cada componente del equipo era responsable de la tarea que llevaba a cabo y tenía poder decisión sobre la misma (empowerment), lo cual no quiere decir que no se tomasen decisiones en equipo.
Usa timebox para tomar decisiones
Timebox es un concepto muy sencillo, fijar un tiempo máximo para una reunión o tarea. Ni que decir tiene que en un SW el tiempo es el bien más preciado, junto con los diseñadores ;-) Por lo que es necesario no gastar más tiempo del necesario en absolutamente nada.
Por poner un ejemplo. Nosotros limitamos el tiempo a seleccionar el nombre del producto a 30 minutos, después de esos 30 minutos nos quedamos con el que mejor encajaba. Cuando llegó la primera ronda de mentores se comentó que el nombre ya lo usaban otras webs y que algunos de los perfiles sociales ya estaban cogidos. Pues sí, pero de nada hubiera servidor buscar un nombre molón y que no tuviese nadie durante 5 horas, porque no habríamos tenido el producto, ni podríamos haber cerrado colaboraciones con futuros clientes como sí hicimos. El tiempo es tuyo, usalo como quieras, pero recuerda que sólo hay 54 horas y debes hacer las cosas que más valor aporten.
Por poner un ejemplo. Nosotros limitamos el tiempo a seleccionar el nombre del producto a 30 minutos, después de esos 30 minutos nos quedamos con el que mejor encajaba. Cuando llegó la primera ronda de mentores se comentó que el nombre ya lo usaban otras webs y que algunos de los perfiles sociales ya estaban cogidos. Pues sí, pero de nada hubiera servidor buscar un nombre molón y que no tuviese nadie durante 5 horas, porque no habríamos tenido el producto, ni podríamos haber cerrado colaboraciones con futuros clientes como sí hicimos. El tiempo es tuyo, usalo como quieras, pero recuerda que sólo hay 54 horas y debes hacer las cosas que más valor aporten.
Mentores sí, pero con cuidado
Al final del evento Sergio Montoro dio una breve charla en la que comentaba que no debemos hacer caso a los mentores :-) yo no creo que haya que llegar a esos extremos, pero estoy en parte de acuerdo. Durante el fin de semana te visitarán mentores entre tres y cinco veces, en cada ocasión te darán consejos, nuevas ideas, nuevas opciones de negocio, pero no puedes intentar hacer todas esas cosas. Escoge sólo aquellas cosas que vayan en la línea de lo que estas haciendo y se puedan implementar rápidamente, pero no descartes las otras, apuntalas en la libreta para analizarlas de cara al futuro, recuerda que después del fin de semana puedes seguir trabajando en tu idea.
Acostumbrate, cometerás fallos
Quizás este sea uno de los puntos más importantes, en 54 horas no hay tiempo para lamentarse por los errores, hay que seguir adelante y trabajar en aquellas cosas que nos aporten más valor y beneficios. Por ejemplo, nosotros no llegamos a comprar el dominio para la aplicación, tampoco actuamos en las redes sociales, pero eso no supuso necesariamente un impedimento.
A nivel personal como coordinador del equipo me quedo con un regusto amargo por no haber podido mantener a todo el equipo inicial hasta el final, dos componentes decidieron abandonar el domingo por la mañana. Pero debes saber que esto no es extraño en los SW, son cosas que pasan a menudo y que debes aceptar o de lo contrario no llegarás a la presentación del producto.
A nivel personal como coordinador del equipo me quedo con un regusto amargo por no haber podido mantener a todo el equipo inicial hasta el final, dos componentes decidieron abandonar el domingo por la mañana. Pero debes saber que esto no es extraño en los SW, son cosas que pasan a menudo y que debes aceptar o de lo contrario no llegarás a la presentación del producto.
Agradecimientos
Ha sido un evento fantástico y me gustaría agradecer a toda la organización el magnifico trabajo que ha realizado. Sé de buena tinta que no es nada fácil organizar un evento como este, pero lo han hecho magnificamente y se merecen un 10 ^_^
Material adicional
Este artículo muestra algunas herramientas que pueden ser de gran valor en un SW.
Aquí puedes encontrar un enlace al análisis que hice hace unas semanas del libro de Startup Weekend.
Comentarios
A mi sigue sin cuadrarme que la discusion sobre qué debe hacer el producto se ayude de wireframes (el cómo) porque creo que le limita las posibilidades a la hora de abrir debate sobre lo que se quiere y se necesita que el software haga. Pero en cuanto a llegar un diseño de UI parelelo, la verdad que esos wireframes eran espectaculares, muy bien hechos. Estupendos para abordar la labor de usabilidad y diseño.
Estaba claro que la idea de ustedes debia ser ganadora. Fue el equipo mas maduro y con las cosas mas claras. En mi opinion, claro.
Enhorabuena :-)
Valoro mucho tu opinión por lo que muchas gracias de nuevo por los ánimos :-)
Respecto al tema de los wireframes creo que podría generar una discusión muy interesante. En un Startup Weekend para mi son fundamentales, sólo hay dos días y si las ideas de lo que queremos están claras, mejor. Pero en la "vida real" entiendo muy bien tu punto de vista, por ejemplo porque la existencia de un wireframe impida que se generen nuevas ideas o formas de hacer las cosas mejores o más elegantes, cómodas, etc. Sí, diría que en eso estoy de acuerdo contigo, para mi es una herramientas útil cuando voy a empezar una funcionalidad, pero desde luego para determinar que cosas hace la aplicación o que funcionalidades queremos sigo prefiriendo una tormenta de ideas, escribir historias de usuario, esas herramientas que son menos concretas que un wireframe.
Quizás aquí estaría bien hablar sobre la madurez del equipo, porque un gran problema que veo, y probablemente es al que haces referencia en mayor o menor medida, es que si el que hace el wireframe digamos que tiene el respeto unánime del equipo, no se produce discusión alguna, lo cual es malo. Ciertamente se necesita un gran grado de confianza y participación, es un trozo de papel así que se puede dibujar encima y cambiarlo cuanto se quiera, no como una especificación cerrada.
Creo que voy a parar aquí que se me va ... voy a investigar un poco más y hacer un artículo con pros y contras de los wireframes.
Un abrazo amigo :-)
Para mi fue clave que Yeray tuviera preparados los wireframes para poder empezar a desarrollar la app desde el sábado a primera hora, sin ningún tipo de discusión de por medio, ni retrasos, estaba claro el concepto más básico de nuestro producto, una agenda con el programa de un evento ficticio (el prototipo que queríamos presentar). Fue magnífico ver como el equipo de desarrollo se auto-organizó y comenzaron a desarrollar basados en la guía que Yeray puso sobre la mesa. Sólo hubieron unos checkpoints para saber del progreso de la app, mientras tanto, en el área de negocio, estudiábamos si había mercado, cómo estaba el mercado, se redefinía el modelo de negocio, surgieron nuevas funcionalidades que se le podrán añadir a la app, pero no para incluirla en el desarrollo que ya estaba en curso, si no para el futuro, etc...
Todo esto me recuerda a las típicas discusiones sobre el liderazgo, si es mejor democrático-consultivo, autoritario, etc... Pues yo siempre digo, depende del contexto, ¿y quién suele marcar ese contexto? pues casi siempre es el tiempo, pero además, también dependerá de los recursos con los que cuentes. Hay momentos en los que hay tiempo para pensar, reflexionar y hacer las cosas bien, pero hay otros que sólo tienes tiempo para decidir y ejecutar, podrá ser una buena o mala decisión, pero hay que decidir rápido. También puede ocurrir que tú seas la única persona cualificada o experta en la materia dentro de un grupo, y probablemente, lo que digas, irá a misa casi sin ser cuestionado. Pero coincido plenamente en que siempre es sano cuestionar y debatir las cosas, aunque en un principio parezca una buena solución, siempre puede saltar una chispa que haga cambiar el concepto inicial, y todo ello siempre dentro del timebox asignado para que el debate no se eternice.
Bueno, ahí queda mi reflexión. Saludos.