Cómo definir el alcance de una primera versión que sí vas a lanzar
La mayoría de primeras versiones llegan tarde por lo que se metió dentro, no por lo rápido que trabajó el equipo. El método de recorte que usamos, y las tres cosas que nunca conviene recortar.
Una primera versión que tarda ocho meses rara vez es un equipo que trabajó despacio. Casi siempre es un alcance que nunca fue viable, acordado en una sala donde recortar parecía pesimismo.
Definir bien el alcance es una habilidad, y consiste sobre todo en decidir qué no construir mientras todo el mundo aún se siente optimista.
Empieza por el bucle
Todo producto tiene un bucle central: la secuencia que el usuario repite y que entrega el valor. En un diccionario es buscar, leer, entender. En un marketplace es publicar, descubrir, transaccionar.
Escribe el tuyo en una frase. Después reparte cada funcionalidad propuesta en dos montones: imprescindible para que el bucle funcione y todo lo demás.
El segundo montón es casi siempre cuatro o cinco veces mayor de lo que la gente espera, y ahí es donde se fue tu calendario. No porque esas funcionalidades sean malas, sino porque ninguna sostenía la estructura y todas estaban planificadas.
«MVP» ha dejado de significar nada
El término abarca ahora dos cosas incompatibles: un producto deliberadamente pequeño que hace muy bien una cosa, y un producto amplio construido mal. Lo segundo es lo que la mayoría lanza en realidad, y fracasa porque los usuarios perdonan un producto estrecho pero no uno roto.
Un marco más útil: estrecho y terminado. Menos cosas, cada una hecha como es debido, incluidos los estados de error y los estados vacíos. Una primera versión que hace un trabajo completo se gana el derecho a una segunda. Una que hace ocho trabajos al 60% no.
Recorta alcance, no calidad. Recortar calidad es invisible en un plan y muy visible para un usuario.
Los recortes que suelen ser correctos
Cosas que parecen imprescindibles y casi siempre pueden esperar:
- Cuentas, si el valor funciona sin ellas. El registro es la mayor fuga de casi cualquier embudo. Deja que usen la cosa, y añade cuentas cuando haya estado que merezca guardarse.
- Interfaces de administración. Tú no eres el usuario. Un cliente de base de datos o un script aguantan meses.
- Ajustes. Cada preferencia es una bifurcación de comportamiento que hay que construir y probar. Elige un valor por defecto sensato; añade el interruptor cuando lo pidan.
- Flujos de onboarding. Un tour suele ser un parche sobre una interfaz que no es obvia. Arregla la interfaz primero.
- La segunda plataforma. Web y luego móvil, o una plataforma móvil y luego la otra. Hacer ambas a la vez más que duplica el trabajo y reduce a la mitad la velocidad de feedback.
- La localización. Salvo que un mercado concreto sea el de lanzamiento. Traducir un producto que aún cambia de forma significa volver a traducirlo.
Las tres cosas que no hay que recortar
Recortar esto parece velocidad y es deuda con intereses altos.
1. Los caminos que van mal
Estados de error, estados vacíos, estados de carga, sin conexión. Son quizá una quinta parte del trabajo y la mayor parte de la calidad percibida. Un producto que gestiona el fallo con elegancia se siente sólido aunque sea pequeño. Uno que muestra una pantalla en blanco cuando algo falla se siente roto por muy bueno que sea el camino feliz.
2. La medición
Lanza sin analítica y tu primera versión no te enseñará nada. No sabrás qué partes se usan, dónde se para la gente ni si el bucle se cierra. No necesitas un almacén de datos; necesitas saber que el bucle central se completa y dónde no.
3. La capacidad de desplegar rápido
Si publicar un arreglo cuesta un día de trabajo manual, publicarás menos arreglos, y las primeras semanas tras el lanzamiento son cuando más importan. Un pipeline básico son un par de días de trabajo que se amortizan en la primera quincena.
Corta por recorrido de usuario, no por capas
El error de planificación más común es construir en horizontal: todos los modelos de datos, luego toda la API, luego todas las pantallas. Nada funciona hasta que funciona todo, y no aprendes nada hasta el final.
Corta en vertical. Construye un camino completo de punta a punta, fino pero real, y luego ensánchalo. En la segunda semana ya tienes algo clicable. Eso cambia la conversación de imaginar el producto a reaccionar ante él, que es donde vive el feedback útil.
Una forma realista
Para una primera versión enfocada, más o menos:
| Fase | Tiempo | Resultado |
|---|---|---|
| Descubrimiento | 1 a 3 semanas | Bucle, alcance y riesgos acordados; prototipo clicable |
| Construcción | 6 a 12 semanas | Ciclos de dos semanas con software funcionando en cada uno |
| Lanzamiento | 1 a 2 semanas | Revisión de tienda, monitorización y una primera semana vigilada |
De ocho a dieciséis semanas para algo estrecho y terminado. Si tu plan dice seis semanas para algo amplio, lo que está mal es el alcance, no la estimación.
Escribe lo que recortaste
Una práctica que no cuesta nada y evita una discusión recurrente: mantén una lista explícita de «fuera de la v1», visible para todos, con una línea de motivo por cada punto.
Convierte el «se nos olvidó» en «lo decidimos», impide que la misma funcionalidad se relitigue cada mes, y se convierte en tu backlog de v2 ya ordenado por la discusión que tuvisteis cuando más contexto teníais.
La prueba de un buen alcance
Dos preguntas, y quieres un sí en las dos:
- Si construyéramos solo esto, ¿lo usaría alguien? Si no, has recortado algo que sostenía la estructura.
- ¿Podríamos construir esto como es debido, incluidos los caminos que van mal, en el tiempo que tenemos? Si no, recorta más.
La mayoría de planes suspende la segunda pregunta y nadie lo dice hasta la semana diez.