"Terminado" en una primera versión significa que el flujo central funciona, está probado y cumple un nivel de calidad acordado antes del build — no "están todas las ideas". Una definición de hecho clara es la lista corta de lo que debe ser cierto para lanzar: la acción clave del usuario funciona de punta a punta, es confiable y lo básico de lanzamiento está cubierto. Sin ella, "terminado" se arrastra para siempre. Con ella, lanzas de verdad.
¿Por qué necesitas una definición de hecho?
Porque sin ella el alcance crece y nada se siente terminado. Una definición de hecho se acuerda por adelantado: las cosas específicas que deben funcionar para que la v1 lance. Convierte "¿está listo?" de una opinión en una checklist. La fijo antes de empezar, para que la meta esté acordada en vez de negociada al final — que es justo cuando "solo una cosa más" atrasa un lanzamiento un mes en silencio. Decide la línea, luego construye hacia ella. También te protege comercialmente: cuando "terminado" está escrito, no hay ambigüedad sobre qué pagaste y qué cuenta como una solicitud nueva. La definición de hecho y el alcance son dos caras del mismo acuerdo — uno dice qué se construye, el otro cuándo está terminado.
¿Qué va en los criterios?
Lo esencial, no la lista de deseos: el flujo central del usuario funciona de punta a punta, los casos borde clave están manejados, está probado en dispositivos reales, lo básico de lanzamiento está en su lugar (auth, manejo de errores, analítica) y cumple el nivel de calidad acordado. Cualquier cosa más allá es un seguimiento rápido, no un bloqueante de lanzamiento. La habilidad es separar "debe funcionar para lanzar" de "estaría bien" — la segunda lista es donde mueren las primeras versiones. Una prueba útil para cada ítem: ¿detendrías el lanzamiento por esto? Si sí, es un criterio; si no, es un seguimiento rápido. Esa única pregunta mantiene la lista honesta y evita que el nivel de calidad se deslice en cualquier dirección — ni lanzar algo roto ni pulir algo que nadie pidió.
¿En qué se diferencia 'terminado' de 'perfecto'?
Terminado es lanzable; perfecto es un blanco móvil. Una primera versión debe ser suficientemente buena para ponerla frente a usuarios reales y aprender, no pulida hasta el infinito primero. Perseguir lo perfecto antes de lanzar quema el calendario en cosas que los usuarios quizá nunca noten, mientras la pregunta real del producto queda sin probar. Construyo hacia terminado — sólido, real y en vivo — y luego mejoro con uso real. Lo perfecto viene de iterar, no de retrasar el inicio. Lanzar en terminado no es bajar el nivel — el flujo central aún tiene que ser confiable, probado y digno de confianza. Es estrechar a qué aplica el nivel: un producto pequeño, funcionando del todo, le gana a uno grande que está perpetuamente casi listo. Terminado significa alta calidad en una superficie pequeña, no baja calidad en una grande.
¿Cómo se ve una checklist de definición de hecho?
Para una primera versión, es corta y concreta — algo así:
- el flujo central del usuario funciona de punta a punta en dispositivos reales
- los estados clave de error y vacío están manejados, no solo el camino feliz
- la autenticación y el control de acceso funcionan correctamente
- la analítica básica está disparando para que aprendas del lanzamiento
- se cumple el nivel de calidad acordado (velocidad, sin bugs bloqueantes conocidos)
- hay una ruta de despliegue y reversión en su lugar
Si cada casilla está marcada, lanza; si una no, aún no está terminado. Todo lo que no está en la lista es explícitamente un seguimiento rápido, que es lo que evita que la lista crezca en silencio hasta volverse un segundo proyecto.
¿Quién decide cuándo una versión está terminada?
Tú y yo acordamos la definición juntos, por adelantado — luego "terminado" lo decide la checklist, no ninguno de los dos en el momento. Ese es todo el valor de escribirlo: la meta deja de ser cuestión de opinión o de ánimo cerca de la fecha, y se vuelve una lista que cualquiera puede verificar. Te diré con honestidad cuándo se cumple cada criterio; sabrás exactamente qué significa "cumplido" porque lo acordaste antes del sprint uno. Si algo nuevo se siente esencial tarde en el build, es una decisión de alcance deliberada que tomamos juntos — agrégalo y mueve la fecha, o lanza y haz seguimiento rápido — nunca un deslizamiento silencioso.
¿Cómo defino 'terminado' en un build?
Escribo la definición de hecho en el alcance antes del sprint uno: el flujo central, el nivel de calidad, los chequeos de lanzamiento. Es la misma disciplina detrás de cómo acoto un MVP y mi entrega SaaS — acordar la meta, construir hacia ella, lanzar, luego iterar. Un "terminado" claro es lo que deja a una primera versión lanzar de verdad en vez de arrastrarse. Decide qué significa lanzable, y ve a lograrlo.
Guías de estrategia relacionadas
Mira cómo acotar un MVP, errores de MVP que arruinan lanzamientos y cuánto tarda construir un MVP.
¿No sabes qué debe incluir tu v1? Cuéntame qué estás construyendo — defino "terminado" contigo antes de una línea de código.
