Desarrollo de una aplicación móvil: las siete fases del proyecto

Casaverde, una cadena de artículos para el hogar, aprobó su aplicación móvil en enero y la esperaba en manos de sus clientes antes del verano. El equipo de desarrollo entregó a tiempo. La app no llegó a publicarse: la base de datos del programa de fidelización nunca se había expuesto a través de una API, nadie había reservado el plazo de revisión de las tiendas y la campaña de lanzamiento estaba escrita alrededor de una funcionalidad que se recortó en la novena semana.

Nada de eso es un problema de programación. Todo es gestión de proyectos, y es la manera habitual en que fracasan los proyectos de app: el software se construye y el proyecto no termina.

Un proyecto de desarrollo de aplicación móvil va de una necesidad de usuario identificada a un producto publicado y mantenido. Tiene siete fases, y solo en una de ellas se escribe código.

Una app se gana un sitio en el móvil que la web nunca consigue

Antes de que ninguna fase importe, el caso de negocio tiene que sobrevivir a una pregunta: ¿qué hace una app que no haga ya una web móvil? La respuesta es corta y tiene más que ver con la cercanía que con las funcionalidades.

Lo que te da la app	Lo que la web móvil no iguala
Presencia mental	Tu icono vive en la pantalla de inicio, a la vista decenas de veces al día, se abra o no
Disponibilidad inmediata	Un toque, sin navegador, sin buscar, sin URL que recordar
Un canal directo	Noticias, imágenes y ofertas llegan al cliente sin intermediarios
Una relación más estrecha	Contacto en los dos sentidos y en el momento, no un formulario contestado la semana que viene
Contenido que viaja	Compartir de forma nativa empuja tu contenido al círculo social del propio cliente
Visibilidad en las tiendas	La App Store y Google Play te ponen delante de quien ya busca en tu categoría
Notificaciones push	Ofertas, encuestas y recordatorios aterrizan en la pantalla de bloqueo. Abusa y te desinstalan
Interacción real	El comportamiento, la ubicación y el momento permiten responder a un perfil en vez de a una media

Cada una de esas es una razón para construir. Ninguna es un plan.

Una app casi nunca es un solo proyecto

Casaverde creía que compraba una app. Lo que encargó fueron tres proyectos que comparten una fecha de lanzamiento: el trabajo de desarrollo de negocio que convierte el nuevo canal en ingresos, el trabajo de integración que expone los sistemas de fidelización y de catálogo, y el desarrollo en sí. Equipos distintos, perfiles distintos, patrocinadores distintos.

Así que el trabajo del jefe de proyecto aquí no es planificar a los programadores. Es mediar entre el patrocinador y el equipo, sostener el ritmo de entrega frente a una fecha fija y hacerse cargo de lo que ocurre después de ella. La PMO o el director del portafolio se sitúan por encima de los tres y vigilan qué dependencias ajenas al proyecto de la app pueden retrasarlo. Una PMO directiva hace algo más que vigilar: mueve presupuesto y personas desde el trabajo secundario para desbloquear la integración que está frenando la publicación.

En ITM Platform esa agrupación es un programa. Los proyectos y servicios se añaden como componentes desde Seleccionar Componente, un proyecto pertenece a un solo programa a la vez y la sección Calendario del programa reúne en un mismo sitio las dependencias entre los proyectos que lo forman. El presupuesto se agrega igual, con un Presupuesto del Programa asignado de arriba abajo junto al Presupuesto de Componentes agregado de los proyectos y servicios que contiene, de modo que el coste de la app es el coste del programa entero y no solo el del desarrollo. La configuración está en gestión de programas.

El patrocinador suele ser el director de innovación o el CIO, porque la app tiene que responder ante el plan estratégico antes que ante un brief de diseño.

Las siete fases y lo que cada una le debe a la siguiente

Estas siete fases son un caso concreto del ciclo de vida del proyecto general. Lo que distingue al trabajo de app es que las fases 3 a 6 forman un bucle, mientras que la 1, la 2 y la 7 ocurren una sola vez.

Fase	Qué tiene que producir	Está terminada cuando
1. Idea	Un problema con nombre que la app resuelve, no una lista de funcionalidades	Sabes decir qué tarea del cliente se muda al móvil
2. Planificación	Estudio de mercado, definición del MVP, calendario, presupuesto, caso de negocio	El caso de negocio sobrevive a sus propios números
3. Desarrollo	Investigación, wireframe, viabilidad técnica, código que funciona	Existe un prototipo que un desconocido sabe manejar
4. Prototipo	Una versión tosca pero navegable del producto	Es lo bastante realista para provocar comentarios sinceros
5. Pruebas	Sesiones observadas con personas que se parecen a tus usuarios reales	Has visto fallar a alguien, no solo has oído opiniones
6. Revisión y mejora	Nuevas historias de usuario y una definición de terminado fija	El backlog deja de crecer más deprisa de lo que baja
7. Lanzamiento y mantenimiento	Una app publicada más un plan de actualizaciones y soporte	La tienda la aprueba y alguien se ocupa de la cola de errores

La fase 3 concentra la mayor parte del riesgo, así que conviene abrirla:

• Investigación. Averigua qué hace ya bien la competencia y qué tendrá que soportar tu back end. Es el último momento en que recortar alcance sale barato.
• Wireframe y documentación. Dibuja las pantallas y después dibuja el recorrido que hace el usuario entre ellas. Un wireframe es un argumento de navegación, no un dibujo.
• Viabilidad técnica. Confirma que el back end puede servir la funcionalidad, identifica las API públicas de las que dependes y comprueba qué exige cada plataforma y cada tamaño de pantalla. Elegir iOS, Android o ambos se decide aquí, no en la fase de la idea.
• Desarrollo. Parte el producto en historias de usuario y repártelas en ciclos de unas dos semanas, para que exista pronto un prototipo que se pueda probar y no solo al final.

El desarrollo es donde una fecha de lanzamiento fija y una construcción iterativa tienen que convivir, la misma tensión que analizamos en ventajas e inconvenientes de las metodologías ágil y predictiva. En ITM Platform los sprints se activan proyecto a proyecto desde la pestaña General, en la sección Línea de tiempo, y no están reservados a los proyectos ágiles: un proyecto predictivo puede ordenar y filtrar su cronograma por sprint, así que el plan de lanzamiento y el ritmo de desarrollo se leen sobre una misma lista de tareas. Las historias que no están listas pasan al backlog, lo que las desasigna del sprint en lugar de dejarlas contadas dentro. Cómo activarlos, por proyecto o por tipo de proyecto, está en sprints.

El presupuesto se esconde en la tarifa, no en la lista de funcionalidades

El primer número que pide todo el mundo es el total, y es el menos informativo de todos. El coste de desarrollo es producto del alcance y de la tarifa, y los dos se mueven.

Coste de desarrollo = Σ (esfuerzo por funcionalidad en horas × tarifa media por hora) + diseño + sobrecoste de plataforma y cumplimiento

La tarifa media es donde se tuercen las estimaciones: la misma funcionalidad se presupuesta de maneras muy distintas según quién la programe.

Quién lo desarrolla	Tarifa por hora orientativa	Qué estás comprando en realidad
Freelance júnior	30 €	Horas baratas y una supervisión que nadie ha presupuestado
Agencia especializada	80 €	Capacidad de entrega y un contrato que puedes hacer valer
Programador sénior en plantilla	120 €	Conocimiento que se queda en casa después del lanzamiento

El mismo conjunto de funcionalidades, y de un extremo al otro la factura se multiplica por cuatro. Por eso “cuánto cuesta una app” no tiene respuesta y “cuántas horas, a qué tarifa y sobre cuántas plataformas” sí la tiene. Publicar en iOS y en Android se parece mucho a dos desarrollos, salvo que te comprometas pronto con un framework multiplataforma, y esa decisión pertenece al paso de viabilidad, no a una petición de cambio posterior.

En las pruebas y el lanzamiento es donde suelen desaparecer los números

Probar no es hacer una demo. Pon el prototipo delante de personas que se parezcan a tus usuarios reales, dales una tarea y observa dónde dudan. Las opiniones recogidas después valen mucho menos que los tres segundos que alguien pasó buscando un botón que no estaba.

Lo que vuelve de ahí se convierte en nuevas historias de usuario, y el bucle de desarrollo, prototipo y prueba se repite. Lo que impide que ese bucle gire para siempre no es la disciplina, es una regla escrita:

Definición de terminado: una historia está acabada cuando está programada, revisada, probada en todas las plataformas objetivo y aceptada por el propietario de producto. Cualquier cosa por debajo de eso vuelve al backlog.

Después llega el lanzamiento. La publicación en la tienda tarda horas o días según lo limpiamente que el desarrollo cumpla las políticas de cada una, así que va en el calendario como una tarea con su riesgo asociado y no como un apéndice pasado el último hito. Y luego viene la parte que los planes omiten con toda naturalidad: actualizaciones, nuevas funcionalidades y soporte para los defectos que las pruebas no cazaron.

Ahí es también donde un proyecto de app pierde sus números sin hacer ruido. Los comentarios de quienes prueban, los rechazos de la tienda y los errores reportados después de publicar llegan como mensajes, se arreglan y no dejan constancia de lo que han costado. En ITM Platform esto es gestión de incidencias, no un segundo backlog: una incidencia se tipifica como Error, Solicitud de cambio o Problema, de modo que un defecto encontrado en pruebas y un cambio de alcance pedido después de la demo no se archivan como lo mismo, y cerrarla registra una variación en el coste del proyecto y una variación de calendario en días. El cuadro de mando suma el coste total de los cambios derivados de incidencias cerradas y el coste total de las incidencias por tipo, que es lo que convierte “tuvimos muchos errores” en una cifra con la que estimar la siguiente versión. Los tipos de incidencia y los campos de resolución están en gestión de riesgos e incidencias.

Los proyectos de app fracasan siempre en los mismos tres sitios: un caso de negocio que nunca llegó a ser un plan, un desarrollo que se controlaba mientras sus dependencias no, y un lanzamiento sin nadie a cargo la mañana siguiente. Las siete fases no son lo difícil. Lo difícil es mantenerlas enganchadas a todo lo demás de lo que la app depende.

Siguientes pasos

• Empieza una prueba gratuita de ITM Platform y monta el desarrollo de la app y su trabajo de integración como componentes de un mismo programa.
• Descubre cómo la gestión de programas y portafolio mantiene visibles las dependencias entre proyectos relacionados.
• Acierta primero con el ritmo de entrega: los sprints funcionan tanto en cronogramas predictivos como en tableros ágiles.