Introducción a Shape Up: diseño y desarrollo de productos
Cuando se habla de diseño de productos digitales, la mayoría de las veces pensamos automáticamente en scrum: el backlog, un sprint de dos semanas durante las cuales se trabaja en aportar algo que incremente valor al producto actual y las diferentes reuniones que genera.
Pero si has trabajado utilizando scrum, seguro que estarás de acuerdo conmigo con que tiene algún que otro fallito.
Me leí el libro de Shape Up, la metodología de gestión de proyectos desarrollada por Basecamp, y pensé que sería una buena idea resumir las ideas principales.
No es una solución infalible, ninguna lo es, pero sí ofrece un punto de vista muy diferente que vale la pena conocer.
Qué es la metodología Shape Up
Partamos de la base de que el software tiene un altísimo grado de desconocimiento. Hay muchos problemas y situaciones que no podemos conocer de antemano (cuando planificamos), y solo las vemos una vez nos hemos puesto manos a la obra.
Shape Up es una propuesta para diseñar y desarrollar de productos digitales enfocada en trabajar en proyectos bien definidos y delimitados en ciclos de seis semanas.
En el contexto de Basecamp, Shape Up se basa en estos conceptos clave:
- Se trabaja en ciclos de seis semanas, de inicio a fin. No se trata de contar horas ni de hacer reuniones diarias (como las daily de scrum). No se cambia el roadmap cada dos días ni se cambia el foco del equipo cada dos por tres.
- El equipo que trabaja en el proyecto tiene toda la responsabilidad y es totalmente autónomo. Esto significa que son ellos quienes deciden qué tareas hacer, cómo ajustan el scope y cómo trabajan.
- Shape Up permite reducir los riesgos, ya que el equipo empieza a trabajar en un proyecto cuando ya tiene forma (shaped), después de que se hayan contemplado y trabajado las variables.
Todo esto en cuatro fases: shaping, bet, build y cool down:
Si te fijas en la estructura, tiene dos carriles, out of cycle (discovery, descubrimiento) y in cycle (delivery, entrega).
Las cuatro fases de Shape Up
A grandes rasgos, estas son las cuatro fases de Shape Up. Si quieres profundizar en ellas, te recomiendo que leas el libro (es gratuito, aunque también puedes comprar la edición impresa).
Shape: dar forma
En esta fase, que se lleva a cabo en paralelo a los ciclos, se reúnen varias personas senior de negocio, diseño y desarrollo. En estas sesiones de trabajo asíncronas se definen y perfilan las funcionalidades principales (darles forma, shape) de una solución con el nivel adecuado de abstracción.
Sobre la abstracción, en Basecamp consideran que:
- Si tiene una forma demasiado concreta, como un wireframe, tiene demasiado detalle y demasiado pronto. Se sesga al equipo y se le deja poco margen para afrontar imprevistos o para ser creativo.
- Si es demasiado abstracto, como en una descripción en forma de texto, es demasiado genérico. ¿Qué significa para ti diseñar la vista de un calendario? cada persona del equipo contestará a esa pregunta de una forma diferente. Más abajo describo esto con un case study.
Hay otro aspecto importante a la hora de hacer el shaping: la definición de qué hay que hacer. Como en el caso de la abstracción, los extremos son malos:
- Una definición demasiado laxa es simplemente un deseo: “Como gerente quiero poder consultar las cantidad de pedidos en un solo lugar”. Esto tiene demasiadas incógnitas, muchas preguntas y tiene potencial para estancarse.
- Una definición demasiado estricta define el proyecto de tal manera que no admite ajustes sobre la marcha… ajustes que suceden sí o sí una vez se empieza a trabajar en un proyecto.
Este ejemplo descrito en el libro es muy claro. Supongamos que queremos que nuestros clientes puedan pagar automáticamente (autopay) facturas.
Inicialmente podríamos plantear la solución así:
Después de discutir sobre la solución, parece no tener sentido que la funcionalidad autopay se active antes de pagar la factura, y que quizás es mejor que exista como una opción de configuración al pagar una factura. De este modo, si se activa, todas las futuras facturas tendrán pago automático.
Se termina definiendo que el pago automático esté habilitado por defecto como configuración global y solo exista la función de deshabilitarlo en la página de configuración de cada cliente (customer detail). De esta manera, no se repite/muestra la opción en cada factura.
En pocas palabras: en la fase de shape se investiga y se trabaja en dar forma a un problema y a una solución que se pueda terminar en seis semanas de forma completa.
Escribir el Pitch
El documento resultante de la fase de shaping se llama Pitch y suele tener esta estructura:
- Problema. Información sobre a qué porcentaje de usuarios afecta, qué tipo de usuarios son los afectados (los que pagan vs. los gratuitos, por ejemplo)… suele ser una descripción de por qué lo que hay ahora no funciona.
- Apetito. El estándar son seis semanas, aunque en Basecamp también trabajan con proyectos más pequeños de solo dos. ¿Cómo es la solución que resuelve el problema con esta cantidad de apetito/tiempo?
- Solución. Como te contaba más arriba, tiene que tener un nivel de abstracción y definición adecuado. Si todavía no está claro, hay que volver a la etapa de shaping.
Bet: apostar por un proyecto
En Shape Up no existe el backlog. Trabajan con la teoría de que si una idea es importante, aparecerá constantemente en las conversaciones.
Para ellos no tiene sentido acumular una lista infinita de tickets que rara vez se termina, y en la que se invierte pierde mucho tiempo en las reuniones de planificación y refinement de Scrum.
La Betting Table se produce cuando se decide en qué se trabaja durante el siguiente ciclo. Es una reunión con la figura de CEO, CTO y otros perfiles senior en la que se presentan todos los documentos de Pitch, que no dejan de ser apuestas potencialmente buenas. Si se apuesta (bet) por algún Pitch en concreto, es en ello en lo que el equipo invertirá el próximo ciclo.
Build: construir en seis semanas
En Basecamp trabajan con equipos pequeños: o un perfil de diseño con dos de desarrollo, o uno de diseño y uno de desarrollo. Y el tamaño del proyecto es lo que hemos visto hasta ahora: aquello que pueda construirse en seis semanas.
La fase de Build tiene estas características:
- El equipo no puede ser interrumpido con otro proyecto (bet) durante esas seis semanas
- El tiempo que se dedica es fijo, pero el scope (alcance) puede variar. Al trabajar en algún proyecto siempre se producen estas fases, que permiten definir mejor qué hay que hacer exactamente y cómo se resolverá:
- Si el equipo no es capaz de finalizar el proyecto en ese tiempo, por defecto no hay una extensión. Simplemente no se termina, porque extender el tiempo significaría aplazar otras apuestas y que se ha hecho mal la fase de shaping. Esta situación obliga a parar, reflexionar y reencuadrar el problema.
Cool down: resolver, descansar y enfocarse
Al finalizar la etapa de Build, el equipo tiene dos semanas en las que puede trabajar libremente en lo que desean hacer. En software siempre hay bugs que resolver, refactors por hacer y aspectos de diseño que ajustar.
Caso de estudio: el calendario Dot Grid
Este caso está descrito en el libro, por lo que solo lo resumiré. Lo incluyo para que tengas un ejemplo tangible y en español de cómo manejaron el proyecto utilizando Shape Up.
Los clientes de Basecamp solían pedir a la empresa que “añadiera un calendario”. Alguna versión previa de Basecamp ya tenía calendario, y el equipo sabía que diseñar y desarrollar uno podía requerir seis meses y que aproximadamente solo el 10% de los clientes lo utilizaba. Un calendario suele tener:
- Envío de invitaciones y posibilidad de aceptar, reagendar o rechazar
- Eventos que se expanden más de un día
- Eventos de cualquier duración
- Códigos de color y categorías diferentes
- Varias vistas: diaria, semanal, mensual y anual
- Funcionalidades y adaptaciones diferentes para desktop y móvil
- Capacidad de arrastrar eventos para moverlos
Con estos precedentes, estaba claro que no tenían apetito para trabajar en ello.
Pese a ello, sí querían hacer algo que pudiera satisfacer a los clientes actuales que pedían un calendario. La pregunta es: ¿qué parte del calendario había que construir?
En la etapa de Shaping, llevaron a cabo una investigación con los usuarios y consiguieron reducirlo todo a un caso de uso específico que había que resolver:
Finalmente llegamos a un concepto prometedor inspirado en los calendarios de los teléfonos. Podríamos crear una vista de cuadrícula de solo lectura de dos meses. Cualquier día con un evento tendría un punto. Aparecería una lista de eventos debajo del calendario y, al hacer clic en un día con un punto, se mostrarían los eventos de ese día. Lo llamamos Dot Grid.
Este es el nivel de abstracción que utilizaron para definir la solución:
Con esto, la persona que diseñaba tenía la libertad suficiente para decidir cómo se vería, y técnicamente estaba bien definido.
Este fue el resultado:
Apuntes finales
En este artículo he tratado de resumir las ideas principales de Shape Up, pero si has llegado hasta aquí estoy segura de que te habrás hecho muchas preguntas:
- ¿Cómo se gestionan los imprevistos?
- ¿Puede utilizarse Shape Up en productos que ya existan, o solo en funcionalidades nuevas?
- ¿Cómo se organizan y coordinan los diferentes equipos?
- ¿Cómo se crea un roadmap a base de Bets?
- ¿Sirve para cualquier equipo, y cualquier fase del producto?
Como todas las metodologías, puede que encaje en tu producto o no. En Automattic hay algunos equipos que utilizan Shape Up, otros prefieren scrum y otros eligen otras metodologías.
Te recomiendo una vez más que te leas el libro, ya que contiene muchos ejemplos y todas las respuestas a esta y otras preguntas.