Modelo nearshore para Adobe Experience Cloud: cómo un partner en México trabaja con equipos de Estados Unidos

Casi todas las conversaciones sobre nearshore arrancan en el lugar equivocado: arrancan en una tarifa. Y una tarifa no explica prácticamente nada sobre si un programa de Adobe Commerce o de Adobe Experience Platform va a aterrizar en tiempo. Un modelo de entrega no es, en primer lugar, una decisión de precio: es una decisión sobre con qué frecuencia el equipo del cliente y el equipo de implementación pueden estar en la misma sala, a la misma hora, con el mismo contexto, y sobre qué pasa el día en que algo se rompe.

En WolfSellers somos Adobe Gold Partner con sede en Ciudad de México, y buena parte de nuestro delivery corre contra el horario hábil de Norteamérica. Este artículo no es una guía para elegir partner: si eso es lo que necesitas, escribimos cómo elegir un partner de Adobe Experience Cloud en México, que cubre tipos de partner, criterios de evaluación, preguntas de pitch y red flags. Este artículo responde algo más acotado y más operativo: qué cambia realmente en tu semana de trabajo cuando el equipo que construye tu plataforma Adobe Experience Cloud está en la misma franja horaria que tú.

Vamos a recorrer los ejes objetivos que definen un modelo de entrega, las diferencias concretas semana a semana, el marco legal y contractual entre México y Estados Unidos, qué aporta la proximidad en cada tipo de servicio y —igual de importante— los escenarios donde el nearshore no es la respuesta correcta y otro modelo gana por mérito propio.

---

Qué es el modelo nearshore y qué no es

El modelo de entrega nearshore es aquel en el que el equipo de implementación está en un país distinto al del cliente, pero dentro de una franja horaria que produce una jornada laboral sustancialmente compartida, y a una distancia de viaje que hace práctico el trabajo presencial sin necesidad de un traslado de varios días. Para una empresa en Estados Unidos, esa franja pasa por México, Centroamérica, Colombia y parte del Cono Sur.

Esa definición contiene dos afirmaciones medibles y ningún adjetivo. No dice nada sobre calidad, nada sobre precio y nada sobre cultura. Esas cosas varían por firma, no por modelo. Lo que sí determina el modelo es un conjunto reducido de hechos operativos duros:

1. Cuántas horas de la jornada del cliente el equipo de entrega también está trabajando.
2. Cuánto cuesta poner a la gente en una misma sala cuando una decisión necesita caras, pizarrón y un día completo.
3. Bajo qué marco contractual y legal se rige la relación, incluyendo propiedad intelectual y datos personales.
4. Si el equipo que presentó el trabajo es el equipo que lo ejecuta, que depende más de cómo está estructurada la firma que de la geografía, pero que las estructuras de entrega distribuidas en múltiples regiones vuelven más difícil de garantizar.

Vale la pena ser igual de explícitos sobre lo que el nearshore no es:

• Nearshore no es sinónimo de "más barato". Si el único argumento a favor de un modelo de entrega es una tarifa mezclada más baja, el modelo no se sostiene. Las diferencias de tarifa se achican rápido cuando se contabiliza el retrabajo, el overhead de coordinación y el costo de calendario de las decisiones que esperan un día para tener respuesta. Nosotros no vendemos nearshore como descuento, y un comprador que lo evalúa exclusivamente como descuento va a elegir mal.
• Nearshore no es lo mismo que un modelo offshore con mejor marketing. La variable que los distingue es el solape, y el solape es aritmética: se puede verificar en un calendario antes de firmar nada.
• Nearshore no implica automáticamente equipo bilingüe ni automáticamente equipo senior. Son atributos de cada firma que hay que verificar uno por uno, exactamente igual que en cualquier otro modelo.
• Nearshore no es un modelo de cobertura 24/7. Un equipo que comparte tu jornada, por definición, no está despierto mientras duermes. Es un trade-off real y volvemos sobre él más adelante.

El encuadre honesto es este: el nearshore compra proximidad operativa. Si la proximidad operativa vale algo para ti depende enteramente de cómo corre tu programa. En un desarrollo bien especificado, de baja ambigüedad y alcance estable, la proximidad vale relativamente poco. En un replatform de Adobe Commerce con integración a ERP, una tienda legacy en vivo y un stakeholder de negocio que cambia de opinión cuando ve la primera demo, la proximidad vale muchísimo — porque la ambigüedad se resuelve conversando, y conversar requiere horas compartidas.

---

Los cuatro ejes objetivos de cualquier modelo de entrega

Cuando comparamos modelos de entrega con un cliente, los comparamos sobre ejes que se pueden verificar contra un calendario, un itinerario de vuelos o un contrato — nunca sobre generalizaciones nacionales o culturales, que no son verificables ni defendibles. Los cuatro que importan operativamente:

Dos notas para leer esta tabla con honestidad.

Primero, la última fila no es una nota al pie. Un modelo que comparte tu jornada no puede además cubrir tu noche. Cualquier firma que promete las dos cosas sin describir una guardia está describiendo un deseo. Más abajo dejamos por escrito nuestra propia posición.

Segundo, ninguno de estos ejes habla de las personas. Hablan de la geometría del arreglo: horas, distancia, contratos, cobertura. Un equipo excelente en una estructura distribuida va a rendir mejor que un equipo mediocre a la vuelta de la esquina. Lo que el modelo cambia es el costo de cada interacción, que se acumula a lo largo de un programa de doce meses de formas que no aparecen en ningún Gantt.

Por qué la aritmética del huso horario importa más de lo que parece

México eliminó el horario de verano a nivel nacional en 2022, así que Ciudad de México se mantiene en UTC-6 todo el año. En la práctica esto significa que la jornada en CDMX coincide con la zona Central de Estados Unidos durante parte del año y queda a una hora de diferencia el resto, y nunca se aleja más de unas dos horas de cualquier huso de Estados Unidos continental.

La consecuencia no es "podemos reunirnos". Todo el mundo puede reunirse. La consecuencia es que no existe una cola diaria de decisiones. En un modelo con dos horas de solape, cada pregunta que no se resuelve dentro de esa ventana se convierte en un mensaje asincrónico que se responde mañana. Diez preguntas sin resolver en un sprint son diez días de latencia repartidos de forma invisible en el backlog. Esa latencia no aparece en ningún reporte de estatus: aparece como "el sprint se atrasó".

---

Qué cambia realmente en la semana de trabajo

Esta es la sección que importa, porque es la única que un comprador puede contrastar contra su propio calendario. Esto es lo que cambia concretamente una jornada compartida en un programa de Adobe Commerce o de Adobe Experience Cloud.

El daily ocurre a una hora que le sirve a los dos

Un daily agendado a las 9:00 en Chicago son las 9:00 o las 10:00 en Ciudad de México. Los dos equipos están al inicio de su día, despiertos, con la jornada entera por delante para actuar sobre lo que salga de esa llamada. Nadie se conecta a las 6:00 de la mañana antes de dejar a los niños en la escuela, y nadie se conecta a las 9 de la noche después de cenar.

El efecto de segundo orden es el que cuenta: como la reunión no duele para ninguna de las dos partes, no se abandona calladamente en la semana seis. Las ceremonias que duelen se saltan, y donde se saltan ceremonias es donde empieza el scope drift.

Un incidente de producción se atiende dentro del horario hábil del cliente

Cuando el checkout empieza a fallar un martes a las 2 de la tarde, la pregunta es si los ingenieros que escribieron ese código están en sus escritorios. En un modelo de jornada compartida, sí lo están. La llamada de triage sucede en minutos, la persona que construyó la integración de pagos está en ella, y el camino del fix se decide mientras los stakeholders de negocio que tienen que aprobar un workaround temporal también están despiertos y disponibles.

En un modelo con solape angosto, el mismo incidente suele seguir otro camino: se documenta, se escala, se toma al inicio de la jornada del otro equipo y se resuelve en un ciclo medido en días hábiles y no en horas. Para un incidente un martes de bajo tráfico, esa diferencia puede ser tolerable. Para un incidente en plena ventana promocional, normalmente no lo es.

El code review es el mismo día, no el siguiente

Este es el punto menos espectacular de la lista y probablemente el de mayor consecuencia acumulada en un año. Un pull request abierto a las 11 de la mañana se revisa después de comer, se corrige por la tarde y se mergea antes de que termine el día. El autor todavía tiene el cambio en la cabeza.

Cuando el review cae al siguiente día hábil, el autor ya cambió de contexto, la rama se desactualizó, y el revisor está leyendo código escrito por alguien que ya se movió a otra cosa. Multiplicalo por cada cambio no trivial de un replatform y el costo es sustancial — no en ningún caso individual, sino en el impuesto acumulado sobre la velocidad y en los defectos que sobreviven a un review que nadie tuvo del todo el contexto para hacer bien.

La temporada alta se cubre en vivo: Black Friday, Cyber Monday y El Buen Fin

El comercio norteamericano concentra un riesgo enorme en un puñado de días, y las empresas que venden tanto en Estados Unidos como en México tienen que cubrir El Buen Fin —el fin de semana comercial mexicano, a mediados de noviembre— además de Black Friday y Cyber Monday, con esas ventanas muy próximas entre sí en el calendario.

Una jornada compartida significa que el war room es una sala real, en una llamada, en vivo, con los ingenieros que desplegaron el último release. Cuando el tráfico pica y hay que cambiar una configuración de Full Page Cache, o la sincronización de inventario empieza a rezagarse bajo carga, o un método de pago comienza a rechazar un rango específico de tarjetas, el ciclo de decisión dura minutos. Cuando la temporada alta cae sobre un desfase horario amplio, el patrón se corre hacia la planificación previa intensiva, el congelamiento de deploys y un runbook — una estrategia legítima, y más lenta cuando el runbook no cubre lo que efectivamente pasó.

Hay un segundo punto, más mundano: los dos equipos comparten buena parte del mismo ritmo anual. Un calendario de entrega cuyos días festivos caen en semanas completamente distintas a las del cliente no es catastrófico, pero es fricción, y aparece justo en los peores momentos del año.

Un workshop presencial no cuesta un día entero de viaje

Hay trabajo que no sobrevive a hacerse en remoto. El discovery de un catálogo B2B complejo. Mapear un flujo order-to-cash sobre un ERP con doce años de excepciones acumuladas. Un design sprint donde el equipo de merchandising, el dueño del ERP y el arquitecto necesitan un pizarrón y seis horas sin interrupciones. Sesiones de alineación ejecutiva donde el valor está en la sala, no en las láminas.

Con vuelos directos entre Ciudad de México y varios hubs de Estados Unidos del orden de dos a cuatro horas según el destino, esas sesiones son un viaje en el día o con una sola noche. Esa es la diferencia entre que un workshop se agende cuando hace falta y que se agende una sola vez, en el kickoff, porque el costo de viaje obliga a agruparlo todo.

Deliberadamente no ponemos un número sobre cuánto viajan nuestros equipos: eso varía por proyecto y por política de cada cliente. El punto estructural es que la opción es lo bastante barata como para ejercerla cuando se justifica.

Las conversaciones informales directamente existen

El último punto es difícil de escribir en un contrato y es el que los compradores con experiencia reconocen de inmediato. En un modelo de jornada compartida, un ingeniero le puede escribir a un desarrollador del lado del cliente y tener respuesta en cuatro minutos. Un product owner puede tomar quince minutos con el arquitecto sin una negociación de agenda. Esas microinteracciones no aparecen en ningún plan de proyecto, y ahí es donde se resuelve buena parte de la ambigüedad real.

---

Marco legal: T-MEC, propiedad intelectual y datos

La dimensión contractual y regulatoria es la parte menos discutida de la conversación nearshore y uno de sus argumentos más defendibles, sobre todo para compradores en industrias reguladas o con un área de procurement exigente. Lo que sigue es una descripción del marco, no asesoría legal: cada proyecto debe revisarlo tu propio equipo jurídico.

El T-MEC como telón de fondo operativo

El Tratado entre México, Estados Unidos y Canadá (T-MEC, USMCA por sus siglas en inglés) es el marco comercial que rige las relaciones entre los tres países desde 2020. Su relevancia práctica para un proyecto de servicios tecnológicos tiene menos que ver con aranceles —los servicios no son mercancías— y más con el hecho de que los servicios comerciales transfronterizos entre México y Estados Unidos operan dentro de un marco trilateral maduro y activamente mantenido, con capítulos sobre comercio digital, propiedad intelectual y servicios transfronterizos.

Para un área de compras, la consecuencia relevante es la familiaridad. La contratación transfronteriza entre entidades mexicanas y estadounidenses es terreno transitado: los equipos legales de Estados Unidos revisan estos contratos de manera rutinaria, las firmas mexicanas están acostumbradas a los estándares contractuales estadounidenses, y hay abogados con experiencia previa de ambos lados. La novedad es un costo en revisión legal, y aquí hay muy poca novedad.

Cesión de propiedad intelectual

En cualquier desarrollo a medida sobre Adobe Commerce —módulos, integraciones, código del storefront, pipelines de datos en Adobe Experience Platform— la pregunta que importa es si el cliente termina siendo dueño de lo que se construyó, sin ambigüedad, bajo una ley que pueda hacer valer.

La estructura estándar con la que trabajamos es directa: el proyecto se rige por el contrato con el que el equipo legal del cliente está cómodo, la propiedad intelectual de los entregables se cede al cliente al momento de su creación o del pago, cada persona del equipo de entrega está cubierta por contratos laborales o de prestación de servicios que ceden el producto del trabajo hacia arriba, y la cadena de cesión queda documentada en lugar de asumida. Esto no es exclusivo del nearshore: es lo que debería ofrecer cualquier arreglo competente en cualquier modelo. Lo que cambia con la proximidad es la facilidad de verificarlo: la entidad está a un vuelo de distancia, en una jurisdicción cuyos tribunales mercantiles y cuya ejecución de contratos tu equipo legal puede evaluar sin investigación exótica.

Datos personales y transferencia transfronteriza

Los proyectos de Adobe Experience Platform, Adobe Real-Time CDP y Adobe Journey Optimizer son, por construcción, proyectos sobre datos personales. Quién puede ver datos de producción, dónde se procesan y bajo qué base cruzan una frontera son preguntas que necesitan respuesta antes de aprovisionar el primer ambiente.

Las consideraciones relevantes:

• En México, el tratamiento de datos personales por parte de particulares se rige por la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares), que establece los principios de consentimiento y finalidad, y los derechos ARCO —acceso, rectificación, cancelación y oposición— del titular de los datos.
• En Estados Unidos, las obligaciones dependen del marco estatal y de las reglas sectoriales aplicables al cliente, y cada vez más de los estatutos estatales de privacidad de alcance general.
• La respuesta práctica es casi siempre contractual y arquitectónica, no geográfica. Convenios de tratamiento de datos que definen el rol del partner y las finalidades permitidas. Residencia de datos definida para los ambientes productivos. Acceso por rol otorgado a personas nombradas, no al equipo en bloque. Datasets anonimizados o sintéticos en ambientes inferiores, para que los ingenieros casi nunca necesiten datos de producción. Bitácoras de auditoría del acceso a los almacenes productivos.

Esa última práctica merece énfasis independientemente del modelo de entrega: la mejor respuesta a "a dónde van los datos de nuestros clientes" suele ser "los ingenieros no los tocan". Un dataset de staging correctamente anonimizado saca la mayor parte de la pregunta transfronteriza del día a día y la confina a un conjunto pequeño y controlado de escenarios operativos.

Donde la proximidad ayuda es en la auditabilidad de todo lo anterior. Una revisión de seguridad, una evaluación de protección de datos o una auditoría de proveedor son ejercicios normales cuando el proveedor está en una jurisdicción vecina, con un marco establecido y a dos horas de vuelo.

---

Qué cambia el nearshore en cada tipo de servicio

La proximidad no aporta lo mismo en todos lados. Esto es dónde mueve la aguja, servicio por servicio, y dónde la mueve menos.

Implementación de Adobe Commerce

Una implementación de Adobe Commerce (antes Magento) es un ejercicio de resolver miles de ambigüedades pequeñas: cómo se comporta un producto bundle cuando uno de sus componentes se queda sin stock, qué pasa en el ERP con una orden surtida parcialmente, qué regla de impuesto aplica a una categoría específica, si un grupo de clientes hereda el precio de un catálogo compartido o el de una cotización negociada.

Cada una de esas es una conversación de cinco minutos y un hilo de correo de dos días. La fase de implementación es donde más se acumula el efecto de una jornada compartida, porque la densidad de ambigüedad está en su pico y el costo de resolver cada punto tarde es un ciclo de retrabajo, no una decisión.

El go-live es el caso más agudo. Los fines de semana de cutover tienen una ventana, y en esa ventana quieres al arquitecto, al ingeniero de integración y al líder de operaciones del cliente todos conscientes y en la misma llamada.

Soporte y mantenimiento evolutivo

Para soporte y mantenimiento, el encuadre honesto es un intercambio: un modelo de jornada compartida te da una postura muy fuerte en horario hábil y no te da, por sí solo, cobertura nocturna.

Lo que eso significa en la práctica es que los incidentes de severidad uno durante la jornada del cliente los atienden los ingenieros que conocen el código, sin un handoff de escalamiento; que un bug reportado en la mañana puede salir a producción esa misma tarde en lugar de entrar a una cola; y que la cobertura fuera de horario es una guardia contratada y explícita, no una consecuencia implícita de la geografía. Si tu negocio realmente opera 24/7 con volumen relevante de pedidos de madrugada, pedile a cualquier partner —en cualquier modelo— que describa por escrito la rotación, la ruta de escalamiento y los tiempos de respuesta. La geografía no sustituye un SLA.

Staff augmentation y equipos dedicados

Aquí es donde el diferencial de modelo es más grande, porque el staff augmentation es el tipo de servicio que más depende de que el equipo de entrega se comporte como parte de la organización del cliente.

Un ingeniero aumentado que asiste a tu daily, a tu refinement y a tu retro en su horario normal de trabajo es un miembro de tu equipo. El mismo ingeniero asistiendo a esas ceremonias en el borde de su jornada es un contratista recibiendo instrucciones. El output puede ser comparable; la integración no lo es. Cuando el trabajo involucra desarrolladores certificados de Adobe Commerce integrados a un squad existente del cliente, esa distinción determina si el arreglo produce transferencia de capacidad o solamente throughput.

Rescate de proyectos

El rescate y optimización de proyectos es el tipo de servicio más sensible al tiempo que operamos, y en el que la proximidad aporta más por semana. Un rescate empieza con un diagnóstico, el diagnóstico necesita acceso a personas que normalmente están estresadas y ocupadas, y la versión útil de ese acceso es una sala, no un cuestionario.

Los rescates además tienen una dimensión emocional que el trabajo remoto maneja mal. Casi siempre hay un equipo interno que se siente señalado, una relación con un proveedor en problemas y un directivo que perdió la paciencia. Sentarse en persona en la semana uno cambia la trayectoria del proyecto de formas difíciles de reproducir por video.

Integración con ERP

La integración con ERP —SAP, Oracle, Dynamics— es la disciplina donde el recurso escaso no es la capacidad de ingeniería sino la agenda del equipo de ERP. Esas personas normalmente están sosteniendo el cierre contable, el cumplimiento fiscal y el núcleo operativo del negocio, y tienen muy poco margen.

Cuando los ingenieros de integración comparten jornada con el equipo de ERP, las sesiones conjuntas se agendan donde entran y no en la única hora que técnicamente solapa. El mapeo de order-to-cash, la cadena de facturación CFDI para operaciones en México, la validación de límite de crédito en el checkout, la frecuencia de sincronización de inventario: eso se trabaja en conjunto, en sesiones, no se especifica en un documento y se descubre equivocado en pruebas.

El caso B2B intensifica todavía más esto, porque en B2B el ERP deja de ser un sistema de registro y pasa a formar parte del camino transaccional.

---

Cuándo el nearshore no es el modelo correcto

Todo modelo de entrega tiene un dominio donde gana por mérito propio. Fingir lo contrario es la forma en que los compradores terminan en el arreglo equivocado, y preferimos decirlo con claridad antes que perder la credibilidad del resto del artículo. Hay tres situaciones en las que le decimos a un prospecto que otro modelo le queda mejor que el nuestro.

1. Rollout simultáneo multi-país con governance compleja

Si el programa es un lanzamiento coordinado en muchos países a la vez —con entidades legales regionales, regímenes regulatorios distintos, múltiples organizaciones de compras y una estructura de governance que tiene que reconciliarlas a todas— la capacidad que necesitas es governance de programa a escala, y las firmas construidas para eso son los grandes system integrators globales, con prácticas en varios continentes y la maquinaria interna para operarlas en conjunto.

Una firma regional especializada puede perfectamente ejecutar la porción de México o LATAM de un programa así, y muchas veces esa es la división de trabajo correcta. Pero ser el contratista principal que coordina quince mercados es una competencia distinta a entregar una excelente implementación, y la profundidad en una no implica la otra.

2. Procurement que exige un único proveedor global

Algunas empresas tienen una política de compras o de auditoría que exige un solo proveedor de registro en todas las regiones: por consolidación de responsabilidad, por un contrato marco único, por una sola revisión de seguridad o por un marco de riesgo de proveedores caro de correr contra varias firmas.

Es una restricción legítima y no es un argumento técnico que se pueda ganar siendo mejor. Si la política es firme, la respuesta honesta es que un proveedor global es el que encaja, a veces con especialistas regionales subcontratados por debajo.

3. Cobertura follow-the-sun 24/7 genuina

Si tu operación requiere cobertura de ingeniería continua —no guardia, sino un equipo trabajando a toda hora del reloj— entonces necesitas ubicaciones de entrega cuyas jornadas sean complementarias y no solapadas. Eso es exactamente lo que provee una huella de delivery ampliamente distribuida, y es una ventaja estructural real de ese modelo, no un premio de consolación.

Un modelo de jornada compartida sólo puede cubrir esto con una guardia deliberada, que es algo distinto de un turno con personal: los tiempos de respuesta son más largos, quien responde puede tener menos profundidad en ese subsistema, y el uso sostenido de ese esquema desgasta a los equipos. Si la cobertura continua es un requisito duro y no un deseable, pesalo fuerte, y desconfiá de cualquiera —en cualquier modelo— que prometa cobertura total sin describir exactamente cómo está cubierta.

Hay además un cuarto caso, menos de modelo que de escala: programas muy grandes y de horizonte largo, con cientos de ingenieros en paralelo. La profundidad de banca a esa escala es una propiedad estructural de las firmas muy grandes. Un partner especializado debería decirte cuándo un programa excede lo que puede dotar sin diluir la calidad, y un partner que nunca dice eso de ningún proyecto te está contando algo sobre su proceso comercial y no sobre su capacidad.

---

WolfSellers y el modelo nearshore

En WolfSellers somos Adobe Gold Partner con sede en Ciudad de México, con más de una década entregando proyectos de Adobe Commerce y Adobe Experience Cloud en México y Latinoamérica, y trabajando con clientes en ambos mercados. Nuestro delivery corre contra el horario hábil de Norteamérica, en español e inglés, bajo una estructura de una sola sede en la que las personas que dimensionan el trabajo son las que lo construyen.

Qué significa eso concretamente para un comprador basado en Estados Unidos o para una operación con presencia en los dos países:

1. El equipo de entrega está disponible a lo largo de tu jornada, no en sus bordes, así que las decisiones no se encolan de un día para el otro.
2. Las personas del discovery son las personas del sprint. No tenemos una región de delivery aparte a la cual pasarle tu proyecto, y eso es un hecho estructural, no una promesa.
3. El trabajo presencial es práctico. Los workshops de discovery, el acompañamiento de go-live y las sesiones ejecutivas son un vuelo corto, no una expedición.
4. La contratación transfronteriza es rutina, bajo el marco del T-MEC, con cláusulas de cesión de propiedad intelectual y de tratamiento de datos que a tu equipo legal le van a resultar familiares.
5. El contexto comercial local es nativo, lo cual importa si alguna parte de tu operación toca México: facturación CFDI 4.0, conciliación de OXXO Pay y SPEI, meses sin intereses por banco y los patrones de tráfico de El Buen Fin son cosas que hemos implementado, no cosas que tendríamos que investigar.
6. Decimos cuándo otro modelo encaja mejor. Los tres escenarios de arriba son reales, y preferimos señalarte la estructura correcta antes que tomar un proyecto que nuestro modelo no sirve bien.

Si estás evaluando cómo dotar un replatform de Adobe Commerce, un esquema de soporte y evolución, un equipo dedicado o la recuperación de un proyecto que se torció, la forma en que empezamos es la misma en todos los casos: una sesión de discovery gratuito donde mapeamos el programa, las restricciones y la realidad de calendario antes de que nadie proponga una arquitectura. Nuestra página de consultoría describe cómo trabajamos, y si lo que necesitas primero es un marco para elegir entre partners y no un modelo de entrega, empezá por nuestra guía sobre cómo elegir un partner de Adobe Experience Cloud en México o por nuestro panorama de consultoría Adobe Commerce como partner en México.

---

Preguntas frecuentes sobre el modelo nearshore en Adobe Commerce

¿Qué es el modelo nearshore en un proyecto de Adobe Commerce?

Nearshore significa que el equipo de implementación trabaja desde un país distinto al del cliente, pero dentro de una franja horaria que produce una jornada laboral sustancialmente compartida, y lo bastante cerca como para hacer sesiones presenciales sin un viaje de varios días. Para un cliente en Estados Unidos, un partner con sede en Ciudad de México opera en UTC-6 todo el año, lo que lo mantiene dentro de unas dos horas de cualquier huso de Estados Unidos continental. Operativamente el modelo se define por tres cosas: las ceremonias diarias ocurren a horas razonables para ambas partes, los incidentes de producción durante el horario hábil del cliente llegan a los ingenieros que escribieron el código, y los workshops presenciales son un viaje en el día. No se define por precio, y un proyecto nearshore evaluado exclusivamente como descuento está siendo evaluado sobre el eje equivocado.

¿Cuántas horas de solape tiene un equipo en México con el horario hábil de Estados Unidos?

México eliminó el horario de verano a nivel nacional en 2022, así que Ciudad de México permanece en UTC-6 durante todo el año. Eso la deja a la par de la zona Central de Estados Unidos durante parte del año y a una hora de diferencia el resto, aproximadamente a una o dos horas de la zona Este, y a una o dos horas de la zona Pacífico. En la práctica esto produce prácticamente una jornada laboral completa compartida con cualquier parte de Estados Unidos continental: las ventanas de trabajo estándar se superponen en lugar de tocarse en los bordes. La consecuencia relevante no es que las reuniones sean posibles, sino que las preguntas no se acumulan en una cola de decisiones que espera hasta el día siguiente.

¿Un partner nearshore de Adobe Commerce en México es más barato que las alternativas?

No posicionamos el modelo sobre el precio y no publicamos tarifas en un artículo de blog, porque la respuesta honesta depende del alcance, de la mezcla de seniority y de la duración. Lo que sí decimos con claridad es que si el costo fuera la única variable, el modelo no valdría la pena escribirlo. Los argumentos defendibles son operativos: horas hábiles solapadas, acceso presencial práctico, un marco contractual familiar y continuidad entre el equipo que dimensiona y el que construye. El costo total de un programa lo determinan mucho más el retrabajo, el scope drift y la latencia de decisión que una tarifa mezclada, y son precisamente esas las variables sobre las que influye el modelo de entrega. Para un número real sobre un alcance real, primero corremos un discovery gratuito.

¿Cómo se manejan la propiedad intelectual y los datos personales en un proyecto transfronterizo?

Propiedad intelectual: en los esquemas bajo los que trabajamos, es del cliente. La estructura estándar le cede la propiedad intelectual de todos los entregables —módulos a medida, integraciones, código del storefront, pipelines de datos— con la cadena de cesión documentada desde cada persona que contribuye hacia arriba, mediante contratos laborales o de prestación de servicios. No es una propiedad exclusiva del nearshore: es lo que debería ofrecer cualquier contrato de servicios bien redactado en cualquier modelo. Lo que cambia con la proximidad es la verificación: la contratación transfronteriza entre entidades mexicanas y estadounidenses bajo el marco del T-MEC es terreno rutinario para los abogados de ambos lados.

Datos personales: la respuesta es contractual y arquitectónica, no geográfica. En proyectos de Adobe Experience Platform, Real-Time CDP y Adobe Journey Optimizer, las prácticas que importan son un convenio de tratamiento de datos que defina el rol del partner y las finalidades permitidas, residencia de datos definida para los ambientes productivos, acceso por rol otorgado a personas nombradas y no al equipo en bloque, datasets anonimizados o sintéticos en ambientes inferiores para que los ingenieros casi nunca necesiten datos de producción, y bitácoras de auditoría del acceso a los almacenes productivos. En México, el tratamiento de datos personales por particulares se rige por la LFPDPPP, que establece los principios de consentimiento y finalidad y los derechos ARCO del titular; en Estados Unidos, las obligaciones dependen del marco estatal y sectorial del cliente. Hacé que tu propio equipo legal revise ambos bloques de cláusulas antes de firmar.

¿Cuándo el nearshore es la elección equivocada para un programa de Adobe Experience Cloud?

Tres casos, y se los decimos a los clientes de frente. Primero, un rollout simultáneo en muchos países con governance multi-región, donde la competencia escasa es la coordinación de programa a escala y un integrador global grande está estructuralmente mejor equipado. Segundo, un procurement que exige un único proveedor global de registro por consolidación de responsabilidad o por una auditoría unificada: una restricción de política que ningún argumento técnico revierte. Tercero, cobertura follow-the-sun genuina, donde necesitás ingeniería con personal a toda hora del reloj: eso requiere husos complementarios, que es una ventaja estructural de las huellas de delivery ampliamente distribuidas y algo que un modelo de jornada compartida sólo puede aproximar con una guardia. Un cuarto caso relacionado es un programa tan grande que la profundidad de banca se vuelve la restricción vinculante.

¿Un esquema de soporte nearshore cubre incidentes fuera del horario hábil?

Sólo si está contratado para eso. Un equipo que comparte tu jornada, por definición, no tiene personal trabajando mientras dormís, y cualquier partner que sostenga lo contrario sin describir el mecanismo está describiendo un deseo. Lo que el modelo sí aporta es que los incidentes dentro de tu horario hábil llegan a los ingenieros que construyeron el sistema, sin un handoff de escalamiento, y que un bug reportado en la mañana puede salir esa misma tarde. Para cobertura nocturna, pedí las especificaciones por escrito sin importar el modelo del partner: quién está en la rotación, cuáles son los objetivos de respuesta por severidad, cómo funciona el escalamiento y si quien responde de guardia realmente conoce el subsistema. La geografía nunca sustituye un SLA documentado.

---

Servicios relacionados