Cómo decidir qué entra en la versión uno

Todo proyecto de app empieza con más ideas de las que caben en una primera versión. Eso es normal. El problema surge cuando todas entran en la versión uno, la fecha de lanzamiento se retrasa y la parte más importante recibe menos atención de la debida. Definir el alcance es el trabajo de elegir, a propósito, qué se publica primero.

Empiece por la tarea principal

Escriba la única tarea que la app debe hacer bien. Luego recorra el camino más corto que alguien sigue para completarla: abrir la app, iniciar sesión si es necesario, hacer la tarea y ver que funcionó. Cada pantalla en ese camino entra en el alcance. Todo lo demás necesita una justificación.

Divida las ideas en tres grupos

Tome cada idea de funcionalidad y colóquela en uno de tres grupos:

• Imprescindible: la tarea principal no funciona sin ella.
• Deseable: mejora notablemente la tarea principal y es pequeña.
• Para después: todo lo demás, por muy buena que sea la idea.

Sea estricto con el primer grupo. Una función que «los usuarios esperan» no es imprescindible a menos que la app no funcione sin ella. En el segundo grupo es donde se negocia, y no pasa nada si algo queda fuera.

Cuente el trabajo que no se ve

Hay cosas que nunca aparecen en una lista de funciones, pero que igual deben publicarse: inicio de sesión y recuperación de contraseña, eliminación de cuenta, política de privacidad, estados vacíos y de error, ajustes, reportes de fallos, analítica y la ficha en las tiendas de apps. Juntas pueden representar una parte importante del primer lanzamiento. Inclúyalas en el plan desde el principio para que no le sorprendan en las últimas dos semanas.

Empiece de forma manual donde pueda

Algunas funciones pueden empezar como un proceso manual entre bambalinas. La aprobación de cuentas nuevas puede ser alguien revisando una lista cada mañana. Un informe semanal puede ser una consulta que alguien ejecuta a mano. Automatice cuando sepa que la función se usa y de qué manera. Es una forma económica de aprender lo que la gente realmente necesita antes de construirlo como corresponde.

Dé un lugar a lo que queda «para después»

Las ideas que esperan necesitan un sitio donde estar, o volverán a colarse. Mantenga una lista sencilla para la siguiente versión y revísela tras el lanzamiento, con el uso real como guía. Algunos elementos resultarán no tener importancia. Otros importarán más que nada de lo que había en la lista inicial, y nunca lo habría sabido sin haber publicado primero.

Fije la fecha, flexibilice el alcance

Una fecha de lanzamiento fija con un alcance flexible es más fácil de cumplir que al revés. Si los plazos se alargan, pase funciones a la siguiente versión en lugar de mover la fecha. Así la entrega se mantiene pequeña y la app llega antes a usuarios reales, que es de donde surge el feedback útil.

En resumen

Una sola tarea principal, una lista estricta de imprescindibles, el trabajo invisible contemplado desde el primer día y un lugar para todo lo demás. Una primera versión que hace menos, pero bien, le da algo real de lo que aprender. Una primera versión que intenta hacerlo todo rara vez llega a publicarse.