El verdadero calendario del desarrollo de apps: de la idea al lanzamiento

Si pregunta a diez agencias cuánto se tarda en desarrollar una app, recibirá diez respuestas seguras y ni una sola será cierta. La respuesta honesta es que nadie puede decírselo con precisión el primer día, pero cualquiera que haya entregado software de verdad puede describirle su forma: qué fases existen, cuáles se comen el calendario sin que nadie lo note y dónde sus propias decisiones aceleran las cosas o las paralizan. Esa forma es justo lo que aquí está escrito, sin rodeos.

He visto a muchos propietarios de pequeñas empresas entrar en un proyecto de app esperando una marcha ordenada y lineal desde el boceto hasta la App Store. Lo que reciben, en cambio, se parece más a una sucesión de mesetas y saltos repentinos. Semanas en las que parece que no pasa nada, y luego un día en que todo encaja de golpe. Nada de eso es señal de que algo vaya mal. Así es como se hace el software, y en cuanto puede nombrar las fases, todo el proceso deja de ser una caja negra en la que paga esperando que salga bien.

Así que fijemos expectativas realistas. Para una primera versión enfocada de una app de empresa —no una plataforma desbordante, sino una primera versión que hace bien una sola cosa— suele moverse en una horquilla de tres a cinco meses, desde un arranque serio hasta un lanzamiento real. Dónde caiga dentro de esa horquilla depende menos de la tecnología que de su claridad, de la rapidez con que decide y de cuánto intenta meter antes de lanzar. Vamos a recorrerlo.

Por qué la estimación que le dieron probablemente está mal

La cifra de seis semanas no es exactamente una mentira: es el tiempo que se tarda en construir la parte que todo el mundo puede imaginar. Las pantallas. Los botones. Eso que se puede enseñar en una demo. Lo que ese número ignora en silencio es todo lo que rodea a la app visible: las decisiones, los datos, las integraciones con herramientas que ya usa, las pruebas, la revisión de la tienda de apps, la inevitable ronda de «oye, ¿y no podría hacer también esto?»

Una forma útil de verlo: la programación rara vez es el cuello de botella. El cuello de botella es la claridad. Cada hora que su desarrollador espera una decisión —qué proveedor de pago, qué pasa cuando se cancela una reserva, quién puede ver qué— es una hora que el calendario se desliza. Los proyectos que terminan rápido no son los de los mejores ingenieros. Son aquellos en los que la dueña responde las preguntas en un día en lugar de en quince.

Así que al leer las fases siguientes, fíjese en los momentos en que la pelota está en su tejado. Esos son los puntos en los que un proyecto mantiene su impulso o se estanca en silencio durante tres semanas porque un correo se quedó sin responder. El calendario es una responsabilidad compartida, y la mitad del cliente es la que la gente subestima.

Fase 1: Descubrimiento y definición del alcance (1–3 semanas)

Antes de que nadie diseñe una sola pantalla, hay una fase que no parece progreso pero lo determina todo: averiguar qué está construyendo de verdad y, más importante aún, qué no. Aquí una idea vaga («una app para mis clientes») se convierte en una lista concreta y rematable de funciones para la versión uno.

Bien hecho, el descubrimiento es sobre todo conversación y preguntas incómodas. ¿Quién la usa, y en qué dispositivo? ¿Cuál es la única cosa que tiene que hacer de maravilla? ¿Qué puede esperar a la versión dos? Un buen socio le replicará aquí, y conviene que lo haga: cada función que recorta ahora son semanas que recupera. El resultado suele ser un alcance escrito y breve y un wireframe en bruto, algo que puede tener en la mano y decir sí, eso es.

Fase 2: Diseño y prototipo (2–4 semanas)

Ahora la app se convierte en algo que puede ver y pulsar, antes de que una sola línea de código real le comprometa con nada. Los diseñadores convierten el wireframe en pantallas de verdad —los colores, el flujo, la sensación real de usarla— normalmente como un prototipo interactivo que puede recorrer con el dedo en su propio teléfono.

Esta fase vale oro por una razón: cambiar un diseño es barato; cambiar software ya construido es caro. Mover un botón en un prototipo lleva cinco minutos. Moverlo cuando la función ya está programada, probada y conectada a sus datos puede llevar un día. Así que este es el momento de ser exigente, de enseñárselo a unos cuantos clientes o empleados reales y de cazar los problemas del tipo «ah, esto no lo va a entender nadie» mientras todavía son indoloros de arreglar.

La forma más común de que esta fase se alargue no es el diseñador, sino la indecisión por su parte. Rondas interminables de pequeños retoques, o tres personas con derecho a veto que nunca se ponen de acuerdo. Decida pronto quién da el visto bueno, dé el feedback en lotes en vez de a cuentagotas, y esta fase se mantiene ceñida.

Fase 3: Construcción (6–12 semanas)

Esta es la parte que todo el mundo imagina cuando piensa en «hacer una app», y es el tramo más largo —pero rara vez el más imprevisible, si las dos primeras fases se hicieron bien—. Los desarrolladores construyen la app por partes, normalmente en ciclos cortos en los que ve piezas funcionando cada una o dos semanas, en lugar de desaparecer tres meses y reaparecer con un producto terminado.

Ese ritmo importa. Conviene reaccionar pronto ante software real y en marcha, no ante un informe de estado. Cuando pueda usar de verdad el flujo de reservas en la semana cuatro, notará cosas que ninguna especificación habría captado, y arreglarlas en la semana cuatro es mucho más barato que en la diez. Un buen proceso de construcción hace la app visible para usted de forma continua, no solo al final.

Lo que alarga la construcción sin que se note

Dos cosas expanden una construcción más que ninguna otra. La primera son las integraciones: cada sistema externo con el que la app debe hablar (su proveedor de pago, su herramienta de reservas actual, su software de contabilidad, un servicio de reparto) añade trabajo, y cada uno puede dar sus propias sorpresas. La segunda es el aumento del alcance: el goteo constante de pequeñas añadiduras que individualmente parecen mínimas pero que en conjunto retrasan el lanzamiento un mes. Ambas son manejables, pero solo si las ve venir.

• Cada integración externa añade días, a veces semanas: presupuéstelas de forma explícita, no dé por hecho que son gratis.
• «Solo una funcioncita más» es, con diferencia, la causa más común de un lanzamiento incumplido.
• Los datos reales son más enredados que los de prueba; reserve tiempo para los casos límite que su hoja de cálculo toleraba en silencio.
• Cuentas de usuario, pagos y notificaciones son engañosamente profundos: siempre cuestan más de lo que parecen.
• Las aprobaciones y los contenidos que debe al equipo (logos, textos, avisos legales) pueden frenar una construcción tan seguro como un fallo.

Fase 4: Pruebas y correcciones (2–4 semanas)

Aquí hay una fase cuya existencia la gente olvida, y luego resiente cuando aparece. Una vez construida la app, hay que ponerla a prueba a fondo: en distintos teléfonos, con mala conexión, por personas que no la construyeron y harán cosas que nadie previó. Probar no es un trámite. Es la diferencia entre una app en la que sus clientes confían y otra que desinstalan tras el primer cierre inesperado.

Espere que aquí aflore una lista de fallos y asperezas. No es señal de que la construcción saliera mal; es el sentido entero de la fase. Algunos son arreglos rápidos, otros revelan una decisión que hay que revisar. Los equipos que llevan esto bien lo tratan como una parte normal y prevista del trabajo, no como una emergencia ni como algo que saltarse porque el lanzamiento aprieta. Saltarse las pruebas no ahorra tiempo. Solo traslada los fallos de su teléfono de prueba a los teléfonos de sus clientes, donde cuesta diez veces más arreglarlos.

Fase 5: Lanzamiento y la espera de la tienda de apps (1–2 semanas, más revisión)

El lanzamiento es menos un momento único y más un despliegue cuidadoso. Si es una app web, controla por completo el momento: acciona el interruptor cuando esté listo. Si va a la App Store de Apple o a Google Play, cede parte del calendario a ellos: su proceso de revisión puede llevar desde un día hasta más de una semana, y de vez en cuando se la devuelven con algo que corregir. Conviene saberlo de antemano para que no pille por sorpresa una fecha de lanzamiento que prometió a sus clientes.

La forma inteligente de lanzar no es una gran revelación a toda su base de clientes. Es primero una publicación discreta a un grupo pequeño —un puñado de clientes afines o su propio personal— para cazar los problemas del mundo real antes de que todos los vean. Luego abre más la puerta. Un lanzamiento que se siente aburridamente tranquilo es un lanzamiento que salió bien.

1. 1
   Lanzamiento suave a un grupo pequeño

   Publique primero a un puñado de usuarios afines o empleados. El uso real encuentra lo que las pruebas no vieron, con el riesgo al mínimo.
2. 2
   Envíe pronto si va a las tiendas de apps

   Apple y Google controlan el reloj de la revisión, no usted. Envíe con margen para que una revisión lenta o un rechazo no revienten la fecha prometida.
3. 3
   Vigile de cerca la primera semana

   Tenga a alguien a mano para reaccionar rápido. La primera semana saca a la luz los casos límite reales que ningún entorno de prueba reproduce.
4. 4
   Planifique el trabajo del día después antes de lanzar

   Una app nunca está 'terminada' al lanzarse. Acuerde de antemano quién atiende los inevitables arreglos pequeños y la primera ronda de feedback.

Componiendo el calendario completo

Apiladas de principio a fin, esas fases dan un cuadro realista. Ninguna es exótica; lo que descoloca a la gente es olvidar que las poco vistosas —descubrimiento, pruebas, la espera de la tienda— son tiempo real en el calendario, no errores de redondeo. Aquí tiene cómo tiende a repartirse una primera versión enfocada a lo largo de los meses.

Súmelo y verá por qué tres a cinco meses es la horquilla honesta para una primera versión de verdad, y por qué quienes prometen seis semanas redefinen en silencio lo que significa «una app». No es pesimismo: es la diferencia entre una fecha que de verdad cumplirá y otra por la que pasará el proyecto pidiendo disculpas.

Cómo acelerarlo de verdad (y cómo no)

Puede ir más rápido, pero las palancas reales no son las que la gente busca. Echar más desarrolladores a un proyecto a medio definir suele hacerlo más lento, no más rápido. Los aceleradores honestos son poco vistosos: decida qué dejar fuera, responda rápido a las preguntas y resista el impulso de añadir cosas a mitad de construcción.

El mayor con diferencia es un alcance despiadado. Cuanto más pequeña y clara sea su primera versión, antes se lanza, y una app lanzada que se gana el sueldo le enseña más en dos semanas que otros dos meses de planificación. Siempre puede añadir. No puede recuperar los meses gastados en construir funciones que resultó que nadie quería.

Hay una verdad relacionada que conviene decir en voz alta: no todo necesita ser una app a medida. A veces el problema real es un tramo de trabajo manual que una automatización podría resolver en silencio, sin app alguna. Un buen socio le dirá cuándo es ese el caso en lugar de venderle la construcción más grande, porque la app más barata es la que no tuvo que hacer.

Preguntas frecuentes