Estrategias Efectivas para Gestionar Equipos Remotos de Frontend

Hola a todos. Estoy muy emocionado de estar aquí. ¿Cuántos de ustedes han tenido un error de CSS que tomó tres días en arreglar porque la persona que lo escribió está seis veces más lejos y ya está dormida? Sí, por eso estoy aquí. Mi nombre es Martin Mordanov. Y durante más de siete años, he gestionado equipos internacionales de front-end y creado soluciones escalables.

Mi tema de hoy serán las estrategias efectivas para gestionar equipos remotos de front-end. En nuestro camino para crear un equipo remoto de front-end exitoso, necesitamos pasar por tres reglas diferentes. En primer lugar está la sincronización de la cooperación. La cooperación lo es todo. Muchos de ustedes conocen el dolor cuando crean algo y el ingeniero de QA lo devuelve para importarlo de nuevo. Esto se puede evitar muy fácilmente con comunicación, control de versiones y conexión del navegador. Así que daré un ejemplo de mi experiencia.

Mi miembro del equipo crea, por ejemplo, una caja que tiene un radio de borde de seis píxeles. Pero cuando hace el commit, crea pull requests, el QA lo abre y lo revisa. En el navegador Safari, son cuatro píxeles en lugar de seis. Y la tarea se devuelve. Para evitar esto, necesitas tener conversaciones con ellos entre equipos. Por ejemplo, en mis equipos, tenemos hilos de discusión, tenemos un sistema de documentación, tenemos storybook, tenemos archivos readme dentro de los componentes, dentro de diferentes partes de los proyectos. Es muy importante pasar cada regla para crear un proyecto exitoso y pasar todas las reglas. A continuación están los problemas de rendimiento.

No podemos crear un proyecto sin problemas de rendimiento, creo. Los problemas de rendimiento en los equipos de desarrollo front-end, la mayoría de ellos se basan en no probar las APIs en el host local y usar APIs simuladas. Para evitar todo y estos problemas, el desarrollador front-end necesita tener una instancia local del desarrollo back-end y probar las cosas cuántas veces carga, tiempo de respuesta, detalles web principales, muy importantes para la optimización SEO. Así que es muy importante que el desarrollador front-end tenga una configuración local para el back-end, no solo el entorno de desarrollo, en el cual en esta hora, 10 o más desarrolladores hacen solicitudes en él. Necesita estar separado para cada tarea. Y para el final, pero no por prioridad al final, las luchas de alineación. El conocimiento lo es todo. Cuando un nuevo miembro del equipo llega a mis proyectos, le comparto documentación y lo incorporo como hace una semana. Así que es muy importante tener documentación sobre todo. No es como un libro, no te equivoques, pero necesitamos escribir todo lo importante para asegurarnos de que cada desarrollador lo sepa, lo buscará y de esta manera tendremos el proyecto documentado, proyecto exitoso y el producto estará bien.

Así que no pierdan estas tres reglas y les prometo que tendrán una gran oportunidad de crear algo increíble sin volver a lo básico.

Continuamos con el liderazgo basado en la confianza. ¿Qué quiero decir?

Me refiero a esta parte del proyecto que necesita ser medida y tener resultados de ello. Sí, eso no es el código, son los miembros del equipo. La calidad de los miembros del equipo necesita ser medida y mejorada.

En mi experiencia en mi carrera temprana, usé mi antigüedad para hacer muchas reuniones todos los días para preguntarles cuál es el estado de esta tarea, cuál es el progreso de esto. Y usé mucho tiempo, que ellos tienen para desarrollar, para hablar con ellos, hacer preguntas y yo era el cuello de botella. Me di cuenta de ello y lo cambié globalmente.

Los ingenieros junior y de nivel medio hacen las documentaciones y aprenden cosas nuevas sobre las tareas. Les proporcioné creatividad. Entonces, ¿qué cosas aprendí muy rápido? Aprendí muy rápido cuando el miembro del equipo tiene derechos de decisión sobre algo en el proyecto. Todo cambia en su cabeza y la motivación aumenta y mucha productividad se utiliza en el proyecto. Así que recomiendo usar esto. Prometo que funcionará.

Cada miembro del equipo necesita ser una parte insustituible del proyecto y los resultados seguirán adelante. Eliminar malentendidos. ¿Cómo estar seguro cuando tienes tareas y las das al desarrollador? El desarrollador las leerá, comenzará a trabajar, describirá problemas de código antes de eso y la tarea se hará correctamente. Sí, esa es la parte difícil.

Los desarrolladores en nuestros días comienzan la tarea, comienzan el código. Y después de una hora o días, se dan cuenta de que tienen un problema, que es general y pueden enviar la tarea sin solucionarlo. Pero este problema está asignado a otro equipo, por ejemplo, backend, y backend necesita tener una resolución para ello. Esto toma tiempo. El desarrollador se queda atascado. El tiempo se queda atascado. El sprint se queda atascado. El producto casi se queda atascado. Y el negocio se queda atascado. Así que este es un problema muy grande.

El desarrollador necesita leer la tarea antes de comenzar a hacerla y pensar en ella, describir los problemas que tienen o que creen que tienen que hablar con otro desarrollador y después de eso, comenzar a hacer la tarea. Antes de eso, todo es solo pasar el tiempo y no está bien. Si esta tarea tiene un problema, comienza otra tarea. Habla con tu product owner para que te dé algo. Habla con backend. Pero es muy importante que todos los miembros del equipo conozcan este proceso y entrenen este proceso. Esto no es fácil de integrar en tu equipo. Esto necesita tiempo, necesita verificaciones consistentes. Yo reviso a mi equipo, por ejemplo, de dos a cuatro meses, cada uno de ellos, lo que saben del proceso. Y es solo una conversación amistosa, que será mejor para ellos. Así que esta es una parte muy importante de nuestros proyectos y la sincronización entre equipos.

Puertas de calidad automatizadas, pero no solo pipelines, integración continua, despliegue continuo. Hablaremos sobre la configuración local del desarrollador front-end, procesos de commit locales y operaciones de despliegue. Es muy importante saber que cada desarrollador usa la misma configuración local. ¿Qué quiero decir con configuración local? Me refiero a la versión de pre-tier, configuración de pre-tier, actualizaciones dependables, procesos de seguridad, que ejecutan para cada commit. Así que implemento una carpeta .settings en cada proyecto que hago. Y allí creo un JSON de configuración y otro JSON, que son necesarios para las extensiones instaladas en el IDE. Las extensiones son muy flexibles cuando las usas. Uso actualizaciones de pre-tier. Uso ESLint y con Husky, con cada commit de Git, lo ejecuto una y otra vez. Linting del código y verificaciones de las reglas. Así que esto es muy importante y la integración de esto es requerida para cada proyecto.

Porque los desarrolladores pueden instalar, por ejemplo, una extensión que puede formatear el código de manera diferente a otros desarrolladores. Y cuando se crea una pull request, los conflictos de merge están garantizados. Necesitas evitar esto. Así que el pipeline de esenciales locales se integra con éxito. Después de eso, revisas esto y tienes un pipeline. Cuando haces merge, ejecutas estas cosas una y otra vez. Y después de eso, verificas la build. El tiempo de vida del PR se reduce porque no tienes reuniones con el desarrollador.

Por qué usas este factor de preformato. Simplemente lees el código y estás seguro de que tus reglas son aceptables y confirmadas y estás listo para el despliegue. Así que continuamos con los entornos de previsualización. Y para ser honesto, hablamos sobre las corporaciones. Hablamos sobre el proceso. Ahora cómo los desarrolladores compartirán su proceso en la tarea con otro equipo. Sí. La palabra es entorno sandbox o entorno de previsualización. No importa si usas AWS, Vercel o un servidor autohospedado. Puedes crear en cada rama tener una URL de sandbox creada automáticamente cuando algo se fusiona en el entorno de área de desarrollo. Así que una parte muy importante de esto es que esta URL se proporcione al equipo de creación, al equipo de diseño. Los miembros del equipo de diseño necesitan verificar que esta interacción, que está, por ejemplo, en un archivo proporcionado por Figma, Sketch o XD, sea correcta en el entorno sandbox.

Cuando todo está confirmado, estamos listos para el despliegue y estamos seguros de que las corporaciones de cada miembro del equipo son aceptadas y aprobadas y la cosa se envía con éxito. Registro de zona horaria o cómo identificar y proteger los poderes generales entre equipos con diferentes zonas horarias y diferentes países. Necesitas captar estas horas y hacer reuniones, reuniones requeridas para ellos. Reuniones de todos, planificaciones de sprint, planificaciones de cooperación. Así que, sí, sabes a lo que me refiero. Usar estas horas y el equipo para hablar y cooperar con otros equipos. Estos equipos, que están en diferentes horarios, necesitan sentirse en el equipo, en el equipo interno sin este problema de horario. Porque se sienten aislados si no los invitas a las reuniones requeridas. Así que es muy importante identificar estas horas para crear reuniones recurrentes y hacerlas una parte muy importante de todo el equipo. No aislados.

En mi experiencia, mido esto con diferentes métricas porque los diferentes países, no tienen días laborables. Tenemos días laborables en otro país. Se superponen. Creo que las cosas al inicio de cada año, para estar seguro, en este año, creé todas las cosas y el equipo está feliz. El equipo es una parte muy importante de nuestro proyecto y creo que el equipo es el verdadero valor, no el proyecto. Necesitamos asegurarnos de que nuestro equipo no se queme, ¿verdad? Así que hablemos de esto. Esta es una parte muy importante de nuestra presentación y de nuestro trabajo, por supuesto, porque necesitamos asegurarnos de que los miembros de nuestro equipo obtengan suficiente trabajo para el sprint. No tendrán presión, no tendrán bloqueos y se sentirán bien.

Tengo muchos bloqueos. No hago mi trabajo muy bien. Así que esta es una parte muy importante, las personas. El agotamiento es el proceso en el que las personas piensan y sobrepasan algunas métricas. El tiempo que necesita ser para esta tarea y la fecha de finalización, por supuesto. Esto les genera presión y no se sienten bien. Así que necesitas, como líder, asegurarte de que las tareas comiencen, qué preguntas tienen.

Necesitas contactarlos, por ejemplo, dos veces a la semana, pero en el chat, no es necesario crear una reunión, solo para que se sientan bien y no invertir tiempo en esto. El desarrollador necesita tomar decisiones por sí mismo, no tú, para hablar y mostrar cómo se deben hacer las cosas en esta tarea. Porque no los ayudas de esta manera. No pueden hacer esto sin ti. Necesitas hacer las cosas sin ti.

Tú solo serás el asistente y el liderazgo del proyecto. Implemento los viernes sin reuniones, como dije. Pueden concentrarse en todo. Pueden invertir tiempo en sus habilidades técnicas.

Estoy bien con esto. La empresa está bien con esto. Todos están felices. En nuestras reuniones diarias, que anteriormente eran todos los días, ahora las reemplazamos por dos veces a la semana. ¿Por qué dos veces? Porque tenemos actualizaciones escritas en toda la documentación, en todos los paneles de discusión en Teams. No necesitamos hablar todos los días sobre nuestras actividades diarias, porque el equipo sabe qué hacer. Esto es mucho tiempo que pueden usar para ellos mismos.

Por último, pero no menos importante, por supuesto, la cooperación entre ellos. Cuando asignas tiempo para cada tarea, se sienten bien. Se sienten cómodos, y esto aumenta la productividad y los entregables de tu proyecto. Resumamos todas las cosas de las que hablamos en esta presentación. Primero, la documentación, por supuesto. Asegúrate de tener una documentación bien mantenida. Tu equipo la actualiza. Estás bien con esto, y el equipo está contribuyendo al bienestar con esto.

Asegúrate de tener calidad de código automatizada, no solo en la pipeline para el punto. Asegúrate de que los desarrolladores tengan instalados los elementos esenciales locales. Procesos de Linkedin, dependencias de prettier, reglas para cada uno de ellos. Y una gran cosa, cada desarrollador usa una misma configuración de front-end, y puedes actualizarla de forma remota. Solo necesitas hacer push a la rama. Y por último, el bienestar del equipo. Piensa en las culturas del equipo, actividades del equipo, soluciones del equipo, compromisos del equipo, y cómo hacer un área más feliz en tu equipo, y cuáles son los problemas en tu equipo. Identifícalos, habla con tus desarrolladores. No seas tímido porque, ya sabes, el tiempo se revisa todos los días, y necesitas ser más creativo y creativo, porque con esta creatividad y soluciones, tu equipo remoto de front-end será feliz, y los resultados serán buenos para el negocio y buenos para todas las personas.