The Sketchnote Handbook

Hace ya un tiempo que leí uno de los libros de Nancy Duarte, Resonate, y añadí la RSS del blog de su estudio a mi lista de blogs habituales. Y es allí, a principios del mes de febrero, donde encontré una referencia a un libro que parecía bastante interesante, The Sketchnote Handbook, escrito por Mike Rohde. Hoy te voy a contar que me hizo comprármelo y te daré mi opinión personal del mismo.

El aspecto general del libro, que os puedo asegurar está muy bien ilustrado y encuadernado

Una de las constantes del desarrollador de software es que debe estar continuamente aprendiendo, y una de las formas más comunes de hacerlo es en eventos con otros desarrolladores; durante charlas en comunidades locales, conferencias, workshops, lo que sea, pero todas ellas implican un continuo bombardeo de información. Es la necesidad de sintetizar toda esta información lo que me ha hecho buscar formas mejores de atender a las ponencias y talleres, por esta razón he comprado el libro. Aunque al principio el precio parecía excesivo en relación con otras alternativas, he de decir que no me arrepiento en absoluto.

Lo primero que llama la atención, a parte de su elegante cubierta, es que no es un libro al uso lleno de texto en toda su extensión. El propio autor, en colaboración con otros expertos en este campo, hace uso de sketchnotes para explicar las ideas, lo que hace que te puedas leer el libro en unas pocas horas. Se hace muy ameno y la idea de dejar que otros profesionales explicasen su visión permite tener diferentes puntos de vista que fomentan la reflexión del lector.

El libro avanza desde la explicación general de porque es mejor hacer sketchnotes, hasta los últimos capítulos más técnicos y que requieren de práctica por parte del lector. Pero lo mejor es que lo aprecies en el índice del libro.

1. What are sketchnotes?
2. Why sketchnotes?
3. Listen up!
4. The sketchnoting process
5. Types of sketchnotes
6. Sketchnoting approaches, hierarchy, and personalization
7. Sketchnoting skills & techniques

A quién le puede interesar

En resumen, a todas aquellas personas que necesitan resumir gran cantidad de información, asistentes habituales a conferencias, conferenciantes profesionales, alumnos de universidad, al panadero de mi barrio ... simplemente personas que les gusta probar nuevas ideas :-P

A quien no le interesará

Pues no se me ocurre a quien no le puede resultar interesante, probablemente todas aquellas personas que ya tienen experiencia haciendo sketchnotes. O, quien no le apetezca lo más mínimo mejorar su capacidad de atención en un evento :-)

Mis primeras sketchnotes 

Como bien indican varias veces a lo largo de la lectura, la mejor forma de aprender es practicando, y aunque el libro se lee en un par de horas hay bastantes ejercicios recomendados que harán que te acompañe durante unos cuantos días.

Yo he decidido hacer caso a una de las notas incluidas en el libro y he comenzado por hacer sketchnotes de algunas charlas TED que a priori me parecían interesantes; es una gran forma de practicar en casa. No he logrado hacer ninguna obra de arte, pero sí he comprobado de primera mano como con este sistema mi nivel de atención era bastante mayor. Ya os contaré cuando lo ponga en práctica en un evento real.

Lo sé, me he equivocado con el apellido de Jeff Sutherland, pero los errores son parte del sketchnoting ;-)

Al principio me parece complicado calcular cuanto van a ocupar los dibujos o la organización, pero la práctica hace la perfección

A veces los conceptos explicados no son tan sencillos de dibujar con formas simples, es el momento de las flechas y los diagramas :-)

Bola extra: Vídeos del autor

Por lo menos en la edición que yo he comprado, se incluye un código que permite la descarga de vídeos del autor explicando el proceso. Aunque estos vídeos no expliquen nada que no esté en el libro, son muy útiles para observar todo el proceso de un sketchnote desde el principio, lo cual ayuda bastante. 

Aquí tenéis un ejemplo.

Espero que esta crítica os haya servido y os anime a darle una oportunidad al sketchnoting.

P.D: Si compras una edición electrónica que sea en tablet o PDF porque en una pantalla monocroma como la del Kindle seguro que desluce un poco.

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

No es necesario que hables de todas y cada una de las características que quieres que tenga, ni la infinidad de problemas que quieres que resuelva, centrate en un único problema, algo que le haga la vida más fácil alguien y evoluciona el concepto. Lo bueno del SW es que durante el fin de semana coincidirás con mucha gente, entre ellos los mentores, que te irán aportando nuevas ideas y visiones, es útil que hagas una lista para revisarlas cuando tengas algo más de tiempo.

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.

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.

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.

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.

Bibliografía: Startup Weekend

Durante la segunda mitad del año pasado perdí el ritmo del blog, así que ahora lo estoy intentando recuperar poco a poco, y nada mejor que una reseña de un libro que acabo de terminar de leer. Dicho libro es "Startup Weekend: How to take a company from concept to creation in 54 hours". No solo es una entrada relativamente fácil, contar mi opinión, sino que coincide con la celebración del Startup Weekend Tenerife este próximo fin de semana :-)

El pack preparatorio para el Tenerife Startup Weekend :-P

Compré este libro junto con "Lean startup", quizás de una forma un poco impulsiva y sin revisar demasiado las opiniones de otros lectores, quizás por conocer en detalle que era eso de Startup Weekend  y en ese aspecto no defrauda. Pero no es el tipo de libro que os recomendaría encarecidamente, para mi es un tres sobre cinco, se deja leer, pero para mucha gente del sector puede que no aporte nada nuevo, sobretodo si ya has leído "Lean startup" y además eres conocedor del mundo de las metodologías ágiles.

Como se estructura

No es uno de esos libros que te da pereza nada más verlo, en realidad solo tiene 171 páginas contando los índices, glosario, anexos y demás parafernalia. La letra no es grande ni pequeña, cómoda de leer vamos, uno de esos libros que si estas decidido te acabas en 4 tardes.

Se divide en cinco capítulos que van avanzando desde las peripecias de los autores en sus años mozos, es decir cuando no tenían ni pu** idea de lo que iban a hacer con su vida y crearon Startup Weekend,  hasta lo que tú mismo te encontrarás cuando asistas a uno, y (un poco) más allá. Especial atención presté a los capítulos 2 y 3 que te pueden servir para preparar la asistencia al evento, lo que a mi me interesaba, ya que cuentan algunas de las actividades que se realizan.

Hay que reconocer una cosa muy importante y es que en cada capítulo encontrarás muchas referencias externas que, si las sigues, te pueden llevar a la experiencia de asistentes a pasadas ediciones, y eso para mi es lo que salva el libro.

A quién va dirigido

Sin ningún lugar a dudas, hay un público muy concreto al que está enfocado el libro. Todas aquellas personas que vayan a asistir a un Startup Weekend,  en concreto aquellas que no hayan asistido nunca o no tenga una profunda experiencia en el mundo de las startups.

Quiénes lo encontraran, probablemente, aburrido

Todos aquellas personas que ya han leído "Lean startup" y conocen a autores como Mike Cohn, Rachel Davies o Henrik Kniberg, sin ir más lejos. No encontrarán nada nuevo, ni en el mundo de las startups ni en las prácticas y actividades que enseña el libro. Conceptos como "agile", "scrum" o "lean" aparecen referenciados en multitud de páginas, pero sin llegar al nivel de profundidad que interesaría a alguien que ya conoce dichos conceptos.

Y esta chicos y chicas es mi opinión de este libro, que por otro lado ahora me parece un poco caro para lo que pagué en la edición en papel, comprad la edición Kindle ^_^

Vísteme despacio que tengo prisa

Este domingo por la tarde estaba haciendo un postre, lo he hecho múltiples veces, y por lo que dicen mis compañeros no me queda mal :-) En esta ocasión cuando lo saqué del horno y lo probé, tras dejarlo enfriar claro, casi me muero del susto, no estaba malo, estaba mucho peor. ¡Me olvidé de poner el azúcar!, un error de principiante. Pero se me encendió una bombilla ya que de esta experiencia podía sacar un artículo "interesante" para el blog.

El post de Ancor que me animo a escribir esta entrada en el blog.

Es curioso como puedes conectar cualquier anécdota cotidiana para sacar conclusiones de otro campo que nada tiene que ver. Aquí van las conclusiones que saqué de hacer un postre, aplicadas al desarrollo de software.

Evita el Cowboy Style

Cuando a la gente le hablas por primera vez de desarrollo ágil muchas veces piensa que no es más que tirar la documentación y ponerse a programar como si no hubiese mañana. Nada más lejos de la realidad. El desarrollo ágil intenta evitar hacer cosas que no tienen valor (muy parecido a "lean"), pero eso no quiere decir que no haya que planificar o tener en mente la "imagen global" del proyecto.

Lo que yo he hecho en la cocina es Cowboy Style, he ido cogiendo los ingredientes a medida que los necesitaba y mezclándolos, incluso prestando atención a otras cosas durante el proceso, lo raro es que no hubiese metido la pata más aún. Gracias a Dios no es lo que hago normalmente. Lo que debía haber hecho es terminar con todo lo que estuviese haciendo para que no hubiesen intromisiones, preparar todos los ingredientes antes de empezar revisándolos con la lista de la receta y posteriormente con calma preparar el postre.

En el desarrollo de software es exactamente igual, incluso muchos equipos han incluido un sus tableros Scrum o Kanban (o Scrumban o como quieras llamarlos) una columna que indica cuando una funcionalidad está lista para ser implementada, es decir cuando tienes todos los datos necesarios para no hacer una chapuza y que dicha funcionalidad de verdad aporte valor una vez la hayas completado. Si, en cambio, haces lo que yo he hecho en la cocina terminarás trabajando por dos o peor.

Que lo hayas hecho muchas veces no quiere decir que no te pueda salir mal

Este postre en concreto lo había hecho unas cuantas veces, razón por la que me he confiado, muy mal. Ya habéis visto que incluso cuando tienes experiencia puedes meter la pata, somos humanos. Ya tenía un proceso que me funcionaba, ha sido cuando he modificado ese proceso, sin ninguna razón aparente, cuando todo ha fallado.

Lo mismo se puede aplicar al desarrollo y sus metodologías. Si tienes un proceso que te funciona, o no, no lo puedes cambiar de cualquier manera, tienes que experimentar, documentarte sobre como mejorarlo, pero no cambiarlo a la ligera porque algo simplemente no te gusta. Ocurre muy a menudo que equipos que aplican Scrum en sus proyectos no terminan de sentirse cómodos, pero lo que hacen muchos es cambiar sus practicas sin una experiencia previa, mal, porque no sabes si estas mejorando o empeorando.

Intenta hacer TDD 

Recordando el tweet de Ancor, ha sido el no tener una prueba unitaria lo que ha provocado que fallase al hacer el postre. Imaginad que con la lista de ingredientes los preparo todos y los dispongo para hacer la masa. Luego cuando termino de hacer la masa reviso que los he utilizado todos, no habría cometido ese error, ¿verdad?

En desarrollo de software puedes lograr algo muy similar haciendo uso de TDD (Test Driven Development). Al pensar en una prueba antes de desarrollar la funcionalidad, te está forzando a pensar el problema de forma que se evita fácilmente el Cowboy Style. Y como punto extra, tienes un código soportado por pruebas :-)


Y eso es todo por esta vez amigos :-)

Retrospectiva del año

Todos los años por estas fechas muchos amigos, o incluso gente a la que sigo pero no conozco en persona, aprovecha para hacer su retrospectiva personal del año - cosa que curiosamente no ha ocurrido este año. Ya hace algún tiempo que David Bonilla empezó esta costumbre y yo voy a aprovechar el día de mi cumpleaños para hacer la mia, ¿qué mejor día que este?.

Empecé a escribir la retrospectiva como si fuese una entrada más del blog, un tocho infumable que no me servía ni a mi, pero después de releerla decidí tirarla a la basura. ¿De qué me sirven todos mis conocimientos de técnicas de desarrollo ágil y retrospectivas si luego voy y lo hago mal? Así que he decidido "comerme mi propia comida de perros" y hacer una retrospectiva como Dios manda.

Haciendo uso de la técnica The Retrospective Starfish y las varias libretas que he rellenado a largo del año he comenzado a rememorar y buscar posibles puntos de mejora. Y aquí está el resultado, la herramienta que me ayudará a hacerlo mejor el próximo año.

La retrospectiva colgada para tenerla siempre a mano :-)

El resultado final me ha gustado mucho, ha habido una parte del año en la que pensaba que estaba desaprovechando el tiempo, que no hacía todo lo que podía, pero me estaba engañando a mi mismo. Este año he hecho más cosas que nunca, y he hecho las que más me apetecía, eso sí el blog se ha visto muy afectado, siempre hay que dejar de hacer unas cosas por hacer otras. Desde participar en el Atlassian Recruitment Roadshow hasta "escribir" un libro con Esteban Manchado y Joaquín Caraballo, este año ha sido un sin parar. Una montaña rusa que me ha dado experiencias únicas y con las que he aprendido muchísimo.

Listado de los eventos a los que he asistido o participado

No todo es bueno, hay cosas que tendría que haber hecho - escribir sobre Milán Dopico o sobre mi experiencia con la gente de Geosophic, cosas que había prometido. Hay varios eventos en los que he estado y tampoco he escrito nada. Y también se me ha pasado escribir sobre ¡mi experiencia en la Apache Barcamp!, pero ya le iré poniendo solución a eso. Tampoco he mejorado la calidad de "mis productos" tanto como hubiera querido, pero tampoco ha caído.

Han habido muy buenos momentos, he podido aprovechar para compaginar eventos y vacaciones y he estado en múltiples lugares, desde Sevilla hasta Amsterdam, pasando por Cáceres, Madrid o Zaragoza. He podido probar las tremendas empanadas de Milán Dopico, he podido probar la plataforma Otogami de mis amigos de Funius. He colaborado con la gente de la Apache Barcamp para ayudar en la organización, y de donde me llevo muy buenos amigos y mejores personas ... Sin lugar a dudas he hecho muchas cosas y me quedo con ganas de hacer muchas más.

A nivel personal el año no ha sufrido mucho cambio, quizás este año he hecho muchas menos fotos que antes, cosa que me gustaría recuperar lo antes posible, pero he mejorado mucho mi habilidad en la cocina. Ya se sabe, no se pueden hacer dos cosas a la vez.

Gracias a @supejueves he mejorado mucho en la repositería - un día de desayuno en Avantic.

¿Qué ocurrirá el próximo año?

Por mucho que me esté aficionando a Fringe, no soy uno de los Bishop ni Olivia Dunhan, no tengo ni idea que va a pasar el próximo año. Lo que he hecho es colgar el resultado de la retrospectiva en la pared de mi cuarto para poder comprobar que me estoy ciñendo al plan, pero sin cerrarme a otras ideas. Lo que es seguro es que celebraremos la AOS 2013, ya no nos podemos echar para atrás ^_^

Y espero sinceramente pasarlo tan bien como en este último año.

Ahora sería el momento ideal en el que todas esas personas con las que he compartido este año publicaran su propia retrospectiva, se que han habido noticias estupendas para muchos :-D

@yurenaghm y @chozero haciendo pruebas de sus prototipos en los HQ de Geosophic

Que bien nos tratan @kinisoftware y @oyabun

Fiesta de la CAS en Cáceres

@titeroygatra levantando Geosophic con trabajo duro

Una de esas noches de AOS en Zaragoza con la gente de Cachirulo Valley :-)

Momentos previos a la ingesta de una fantabulosa empanada de bonito con @kinisoftware y @jerolba gracias a @david_bonilla

Sigo sin creerlo pero mi propuesta fue de las más votadas en la Apache Barcamp, que gente más grande