Cuando una empresa tecnológica en crecimiento quiere expandirse rápida y eficazmente a nuevos mercados, se enfrenta a una serie de nuevos retos. Esto fue muy cierto en DoorDash, donde pasamos años actualizando nuestra plataforma para garantizar un lanzamiento exitoso en 2015 en Canadá, seguido de nuestra expansión a Australia en 2019 y a Japón en 2021. Para reducir el tiempo entre lanzamientos, necesitábamos ir más allá de abordar los desafíos específicos de cada país y construir una plataforma que pudiera hacer que los lanzamientos al mercado fueran más automatizados y rápidos de ejecutar.
Aquí veremos algunos de los retos específicos a los que nos enfrentamos y describiremos nuestro planteamiento general para crear una plataforma que agilice los lanzamientos internacionales. En próximas entradas repasaremos las soluciones específicas que estamos construyendo para resolver estos problemas.
Retos y oportunidades de la expansión mundial
A pesar de los retos que supone introducirse en nuevos mercados, las empresas tecnológicas pueden captar innumerables oportunidades mediante la expansión internacional. Además de disfrutar de mercados diversos, las empresas pueden aprovechar los mercados laborales locales para incorporar más talentos al equipo. Principalmente, por supuesto, las empresas que crecen en el extranjero buscan aumentar el grupo de consumidores disponibles. En general, las empresas se dirigen a una clientela específica, que puede ser limitada en su país de origen. La expansión a nuevos mercados ofrece oportunidades para atraer a nuevos clientes y aumentar los ingresos.
La expansión internacional también facilita la atracción y retención de nuevos talentos locales. Dado que sólo hay un número limitado de ingenieros experimentados en un lugar determinado, trasladarse a un nuevo mercado crea una oportunidad para competir en ese mercado local de contratación y hacer crecer el equipo. Una ventaja añadida es que los ingenieros locales están más en sintonía con las necesidades específicas de su país de origen.
Los retos de crear una plataforma internacional
Construir una plataforma internacional que permita a nuestro equipo lanzarse rápidamente en un nuevo país conlleva una serie de retos que tuvimos que abordar.
Desafío: Localizar un conjunto de productos de forma coherente en una plataforma global.
Una pieza central del reto de la globalización es localizar y traducir todos los productos que se utilizan en la plataforma global de DoorDash para que cualquiera pueda utilizarlos. Los usuarios de cada mercado preferirán interfaces de aplicaciones que tengan un formato, un idioma y un sistema de numeración localizados. Esto será cada vez más importante a medida que DoorDash se expanda a países de habla no inglesa. Para tener éxito en un mercado, los productos deben presentar los datos a todos los usuarios en un formato con el que se sientan cómodos. Cada tipo de datos que necesita ser localizado puede traer su propio conjunto de desafíos. En una de nuestras entradas anteriores se explicaban los distintos tipos de datos que se incluyen en un proceso de localización:
- Texto: Un proceso de localización requiere traducir todas las cadenas de texto de las aplicaciones y hacerlas visibles para los usuarios.
- Direcciones: Si la aplicación trata con una dirección física, es importante tener en cuenta que las distintas localidades escriben las direcciones en formatos diferentes. En algunas regiones, las direcciones empiezan por el país y luego descienden hasta el número de unidad, mientras que en otras se sigue el orden inverso.
- Unidades de medida correctas: Las distintas regiones muestran medidas como el peso de un artículo en una variedad de unidades; la aplicación debe utilizar la más común para esa región.
- Costumbres en materia de nombres: El orden del nombre de pila y del nombre de pila puede variar de un país a otro. Además, los pronombres pueden utilizarse en contextos diferentes según el público y la formalidad del idioma, como los honoríficos en japonés.
- Los números: Cada lengua tiene su propia forma de escribir los números con respecto a los puntos decimales y los separadores de grupos de dígitos.
- Divisa: presenta dos retos, convertir los precios y mostrarlos en la divisa local y tratar con las diferentes anotaciones en la base de datos, ya que un punto y una coma significan cosas diferentes para las distintas divisas y puede ser difícil para el backend determinar el número de unidades significativas en cada precio.
- Fecha y hora: Diferentes regiones tienen diferentes convenciones para mostrar la fecha. Por ejemplo, en los países donde la convención es que el día es la primera parte de una fecha el mes causaría confusión. Nuestra aplicación debe ser capaz de mostrar la fecha de forma diferente en función del lugar en el que se utilice.
Además de garantizar la aplicación de todos estos atributos, es importante que los esfuerzos de localización estén estandarizados. Sin un sistema de localización estándar y centralizado, los equipos internos idearán sus propias soluciones, que no se adaptarán ni podrán mantenerse a largo plazo.
Otro problema habitual a la hora de realizar estas traducciones es el tamaño binario de las aplicaciones cliente, que crece linealmente con el número de configuraciones regionales compatibles. El creciente tamaño binario sobrecarga la aplicación, dificultando su descarga y uso, aunque cada usuario solo utilice una configuración regional dentro de la aplicación.
Solución: Crear un servicio de localización centralizado y bibliotecas para ofrecer una experiencia coherente.
Para abordar la localización de todos los productos de DoorDash, estamos creando un servicio que satisfaga todas las necesidades de traducción de todas las aplicaciones y binarios, así como un conjunto de bibliotecas estáticas que cubran la localización de un subconjunto de otros tipos de datos. Esto estandarizará todos los servicios, simplificando el mantenimiento del sistema.
Una cuestión clave para una buena canalización de la localización es qué solución adoptaríamos para cada uno de los formatos de datos descritos en la sección anterior. Podríamos adoptar dos enfoques:
- Crear servicios a los que otros servicios llamen para obtener la versión localizada del contenido. Aunque esta solución añadirá latencia y dependencia del servicio de localización, garantizará que toda la localización se encuentre en un único lugar.
- Crear bibliotecas estáticas que los servicios y binarios puedan integrar y llamar en sus flujos de código. Esta solución ofrece la menor sobrecarga, pero el menor control porque dependería de los servicios y binarios individuales asegurarse de que se integran con las bibliotecas.
Para aprovechar ambos enfoques, adoptamos una solución híbrida que difiere en función del formato de los datos.
El servicio de traducción que estamos construyendo puede servir las cadenas traducidas dinámicamente cuando se soliciten durante el tiempo de ejecución desde nuestros otros microservicios. Esto ayudaría a los equipos a servir cadenas completamente nuevas desde sus bases de datos sin necesidad de reconstruir y desplegar sus servicios. El servicio también servirá traducciones para las aplicaciones del lado del cliente que deseen compilar todas las traducciones en el paquete de aplicaciones.
Este servicio de localización será completamente transparente para los desarrolladores y mejorará su velocidad, ya que podrán llamar al servicio de traducción en lugar de esperar a que las traducciones se realicen en segundo plano. Además del servicio de traducción, tenemos bibliotecas en todos los idiomas y marcos utilizados en DoorDash para admitir otros formatos de localización de datos, como fecha/hora, moneda y formato numérico. También aprovechamos al máximo las API de la plataforma dentro de esas bibliotecas. Estas herramientas permiten a los equipos optar por estas herramientas comunes en toda la empresa con una sobrecarga mínima, al tiempo que les da cierta autonomía para elegir el idioma y el marco con el que quieren trabajar.
Reto: adaptar nuestra plataforma para respetar las leyes, normativas y costumbres locales.
Para que un producto esté listo para su lanzamiento en un nuevo mercado, debe respetar las leyes, normativas y costumbres locales. Este proceso crea una serie de elementos de acción para empresas como DoorDash, porque tenemos muchos puntos de contacto diferentes que están todos integrados en plataformas diseñadas para atender a todos nuestros clientes. Si hay que hacer frente a una ley o reglamento importante, tenemos que crear una experiencia totalmente nueva para esa localidad específica o modificar nuestra plataforma existente para que pueda hacer frente a las leyes locales en sus respectivos lugares.
Dado que los procesos empresariales tienen muchas capas de complejidad, llevaría mucho tiempo y exigiría duplicar esfuerzos escudriñar esos procesos para reescribir los flujos operativos. En lugar de eso, necesitábamos una forma de copiar los flujos que seguían funcionando en un nuevo mercado y, al mismo tiempo, poder sustituirlos fácilmente por otros nuevos que cumplieran la legislación local.
Solución: Utilizar un patrón de almacén de configuración para flujos alternativos
La forma más práctica de tratar las distintas configuraciones es crear un paso inicial que decida qué flujo utilizar en función de la región o el código de país del usuario de la aplicación. De este modo, la aplicación puede decidir qué experiencias mostrar, sin necesidad de crear aplicaciones separadas, que serían más difíciles de mantener. Cada experiencia puede adaptarse a un mercado concreto. Esto nos permite construir flujos separados para satisfacer los requisitos únicos de cada lugar. Cuando cada usuario abre la aplicación, su experiencia puede dirigirse a un flujo de aplicación que se ajuste a la normativa local.
Para lograr este objetivo fue necesario construir un conjunto de componentes reutilizables que capturan las diferentes partes del flujo en lugar de crear una aplicación monolítica menos flexible. Estos componentes son plug-and-play, lo que nos permite elegir cuál incluir en la tubería a través de una configuración JSON externa. Aprovechando los componentes reutilizables, podemos personalizar fácilmente el flujo para cada mercado de modo que la aplicación muestre automáticamente el modelo correcto para ese mercado.
Reto: cómo integrarse con los socios locales de cada mercado
La integración con socios locales también es clave para el éxito del lanzamiento. Las asociaciones locales contribuyen al éxito de la empresa en una región al integrarse con un producto para un uso más fluido y una adopción más rápida. Por supuesto, las distintas empresas tienen diferentes puntos de integración y API porque cada una se diseñó de forma independiente. Cuando no existen normas de código abierto aceptadas o grupos de trabajo que normalicen las reglas y formatos de las API en un ámbito concreto, la integración se convierte en un problema de escalabilidad; cada nuevo socio requiere desarrollar una nueva integración desde cero.
A medida que aumenta el número de socios de una empresa, también lo hace la amplitud de sus API. Sin la estrategia adecuada, el esfuerzo necesario para incorporar nuevos socios e integrarse con sus API crecerá linealmente con el número de socios. Esto puede suponer un reto engorroso que no sería escalable para ninguna empresa que pretenda captar la larga cola de pequeños socios en todo el mundo.
Un ejemplo del esfuerzo que ha supuesto ha sido nuestra integración con bancos locales para integrar su sistema de pagos en DashPass. Como no disponíamos de estas API ni de puntos de integración con plantillas, tuvimos que invertir una buena cantidad de recursos para ofrecer ese producto.
Solución: Crear una biblioteca para todas las API de terceros
La mejor forma de abordar las integraciones de terceros es proporcionar API claras y comprensibles para que los desarrolladores de terceros puedan utilizar nuestros estándares, en lugar de adaptarnos al sistema exclusivo de cada socio. A medida que nos lanzamos en diferentes países, nos integramos con socios locales en una variedad de espacios, como tiendas de comestibles y bancos locales. Para poder generalizar nuestro sistema, necesitamos formalizar las API de los distintos productos para que cualquier tercero pueda integrarse con ellos. Al formalizar nuestras API, podemos resolver el problema de la integración de terceros publicando nuestros patrones y proporcionando guías de integración a los desarrolladores de terceros.
Un buen conjunto de API debe ser coherente en todos los ámbitos para minimizar el esfuerzo de integración. Estas son las mejores prácticas que nos han guiado:
- Coherencia en toda la superficie de la API: Si hay un campo común esperado en diferentes endpoints, todos ellos los esperarán de la misma manera. Por ejemplo, pasar la clave de desarrollador, que es el campo más común en todas las API, debe ser coherente. La existencia de API diferentes dificultaría la integración con ellas.
- APIs adaptables: Crear APIs para que los llamantes puedan adaptarlas con consultas les permite recibir la respuesta deseada en el formato adecuado, como xml o json.
- Compatibilidad con versiones anteriores y evolución futura: Aunque la API evolucione y añada más funciones, es importante que estos cambios no rompan ninguna integración existente.
Un conjunto coherente de API nos permite captar la larga cola de pequeños socios que sería imposible acomodar caso por caso.
Para optimizar este proceso de generalización de nuestros patrones de API, estamos realizando grandes inversiones en Drive y DashPass para facilitar a los bancos y otros minoristas la integración con ellas. Esto nos permitirá ampliar nuestro alcance mucho más rápido y permitirá a terceros aprovechar fácilmente nuestras API.
Reto: mantener los servicios en todas las zonas horarias
A medida que un producto se lanza en nuevos países y zonas horarias, se crean problemas específicos de cada mercado que deben resolverse en todo momento, sin que ello suponga una carga excesiva para los equipos de ingeniería de apoyo. Suele haber un patrón de tráfico de usuarios que cambia según el día de la semana o la hora del día en cada mercado. Por ejemplo, el número de pedidos de comida a domicilio es mayor durante el día que por la noche. Por lo tanto, los distintos problemas pueden tener un impacto diferente en función del lugar en el que se produzcan.
La principal preocupación es obtener la respuesta más rápida sobre problemas y cortes importantes, minimizando al mismo tiempo el número de personas implicadas para evitar ruido redundante. Es posible que haya empleados en la zona horaria afectada que puedan examinar el problema durante su horario laboral. Eso puede darnos el tiempo de respuesta más rápido, pero puede que no nos proporcione los conocimientos más relevantes relacionados con la avería. Por otro lado, avisar siempre al equipo propietario puede proporcionarnos los conocimientos óptimos, pero puede costar un tiempo precioso si el ingeniero al que llamamos debe despertarse en mitad de la noche y ponerse a tono para gestionar el problema.
Solución: Garantizar la salud del sistema con una estrategia de guardia eficaz
Un sistema de atención continuada de varios niveles podría ofrecernos lo mejor de ambos mundos en términos de optimización de la experiencia y la eficiencia". A medida que DoorDash avance hacia nuevas regiones, ampliará su huella de ingeniería en cada país. A lo largo de la colaboración entre estas oficinas y el establecimiento de una buena ruta de transferencia de conocimientos, asignaremos a los ingenieros de cada región el soporte de guardia de esa zona. Por ejemplo, asignaremos a los ingenieros de APAC las guardias de APAC y a los ingenieros de EMEA las guardias de EMEA.
Esta estrategia garantiza que cada problema se dirija a los expertos regionales. La otra nota positiva de esta estrategia es que, debido al patrón de tráfico de usuarios día/noche, cuando el tráfico es elevado en una región es menos probable que el ingeniero de guardia designado, que se encuentra en la misma zona horaria, esté dormido, lo que genera tiempos de respuesta más rápidos. Si se necesita más ayuda de otros equipos, el ingeniero de guardia regional puede derivar el problema al equipo de dominio si es necesario. En ese caso, los equipos de dominio sólo tendrán que intervenir si el problema no puede ser resuelto inmediatamente por el equipo regional de guardia o para el seguimiento de soluciones a largo plazo que no sean tan urgentes como el problema o la avería original.
Conclusión
A medida que más empresas se trasladen al extranjero y las empresas sigan adoptando el trabajo a distancia, estos retos se dejarán sentir con más intensidad en todo el sector. El desarrollo de las mejores prácticas ayuda a todas las empresas a crecer con mayor rapidez y eficacia.
Hemos creado una organización dedicada a proporcionar apoyo a otros equipos de DoorDash para resolver algunos de estos retos. Esta organización está muy involucrada en el lanzamiento de DoorDash en nuevos países y permite a DoorDash innovar horizontalmente mientras los equipos principales innovan verticalmente en otros productos. Si estás interesado en formar parte de este esfuerzo de ingeniería, considera unirte a nuestro equipo de plataforma internacional consultando las oportunidades abiertas aquí.
