lean startup

Green Kiwi Games © es un proyecto en el que he ido trabajando muy poco a poco en los últimos meses y que constituye lo que se llama un producto mínimo viable (MVP), esto es, un producto o proyecto que muestra la esencia de algo y que se expone para validar su propuesta de valor (o sea, si a la gente le resulta útil o no).

Si una cosa he aprendido en los últimos diez años, y no exagero, es que tu día a día como profesional termina reduciendo tus habilidades a un conjunto de tecnologías, las que usas lógicamente en la compañía para la que trabajas. Y esto no es bueno más aún cuando el cambio en nuestra profesión es vertiginoso. No obstante, en tecnología en general y en software en particular, las posibilidades son tremendas y la cantidad de tecnologías consolidadas y stacks maduros que existen te obligan a tener que estar al día si en unos años no quieres estar más obsoleto que el T-800 de Terminator.

Pues bien, Green Kiwi Games ha sido para mí la forma de profundizar en el stack MySql+Express+AngularJS+Nodejs (lo que se suele llamar MEAN, pero en esta ocasión sin MongoDB...).

Ya he hablado en alguna ocasión brevemente sobre cómo enfocar proyectos de emprendimiento desde el punto de vista del software, campo en el que he tenido mis éxitos pero también mis fracasos. Es un tema muy amplio y lamentablemente muchos proyectos fallan no por falta de una idea que pueda funcionar, sino por la ejecución del mismo proyecto y falta de disciplina para llevarlo a cabo en el tiempo. Buena ejecución, tenacidad y disciplina en el trabajo, esta es la receta en mi opinión.

En cualquier caso, todo parte de una idea que termina siendo lo que nos anima a seguir adelante porque de algún modo creemos en ella. Ahora bien, ¿cómo saber si los demás también la ven útil? Desde luego no es contándola, sino creando algo que lo muestre, algo que se pueda tocar y evaluar. De ahí lo del producto mínimo.

Pero, ¿cómo surgió la idea y qué es Green Kiwi Games? Pues bien, hace un tiempo me encontré con ciertas personas que hacían por su cuenta juegos de cartas, pero con un esfuerzo tremendo al no dominar ninguna herramienta informática y de forma totalmente manual. ¿Por qué no habilitar una web en donde el usuario subiera las imágenes y que la aplicación web se encargara de generar un pdf con las cartas listo para impresión? Sencillo, nada de otro mundo. Una idea, para ser buena, se tiene que poder explicar con muy pocas palabras. La innovación no trata de generar productos cercanos a la ciencia ficción, en cosas sencillas y banales se puede innovar también; es más, la mayor parte de la innovación pertenece a este último grupo. Tendemos a mitificar la innovación.

Eso es Green Kiwi Games, un sencillo portal que le permite a un usuario crear juegos de cartas de manera muy fácil, casi a golpe de clic. En un mundo en el que va dominando el do-it-yourself, descubrí auténticas comunidades dedicadas a hacer juegos de cartas personales y de distribución fuera de los canales habituales comerciales.

Si embargo, no hay dos sin tres, de modo que aproveché este mini proyecto para meterme de lleno en tecnologías que me apasionan, de modo que puedo decir que he pasado por todos los elementos que debe dominar un full-stack-developer y que describo a continuación.

Muy brevemente resumo todas las piezas que he ido utilizando, al menos las más relevantes:

• Por supuesto NodeJS. He sufrido en el camino el cambio producido con la integración por fin de io.js y la creación de la Node.js Foundation, magnífica noticia para quienes amamos este entorno.
• Express para la construcción de la infraestructura de la web con infinidad de módulos relacionados y bien integrados.
• AngularJS para el front-end.
• Muchísimas pruebas unitarias con Mocha para su ejecución y Chai como librería de aserciones.
• Lodash que me ha salvado la vida para construir código más legible. Impresionante el trabajo de la gente de esta librería.
• FabricJS tanto en el front-end como en el back-end para la construcción de las cartas.
• ImageMagick para el tratamiento de imágenes.
• Redis para el mantenimiento de las sesiones de usuario así como para almacenar ahí información útil y relevante y no abusar de la base de datos.
• S3 de Amazon para el almacenamiento masivo de las imágenes y pdfs finales.
• wkhtmltopdf para la construcción de los pdfs con las cartas construidas.
• Grunt como gestor de tareas para la construcción del proyecto de cara a su despliegue.
• Despliegue en DigitalOcean con nginx con un certificado adquirido desde Namecheap.
• Y muchíisimos más paquetes y librerías.

Del mismo modo, este proyecto me ha permitido adentrarme en todo lo relacionado sobre rendimiento y seguridad web, tema fascinante y que dejan muy de lado muchos desarrolladores de aplicaciones web y con un enorme campo comercial por delante: optimización de todos los assets del proyecto, carga retrasada de imágenes sólo si se muestran en el navegador, minificación de ficheros, optimizaciones en javascript, reducción del número de requests, seguridad frente a los ataques más comunes, etc. Este tema me gusta muchísimo y de hecho estoy escribiendo unos cuadernos prácticos de cara a su publicación en 2016.

¿Y ahora qué? Realmente es después de crear el producto mínimo viable cuando se abren todas las posibilidades: el MVP es un primer paso con el que validas cualquier idea, después hay que recibir todo el feedback posible para mejorarla, pivotar sobre algunos conceptos o bien tirar la idea a la basura y a otra cosa. Esto es así, aunque lo bueno es que podemos probar ideas con una metodología sin reinventar la rueda continuamente y sin dedicar demasiado esfuerzo en ello.

Mi interés fundamental con Green Kiwi Games es ayudar a esa comunidad de creadores de juegos de cartas a realizardos y fomentar esa actividad. También conocer desde dentro la construcción de un proyecto real con esas tecnologías y no quedarme en sencillos artículos que te muestran sólo la punta del iceberg. Sobre todo, conocer de primera mano cómo se debe construir un proyecto de esta naturaleza para su escalabilidad futura en caso de tener miles de usuarios.

Si quieres conocer una tecnología, la mejor forma es construir un proyecto real con ella.

Para la idea esencial me he centrado en lo que considerado importante, no obstante, los próximos pasos serán:

• Hacer la web responsiva. Ya sé que existe el enfoque mobile-first pero para avanzar hacia el MVP lo descarté en un principio.
• Añadir características muy poco a poco según el feedback recibido. Me gusta en enfoque de Accuradio: si usas a menudo su servicio para escuchar las maravillosas compilaciones de música que hacen, te darás cuenta de que poco a poco van agregando pequeños detalles y mejoras, muy sutilmente.
• Si el proyecto despega, lógicamente habrá que prepararlo para su explotación comercial con un modelo de negocio que lo haga sostenible, para lo que contaré sin duda con la empresa para la que trabajo. Para esto hay gurús que opinan que el proyecto debería generar ingresos desde un primer momento, aunque este es un proyecto personal con el que sencillamente me relajo trabajando en cosas que me gustan. Si el proyecto o su futura evolución funciona, los ingresos llegarán de un modo u otro.

Si una cosa importante he aprendido con Green Kiwi Games, es el poder de las pequeñas tareas mantenidas en el tiempo: pequeños ratos, unas horas los fines de semana, lecturas en el baño de artículos relacionados (...), en fin, cualquier momento es bueno, al cabo del tiempo, has acumulado cientos de minitareas que terminan generando un proyecto con cierta madurez y listo para su publicación. La satisfacción de hacer un despliegue final a disposición de todo el mundo es casi adictiva.

Yo insisto siempre en lo siguiente: si trabajas para una empresa, la mejora forma de mejorar tu trabajo y convertirte en intraemprendedor es crear proyectos personales en areas que no tocas frecuentemente. Las habilidades que aprendes en estos últimos terminan volcándose en tu día a día en la compañía para la que trabajas, así que todos ganan.

Uno o dos proyectos personales al año al margen de los que ocupan tu dedicación profesional si es que trabajas para una compañía: ese es siempre mi objetivo y paradójicamente, eso me ha permitido mejorar mi trabajo en la empresa sustancialmente.

Ahora mismo se está viviendo una auténtica ola sobre el emprendimiento en mi país; no sé si en otros lugares está sucediento lo mismo. Lo que debería ser una actitud que se les enseña a los niños desde parvulario, ahora parece que lo estamos aprendiendo a marchas forzadas (por la urgencia de la crisis económica y financiera que llevamos arrastrando desde hace tiempo).

Revistas y publicaciones, programas de radio y televisión, másters y mucho libro de autoayuda para el desarrollo personal y coaching así como programas de apoyo al emprendedor están ahora por todos sitios.

Para mí todo esto es bueno porque supone que dejamos de pensar que los demás nos van a dar un trabajo y tomamos la responsabilidad de pensar por nosotros mismos, lo que en algunos círculos llaman el empoderamiento personal. Esta misma actitud es también muy positiva como empleado de una compañía, lo que se llama intraemprendedor, es decir, aquella persona que trabajando en una empresa innova o aporta ideas desde su ámbito de responsabilidad manteniendo una actitud proactiva continuamente, con él mismo y con todo lo que le rodea.

Los desarrolladores de software quizá tengamos más facilidades que otros profesionales para emprender en un momento en que todo el mundo mira a Internet y el paradigma económico impulsa la eficiencia y el uso masivo de dispositivos siempre conectados. De ahí que muchos desarrolladores tengan continuamente ideas que poner en marcha con las que intentar emprender un proyecto empresarial.

Programar bien y dominar tecnológicamente ciertas plataformas, no tiene nada que ver con emprender un buen proyecto que funcione comercialmente. Para esto hacen falta muchas otras habilidades que, por supuesto, se pueden aprender.

Lo que no es nada bueno es que se ignoren todas esas habilidades y conocimientos necesarios para montar comercialmente un proyecto. Me preguntaron no hace mucho qué pensaba yo al respecto y cuáles podrían ser los primeros pasos para pasar de la idea al producto, de modo que en esta ocasión me voy a extender un poco más de lo habitual y aportar mi granito de arena para al menos indicar todo lo que hay que tener en cuenta.

Hay cientos de libros, seminarios, cursos y hasta másters que cubren este tema, que, además, evoluciona igual que las tecnologías software. Por tanto, este post viene a ser algo así como una introducción acelerada al emprendimiento con proyectos software.

Por su extensión, he dividido este trabajo en las siguientes secciones.

De la idea al proyecto

En cierta medida, emprender es probar si lo que tienes en mente puede funcionar o no y encontrar un mercado para esa idea o producto. Si de lo que se trata es de probar algo y según los resultados obtenidos, evolucionarlo tantas veces como sea necesario, entonces todo esto huele un poco a ágil y a lean, a iterar sobre algo hasta conseguir un buen resultado.

Muchas veces los errores son grandes maestros. Allá por el 2008 tuve mi primer contacto con un proyecto y una idea emprendedora que fue un auténtico desastre a los pocos meses; la razón es que confundimos la idea con su realización, la amistad con un relación de compromiso en un proyecto común y, por supuesto, una ignorancia total sobre cómo darle cuerpo empresarial a lo que queríamos desarrollar, entre otros muchos errores... Ese primer proyecto fracasado lo recuerdo con cariño por todo lo que me enseñó; también es cierto que ahora se hace mucha apología del fracaso como herramienta de aprendizaje. Digo yo que en un punto intermedio entre la indolencia y el no fustigarnos al tropezar estará la virtud.

En cualquier caso, desde entonces han pasado muy cerca mía multitud de proyectos de conocidos, charlas en eventos sobre modelos de innovación y muchas, muchísimas lecturas al respecto. Igualmente proyectos personales con mayor o menor éxito.

Si estás pensando en poner en marcha una idea que implica el desarrollo de cualquier tipo de software me gustaría decirte que el desarrollo del mismo es tan sólo el centro de un universo de variables y tareas que hay que hacer bien, relacionadas o no con el software pero que sin ese universo tu idea no llegará a ninguna parte, me temo.

Como desarrolladores nos gusta dedicar gran parte de nuestro tiempo programando, creando artefactos que hacen algo, pero si desarrollamos un proyecto emprendedor basado en software, entonces no podemos ignorar dotarle de la estructura emprendedora correcta. Y, por supuesto, estar dispuesto a gastarte algunos eurillos... Esa coletilla de comenzaron sin nada es sólo un mito urbano que pudo funcionar para algún visionario pero de ninguna manera es lo general. No entiendo cómo alguien que dice creer en su idea después no es capaz de invertir en ella algo de dinero.

Veamos cuáles son esas piezas fundamentales en las que casi ningún emprendedor de software ilusionado apenas repara y ni le da importancia y, sobre todo, cómo algunas decisiones desde el punto de vista del software son fundamentales.

La idea, por evidente que parezca decirlo, sólo existe en la cabeza

¡Qué sorpresa! En otras palabras, lo que quiero decir es que si esa idea no sale de la cabeza cobrando vida mediante la acción, ahí quedará, como un ente mental sin valor. Para la mayoría de la gente, las ideas se quedan ahí dentro, sólo para unos pocos la idea es lo suficientemente fuerte para pasar a la acción.

En multitud de ocasiones pensamos idílicamente en un proyecto maravilloso, único, que podría funcionar, es decir, generar usuarios y clientes y por tanto, ingresos. Entonces hacemos planes de cómo hacer esto o aquello, sobre qué tecnologías usar (a menudo son siempre las que más conocemos), las posibilidades que se podrían abrir y un largo etcétera. 

En ocasiones, también, estas maravillosas ideas no son más que quimeras mentales para huir de una realidad personal o laboral que no te gusta. Esto lo he visto hasta la saciedad.

Si eres un iluso, quédate en el mundo de las ideas, pero sólo las que inducen a la acción, al trabajo y al esfuerzo, saldrán adelante.

No hace falta inventar un proyecto maravilloso y totalmente innovador: muchas veces, propuestas que parecen triviales y hasta aburridas son las que encuentran un mercado y una viabilidad.

En mi opinión existen dos momentos claves para pasar de esta fase (llamémosla de la idea al proyecto). La primera es sentarse tranquilamente a poner por escrito una descripción clara del proyecto, su misión, sus expectativas, etc. Poner por escrito todo lo que tenemos en la cabeza tiene un valor incalculable por la sencilla razón de que te obliga a definir cosas que hasta ese momento sólo eran entelequias un poco vagas. Muchas ideas no pasan de esta prueba...

Existen técnicas para pasar al papel una idea de proyecto, como la técnica del canvas (o lienzo), con herramientas online que te ayudan a su definición, como Canvanizer. Del mismo modo, los mapas mentales también ayudan en esta fase.

El segundo momento, si es que se ha superado el primero, es adquirir un compromiso con uno mismo. Ningún proyecto incipiente se va a desarrollar si antes no nos comprometemos personalmente con él, esto es, no nos comprometemos a sacar tiempo extra (quitándonos tiempo de ocio, de fines de semana, etc.). Sólo cuando hay compromiso personal es cuando se llega a algo. Lo sorprendente es que cuando crees en algo, no hay esfuerzo que valga, ya que estás deseando dedicarle tiempo.

Al menos eso funciona para mí: cuando hemos terminado una fase de un proyecto a tiempo, o realizado cualquier proyecto personal sea del tipo que sea, la mayor satisfacción me la produce el haber cumplido con un compromiso personal previo autoimpuesto.

Si este paso a la acción te cuesta trabajo necesitas urgentemente El Arte de Empezar de Guy Kawasaki.

Hay que validar la idea

Me gusta el enfoque lean en la realización de proyectos, sobre todo si son proyectos basados en software que viven en un mundo acelerado en donde los paradigmas cambian tan rápido. Lo que triunfa ahora es la disrupción. 

Los principios de trabajo "lean" me entusiasmaron desde el primer momento en que tuve conocimiento de ellos. El desarrollo ágil viene de la aplicación en cierta medida de los principios de desarrollo lean y guarda muchas similitudes con estos principios. Como todo, si algo es simple, fácil de entender y sencillo de poner en práctica y de sentido común tiene el éxito garantizado. No obstante, me sorprende cómo muchos de estos principios son totalmente desconocidos para muchos desarrolladores de software y emprendedores de cualquier naturaleza.

El Libro Negro del Programador ha sido escrito siguiendo algunos de los principos lean y su finalización (en el momento de escribir esto está en fase de edición) ha sido posible por y gracias a esta metodología.

Muy pero que muy básicamente, la concepción lean en el desarrollo de un proyecto nuevo y emprendedor viene a indicar que no podemos esperar al final del mismo para comprobar si va a tener éxito o no. ¿Cómo puedo averiguar si una idea genial que he tenido puede convertirse en un éxito comercial? Uno de los errores de muchos emprendedores es volcar todo el esfuerzo, tiempo y dinero en terminar algo completamente antes de lanzarla y después esperar (y rezar) para comprobar si tiene buena acogida o todo lo contrario. En ocasiones cuando se llega al final ha pasado tanto tiempo que la genial idea ya ha sido superada por otras en el mercado, o bien se pule y refina el proyecto tanto que se sufre de parálisis por análisis.

Una de las historias fascinantes que cuenta Eric Ries en El Método Lean Startup es la del dueño de Groupon, actualmente una multinacional con presencia y servicio en multitud de países para el intercambio y promoción de cupones de descuento. Desde luego no invirtió en crear toda la infraesctutura actual de Groupon para ponerse en marcha, sino que comenzó muy humildemente probando el concepto con sus familiares y amigos y, de ahí, según la respuesta obtenida, fue mejorando continuamente y dándole forma como proyecto empresarial. Convirtió una idea sencilla, práctica y barata de probar, en una compañía global.

Del mismo modo, desde El Libro Negro del Programador he ido compartiendo los avances de los capítulos para obtener feedback y comprobar el grado de interés que pudiera despertar un proyecto así. ¿No ocurre lo mismo que en software cuando le enseñamos a un cliente cómo se van implementado las historias de usuario para afinar en requisitos y su idea de lo que quiere y necesita?

Afortunadamente, desde los primeros capítulos, El Libro Negro del Programador despertó suficiente interés como para perserverar en su avance, en forma de correos de ánimo, mensajes sobre erratas, sugerencia de nuevos capítulos, puntualizaciones, diversos puntos de vista, ayuda para revisar los documentos gramatical y ortográficamente (gracias Luis)  y, para mí lo más gratificante, preguntas del tipo "¿cuándo y cómo podré adquirir el libro?".

El método lean no sólo te ayuda a comprobar el interés en algún tipo de idea o proyecto, sino que te permite mejorarlo y afirnarlo mediante una táctica de pivotar sobre la idea o perseverar en ella.

Estamos aprendiendo a hacer las cosas de otro modo, a emprender proyectos con otras tácticas; también la redacción de un libro se puede enfocar así.