Deslocalización y la India

Uno de los temas que siempre había leido y nunca había experimentado es el de la deslocalización. Se trata de un tema sobre el que ya se ha escrito mucho, sobre todo en cuanto a bibliografía empresarial, pero al que nunca le había prestado atención hasta ahora, que me toca experimentarlo en cierta medida.

En nuestra empresa tenemos parte del desarrollo deslocalizado en la India. Ahí se encuentra un equipo que ha estado trabajando durante más de un año en la creación de un producto para el mercado financiero, que fue lanzado con bastante buena acogida hace unos meses. A parte de esto, este equipo se dedica también a la creación de algunos módulos para nuestro producto bandera, cuyo 95% se realiza aquí en Dublin, Irlanda. Tras varios meses observando el trabajo de este equipo, la verdad que uno puede sacar una serie de conclusiones sobre el trabajo deslocalizado en zonas como Asia, que intentaré expresar a continuación.

La ventaja más conocida para la deslocalización es el coste. Ante eso no hay discusión posible, y tener un equipo de trabajo en la India es más barato que tenerlo en Europa, incluso en Europa del Este. Por lo tanto ya tenemos una ventaja, que es el dinero.

Sin embargo, esta no es la mayor ventaja según que empresa. Llegado un punto en el que una empresa se expande internacionalmente, como es el caso de muchas empresas financieras, y más incluso cuando entras en un mercado como el FX en el que se opera durante las 24h del día, no te queda más remedio que mover equipos de soporte para servir a la zona de Asia. Este es por ejemplo nuestro caso, en el que desde Europa servimos a todo el mundo durante 16 horas, mientras que desde India sirven las 8 horas restantes también a todo el mundo. Esta ventaja, sumada a la anterior de los salarios, hace realmente de la India el lugar ideal para ofrecer soporte cuando Europa duerme.

Por otra parte parece que los equipos de la India trabajan muy bien de manera independiente, de modo que pueden realizar productos de manera rápida, especialmente cuando puedes crear equipos grandes con la cuarta parte del dinero que emplearías aquí, en Europa.

Sin embargo, también tenemos algunas desventajas. Principalmente también derivadas por el desfase horario. Lo cierto es que aunque estos equipos trabajan muy bien de manera independiente, la realidad es que cuando se intenta coordinar los esfuerzos entre continentes empiezan los problemas. Mientras que el proyecto independiente en la India fue un éxito, la realidad es que los módulos para el núcleo presentaron muchos problemas, y los equipos deslocalizados fueron los que acumularon los mayores retrasos, bugs, etc. El número de problemas ha sido y es relmente extenso

• Retraso general en la implementación.


• Necesidad de mover personas a la India para implantar una cultura de procesos, ofrecer formación, mostrar frameworks, etc., ya que de otra forma es muy difícil realizar la formación a distancia.


• Imposibilidad de una comunicación salvo fuera del horario de trabajo. Correos cruzados que se contestan al día siguiente, en uno u otro sentido, imposibilidad de comunicarse fluidamente en horarios de trabajo, etc.


• Problemas con las builds. Si en un continente no son capaces de solucionar problemas, es imposible realizar una build durante todo el día siguiente en el otro continente.


• Problemas con despliegues. Se hace realmente difícil el sincronizar la clonación clusters, el realizar tests de integración, etc.

En fin, podría seguir. Este problema no se debe a que unos sean más listos que otros. No. Simplemente es un problema de comunicación y como ya he comentado anteriormente, de desfase horario. Por poneros un ejemplo, hoy mismo todavía no teníamos una solución para un problema con un módulo desarrollado allá, y que nos imposibilita el realizar un test de integración completo. El problema: cuando notificas el error, ellos no lo reciben hasta el día siguiente. Si les lleva dos días solucionar el error, tu lo sabrás al día siguiente, haciendo un total de cuatro días de espera. Esto hace que prácticamente hayas perdido una semana sin poder realizar un test completo, mientras que si el equipo estuviera localizado se podría reducir a un día, teniendo en cuenta el mayor número de recursos disponibles.

Bueno, esta es mi experiencia, al menos hasta el momento. Como veis es agridulce. Hay cosas buenas y cosas malas. Resumiendo, el mover el soporte allí me parece una fenomenal idea, y tampoco parece mala idea el mover ciertas aplicaciones. Por otra parte, el compartir el desarrollo de aplicaciones se muestra como algo complicado, y lo mismo se podría decir del mover núcleos importantes hacia zonas con un menos control.

Espero comentar más sobre este tema en un futuro, quizás con conclusiones más definitivas.