El sistemadetrás de unacampaña nacional

Del primer contacto a la adjudicación pasaron ocho días, con la campaña ya comprometida: fechas públicas, material gráfico en producción, premios contratados.

Lo interesante no es la velocidad. Responder rápido improvisando es fácil y sale carísimo después. Lo que hizo posible esos ocho días fue que la cotización salió al día siguiente del primer contacto, con alcance y calendario, y que el día de la adjudicación ya estaba entregado el documento de arquitectura del motor de premiación: ventanas de tiempo, auditabilidad, firma de integridad de los archivos de códigos. El primer código en el repositorio entró al día siguiente.

Es decir: el método existía antes que el proyecto. La arquitectura que sostuvo la operación de julio quedó escrita en un documento fechado en marzo, antes de la primera línea de código. Eso es lo que se puede contratar; la velocidad sola, no.

La palabra «landing» aparece en casi todos los briefs de campaña y casi siempre es la correcta. Acá no lo era.

Una promoción con premiación instantánea entrega algo de valor real en el segundo en que alguien ingresa un código. Eso convierte la pieza en un sistema transaccional público: cada ingreso es una transacción que hay que validar, resolver contra un inventario finito y dejar registrada de forma auditable, en un sitio abierto a cualquiera con conexión.

Lo que quedó en el registro: 338 commits y 422 despliegues en cinco meses, sin un solo rollback de código. Doscientos ochenta y dos de esos despliegues fueron ensayos en ambientes de prueba antes de tocar producción. El dato no es la cantidad, es el método: cada cambio salía con la reversa a un clic, y en cinco meses esa reversa nunca hizo falta.

La plataforma la construyó un equipo de dos. Pero un sistema así no se sostiene desde un solo lado: el producto completo vivía repartido entre ocho áreas de Abastible —marketing, producto digital, portal de cupones, aplicación, marketing cloud, arquitectura, ciberdefensa y riesgo—, más una agencia de medios, una empresa de ethical hacking, una imprenta y un operador logístico.

Más de sesenta personas pasaron por el correo del proyecto. Se agendaron 47 reuniones. Quedaron registradas 104 decisiones con fecha. Ese es el tamaño real del trabajo, y no es de una parte: es la coordinación de un ecosistema.

De ahí sale la lección que más nos sirvió, y no tiene que ver con tecnología. En un producto repartido, lo que decide el calendario no es la dificultad técnica de cada pieza sino la claridad de los acuerdos entre ellas. Cuando una decisión vivía dentro de una sola organización, se ejecutaba rápido: las 19 medidas derivadas de la auditoría de seguridad llegaron al código en menos de dos semanas, las 19, porque decisión y ejecución estaban en las mismas manos. Cuando una decisión cruzaba una frontera organizacional, el costo cambiaba de escala.

Eso no es una evaluación de nadie: es una conclusión de gobernanza que nos incluye. La respuesta no es controlar más piezas, es que alguien gobierne el producto completo aunque no lo controle entero. En esta campaña ese rol no estuvo formalizado ni tuvo autoridad transversal, y esa falta de definición la pagamos todos, en correos y en días.

Hay algo que no aparece en ningún gráfico de esta página y que fue determinante, así que lo decimos con todas sus letras.

Una corporación con ocho áreas, roles definidos y procesos formales puede volverse un laberinto para un proveedor. Acá no pasó, y la razón es cultural: el trato. Hubo mesas técnicas tensas, plazos que no se movían y un incidente en vivo —conversaciones difíciles hubo—, pero nunca tuvimos que gastar energía en administrar el trato además del problema. Las contrapartes respondían, escalaban cuando correspondía, reconocían lo propio cuando era suyo y preguntaban cuando algo no se entendía. Nadie usó la jerarquía como argumento.

Eso no es cortesía decorativa: es infraestructura. En un sistema repartido entre muchas manos, la confianza y la capacidad de nombrar un problema a tiempo pesan tanto como la arquitectura. Los problemas aparecieron —aparecen siempre— y se pudieron poner sobre la mesa rápido justamente porque ponerlos ahí no costaba nada.

Así que el agradecimiento va completo y sin ironía: a los equipos de marketing, canales digitales, tecnología, servicio al cliente, operaciones, arquitectura, ciberdefensa y riesgo de Abastible, y a los proveedores que pusieron piezas del circuito. La demanda la generaron ellos. La capacidad para capturarla la construimos entre todos.

Un caso que solo cuenta aciertos no le sirve a nadie con experiencia. El proyecto tuvo alrededor de dieciocho problemas con registro de inicio y cierre. La pregunta interesante no es cuántos: es dónde vivían.

Los más costosos tendieron a concentrarse en las interfaces: donde dos equipos, dos sistemas o dos organizaciones se tocan. Y en las interfaces participamos todos, nosotros incluidos. Cuando una integración no tiene un dueño explícito, se convierte en una de las zonas más vulnerables del sistema.

Hubo también errores propios, nacidos dentro de lo que sí controlábamos. Conviene separarlos, porque dejan otro tipo de aprendizaje. Así que antes de hablar de integraciones: dos que son nuestros.

Cuando el servicio externo de emisión de cupones dejó de responder, ya en operación, el sistema hizo bien su parte: siguió asignando premios sin perder un solo dato, y cada caso quedó registrado con su estado, esperando. Cuando el servicio se recuperó, un procedimiento acotado a la ventana del incidente reprocesó los casos afectados sin duplicar ninguno, aprobado por la contraparte antes de correr y verificado después contra la base. Nadie se quedó sin lo suyo.

Pero ahí también hubo algo nuestro que faltó, y es la autocrítica que más nos importa: el circuito de comunicación proactiva a las personas afectadas no estaba diseñado. El sistema sabía exactamente quiénes eran y en qué estado estaba cada uno; nadie les avisó antes de que preguntaran. Que un sistema degrade sin perder información es una virtud de arquitectura. Que además avise, es una decisión de producto que no habíamos tomado. Hoy es parte de nuestro estándar.

Si llegaste hasta acá probablemente estés evaluando a quién encargarle algo parecido. Cuatro cosas que este proyecto nos dejó claras, y que sirven para mirar a cualquiera, incluidos nosotros.

Del lado de Retargeting el trabajo sostenido lo llevaron dos personas, con los roles repartidos: la dirección técnica del sistema en todas sus capas, y la gestión del proyecto y la operación. Otras personas del equipo aparecen en el hilo, casi siempre en copia o en apoyo puntual. Lo decimos como dato, no como mérito: un equipo chico solo funciona a esta escala si el método está antes que el proyecto — que es de lo que trata toda esta página.