Lanzar un producto mínimo viable sin recortes de los que se arrepentirá
El producto mínimo viable se ha ganado mala fama, y casi siempre por las razones equivocadas. La idea es buena: construir lo más pequeño posible que le permita averiguar si está resolviendo un problema real y luego decidir el siguiente paso. Los problemas empiezan cuando «mínimo» se convierte sin ruido en una excusa para saltarse las partes del trabajo más difíciles de ver: pruebas, accesibilidad, seguridad, una forma clara de medir si alguien usó de verdad la cosa. Tras dieciocho meses de entrega remota e híbrida, con equipos exigidos y proveedores aún impredecibles, la tentación de lanzar algo endeble y llamarlo aprendizaje es más fuerte que nunca.
Conviene recordar qué pide en realidad la Guía Scrum a un equipo. Cada Sprint debe producir un Incremento «Terminado»: utilizable, valioso y que cumple la Definición de Terminado. Un PMV no es un atajo para eludir eso. Es una porción de alcance deliberadamente estrecha que aun así cumple el mismo nivel de calidad. Se reduce lo que el producto hace, no lo bien que lo hace.
Los errores que convierten un PMV en un pasivo
Confundir mínimo con inacabado. Recortar funciones es el propósito. Recortar calidad —manejo de errores, integridad de datos, una forma de revertir— es lanzar algo que no se puede poner con seguridad frente a un usuario. La Definición de Terminado no encoge porque el alcance lo haya hecho.
Saltarse la hipótesis. Un PMV existe para validar una suposición. Si no puede decir en una frase qué espera aprender y cómo lo medirá, no está construyendo un PMV: simplemente está construyendo menos.
Sin forma de captar lo que ocurre después. Los equipos lanzan la versión escueta y olvidan instrumentarla. Sin retroalimentación —datos de uso, tiquetes de soporte, una entrevista breve— la versión no enseña nada, y ha gastado esfuerzo real para seguir tan incierto como antes.
Dejar que el PMV se convierta sin ruido en el producto. En cuanto algo funciona lo bastante bien, la presión por seguir adelante es enorme. Los atajos aceptados como temporales se vuelven deuda permanente que el siguiente equipo hereda sin contexto.
Construirlo en aislamiento. Cuando quienes operarán, darán soporte o auditarán el producto no lo ven hasta el lanzamiento, las brechas salen en el peor momento. El trabajo remoto lo empeora, porque las conversaciones de pasillo que antes detectaban problemas ya no ocurren por casualidad.
Cómo lanzar uno que pueda respaldar
Escriba la meta de aprendizaje antes que el backlog. Enuncie la suposición, la métrica y el umbral que le haría continuar, pivotar o detenerse.
Mantenga intacta la Definición de Terminado. Reduzca el alcance, no los estándares: una función estrecha realmente terminada vale más que una amplia sostenida con cinta adhesiva.
Instrumente desde el primer día para que la versión pueda responder de verdad a la pregunta que se planteó.
Nombre la deuda en voz alta. Registre cada atajo como un elemento del backlog del producto, visible y no enterrado.
Involucre temprano a las personas de operaciones, soporte y registros, sobre todo cuando el equipo está disperso y nadie se cruza en persona.
Hecho con responsabilidad, un PMV es una de las herramientas más honestas de la entrega. Admite que aún no se conoce la respuesta y gasta el menor esfuerzo posible para hallarla, sin dejar un desastre a quienes vienen después. La disciplina no está en lanzar rápido; está en tener claridad sobre qué incluye «mínimo» y qué nunca debe excluir.
Si su organización está sopesando cuánto construir antes de comprometerse con un programa completo, la asesoría en entrega de programas y proyectos de XNM puede ayudarle a delimitar una primera versión responsable y un plan para lo que venga después.