De cero a App Store en 7 semanas

Hace algunos meses comenzamos a trabajar en un nuevo producto dentro de beek.io. Y en cuanto comenzamos con la idea, casi de manera inmediata, surgió también la pregunta más común e incomoda para un líder técnico o de producto:

¿Cuánto tiempo nos tomará?

Por suerte, no es la primera vez que me toca ser responsable de responder esta pregunta y creo que entiendo (suficientemente) bien las diversas consecuencias de cómo decido formular mi respuesta.

Este blog post es la historia de una de las muchas maneras en las que, quizá en el futuro, puedas contestar esta pregunta perenne de los que construimos con código.

Primero, ¿cómo respondes sin equivocarte de una manera catastrófica?

Sin duda, responder la pregunta es una de las habilidades más importantes que todo programador tiene que dominar a lo largo de su carrera. Y lamentablemente, la industria y la filosofía común de cómo construir software normalmente nos recomienda no responderla... mínimo no con una respuesta certera porque no vaya a ser que nos equivoquemos. (Si somos honestos, la mayoría de las veces nos vamos a equivocar).

Por eso hablamos constantemente de estimaciones y puntos o unidades adimensionales y relativas en lugar de tiempos reales y certeros. Sprints con avances constantes pero nunca fechas de compromiso. Hemos hecho hasta lo imposible por no contestar esta pregunta. Construimos la iglesia de los santos ágiles para que nos den el poder de invocar los mágicos puntos de poker con tal de no responder esta pregunta. Y está bien, a veces eso es lo mejor que podemos hacer con lo que tenemos.

No me malentiendan, yo también he sido un practicante devoto y feliz del Scrum. Sin embargo, tengo la fortuna de trabajar en un equipo increíble que está dispuesto a cuestionarse todo para seguir mejorando (a pesar de llevar casi tres años de sprints “ágiles”, constantes y productivos).

En Beek, siempre hemos tomado las metodologías ágiles como lo que son: filosofías de trabajo y comunicación que se adoptan cuando dan un beneficio, pero no son un dogma inamovible que se debe seguir al pie de la letra.

Y a pesar de que acabo de tirarle a sus majestades Fowler, Beck y sus cuates, irónicamente la respuesta que decidí dar fue la misma que ellos: no contestar la pregunta. Pero en lugar de evadir la pregunta con una respuesta de puntos, estimados, pronósticos de velocidad y líneas de tendencia, lo que decidimos fue plantear una pregunta distinta:

¿Qué podemos construir y lanzar en seis semanas?

Empieza con un apetito

En lugar de preguntar cuánto tiempo nos tomará este nuevo proyecto nos hicimos la pregunta opuesta: ¿cuánto tiempo queremos invertir a esto para convertirlo en realidad?

¿De qué tamaño es nuestro apetito para invertir en este nuevo producto o funcionalidad?

Este simple cambio de paradigma te da una perspectiva distinta. El triángulo de la administración de proyectos toma un nuevo significado. Asumiendo siempre recursos constantes, lo que ahora está fijo es el tiempo. Antes, lo que era fijo era el alcance y el tiempo podía variar, pero ahora la variable que podemos manipular es el alcance.

Y aunque dé miedo tener algo que haga menos o parezca contraintuitiva la idea de limitar lo que tu producto hace, esta es la única manera en la que vamos a lograr nuestro objetivo en el tiempo prometido. El objetivo ahora es tener algo listo sí o sí en las seis semanas definidas, y la nueva pregunta a responder es:

¿Qué es lo mejor que podemos lograr en ese tiempo?

Esta sabia filosofía obvio no me la saqué de la manga ni la inventé yo. Los genios de 37signals son quienes nos inspiraron y han profundizado en esta manera de construir producto en su libro Shape Up (es gratis, por favor no te quedes sin leerlo).

Define la forma de lo que quieres lograr

El libro tiene el nombre de Shape Up porque la parte inicial del proceso es definir la forma o el contorno de tu nuevo producto o funcionalidad. Describir el objetivo con suficiente calidad para que sea claro y alcanzable, pero dejando los detalles de diseño e implementación abiertos para ser flexibles a una solución que se pueda ejecutar de manera real conforme avanza el tiempo designado.

Esta definición se tiene que hacer antes y toma bastante tiempo. No solo se trata de comunicar qué nos imaginamos con la solución, sino entender profundamente el problema, por qué lo queremos resolver y cuál es nuestro apetito real para lograr una solución. Así como el contexto del equipo, la tecnología y el producto que ya existe.

Este último punto es importante porque en el título del post, cuando digo siete semanas me refiero a empezar a hacer Figmas y código pero no a definir qué es lo que queremos lograr y cómo se ve más o menos el resultado que esperamos o, aún más importante, por qué esto es valioso para nuestro negocio y usuarios (pero esa es una plática para otro día).

Para responder estas preguntas (muy importantes), hicimos mucha investigación previa con usuarios y tuvimos dos Design Sprints con ciclos de prototipado y pruebas de usabilidad. Una vez que teníamos convicción, entonces, empezó el proceso de decidir cómo hacer este nuevo producto realidad.

Para definir la solución y el apetito, el equipo de 37signals habla de utilizar fat marker sketches (bocetos con marcador de punta gorda). La idea es definir la solución utilizando bocetos que no tengan mucho detalle pero que den suficiente claridad de lo esperado para que el equipo de ejecución pueda "llenar entre las líneas".

También hay que construir un documento, el pitch, el cual explica claramente el objetivo a lograr (para el usuario y negocio), el apetito (en semanas), la solución como shape y el contexto necesario para que el equipo de ejecución pueda tomar las decisiones correctas al momento de colorear nuestro boceto y ponerle detalles.

El pitch debe ser creado por una o más personas capaces de entender el producto, la tecnología, el diseño y el negocio (al usuario) para que nos aseguremos de que podemos cumplir con nuestro apetito. Pero estas personas que definen o dan forma no serán quienes ejecuten el proyecto; para eso tienes un excelente equipo de programadores y diseñadores que harán esto realidad y convertirán tu boceto en una obra de arte real.

Suelta las riendas y deja que los expertos hagan lo suyo

Esta es la parte más difícil, ya que no definiste los detalles y te sientes incómodo de que el resultado no sea exactamente lo que esperas. Pero no pasa nada, si no sueltas las riendas y permites que el equipo ejecute con autonomía (además de tu apoyo y guía constante) el resultado probablemente no será bueno.

Si es la primera vez que trabajas con este equipo, probablemente no salgan bien las cosas, pero seguramente tampoco con otras filosofías de trabajo saldrían a la primera, y eso está bien. Es parte de formar a un equipo: fallar y adaptarse. Hay que construir confianza y conocer muy bien las fortalezas y debilidades de todos para ser capaces de construir y lanzar productos con velocidad y calidad.

En nuestro caso, es muy importante notar que el equipo con quienes ejecutamos este proyecto tenía casi tres años trabajando junto y el último miembro que se unió llevaba casi un año con nosotros en este punto. Hemos lanzado decenas de funcionalidades, tenemos un equipo que puede hacer todas las especialidades y generalidades necesarias y hemos construido la confianza suficiente y la cultura de excelencia para poder trabajar de esta manera.

También fue muy importante hablar mucho sobre esta nueva filosofía de trabajo, tanto en juntas del equipo como en juntas one on one. "Socializar" el cambio es parte fundamental del éxito. Escuchar las preocupaciones y ayudar a todos a estar comprometidos y convencidos de que esto puede funcionar es una de las cosas más importantes a considerar.

Para comenzar cada uno de los flujos de trabajo, organizamos un kickoff formal de cada pitch/proyecto y, a partir de ese punto, es responsabilidad de los diseñadores e ingenieros trabajar en la definición e implementación de los detalles. Cada equipo de ejecución debe ser pequeño, 3 o 4 personas máximo (idealmente 2: diseñador + ingeniero). Es importante mantener cada flujo de trabajo separado y con pocas personas para que la comunicación sea rápida y el trabajo fluido.

Dado que nuestro objetivo era un producto completamente nuevo y no solo un feature, en este punto formamos tres equipos de entre 2 y 4 personas (diseño + ingeniería) y cada equipo comenzó a trabajar en su parte del nuevo producto. En paralelo, teníamos un pequeño equipo adicional que comenzó un poco antes que el resto para sentar las bases de la aplicación sobre la cual los equipos iban a construir.

Te puedes comer una rebanada sin comerte todo el pastel

Una vez que el equipo entiende el objetivo y los bocetos, es hora de dividir el contorno de la solución en rebanadas que puedas ver claramente y que juntas formen el pastel completo.

Y aquí es importante pensar de manera full-stack y empezar con la solución más sencilla posible para cada rebanada y de ahí mejorar. Si analizas los pedazos a construir, cada uno debe ser un pedazo completo y funcional. La suma de las rebanadas debe sumar el contorno completo que se definió en el shaping.

Cada rebanada está compuesta de capas o layers, las cuales deben componer la rebanada de principio a fin, es decir, backend y frontend (o cliente y servidor). Pensar en las rebanadas como pedazos de trabajo completo que van desde el UI hasta la base de datos es importante para lograr funcionalidad rápido y de ahí poder iterar.

Este cambio de perspectiva también evita el fenómeno común de "backend está bloqueando a frontend" o "diseño está bloqueando a frontend" o cualquiera de las combinaciones posibles de una equipo bloqueando a otro.

Al pensar en tu funcionalidad como rebanadas tu trabajo pasa de ser así:

A convertirse en algo que funciona:

Por ejemplo, un pedazo podría ser una forma de login que funcione. La más sencilla posible, aunque no tenga login con Google, ni animaciones, ni password reset. Este pedazo se puede crear por si solo y ser funcional de principio a fin desde la primer iteración, buscando empezar con la versión más sencilla y de ahí mejorarla.

Conforme avancen con la ejecución, el equipo verá cómo el tiempo pasa comparado a su progreso y rápidamente ajustará para agregar más o menos detalles dependiendo de qué tan lejos estén de rellenar todo el boceto y cumplir con el objetivo. Eventualmente habrá ciclos posteriores para mejorar o expandir algo que ya existe, pero esto pasará cuando la versión más sencilla ya funciona y, en el futuro, puedes determinar si tienes más apetito para seguir trabajando en eso o mejor se lo dedicas a algo distinto.

Lo más importante en este proceso es que, aunque la solución que elijan sea la más sencilla, debe ser de la calidad más alta posible. Idealmente, el equipo logra progreso diario y constante y, en lugar de especular sobre las posibilidades y la planeación perfecta, el trabajo sucede sobre discusiones de lo que ya es realidad y funciona. Ejecutar bien la solución más simple (en el buen uso de la palabra) siempre dará un resultado de mayor calidad que ejecutar a medias una solución compleja y rebuscada por más "bien pensada" que esté.

¿Cómo se ve el día a día si no hacemos agile?

La respuesta sencilla es: casi igual. El cambio principal que hicimos fue cómo y a qué nivel de detalle definimos nuestro roadmap en general. Pero el trabajo del día a día fundamentalmente sigue siendo el mismo. Con un cambio importante: para permitir que el equipo de ejecución tenga la mayor cantidad del día disponible para avanzar y colaborar en lograr cosas concretas, decidimos acortar el número de juntas al mínimo.

En lugar de trabajar en sprints de dos semanas, pasamos a trabajar en ciclos de una semana que comienzan con una hora de planning (+ 30 minutos de pre-planning para los managers y leads) y terminan con una sesión de demos de una hora los viernes.

El planning y el pre-planning se tratan de definir objetivos y seleccionar slices en los cuales trabajar. Idealmente, al final de la semana tenemos mínimo un slice terminado para mostrar en el demo. El chiste es siempre poder mostrar progreso funcional aunque esté "incompleto". Dependiendo de cómo lo hagan en tu empresa, esto puede ser muy similar a la filosofía de los sprints ágiles pero sin tener que hacer todo el papeleo.

Los demos se convirtieron en el momento más divertido e interesante de la semana y permitieron a todos mostrar su progreso y recibir feedback. También se convirtieron en una parte muy importante para mantener la motivación del equipo, el buy-in de los stakeholders y promover la colaboración en toda la organización en general (incluso invitamos al equipo de contenido y growth a algunos de estos demos).

En lugar de tener standups largos con todo el equipo (somos ~12 personas en un standup normalmente), pasamos a tener juntas diarias de 15 minutos por track de trabajo. En cada una de estas teníamos solo al Product Manager, Engineering Manager, 2 o 3 ingenieros y un diseñador, por lo que la junta era súper eficiente. Esto resultó en menos horas de juntas a nivel individual y de manera general.

Aparte de los rituales semanales, seguimos haciendo una retro (45 minutos) cada dos semanas con todo el equipo y manteniendo nuestro backlog de bugs, on-call y soporte habituales. Así, el cambio no se sintió tan drástico, pero fue suficientemente significativo para tener un impacto positivo en el trabajo del equipo.

¿Lo volveríamos a hacer?

Definitivamente, sí.

Al inicio, nos preguntamos: ¿si esto sale bien, seguiremos trabajando así en el futuro? Y parece ser que la respuesta es sí. Mínimo durante los siguientes meses en lo que seguimos evolucionando este producto nuevo.

Cuando empezamos estaba seguro de que íbamos a lograr algo, pero (mínimo yo) no tenía idea de que la alta calidad y buena experiencia de colaboración iban a ser tan increíbles como las que logramos alcanzar. Definitivamente el equipo superó mis expectativas y ejecutó como lo que son: unos verdaderos cracks. Y si no te sientes así de tu equipo, probablemente hay cosas más importantes que pensar que cómo defines y ejecutas tu visión de producto.

Eventualmente, quizá lleguemos a la conclusión de que hay que retomar prácticas como PRDs, SPECs y TDDs (Technical Design Documents) una vez que el nuevo producto empiece a incrementar en uso y complejidad o requiera de inversiones más grandes para modificar pedazos grandes ya existentes. Pero según la filosofía de 37signals, esto puede ser sostenible a largo plazo y si resulta serlo para nosotros quizá en el futuro les cuente cómo nos fue.

Gracias por leer y sobre todo, gracias al equipo que lo hizo realidad ♥.

Si te gustó, comparte este post con alguien que le pueda servir. Me puedes encontrar en Twitter si te gustaría hacer preguntas o platicar más sobre estos temas.