¿Ya te decidiste a trabajar con un equipo de devs remotos en Latam? Entonces necesitas una política de trabajo remoto oficial, ya que esto te permitirá clarificar expectativas, alinear a tus desarrolladores y evitar errores críticos.
¿No sabes qué aspectos debe abordar? No te preocupes, aquí te damos una checklist muy puntal de todo lo que debe incluir.
¿Qué es una política de trabajo remoto?
Comencemos por explicar qué no es: una política de trabajo remoto no es una serie de recomendaciones informales que viajan boca a boca entre los colaboradores y los gerentes, y tampoco es una lista de puntos que mencionamos rápidamente durante el onboarding, esperando que el nuevo colaborador tome nota y los ponga en práctica.
Es importante aclarar esto porque una política empresarial de cualquier tipo debe ser un documento formal de estándares que, para fines prácticos, tiene la misma validez que un contrato y cláusulas que especifican perfectamente qué se espera de los empleados y qué pueden esperar los empleados de la compañía.
Puede ser que tu empresa ya tenga una serie de políticas laborales referentes al trabajo presencial, pero el trabajo de desarrollo de software con un equipo remoto generalmente necesita sus propias reglas para adaptarse a metodologías ágiles y a temas relacionados con la seguridad de la información y la asincronía.
Para comenzar, es necesario crear estructura o borrador general de tu política de trabajo remoto, tomando en cuenta los siguientes aspectos básicos:
1.- Horarios, metas y objetivos
La primera pregunta que necesitas hacerte es si las jornadas laborales van a estar guiadas por el número de horas de trabajo efectivo, o por el alcance de objetivos diarios o semanales. En caso de que elijas los objetivos, es importante que sean metas realistas y alcanzables en un espacio de tiempo razonable que no atente contra el equilibrio en las áreas de vida de tus colaboradores.
Si prefieres trabajar por número de horas, es necesario que determines cómo vas a monitorear la productividad de tus devs mientras están trabajando, si entrarán en un horario estricto con breaks a determinadas horas, o si ellos pueden elegir cómo organizan sus tiempos.
En este punto también necesitas especificar cuál es la disponibilidad de respuesta que esperas de tus devs, por ejemplo, que no tarden más de 30 minutos en responder una solicitud del líder de proyecto cuando esta ocurre en horario hábil o síncrono de trabajo.
2.- Requerimientos de hardware, sistema y herramientas
¿Cuáles son los requisitos mínimos que debe cubrir el equipo con el que trabajan tus devs? ¿Qué programas y versiones necesitan tener instalados? ¿En qué plataformas de trabajo colaborativo en la nube tienen que registrarse? ¿La empresa se hará cargo de cubrir algunas herramientas de trabajo y/o licencias, o será responsabilidad de tus colaboradores? En caso de que así sea, ¿cómo amortizan este aspecto las compensaciones generales del puesto?
3.- Seguridad y confidencialidad
Una de las pocas desventajas declaradas que tiene el trabajo remoto en proyectos de programación, es que la información y la seguridad pueden ser mucho más vulnerables cuando no tienes control total de las redes mediante las cuales se conectan a tus sistemas y servidores.
Es muy importante que consultes con un experto en ciberseguridad cuáles son las buenas prácticas que todos los miembros de tu equipo deben seguir, por ejemplo respaldar sus avances diarios, usar un VPN, proteger los meetings con un password o evitar usar dispositivos personales o redes públicas para acceder a la plataforma.
4.- Flujos de trabajo
Esta sección responde a la pregunta ¿cómo vamos a integrar nuestro trabajo con el trabajo de los demás para que se cree una sinergia de productividad y eficiencia con todo el equipo?
Tus devs pueden ser muy talentosos, pero si no te aseguras de que todos siguen las mismas acciones de comunicación, procesos de aprobación y updates de avances en una secuencia predecible, los malos entendidos y los retrasos por falta de actualización de tareas son prácticamente inevitables.
5.- Manejo de problemas y contingencias
¿Cuándo un colaborador debe recurrir a la biblioteca de FAQ´s y recursos para resolver un problema, y cuando necesita comunicarlo directamente a tu líder de proyecto?, ¿a quién deben recurrir si observan una violación de seguridad en un horario no síncrono con el resto del equipo?, ¿qué hacer si hay un bloqueo DNS en el servidor, actualizar la IP o reportar el incidente?
Estar preparados ante lo inesperado es especialmente necesario en contextos de trabajo remoto en los que no podemos sencillamente pararnos de nuestro escritorio y escalar la situación con un superior.
6.- Evaluación de rendimiento
Ya sea que tu equipo trabaje por horas, por objetivos o en un esquema mixto, el desempeño real no necesariamente equivale a la cantidad de tiempo que pasaron programando o al número de entregables que subieron, sino que se relaciona más con la eficiencia, con la calidad del código y con evitar errores.
Tus devs necesitan tener claro cómo vas a evaluar su desempeño y cómo vas a monitorear su trabajo. Por ejemplo, un time tracker puede indicarte que un programador alcanzó la misma productividad que otro durante la semana, pero tuvo que invertir un 30% más de tiempo en ello, lo que significa que, aunque los resultados fueron similares, el desempeño fue menor.
7.- Clima laboral
Finalmente, tu política de trabajo remoto también tiene que abordar temas relacionados con la cultura organizacional en proyectos de desarrollo de software, como la imagen que dan al representar a la compañía, la tolerancia, el respeto, las formas de comunicación que no son aceptables y si las actividades de team building se consideran obligatorias, deseables u opcionales.
Una vez que tienes cubiertos estos aspectos globales, el siguiente paso es revisar tu borrador con todas las áreas de la compañía que se van a relacionar con el equipo de desarrollo remoto, por ejemplo IT y Recursos Humanos, integrar los puntos que hayas podido pasar por alto y finalmente desglosar la información de manera muy detallada para llegar a la versión actual de tu política de trabajo remoto.
Recuerda que este documento debe ser firmado por todos tus devs durante el proceso de onboarding, y que puede haber cambios en respuesta a las necesidades de la compañía, pero siempre deben ser notificados con antelación y se deben recabar las evidencias de conformidad de todos los miembros de tu equipo.
Mientras terminas de perfeccionar la política de trabajo remoto que necesita tu compañía para seguir escalando su productividad, ¿te parece si vamos buscando a los mejores candidatos para tu dream team de programadores remotos? En Workana tenemos uno de los pools más importantes de devs altamente calificados en Latam, y te ofrecemos una prueba única de 7 días sin riesgo para que compruebes la gran calidad de su trabajo. ¡Empecemos!
—
También te puede interesar:
