Estuve estudiando hace unos meses sobre equipos distribuidos que trabajan en diferentes zonas horarias y/o países. En el libro de Mike Cohn sobre Scrum, hay algunos ejemplos sobre este tipo de situaciones y cómo manejarlas.
Quiero saber sobre su aplicabilidad en todos los países y qué desafíos se enfrentan al considerar las diferentes leyes de contratación. ¿Cómo funciona eso en la práctica?
¿Es posible que un desarrollador trabaje desde su casa en China y teletrabaje a EE. UU.?
¿Qué tipo de herramientas se pueden utilizar para mejorar el trabajo en equipo y el contacto personal, aunque estén a kilómetros de distancia?
Agradecería tener ejemplos en la práctica, si existen.
Los dos desafíos principales que encontrará al trabajar con un equipo distribuido globalmente son:
Diferencias horarias. Normalmente, no trabajará con sus colegas al mismo tiempo (a menos que estén dispuestos a trabajar en horarios inusuales); es posible que tenga varias horas de superposición en los horarios, cuando puede comunicarse en tiempo real (teléfono, skype, mensajería instantánea, por ejemplo ). instancia). Esto inhibe en gran medida la comunicación rápida: algo que podría tomar 5 minutos en el teléfono puede extenderse fácilmente a 2 días de correo electrónico.
Barrera del idioma. En particular, si sus colegas están en un país donde el idioma nativo no es el suyo (o el idioma elegido para el proyecto). Tomará más tiempo y esfuerzo asegurarse de que su comunicación sea clara (evite las abreviaturas, la jerga y las referencias específicas de la cultura, por ejemplo). Todavía habrá lugares donde el significado no se transferirá bien (se perderá en la traducción...). Deberá usar documentación explícita y agregar detalles que normalmente no agregaría al comunicarse con personas en la misma oficina.
Por supuesto, hay otros problemas: cultura, diferentes festividades y más, pero estos son secundarios a los dos problemas principales que describí anteriormente.
Quiero saber sobre su aplicabilidad en todos los países y qué desafíos se enfrentan al considerar las diferentes leyes de contratación. ¿Cómo funciona eso en la práctica?
Esto es difícil de responder, ya que cada país tiene diferentes leyes laborales. Si trabaja con estas personas como parte de la misma empresa (es decir, son empleados), deberá cumplir con las leyes locales. Las cosas son más fáciles cuando se trabaja con contratistas/trabajadores autónomos.
¿Es posible que un desarrollador trabaje desde su casa en China y teletrabaje a EE. UU.?
Bueno, el teletrabajo no implica viajar. Es simplemente alguien sentado en su computadora (o la de la oficina) y trabajando en el proyecto. Como describí en mi primer punto, el verdadero problema aquí es la diferencia horaria.
No espere mantener el mismo horario en todo el mundo y espere que la comunicación tarde mucho más de lo esperado para un equipo que no está distribuido.
¿Qué tipo de herramientas se pueden utilizar para mejorar el trabajo en equipo y el contacto personal, aunque estén a kilómetros de distancia?
Básicamente, necesita usar sistemas en línea para la colaboración, sistemas que están disponibles a nivel mundial.
Quiero saber sobre su aplicabilidad en todos los países y qué desafíos se enfrentan al considerar las diferentes leyes de contratación. ¿Cómo funciona eso en la práctica?
Creo que probablemente variará según el país y la empresa, pero al menos algunas de las empresas más grandes manejan esto al tener una empresa/subsidiaria registrada en cada país en el que tienen personal. Los empleados están asociados con la organización correspondiente a su país, y cada empresa/subsidiaria opera bajo las leyes de contratación/empleo asociadas con su país.
Hay muchos gastos generales de contabilidad y teneduría de libros en ese enfoque, por lo que tendría que imaginar que las empresas más pequeñas podrían usar una solución diferente. No estoy seguro de qué podría ser eso, además de posiblemente tratar a los empleados extranjeros como trabajadores contratados en lugar de empleados regulares. Entonces, en teoría, todo lo que necesita es un abogado competente en el derecho contractual del país correspondiente para redactar algún tipo de acuerdo adecuado.
¿Es posible que un desarrollador trabaje desde su casa en China y teletrabaje a EE. UU.?
Sí, aunque no creo que sea muy correcto hablar de teletrabajo en una ubicación específica. El chico en China podría teletrabajar con el fin de colaborar con sus compañeros de equipo en los EE. UU., como discutir tareas, participar en reuniones, etc.
Con suerte, no esperaría que él mantuviera el horario de EE. UU. y que su(s) equipo(s) se acomodaran lo suficiente como para programar sus reuniones en horarios que se consideran horas de trabajo regulares en ambos lugares. A veces, eso no siempre es posible (las diferencias de zona horaria pueden ser complicadas), pero cuanto más acogedor pueda hacer el entorno de trabajo, más éxito tendrá con sus empleados remotos. Nadie quiere tener que levantarse a las 2:00 am para una reunión porque algún gerente en una torre de marfil decretó "todos los trabajadores en todos los países mantendrán la hora de California".
¿Qué tipo de herramientas se pueden utilizar para mejorar el trabajo en equipo y el contacto personal, aunque estén a kilómetros de distancia?
Hay toneladas. Como mínimo querrás:
En el artículo de Martin Fowler, Uso de un proceso de software ágil con desarrollo en el extranjero , se presenta un estudio de caso y una introducción bastante fundamental sobre cómo manejar el desarrollo como usted describe .
Este artículo describe los conceptos básicos y avanzados para configurar la comunicación de equipo distribuido:
Use Continuous Integration to Avoid Integration Headaches Have Each Site Send Ambassadors to the Other Sites Use Contact Visits to build trust Don't Underestimate the Culture Change Use wikis to contain common information Use Test Scripts to Help Understand the Requirements Use Regular Builds to Get Feedback on Functionality Use Regular Short Status Meetings Use Short Iterations Use an Iteration Planning Meeting that's Tailored for Remote Sites When Moving a Code Base, Bug Fixing Makes a Good Start Separate teams by functionality not activity Expect to need more documents. Get multiple communication modes working early
Incluso para los equipos en los que tener todo lo anterior sería una exageración, el artículo mencionado podría ser realmente útil como un medio para tener una lista de verificación completa , de modo que incluso los elementos omitidos se verifiquen y tengan razones claramente documentadas para el rechazo, solo para asegurarse de que no haya nada importante. omitido.
gdfbarbosa