I create cool stuff (which mostly means digital products). Follow me on Twitter or Instagram!

Wakefy está justo ahora en Product Hunt 😻, la popular web americana para votar los mejores productos del mundo. ¡Pasaos a verlo!


La mayoría de ideas que tenemos se quedan en el tintero.

Eso es así, y es normal: todos tenemos decenas, cientos de ideas que en el mejor de los casos se quedan guardando polvo apuntadas en una libreta, ante la misma escasez de recursos que todos sufrimos. Recursos de tiempo, principalmente; o de dinero, que nos permita comprar el tiempo de otros.

Hace unas semanas, me pareció importante reservarme unos días para ejercitar el “músculo de poner cosas en marcha”. Siento que muchas veces se nos atrofia: el día a día, el estar a otras tareas. Cosas que consumen tiempo que no dedicas a darle vida a tus ideas.

Y yo tenía una idea a la que darle vida.

La idea

Dejad que os ponga en contexto.

Ocurre que soy de despertar difícil. No que me despierte de mal humor, que también, sino que me cuesta horrores despertarme. No es nuevo, y viene a raíz de un trastorno del sueño poco común que engaña a mi cerebro haciéndole creer que aún es de noche cuando ya es de día. Esto me ha traído no pocos problemas, como podéis imaginar, y es algo que he intentado solucionar desde hace tiempo. Darle solución a este problema era mi prioridad uno de uno.

También he desarrollado una pasmosa habilidad para apagar las alarmas del móvil sin abrir un solo ojo, móvil que (como nos pasa a todos) siempre suele estar al alcance de mi mano desde la cama. Por no hablar de la manía que les he cogido a los distintos tonos y timbres de alarma del dispositivo. Horribles.

Además, por deformación profesional, suelo trabajar con mi ordenador portátil todo el día. Es mi ordenador personal, lo uso para todo y, por ende, suele ser lo último que leo antes de irme a dormir. Cuando termino de trabajar por la noche, se suele quedar a pocos metros en la mesa al lado de mi cama, velando mi sueño.

Así que, me dije un día así en estilo indirecto, ¿cómo puedo hacer para ir despertándome paulatinamente (no tan de golpe como con esa alarma del demonio) y después forzarme a levantarme físicamente, al menos para apagar la alarma?

Sería genial despertarse con una de esas playlists tan chulas de Spotify y que suene en el ordenador que tengo encima de la mesa (en lugar de en el móvil que tengo al lado), para así tener que forzarme a ponerme de pie y caminar para apagarlo. Seguro que eso me espabila.

Spotify no tiene esa funcionalidad, así que saqué mi navaja suiza informática y descubrí que había una manera de hacerlo con programación. Requería varias cosas bastante complejas desde el punto de vista informático y era muy engorroso: tenía que repetir el proceso cada vez que quería poner la alarma, lo que terminaba desesperándome; así que decidí hacer algo para automatizarlo todo.

Al fin y al cabo, sería genial poder convertir tu ordenador en un despertador con tu música favorita de Spotify.

El reto

Un mentor me dijo hace poco: «la única diferencia entre un sueño y un objetivo es poner una fecha».

Cuánta razón. Puedes desear hacer algo todo lo fuerte que quieras, que no ocurrirá a menos que le pongas una fecha límite.

Mucha gente dice que lo difícil es empezar a hacer algo: yo creo que es todo lo contrario. Lo difícil es continuarlo hasta terminarlo. Así que tenía que haber una fecha límite con objetivos muy claros.

Tres días.

Quienes me siguieron en Instagram pudieron vivir la experiencia en directo 😎

No tenía idea de programar aplicaciones de escritorio y tendría que aprender sobre la marcha, pero el proyecto no parecía complejo, así que me puse de reto hacerlo en tres días. Tres jornadas laborables, unas 24h. Estilo hackathon. Un día entero sin dormir, por si me daba por hacerlo en plan hardcore. El objetivo era tener un producto plenamente funcional para el final del tercer día. Algo que enseñarle al mundo.

¿Habéis oído hablar de las tres restricciones de un proyecto? Básicamente viene a decir que la calidad de tu proyecto está restringida por 3 cosas, como si fueran los 3 lados de un triángulo: por el tiempo que tienes para llevarlo a cabo (a más tiempo, más calidad), por cuánto te cuesta hacerlo (en euros, en personas o en el recurso que sea) y por cuál es el alcance del proyecto, cuánto abarca (cuanto más abarque un proyecto, más costoso y largo será). Viene a decir, también, que no se pueden obtener cosas de calidad en poco tiempo y con pocos recursos si intentas abarcar mucho.

project-management-tiempo-coste-alcance-calidad.png
Las 3 restricciones de un proyecto en “project management”

Restringirlo a 3 días me obligaría a mantener un focus absoluto (no solo en productividad, sino en no perderme en detalles que no aportaran valor).

Leí hace poco esto en un libro sobre diseño de videojuegos:

A game prototype should be created and playtested, at the absolute least, 20 percent of the way into a project schedule. If a game is a two-week student assignment, the students should be playing a version of the game two days after it is assigned. (…) Early prototypes are not pretty.

A priori el de los videojuegos podría parecer un mundo sin relación alguna, pero creo que es no es más que una manifestación de lo mismo: todo se basa en diseñar y construir la mejor experiencia posible para que un usuario la disfrute. Y, sabiendo esto del 20%, las cuentas estaban claras: tendría que tener un prototipo “jugable” dentro de las 5 primeras horas.

Día 1: el prototipo

Objetivo: aprender y construir un prototipo funcional.

Puede ser más feo que una nevera por detrás, pero tiene que realizar la tarea.

Recientemente un concepto nuevo entró mi vida: “throwaway codebases”. Venía también del mundo de los videojuegos, y me pareció de las cosas más liberadoras que me habían dicho últimamente. El principio es sencillo: hacer código para tirarlo después de usarlo.

Programa un prototipo, pero ten claro que el prototipo está para lo que está y lo vas a tirar a la basura en cuanto cumpla su objetivo. No te preocupes por hacer buena ingeniería ni por tener una buena estructura, todo eso irá llegando. Programa el prototipo todo lo rápido que puedas y no te preocupes porque el código no sea perfecto, porque vas a tirarlo todo una vez cumpla su cometido.

Un prototipo sirve para lo que sirve: entender mejor el problema y la solución. Todo lo que no sea esto, fuera del prototipo.

Así que me puse a programar el prototipo. Usé Electron, lo que me permitía trasladar mis conocimientos para crear páginas web al mundo de las apps de escritorio (es la misma tecnología con la que están construidos Slack o GitHub, por ejemplo). Detalles técnicos aparte, no os hacéis a la idea de la de pequeñas minucias que pueden hacer que un proyecto así no funcione en absoluto. Problemas en los que no habías caído pero que tienes que solucionar para que todo funcione.

Total, que lo hice, aprendí sobre la marcha y programé la app más sencilla y fea del mundo en 5 horas. Sencilla, pero cumplía el objetivo de hacer sonar la música a una hora determinada.

Así lucía Wakefy (nacido con el nombre Spotalarm) al terminar el primer día:

Screen Shot 2017-07-03 at 21.25.50.png
El prototipo (la magia estaba detrás)

Era sencilla y fea, pero funcionaba.

Día 2: el diseño

El día 2 ya me desperté con Wakefy.

Funcionaba, pero era horrible. Como diseñador, esto me suponía una gran lucha interna. Odiaba ver tan fea a mi criatura. Se merecía que le dedicara todo el segundo día al diseño de interfaz e interacción. A ofrecer la mejor experiencia posible.

Solo usándolo una noche ya aprendí muchas cosas: hay que poder especificar qué días quieres que se repita la alarma, sería útil tener un botón para suspender el ordenador desde la propia aplicación, estaría bien poder calcular cuál es el mejor momento para despertarme en función de mis ciclos de sueño. Ideas, ideas, ideas.

Unas ideas más importantes y cruciales que otras, sin lugar a dudas. Tendría que afrontar estos dilemas durante el diseño.

Así boceté la aplicación en baja fidelidad por la mañana:

Low fidelity mockups / wireframes for Wakefy
Low fidelity mockups / wireframing

Y así la diseñé en alta fidelidad por la tarde:

High fidelity mockups in Sketch for Wakefy
El diseño de alta fidelidad, en Sketch

Enhorabuena, es usted padre, ha sido una preciosa app.

Día 3: la ingeniería

Empieza un proyecto en blanco. Tira el prototipo, pero quédate con las piezas que sirvan. Rehaz lo que no estuviera bien hecho. Divide el objetivo global en subobjetivos cruciales, subobjetivos “nice to have” y subobjetivos para futuras versiones. Empieza la cuenta atrás, tienes 8 horas para programarlo y terminarlo.

No tengo mucho que decir del tercer día: es la parte más mecánica, más analítica. Todo se basa en:

  1. Creer que sabes hacerlo
  2. Ponerte a hacerlo, darte cuenta de que no es así y dejarte sorprender con problemas y casuísticas muy concretas que no te habías planteado
  3. Buscar en Google cómo solucionarlo
  4. Repetir

Sobre las ocho de la tarde pude grabar este gif. Wakefy estaba casi terminado. Solo quedaban pequeños detalles por pulir.

GIF mostrando el funcionamiento de la primera versión beta de Wakefy
Funcionamiento de la primera versión beta

Saliéndome un par de horas del objetivo, pude empaquetar la app y pasársela a algunos amigos.

Lo había conseguido.

Días 4, 5 y 6

Espera, creía que habías dicho que lo habías conseguido. Ya está, ¿no? ¡Termina de una vez este tostón de artículo, pardiez!

Calma, lectores, calma. El objetivo inicial estaba conseguido, sí, pero servía como poco más que un juguete. Dejad que os cuente por qué:

  • La app no tenía buen branding
  • La app no estaba preparada para distribución: pesaba más de 250Mb porque estaba preparada para desarrollo (no optimizaba ni comprimía nada)
  • No había estrategia alguna de distribución. Ni siquiera había página web: quienes la quisieran me la tendrían que pedir a mí personalmente (después de contactar conmigo de alguna forma, claro)
  • No había ningún tipo de analítica digital: no sabía quién, ni cómo, ni cuándo veía o usaba la app
  • Había errores y bugs que podían hacer que no funcionara en absoluto si no se sabía cómo proceder en cada caso
  • La app no se podía cerrar (literalmente, no había manera “razonable” de cerrarla una vez abierta)

Todo esto caía dentro de una de estas dos categorías:

  1. Marketing y distribución de la app
  2. Iteración, mejora y corrección de errores

Los 3 días siguientes se fueron precisamente en eso: tareas necesarias que no tenía contempladas, bien porque subestimé el coste de ciertas operaciones (como corrección de errores: creí que al final del día 3 todo lo hecho estaría perfecto, o al menos lo suficientemente bien como para enviarlo a la Mac App Store) o bien porque directamente no creí que fuera a hacerlo (marketing: creí que haría el branding en el día 2 junto con el diseño de producto; distribución: creí que optaría por la Mac App Store desde el minuto cero y no le haría una web a la app. Error: por su naturaleza, Wakefy no es admitida en la Mac App Store y la única manera viable de distribución es con medios propios).

Pero, al final, tres (seis) días y 7€ después (lo que me costó comprar Wakefy.com), Wakefy era una realidad tangible que cualquier persona del planeta se podía descargar y usar. Reto superado.

Conclusiones y lecciones aprendidas

Nada de esto tendría sentido si no hubiera aprendido cosas por el camino. Muchas de ellas de alguna manera ya las conocía, y me suena obvio decirlas ahora, pero es ese tipo de conocimiento que tenías latente y que hasta que no experimentas no lo interiorizas de verdad, ¿sabéis a lo que me refiero? Como cuando te dicen de pequeño “Javi, no te subas a la silla que te vas a caer”, y no es hasta que te das la torta en el suelo que realmente lo aprendes.

Otras cosas las he metido aquí en plan repaso, como lecciones aprendidas de experiencias pasadas que igual os resultan útiles.

Ahí van mis 15 lecciones aprendidas (o repasadas) haciendo Wakefy:

  1. Deberías tener un prototipo funcional, a más tardar, al 20% del proyecto, por muy feo que sea.
  2. Un prototipo solo sirve para aprender sobre el problema y la solución.
  3. Throwaway codebases: el código que escribas para el prototipo no tiene que ser perfecto. Piensa que vas a descartarlo todo y date libertad para hacer guarradas con tal de que funcione. Itera rápidamente.
  4. Se aprende haciendo: empieza a hacer y ve buscando soluciones por el camino según aparezcan los problemas. Da igual que no sepas, todo es empezar.
  5. Expón cuanto antes tu producto al mercado. 3 días igual es un poco intensivo para la mayoría de proyectos, pero desde luego creo que deberían ser, como mucho, semanas; o algo estarás haciendo mal: o tu proyecto es demasiado amplio y deberías poner el foco en una parte concreta, o estás muy al inicio de tu curva de aprendizaje en una habilidad clave y necesitas más experiencia en ella.
  6. Al menos la mitad del tiempo del proyecto se irá en temas de negocio que nada tienen que ver con el desarrollo (branding, distribución, marketing en general. Por no hablar de operaciones, si las hubiera, administración…)
  7. Al menos la mitad del tiempo del desarrollo se irá en iterar y corregir cosas que ni te habías planteado, ni había manera humana en las que las pudieras haber predicho.
  8. Hay cosas (requerimientos funcionales o no funcionales) realmente críticos que son los que definen la esencia del proyecto y los que deberían cumplirse a toda costa. El resto son necesariamente secundarios, y por tanto prescindibles, por mucho que duela. Confundir objetivos secundarios con objetivos críticos hará que inviertas recursos en cosas que no aportan demasiado valor, y por ende, que tu proyecto esté un paso más cerca de fracasar. Delimita bien el alcance del proyecto y poda todo lo innecesario. No quieras abarcar todo, no se puede. Hay que dejar cosas fuera.
  9. Existe un compromiso entre hacerlo todo, hacerlo rápido y hacerlo con buena calidad. No se pueden hacer cosas muy grandes con mucha calidad en poco tiempo, así que o reduces la cantidad de cosas a hacer o aumentas el tiempo.
  10. Terminar es lo difícil, no empezar: un proyecto no está listo para el mercado hasta que no hay usuarios que lo pueden disfrutar sin que tú intervengas en el proceso. Si la app funciona solo en tu ordenador, o si para que funcione hay que hacer algo aparte de descargar e instalar, no está terminado.
  11. El diseño no solo lo es todo: el diseño es la base de todo. Buena ingeniería con mal diseño es igual a desastre.
  12. El diseño es diseño porque tiene un propósito: resolver bien un problema. Si no, sería arte. Un buen diseño es bonito, y a la vez funcional.
  13. Se diseña para un tipo de usuario concreto, que es el que define el proyecto. El paso cero de diseñar es empatizar con este usuario y su problema, así que o tú eres el usuario tipo y sufres ese problema en tus propias carnes o tendrás que dedicarle una buena cantidad de tiempo a empatizar con ellos para diseñar una buena solución.
  14. No puedes gustarle a todo el mundo: siempre hay gente que ha de quedarse fuera de tu target. Y gente a la que no le gustarás por muy bien que lo hagas.
  15. Y, sobre todo: las ideas son solo ideas hasta que decides llevarlas a cabo, ¡así que empieza a poner objetivos con responsable y fecha límite!

Cabe decir que Wakefy se pudo hacer en tres (seis) días por la relativamente baja complejidad del proyecto: apenas tenía dos o tres “pantallas” distintas, no había que gestionar login de usuarios, ni desplegar y configurar complicadas infraestructuras… ni siquiera había que gestionar una base de datos compleja. Quizá estos plazos no son realistas para la mayoría de proyectos informáticos, pero desde luego creo que las proporciones y los principios que he contado (sobre todo en la parte de prototipado) son más que razonables.

Con esto, creo que solo queda enseñaros cómo es ahora, y deciros que, si queréis, os podéis descargar Wakefy gratis aquí y probarla vosotros mismos. ¡Espero vuestras opiniones! 😉

wakefy-og-picture-twitter.png
¡Haz clic para ver / descargar Wakefy!

 

¿Te ha gustado? Sígueme en Instagram y Twitter.

¿Tienes preguntas? Contacta conmigo.

Oh, and by the way!

If you wanna keep up to date with my new posts and public launches and all that stuff (fuck, no, I won't send spam, why would I do that) please consider subscribing for free:

You can obviously unsubscribe anytime with a single click.

Comments

comments