La respuesta corta

Se puede construir y entregar una app en cinco semanas. Lo hemos hecho: una fintech global, bajo acuerdo de confidencialidad, para una activación de marca en un evento masivo. Una app de iPad 100 % sin conexión, con ranking en directo proyectado sobre una pantalla externa, del brief al evento en cinco semanas.

Pero conviene entender por qué se pudo, porque no se puede siempre. Un proyecto con fecha inamovible se comprime por tres razones concretas, y ninguna es «el equipo corrió más».

Por qué se puede comprimir un proyecto de evento

1 · El alcance es finito de verdad. Un evento tiene un principio y un final. La app hace una cosa, durante unas horas, en un sitio conocido, con un público conocido. No hay «fase dos», ni usuarios que crecerán, ni casos de uso que aparecerán. Eso elimina la mayor fuente de retraso de cualquier proyecto: la ambigüedad sobre qué hay que construir.

2 · La fecha no se negocia, así que el alcance sí. Es la inversión sana del triángulo. Cuando la fecha es el evento, cualquier discusión sobre una funcionalidad termina en minutos: entra o no entra. En un proyecto sin fecha dura, esa misma discusión dura semanas.

3 · Sin conexión significa sin dependencias. Esta es la clave técnica y suele leerse al revés. Una app 100 % offline no depende de la red del recinto, ni de un backend, ni de un tercero, ni de una integración. Todo lo que suele retrasar un proyecto —accesos, entornos, APIs de otros, latencias— desaparece. Lo que en otro contexto es una restricción incómoda, aquí es lo que hace posible el plazo.

Las condiciones que hay que exigir

Si alguien te pide una app para una fecha fija, esto es lo que hay que poner sobre la mesa antes de decir que sí:

  • Un decisor único, disponible. No un comité. Alguien que responda en horas, no en días. Es el requisito que más veces falta y el que más veces hunde el plazo.
  • Alcance cerrado por escrito el primer día, con lo que queda fuera enumerado explícitamente.
  • Contenido y material de marca disponible desde el principio. Esperar textos e imágenes es la causa número uno de retraso en proyectos de activación.
  • Acceso al hardware real desde el primer momento. Si va sobre iPad y pantalla externa, hay que tener los dos.
  • Una ventana de prueba en el sitio, o lo más parecido posible.

Si alguna de las cinco no se puede garantizar, el plazo deja de ser realista y hay que decirlo antes de firmar, no en la semana cuatro.

Cómo se ordena por dentro

  • Lo que no puede fallar, primero. En una activación, lo crítico es que arranque y que se vea. Eso se construye y se prueba antes que cualquier funcionalidad bonita.
  • Un camino feliz que funcione desde la semana uno, aunque sea feo. Tener algo ejecutándose sobre el hardware real desde el principio elimina las sorpresas del final.
  • Plan de contingencia por cada punto de fallo: qué pasa si el iPad se reinicia, si se pierde la señal a la pantalla, si alguien cierra la app, si se agota la batería. En un evento no hay una segunda oportunidad ni tiempo de depurar.
  • Modo operador: alguien del staff tiene que poder reiniciar, corregir o pasar a un estado seguro sin llamar a nadie.
  • Ensayo completo, con el hardware, en condiciones parecidas. No una demo: un ensayo.

Lo que no se comprime

Por honestidad, y porque es donde la gente se equivoca al extrapolar:

  • No se comprime un producto que va a vivir. Cinco semanas sirven para algo con final; un producto que evolucionará necesita fundamentos que no se ponen a esa velocidad.
  • No se comprime lo que depende de terceros. Integraciones, aprobaciones, entornos ajenos. Ahí el calendario no lo controlas tú — es lo mismo que ocurre con los hospitales o con los almacenes sobre ERP.
  • No se comprime la revisión de las tiendas si hay que publicar. En una app de evento distribuida internamente, no aplica — y esa es otra de las razones por las que el plazo funcionó. Las vías de distribución están en cómo distribuir una app interna.
  • No se comprimen dos veces seguidas. Un equipo que entrega a ese ritmo necesita recuperar después. Encadenar plazos así quema gente y produce deuda.

Qué llevarse a un proyecto normal

Tres cosas de este modo de trabajar funcionan igual de bien sin la urgencia:

  1. Enumerar por escrito lo que queda fuera. Vale tanto como enumerar lo que entra.
  2. Un decisor con nombre y disponibilidad, en cualquier proyecto.
  3. Ejecutar sobre el entorno real desde la primera semana, en vez de dejarlo para la integración final.

Si tienes una fecha que no se mueve y quieres saber si es viable, es exactamente la conversación de la primera llamada: te diremos qué cabe, qué no y qué hace falta de vuestro lado para que quepa. El contexto de cómo trabajamos está en proceso.