Cómo se organiza el trabajo en el sistema FoodSoul: desde la idea hasta el resultado
- Tiempo de lectura: 6 min
- Autor : Equipo FoodSoul

Cómo se organiza el trabajo en el sistema FoodSoul: desde la idea hasta el resultado
Valoramos la confianza de nuestros socios y por eso queremos ser lo más transparentes posible. En este artículo contaremos cómo está formado el equipo, cómo las ideas se convierten en funcionalidades, cómo establecemos prioridades y qué sucede detrás de escena cuando algo no sale como se esperaba.
FoodSoul es un sistema vivo
FoodSoul no es solo una aplicación. Detrás de ella hay una gran infraestructura: CRM, almacenamiento y protección de datos, plantillas de sitios web y aplicaciones móviles, y miles de restaurantes socios, cada uno con sus propias necesidades y escenarios de trabajo.
Estamos en constante escucha: recopilamos ideas de los socios a través del soporte técnico, del contacto directo con los clientes y de nuestros propios analistas del departamento de IT. Todo esto se acumula en el backlog, una lista de tareas en constante actualización, sobre la base de la cual se forma la hoja de ruta para el desarrollo del producto.
Cómo está organizado el equipo y la estructura de trabajo
En FoodSoul trabajan varios grupos de especialistas, y cada uno de ellos tiene su área de responsabilidad y su propia lógica de interacción con los demás.
Soporte técnico — la primera línea de contacto con los socios. Recibe las solicitudes, analiza la esencia del problema y, o bien lo resuelve en el momento, o lo deriva al especialista que conoce la parte correspondiente del sistema.
Especialistas de segunda línea — son ingenieros que conocen en profundidad módulos concretos: integraciones, aplicaciones móviles, CRM, pagos. Son ellos quienes verifican si la solicitud es una característica del funcionamiento o un error real.
Analistas recopilan y estructuran las sugerencias de los socios, evalúan cuán demandado es el cambio y cómo afectará a otros clientes, antes de que la tarea pase a desarrollo.
Desarrolladores y testers implementan las tareas y las verifican antes del lanzamiento, desde pequeños ajustes hasta grandes mejoras funcionales.
Jefes de proyecto mantienen el foco en las prioridades: supervisan el backlog, distribuyen las tareas entre los equipos y se aseguran de que lo importante no se pierda entre las tareas actuales.
El trabajo se organiza de forma cíclica: el equipo revisa regularmente el backlog, evalúa nuevas solicitudes y sugerencias, planifica las tareas más próximas y sigue el estado de las que ya están en marcha. Este ritmo permite no perder de vista ni los problemas urgentes ni el desarrollo a largo plazo del producto, y al mismo tiempo mantener la previsibilidad: el socio siempre puede consultar a través del soporte técnico en qué etapa se encuentra su solicitud.
Cómo establecemos prioridades
Cuando surge un problema, actuamos según uno de los siguientes escenarios.
Fallo masivo — un error con el que varios clientes se encuentran simultáneamente en el transcurso de un día o unas horas. Es la máxima prioridad: el tester y los desarrolladores se conectan de inmediato.
Error crítico en un solo cliente — si el error afecta directamente a los ingresos o la reputación del socio, la prioridad es igual de alta. Dedicamos los recursos clave y resolvemos el problema en el menor tiempo posible.
Error estándar — una solicitud recibida por soporte técnico que no parece una catástrofe. La toma un especialista de segunda línea que conoce bien el sistema. Hay dos posibles desenlaces: o bien se determina que es una característica del funcionamiento que no se tuvo en cuenta, en cuyo caso se explica la solución al cliente; o bien el problema realmente existe, entonces pasa al jefe de proyecto, se registra en el sistema de tareas con prioridad y responsable, y se implementa por orden de llegada. El especialista de soporte técnico sigue el estado y avisa al cliente cuando la tarea está completada.
Error menor — un fallo que no afecta al funcionamiento del sistema, pero requiere corrección: un error tipográfico, un elemento de la interfaz desalineado, un color de botón incorrecto. Estas tareas se abordan cuando no hay solicitudes de mayor prioridad de los puntos anteriores.
Sugerencias — prestamos mucha atención a lo que piden los socios. Cuando una misma petición llega de varios clientes, la prioridad aumenta y la llevamos a análisis. Cualquier cambio afecta a todos los socios a la vez, no solo a quien lo solicitó, por eso antes de implementarlo recogemos feedback de diferentes clientes, para que la mejora para unos no cause molestias a otros. Este es un paso adicional, pero es precisamente lo que hace que la decisión final sea más equilibrada.
Por qué surgen los errores
El desarrollo de cualquier producto complejo está organizado de tal manera que los errores son una parte regular del proceso, no una excepción. Así se compone esta complejidad.
El sistema crece. Cuantas más funciones, integraciones y escenarios de uso, más puntos de interacción entre las distintas partes del sistema. El equipo prueba los escenarios más típicos, pero cubrir todas las combinaciones de antemano es físicamente imposible incluso para el equipo más experimentado.
Cada socio utiliza el sistema a su manera. Miles de establecimientos significan miles de procesos de trabajo únicos. El comportamiento de los usuarios en condiciones reales siempre es más variado de lo que se puede prever en los escenarios de prueba, y algunas desviaciones solo se manifiestan con datos reales.
Un cambio afecta a otro. Cuando un desarrollador mejora un módulo, esto puede afectar a funcionalidades relacionadas. Cuanto más grande es el sistema, más largas son las cadenas de dependencias entre sus partes, y más atención se debe prestar a cada cambio.
El entorno cambia constantemente. Se actualizan los navegadores, los sistemas operativos, los servicios de terceros con los que estamos integrados. Lo que funcionaba ayer puede comportarse de otra manera tras una actualización de una empresa externa, y nosotros monitorizamos estos cambios para reaccionar rápidamente.
Los requisitos se aclaran en el proceso. A veces una función se implementa exactamente como se concibió, pero en el uso real resulta que la idea necesita ser mejorada. Así el producto se vuelve más preciso con cada iteración.
Consideramos esto como una parte normal del crecimiento de un sistema complejo y trabajamos constantemente para que sea más estable, rápido y cómodo para cada socio, gracias a pruebas más profundas, una estructura de equipo clara y un feedback constante con los clientes.
Si te has encontrado con un problema o quieres compartir una idea, escribe al soporte técnico de FoodSoul. Cada solicitud llega al especialista adecuado y no se pierde. ¡Estamos cerca de ti!
Atentamente,
Project Manager FoodSoul




