Por qué son importantes los equipos distribuidos y cómo crear uno

“Suponga que está solo en una startup y quiere un socio. Te llevaría mucho tiempo encontrar pareja, ¿verdad? Sería la mitad de tu empresa. ¿Por qué debería tomar menos tiempo para encontrar un tercio de su empresa o un cuarto de su empresa o una quinta parte de su empresa? Cuando estás en una startup, las primeras diez personas determinarán si la empresa tiene éxito o no. Cada uno es el 10% de la empresa. Entonces, ¿por qué no tomaría todo el tiempo necesario para encontrar a todos los jugadores A? Si tres no fueran tan buenos, ¿por qué querrías una empresa en la que el 30 % de tu gente no fuera tan bueno?”. —Steve Jobs

En 2003, el autor Michael Lewis publicó un libro llamado Moneyball: The Art of Winning an Unfair Game. A primera vista, el libro es una historia clásica de desvalidos: un equipo de béisbol en apuros se da cuenta de que los cazatalentos que confían en la sabiduría de décadas están perdiendo oportunidades para formar equipos ganadores. Al evolucionar sus tácticas de exploración para incorporar herramientas y prácticas modernas, el equipo identifica y contrata una lista de jugadores subestimados, logrando un récord ganador contra oponentes con nóminas mucho más grandes.

La verdadera lección de Moneyball es clara: ya sea que sea una corporación importante o un advenedizo rudimentario que busca una ventaja sobre un titular que puede gastar más que usted, tiene la oportunidad de adaptar sus tácticas y contratar reservas sin explotar de talento de alta calidad al reconocer cuando la sabiduría convencional sobre la formación de equipos ya no refleja la realidad.

Las empresas juegan Moneyball mediante el uso de equipos distribuidos

Desde nuestro punto de vista, existe una clara oportunidad para que las organizaciones jueguen “moneyball” en su búsqueda de talento de alto retorno de la inversión: capacite a su equipo para contratar empleados remotos.

Más del 43% de los trabajadores estadounidenses trabajaron a distancia el año pasado, un aumento sustancial del 9% que dijo lo mismo en 1995.

En 2016, la firma de compromiso de los empleados TinyPulse realizó una encuesta a más de 500 empleados remotos y descubrió que eran más felices, se sentían más valorados y eran abrumadoramente más productivos que sus compañeros en el lugar. Más del 43 % de los trabajadores de EE. UU. teletrabajaron el año pasado, un aumento sustancial del 9 % que dijo lo mismo en 1995. En conjunto, las empresas que permiten el trabajo remoto han demostrado un menor estrés, una mayor eficiencia y una menor rotación en su fuerza laboral.

Adaptar su organización para acomodar equipos distribuidos no es tarea fácil. Pero, desde nuestro punto de vista, mantener el statu quo presenta un riesgo aún mayor. Creemos que las empresas que se resisten al paso a lo remoto son como los buscadores de talentos de la vieja escuela: están haciendo un excelente trabajo siguiendo los buenos consejos de hace veinte años. Por otro lado, las organizaciones que adoptan el trabajo remoto están jugando al dinero: todos seguirán su ejemplo en un futuro cercano, pero por el momento son recompensados ​​con una ventaja competitiva sustancial.

En este artículo, presentamos las objeciones comunes a los equipos distribuidos y compartimos nuestra experiencia al abordar estos obstáculos con cinco recomendaciones que cubren las mejores prácticas en la contratación, la medición de las métricas, la gestión, las herramientas y la cultura correctas.

Inquietudes comunes con los equipos distribuidos

Los ejecutivos experimentados pueden tener un miedo residual a los equipos de desarrollo distribuidos que se deriva de la experiencia en la era temprana de la subcontratación. Los ejecutivos más nuevos pueden verse tentados a confiar en la sabiduría convencional para despedir a los equipos remotos de inmediato. Ambos grupos tienden a citar las siguientes preocupaciones:

• Calidad: Hace casi veinte años, la primera exposición a equipos distribuidos se produjo en el contexto de un modelo de externalización tradicional, impulsado por completo por el ahorro de costes. La colaboración parecía imposible: las herramientas que hoy en día damos por sentadas, como Slack o GitHub, no existían, los intercambios de correo electrónico demoraron días debido a problemas de zona horaria, el ancho de banda era costoso y, por alguna razón, todos se sorprendieron cuando el software creado por el más barato. los desarrolladores que pudimos encontrar resultaron ser pésimos.
• Visibilidad: los gerentes de proyecto odian las sorpresas. Esta es la razón por la que un gerente de fábrica inspecciona la línea de producción con regularidad, o un capataz de construcción se sienta en un escritorio en un remolque en el lugar de trabajo. Por supuesto, no hay muchos casos en los que necesite proximidad física para inspeccionar el progreso en un producto de software o compromiso de servicio profesional, aparte de la proximidad a una buena conexión Wi-Fi o torre móvil, pero la presencia ha conservado su importancia entre los gerentes de todos. clases
• Ortodoxia ágil: vemos muchas empresas considerando o implementando activamente una transformación ágil. Como parte de esa transformación, tienden a buscar orientación para sus ejecutivos en libros, entrenadores y firmas de consultoría Agile. Cuando se trata de formar equipos, estos expertos tienden a decir lo mismo: "Sus equipos deben estar ubicados en el mismo lugar". Este fue un buen consejo hace quince años: en muchos sentidos, Agile fue una reacción a las condiciones anteriores que hacían que la colaboración fuera casi imposible a través de las distancias y hacían necesarias prácticas rígidas de gestión de proyectos en cascada.

Gracias en gran parte a la tecnología mejorada para la colaboración y la comunicación, las condiciones que llevaron a estas preocupaciones ya no existen. Al emplear las cinco mejores prácticas que se describen a continuación, las organizaciones estarán bien equipadas para crear equipos distribuidos de alto rendimiento y maximizar el potencial transformador del trabajo remoto.

1. Contratar para compatibilidad remota

No todo el mundo está hecho para el trabajo remoto. Piense en los rasgos que valora en un desarrollador superior: ingeniería y excelencia técnica, la capacidad de trabajar bien en un entorno de equipo, comunicación abierta y honesta. Evaluar cómo las habilidades blandas en particular se traducirán en un entorno remoto es un desafío, por lo que aquí hay algunas características que debe buscar:

• Proactivo: la proximidad física facilita los controles frecuentes; Salvo ese recurso, las mejores contrataciones son emprendedoras que no necesitan tareas asignadas ni orientación constante para hacer las cosas.
• Implacable en la priorización: los buenos trabajadores remotos tienen un sentido intuitivo de lo que es importante y lo que no lo es en un proyecto determinado, centrándose en lo que importa.
• Habilidades de escritura competentes: la comunicación en equipos remotos generalmente toma forma escrita, lo que hace que las habilidades de escritura sean especialmente cruciales para los equipos remotos.

¿Dónde encuentras a estas superestrellas remotas? Las personas con los atributos anteriores suelen tener experiencia en empresas emergentes o compromisos independientes anteriores que les permiten construir un historial de logros en entornos no estructurados.

2. Para administrar equipos distribuidos, cree un Sandbox

Una preocupación frecuente que escuchamos sobre los equipos de desarrollo distribuidos es la dificultad de hacer cumplir las normas del equipo, los estándares y prácticas de codificación y los procesos de gestión de proyectos. En nuestra experiencia, los equipos productivos están empoderados y se autogobiernan, con mucha libertad para establecer estándares por sí mismos.

Los equipos remotos no son una excepción, pero la gerencia debe tener especial cuidado para garantizar que se implementen los controles. Como principio general para la gestión de equipos distribuidos, nos gusta usar la analogía de una caja de arena. Los bordes de la caja representan límites para el equipo: restricciones acordadas como ceremonias de sprint, herramientas y marcos que se utilizarán, expectativas de cobertura de código, etc.

En otras palabras, el marco y los procesos para la colaboración deben estar firmemente definidos, pero el desarrollo de software es tanto un arte como una ciencia, por lo que es importante que los empleados remotos tengan la libertad de ser creativos dentro de la zona de pruebas.

3. Capacite a los gerentes para realizar un seguimiento de los resultados, no de la producción

Conscientemente o no, algunos gerentes miden la productividad por la cantidad de horas que pasan en un escritorio en comparación con los resultados de ese trabajo. Pero un desarrollador que genera miles de líneas de código mediocre no debe considerarse más productivo que uno que genera unos pocos cientos de líneas de código excelente en el mismo período de tiempo.

Para los equipos remotos en particular, es crucial que las métricas de productividad midan la calidad de los resultados en lugar de la mera producción: ¿Cuánto software bueno enviamos el mes pasado? ¿Nuestra velocidad de desarrollo es estable, predecible y se acelera con el tiempo? ¿El equipo está demostrando una mejora continua? Los equipos remotos deben evaluarse con las métricas correctas, ya que los gerentes tienen menos visibilidad del proceso de hacer el trabajo en sí y no hay forma de otorgar crédito parcial al observar a sus empleados "mostrando el trabajo".

4. Usa las herramientas adecuadas

Las herramientas son la razón principal por la que el trabajo remoto está prosperando en la actualidad. Las aplicaciones modernas de comunicación y colaboración son el andamio que ayuda a los equipos distribuidos a abordar los escollos de épocas anteriores. Nos gusta decir que cuando las personas usan Slack, están en la oficina. Esta es nuestra lista de herramientas esenciales:

• Chat en tiempo real: el chat en tiempo real es una herramienta vital para un equipo remoto. Desea poder replicar la interacción y colaboración inmediatas que tendría en un equipo coubicado. El chat en tiempo real no solo es esencial para la comunicación, sino que también es útil para construir una cultura remota. Para que esto tenga éxito, es vital que toda la comunicación del equipo esté centralizada en un solo lugar; recuerde, el espacio aislado necesita paredes. En Toptal, usamos Slack, pero las alternativas incluyen HipChat, Flowdock y Skype.
• Radiadores de información: sin interacciones en persona para socializar la información, necesitará un wiki en línea y un muro de historias para irradiar información al equipo. En el desarrollo Agile o Kanban, todo el equipo y todas las partes interesadas asociadas deben tener acceso a información inmediata sobre el estado del desarrollo: historias en curso, en espera de pruebas, defectos, etc. El equipo también debe tener acceso a paneles para la canalización de compilación y estado, cobertura de código y otros datos clave. Como administrador remoto, desea una única fuente de información para cada área de información en la que confían el equipo y las partes interesadas para conocer el estado.
• Videoconferencias: el chat de video en tiempo real es un complemento esencial para la mensajería instantánea; según nuestra experiencia, no hay nada como hablar con otro ser humano. En Toptal, usamos Zoom, llamadas de Slack y ocasionalmente Skype para reuniones individuales, reuniones de estado y exhibiciones de códigos. Las reuniones diarias de Scrum a través de videoconferencias son una excelente manera de desarrollar la cultura y la confianza del equipo.

5. Ceremonias de Abrazo

Probablemente tenga varias ceremonias de equipo en puntos fijos de cada sprint: reuniones de planificación y estimación, revisión de código, demostraciones de software. Programe estos de tal manera que todos los miembros del equipo, independientemente de su ubicación, puedan participar. Idealmente, el equipo tendrá varias horas al día en las que todos estén en línea y trabajando.

Si bien es natural preocuparse por las zonas horarias al crear equipos distribuidos, según nuestra experiencia, una pluralidad de personas que han elegido carreras en desarrollo de software remoto prefieren trabajar fuera del horario laboral tradicional de 9 a 5 y, a menudo, son mucho más productivas cuando se les permite. para hacerlo En la medida de lo posible, permita que el equipo defina los tiempos que mejor funcionan para ellos.

Conclusión: es posible que ya confíe en los equipos distribuidos

Incluso si su organización no ha utilizado directamente un modelo de desarrollo distribuido, probablemente esté aprovechando sus beneficios en un grado significativo: lo más probable es que esté utilizando software de código abierto.

Por su propia naturaleza, el desarrollo de código abierto se ha distribuido desde el principio. La innovación en el mundo del código abierto ocurre a un ritmo asombroso, y las prácticas de ingeniería en evolución ayudan a impulsar ese ritmo: uno de los primeros desafíos que resolvieron los primeros proyectos de código abierto fue la colaboración en línea y la transparencia del proceso para los equipos distribuidos.

Ya sea que esté siguiendo el ejemplo del mundo del código abierto o siguiendo el ejemplo de Michael Lewis para jugar "moneyball" en el mundo impulsado por el talento del desarrollo de software y los servicios profesionales, tenga en cuenta las limitaciones que impone a su organización al insistir en que solo puede contratar de grupos de talentos locales.

Un cambio cultural de esta magnitud es una tarea importante, pero puede iniciar la transición de inmediato: dejar de lado la ortodoxia en la oficina, dar la bienvenida a los equipos distribuidos y permitirles alcanzar su potencial proporcionando a los miembros del equipo las métricas, la gestión , herramientas y cultura para hacer el trabajo dondequiera que trabajen.