El proyecto no cumplió el calendario inicial. Cuatro factores lo explican.
El proyecto base se planificó en 50 días laborables, desde diciembre 2025, con entrega en febrero 2026. El piloto se validó en septiembre 2026. En el camino cambió el alcance y el avance dependió de decisiones y recursos de varios actores. La pausa de marzo a mayo fue el factor principal: obligó a reasignar el equipo y redefinir la entrega según los perfiles disponibles.
Lo naranja no es el plan base que se demoró: es un proyecto más grande. APIs, retiro del pago en efectivo, backend ampliado y arquitectura en la nube con modo offline se sumaron a mitad del proyecto. Más allá de quién asumiera su costo, ver un tótem funcionando pasó a depender de esas ampliaciones.
Pausa por dependencias externas
Una dependencia externa detuvo el roadmap entre marzo y mayo de 2026, y el equipo debió reasignarse hasta su reanudación.
BDefiniciones y comunicación técnica
Definiciones técnicas clave llegaron o cambiaron con el trabajo ya en marcha.
CCoordinación con otros actores y recursos
El avance dependió de terceros, equipos físicos y agendas de varios equipos.
DAmpliación y replanteamiento del alcance
El proyecto pasó de un piloto a una solución para toda la red de tiendas.
Qué afectó el avance, causa por causa
A. Una dependencia externa detuvo el roadmap entre marzo y mayo de 2026, y el equipo debió reasignarse hasta su reanudación.
Accesos a n8n retirados
Impacto: Mar – Abr 2026- Se esperaba
- Usar los accesos a n8n entregados al inicio cuando el plan llegara a esa tarea, a inicios de marzo.
- Qué cambió
- Al llegar a esa tarea, los accesos ya estaban retirados, sin aviso previo, porque aún no se usaban. Pulpa lo alertó a la PMO de Mr. Joy y lo conversó con el equipo de Proyectos de Innovación y Marketing: el proyecto quedaba detenido. Por la prioridad de la apertura de Chile, los nuevos accesos llegaron en abril y con otra forma de conexión.
- Qué implicó
- El proyecto se detuvo y se retomó en mayo, adaptando la integración a la nueva conexión.
Reasignación y nueva convocatoria del equipo
Impacto: Retomado en mayo 2026- Se esperaba
- Avanzar de forma continua con el equipo asignado, según el roadmap acordado.
- Qué cambió
- Con el roadmap detenido, el equipo pasó a otros compromisos: el servicio se contrató por horas para un proyecto, no con dedicación exclusiva. Al resolverse el bloqueo, se volvió a convocar.
- Qué implicó
- Tal como se advirtió desde la cotización, si el proyecto se interrumpe por causas ajenas a Pulpa, las fechas se reestiman según la disponibilidad del equipo. En este proyecto se cotizaron horas efectivas de desarrollo, no una dedicación por plazo: con un fee mensual, cada perfil se habría facturado también en las semanas sin avance.
Hardware y POS sin definir
Impacto: Abr – May 2026- Se esperaba
- Tener definidos proveedor de POS, SDK de pinpad e impresora, sistema operativo y equipos.
- Qué cambió
- Esas definiciones y los equipos físicos llegaron recién hacia finales de mayo.
- Qué implicó
- Sin equipos ni definiciones no era posible probar cobros, impresión ni el tótem real.
B. Definiciones técnicas clave llegaron o cambiaron con el trabajo ya en marcha.
Qué procesos desarrollaba Pulpa
Impacto: Por validar- Se esperaba
- Tratar el tótem como un punto de venta: Pulpa asumiría la facturación y los procesos asociados.
- Qué cambió
- Más adelante se definió que Pulpa solo debía dejar endpoints para que los sistemas de Mr. Joy los consuman.
- Qué implicó
- Se trabajó un camino que luego cambió de destino. Ese recorrido y el reproceso los asumió Pulpa.
Accesos a sistemas internos
Impacto: Parte de la pausa (factor A)- Se esperaba
- Contar con los accesos cuando el plan de trabajo los requería. Pulpa pidió por iniciativa propia el acceso a n8n para poder integrarse.
- Qué cambió
- Los accesos entregados al inicio se retiraron antes de que el plan llegara a usarlos, y los nuevos llegaron en abril con otra forma de conexión.
- Qué implicó
- La validación con los sistemas de Mr. Joy quedó en espera.
Forma de entrega y documentación
Impacto: Por validar- Se esperaba
- Una forma de despliegue y un estándar técnico definidos desde el inicio.
- Qué cambió
- Con el proyecto ya en etapa de producción se pidió el despliegue con Docker, además de manuales, especificaciones y reportería que no se habían planteado al inicio.
- Qué implicó
- Hubo que adaptar lo ya desarrollado y producir documentación adicional.
Cierre del flujo completo
Impacto: Por validar- Se esperaba
- Cerrar el flujo de punta a punta, conectado a facturación.
- Qué cambió
- El cierre dependía de las conexiones con los sistemas internos de facturación. Finalmente, Gerencia decidió no incluir esa etapa.
- Qué implicó
- El flujo completo no pudo validarse dentro del proyecto.
C. El avance dependió de terceros, equipos físicos y agendas de varios equipos.
Certificación del POS
Impacto: ~1,5 – 2 semanas (aprox.)- Se esperaba
- Con la integración terminada y probada (con la documentación del POS disponible), recibir las llaves para operar.
- Qué cambió
- La documentación de Datafast llegó cuando se pidieron las llaves de producción y no detallaba el proceso de certificación ni su alcance. Apareció en el camino y coincidió además con feriados en Ecuador.
- Qué implicó
- Más horas de desarrollo para cubrir todas las variantes que pedía la certificación.
Alcance final de la certificación
Impacto: Incluido en el punto anterior- Se esperaba
- Certificar todas las variantes solicitadas.
- Qué cambió
- Las validaciones fallaban del lado del proveedor, por lo que decidió flexibilizar la certificación. Al final bastó con demostrar los casos críticos, cerca del 10% de lo desarrollado.
- Qué implicó
- Buena parte del esfuerzo de certificación no llegó a necesitarse.
Equipos y dispositivos físicos
Impacto: Parte de la pausa (factor A)- Se esperaba
- Tener el tótem, el pinpad, la impresora y la red para probar en el equipo real.
- Qué cambió
- El desarrollo se hizo en un entorno local y los equipos físicos llegaron tarde.
- Qué implicó
- El despliegue y la validación en el tótem solo pudieron empezar al tenerlos.
Ventanas de validación e interlocutores
Impacto: Por validar- Se esperaba
- Validar con continuidad y tener claro con quién coordinar cada frente.
- Qué cambió
- El personal disponible para validar tenía horarios acotados, así que cada validación se extendía al día siguiente. Para frentes como el POS de Chile no había un interlocutor definido.
- Qué implicó
- Menor ritmo de avance, pese a la buena disposición del equipo técnico.
D. El proyecto pasó de un piloto a una solución para toda la red de tiendas.
Cambios en el frontend durante su validación
Impacto: ~1 – 1,5 semanas (aprox.)- Se esperaba
- Validar el funcionamiento del frontend construido sobre un diseño ya aprobado.
- Qué cambió
- En la validación se pidieron cambios en el frontend, una etapa ya cerrada, antes de la pausa.
- Qué implicó
- Reprocesos sobre pantallas ya construidas, asumidos sin costo.
De piloto a red de tiendas
Impacto: ~6 semanas (aprox.)- Se esperaba
- Un piloto, tal como se planteó y cotizó al inicio.
- Qué cambió
- Evolucionó hacia una solución para toda la red: cambios en pantallas, en el flujo del front y en el backend. Los endpoints y la estructura del backend se cotizaron a mitad del proyecto, sobre etapas ya cerradas.
- Qué implicó
- Se rehízo trabajo ya terminado. Con un cambio de estructura así, la extensión del plazo era lógica.
De solución local a solución en la nube y local
Impacto: Incluido en las ~6 semanas del paso a red de tiendas- Se esperaba
- Una solución local por tótem, base sobre la que se armó el roadmap inicial.
- Qué cambió
- Durante el proyecto se contrató una ampliación: base central en la nube con modo local (offline) y sincronización entre ambos.
- Qué implicó
- Fue una venta adicional (44 h), pero condicionó el roadmap: lo ya construido en local tuvo que adaptarse y las entregas siguientes se reordenaron sobre la nueva arquitectura.
De diseño a frontend y backend
Impacto: Por validar- Se esperaba
- Un proyecto de diseño UX/UI.
- Qué cambió
- Se sumó el frontend y, en el camino, el backend. Flujos ya aprobados se replantearon más de una vez (por ejemplo, retirar el pago en efectivo).
- Qué implicó
- Reprocesos sobre pantallas y lógica ya construidas.
Un backend con más funciones
Impacto: Por validar- Se esperaba
- Un backend para gestionar contenidos.
- Qué cambió
- Pasó a cubrir también la operación y la gestión de módulos, con roles que no estaban especificados, como el perfil Superadmin con auditoría.
- Qué implicó
- Más dedicación sin cotización aparte.
Cambios en etapas avanzadas
Impacto: Por validar- Se esperaba
- Stakeholders internos involucrados desde las definiciones iniciales.
- Qué cambió
- Algunas áreas se sumaron más tarde y pidieron cambios, incluso en producción y en pruebas en el tótem (ver Anexo 2).
- Qué implicó
- Funcionalidades nuevas fuera del flujo inicial, hechas sin costo adicional.
Impactos expresados en semanas aproximadas, como orden de magnitud. Los marcados «por validar» aún no tienen una cifra confirmada.
Cómo respondió Pulpa
El proyecto creció y asumimos el trabajo adicional sin cobrarlo
La dedicación y las horas de servicio superaron lo estimado. Para cuidar la relación y aportar valor a una marca con la que trabajamos en varios frentes, los reprocesos y los nuevos pedidos no se facturaron. Los evolutivos también se harán sin costo.
En los tramos de espera, seguimos avanzando
Fuera de la pausa principal: Desarrollo e integración del POS de Chile, con código listo a la espera de los equipos. Lógica y diseño de Chile, distintos a lo cotizado al inicio. Backend ampliado a la operación, listo. Proyecto de bolos culminado a nuestro riesgo, sin cotización aprobada.
Lo que podemos mejorar
También pudimos haber gestionado mejor las expectativas y fijado límites de alcance más claros a medida que el proyecto crecía.
Pulpa no cotizó la PMO del proyecto
Lo que cotizamos
Desarrollo técnico: diseño, frontend, backend e integraciones.
Lo acordado con Mr. Joy
Mr. Joy intermediaría con las empresas de POS y con sus áreas internas.
Aprendizaje: un proyecto con tantos actores necesita una PMO dedicada. En la etapa final, Pulpa sumó a su costo un Project Manager para ayudar a los equipos técnicos a destrabar la coordinación con Mr. Joy y con terceros, y desde entonces todo fluyó mejor. En los próximos proyectos la incluiremos en la cotización.
Proponemos una conversación
Revisar juntos esta perspectiva y acordar cómo cerrar el proyecto: la información comercial de Chile (flujos, afiliación, productos y beneficios) y el apoyo a TI con la comunicación entre el tótem y el sistema de facturación, si lo necesita.
Línea de tiempo del proyecto
Jun 2025 · Inicio
Arranque del proyecto UX/UI
Alineación con Operaciones, Comercial y Marketing para diseñar los tótems de autoservicio.
Jul 2025 · Diseño
Reglas de beneficios por definir
Información pendienteSe mencionaron reglas por categoría de socio que quedaron pendientes de envío. Para mantener el avance, se continuó con 1 beneficio por visita.
Jul – Ago 2025 · Diseño
4 rondas de ajustes de diseño
+5 semanasEn cada revisión se sumaron mejoras: videos, fotos, banners dinámicos, sorteo de cumpleaños, video informativo e ícono de preguntas frecuentes.
Sep 2025 · Diseño
Ajuste en la entrega del diseño
+2 semanasLa entrega final estaba sujeta a recibir precios, banners y video inicial. Se sumó una revisión adicional con gerencia.
Oct – Nov 2025 · Nuevo alcance
Ampliación del proyecto a Front + Backend
+8 semanasA solicitud del equipo de TI se sumó desarrollo, endpoints e integración con POS. La propuesta se ajustó en precio y tiempo hasta su aprobación formal.
Dic 2025 · Desarrollo
Ajuste de flujo: sin pago en efectivo
RediseñoSe redefine el flujo final del tótem ya diseñado.
Dic 2025 · Plan base
Inicio del desarrollo del proyecto base
Entrega Feb 2026Plan acordado: 50 días laborables de tiempo efectivo, con entrega tentativa a mediados de febrero de 2026 (sin evolutivos, nuevos alcances ni recotizaciones).
Ene 2026 · Desarrollo
Nuevas pantallas en el carrito
Sin costoSe piden cálculo automático de seguro y aceptación de términos de protección de datos. Se incorporan sin costo adicional.
Mar – Abr 2026 · Pausa
Accesos a n8n retirados
Pausa ~2 mesesAl llegar a la integración con n8n, los accesos entregados al inicio estaban retirados. Pulpa alertó que el proyecto quedaba detenido. Por la prioridad de la apertura de Chile, los nuevos accesos llegaron en abril con otra forma de conexión; el trabajo se retomó en mayo.
May – Jun 2026 · Pausa
Definiciones de hardware y POS pendientes
Insumos pendientesFaltaban proveedor final de POS, SDK de pinpad e impresora, sistema operativo, hardware, accesos y documentación. Se confirmaron Datafast y Ubuntu; para validar cobros e impresión se requerían pinpad, impresora, red y datos del comercio (la documentación de impresora recibida era para Windows).
Jun – Jul 2026 · Nuevo alcance
Cambio de arquitectura: base central en la nube
Nuevo alcance · 44 hEl desarrollo se había construido con base local por tótem. Al pasar de piloto a múltiples tiendas, TI evaluó nuevos escenarios y finalmente aprobó la nube centralizada con modo offline y sincronización híbrida.
Jun – Jul 2026 · Certificación
Pruebas y certificación con Datafast
Requisito de tercerosDatafast coordinó el paso de ambiente de desarrollo a pruebas y exigió script de transacciones, vouchers y logs. Tras sus observaciones de formato, confirmó reversos y logs correctos.
Ago 2026 · Infraestructura
Definición del despliegue
ReconfiguraciónSe definió el reparto de responsabilidades: Pulpa aporta Dockerfile, docker-compose y MySQL; Mr. Joy configura Caddy. Cambios posteriores en la configuración de Docker del repositorio requirieron adaptar parte del desarrollo.
Ago 2026 · Pausa
Información comercial pendiente de Chile
Validación en pausaPara Chile se requieren cargos, afiliación, productos y beneficios. En Ecuador, validar precios, combos, medias y fotografías.
Ago 2026 · Piloto
Réplica sujeta a aprobación del piloto
La configuración de los demás tótems requería el visto bueno del piloto; la validación POS programada reajustó esa fecha.
Sep 2026 · Entrega
Módulo administrable listo y ajustes aplicados
Ventas offline funcionando, sincronización cada 5 minutos y correcciones visibles en el ambiente de prueba.
Sep 2026 · Piloto
Piloto validado y primera venta real
HitoCon los accesos remotos sin funcionar, se acordó con TI instalar primero el tótem 4. Se validó el piloto y se concretó la primera venta real tras ajustes con Datafast.
Sep 2026 · Decisión
Gerencia define entregar en el estado actual
Gerencia de Mr. Joy decide no iniciar la sincronización bidireccional de facturación/QR y cerrar el proyecto con el alcance actual.
Sep 2026 · Entrega
Nueva solicitud: perfil Superadmin con auditoría
Nuevo alcanceRío Centro queda con 4 autoservicios autónomos. Se solicita un nuevo perfil de seguridad con contraseñas y auditoría.
Sep 2026 · Cierre
Repositorios y extensiones con dependencias
DependenciasLos repositorios de puentes POS y efectivo se entregaron con acceso de solo lectura (vía fork y revisión interna). Chile depende del dispositivo y la certificación de Getnet; el pago en efectivo, del equipo que acepta billetes.
Pedidos adicionales del equipo Mr. Joy
Requerimientos surgidos durante las revisiones, fuera del alcance original. Todos, incluidos los evolutivos, sin costo adicional.
Ajustes y mejoras del flujo
Solicitudes surgidas en las revisiones, fuera del flujo aprobado.
| Requerimiento | Estado | Costo |
|---|---|---|
| Navegación del afiliado: Volver de «Entradas» a «Beneficios» sin perder la sesión ni lo seleccionado. Luego se añadió el paso de beneficios al indicador del flujo. | Listo | Sin costo |
| Tiempo restante: Mostrar el contador en la ventana «¿Necesitas más tiempo?», que seguía corriendo sin mostrarse. | Listo | Sin costo |
| Información en el checkout: Cambiar «medias y zapatos» por «medias y/o zapatos» y añadir el aviso de que los acompañantes no acceden a los juegos (texto administrable; aviso ya incorporado). | Listo | Sin costo |
| Estatura del paquete: Indicar la estatura adecuada en el ítem «Estatura y juego del paquete». | Listo | Sin costo |
| Ítem del seguro: Quitar el resaltado verde y unificarlo con el resto de ítems. Cambio sobre el diseño aprobado. | Listo | Sin costo |
| Descarga de base de clientes: Exportación en Excel de los clientes registrados para análisis comercial. | Listo | Sin costo |
Evolutivos: beneficios Club Mr. Joy
Se desarrollarán sin costo tras el cierre del piloto y el despliegue en Chile.
| Requerimiento | Estado | Costo |
|---|---|---|
| Beneficios múltiples: Permitir más de un beneficio por visita según reglas por categoría. | Evolutivo | Sin costo |
| Regla Boletería: Solo 1 beneficio de esta categoría por transacción (bloquear equivalentes). | Evolutivo | Sin costo |
| Regla Snack Bar: Selección de múltiples ítems dentro de la categoría (ej. combo joy). | Evolutivo | Sin costo |
| «30 minutos gratis»: Administrar el beneficio desde el backend, sin despliegues. | Evolutivo | Sin costo |
Evolutivos sin costo adicional. Se desarrollarán una vez cerrado el piloto y completado el despliegue en Chile.
Pulpa · Fuente: actas de reunión y correos del proyecto Autotótem Mr. Joy (jun 2025 – sep 2026).