Cómo no administrar su equipo remoto de desarrolladores

Como desarrollador y propietario de una pequeña empresa, obtuve información de ambos lados, trabajé como desarrollador remoto y administré desarrolladores remotos para diferentes proyectos y con diferentes equipos.

En esta publicación, compartiré algunas de mis experiencias con la esperanza de que haga la vida un poco más fácil para todas las partes en proyectos remotos. Cuando se trata de lo que se debe y no se debe hacer en la administración remota de equipos, tiendo a centrarme en lo que no se debe hacer, porque a diferencia de lo que se debe hacer, tienden a aplicarse a prácticamente todos los equipos.

Al ingresar al mundo de los desarrolladores remotos, el mayor obstáculo que deben superar los gerentes es cambiar su mentalidad aceptando que el desarrollador no estará a la vista, y donde pueden administrar y seguir el trabajo que se está realizando. Este nuevo paradigma requiere que las empresas implementen una serie de mecanismos para realizar un seguimiento del progreso y evitar una carga de trabajo redundante. Dichos mecanismos ayudarán tanto al administrador como al desarrollador a ser más productivos, lo que redunda en beneficio de todos.

Para que quede claro, todos estos mecanismos no deben utilizarse para controlar o microgestionar al empleado.

No crea en los mitos y conceptos erróneos del equipo remoto

Echemos un vistazo a las ventajas y desventajas de administrar equipos remotos en un solo proyecto, comenzando con la comunicación.

Los negocios se han globalizado y la llegada de grandes organizaciones multinacionales ha creado nuevos desafíos para millones de profesionales en todo el mundo. La naturaleza compleja y entrelazada de los equipos globales exige un enfoque más completo y reflexivo de la comunicación interna.

En tales organizaciones y equipos, muchas personas no pueden darse el lujo de trabajar en un entorno familiar o hablar su idioma nativo. Los equipos que trabajan en el mismo proyecto pueden estar separados por océanos, en lugar de oficinas y cubículos. Los miembros del equipo provienen de diferentes culturas y trabajan en todo el mundo.

Estos profesionales no deberían tener que preocuparse por la comunicación, pero deben poder cooperar con los miembros del equipo multinacional. Todas las partes deben ser proactivas. La cultura corporativa debe reflejar este paradigma y ayudar a fomentar un entorno productivo en el que los equipos remotos y multiculturales puedan prosperar.

Nuestro propio Scott Ritter rompió los cinco mitos principales sobre los equipos remotos en una publicación de blog reciente, que puede resultarle útil si está interesado en el tema. El CEO de Toptal, Taso Du Val, también explicó cómo funciona nuestra red y cómo avanzamos para crear la mejor cultura de equipo remoto.

No se olvide de abrazar y fomentar la diversidad

El primer paso hacia una estrategia sólida de comunicación de equipos remotos comienza con el reconocimiento de que los equipos multiculturales trascienden las fronteras nacionales y culturales, colocándolos en una posición única para ofrecer conocimientos difíciles de lograr con equipos centralizados y monolíticos.

Pero no te preocupes; ¡La diversidad es buena para los negocios!

Según una encuesta realizada por The Economist Intelligence Unit , los equipos multiculturales son los preferidos por las grandes organizaciones; muchos ejecutivos creen que ayudan a fomentar la innovación debido a su conocimiento más amplio de las tendencias globales. Además, es menos probable que sufran de una mentalidad de "pensamiento grupal"; su diversidad les ayuda a abordar los problemas desde diferentes perspectivas, produciendo así una mejor gama de soluciones adaptadas a regiones y mercados específicos.

Se puede argumentar que la gestión de empleados remotos puede ser más productiva en virtud de no estar en el mismo lugar. Puede parecer contradictorio, pero estos equipos remotos simplemente pasan menos tiempo charlando, socializando y discutiendo asuntos triviales.

Si bien la separación física puede conducir a una mayor productividad, también puede generar malentendidos, tensión, alienación y mayor estrés y ansiedad. En consecuencia, se hace necesario mitigar estos efectos secundarios negativos con iniciativas que fomenten el positivismo y la colaboración a nivel personal. Mejorar la comunicación en equipos remotos puede ser una tarea abrumadora, y crear vínculos personales entre los miembros del equipo tiende a ser un desafío. Por eso es necesario un toque humano.

Encontrar algo que pueda mejorar el compromiso, independientemente de los antecedentes, es una forma relativamente sencilla de impulsar la moral y la cooperación. Este esfuerzo puede tomar muchas formas, según el tamaño y la composición de sus equipos. Idealmente, debe centrarse en una actividad tranquila y sin estrés que los miembros del equipo disfruten, desde competencias relacionadas con el trabajo, proyectos de entretenimiento o discusiones que no están relacionadas con el trabajo.

Participar en tales actividades, a expensas de la organización, puede sonar como una asignación menos que ideal de recursos financieros y humanos, pero tenga en cuenta que reunir a los equipos en torno a una causa común generalmente conduce a un mejor ambiente de trabajo, vínculos personales más fuertes y una mayor productividad. .

No se tome a la ligera el reclutamiento y la capacitación

Para aprovechar al máximo la gestión de equipos remotos, debe tener en cuenta las diferencias culturales y compensar con la capacitación adecuada.

Mejorar las habilidades lingüísticas es solo una pieza del rompecabezas, ya que las habilidades de comunicación se ven afectadas por las diferencias culturales. Comienza con buenas políticas de contratación que favorezcan a las personas, especialmente a aquellas que ocuparán puestos directivos, preparadas para trabajar en entornos multinacionales. La experiencia en proyectos remotos obviamente es útil, pero no debería ser un requisito previo. El hecho de que un desarrollador remoto no esté en su oficina todas las semanas no significa que el reclutamiento no deba tener en cuenta los rasgos personales. Usted y su equipo aún tendrán que comunicarse con los desarrolladores remotos de manera regular, así que hágales las mismas preguntas que le haría a cualquier trabajador en el sitio, remoto o no, todavía tienen que encajar.

Si bien es posible abordar algunos problemas con capacitación adicional, puede que no siempre sea práctico, pero en cualquier caso, una buena capacitación es el siguiente paso lógico. La capacitación debe desarrollar los rasgos positivos existentes y, al mismo tiempo, mitigar las deficiencias y abordar los puntos débiles previamente identificados.

Los gerentes que se ocupan de equipos remotos tienen que asumir rutinariamente nuevos roles con poco tiempo de anticipación, hacerse cargo de proyectos con los que no están necesariamente familiarizados y dedicar mucho tiempo a ponerse al día. En tales situaciones, las comunicaciones internas no suelen ocupar un lugar destacado en su lista de prioridades, aunque ahora pueden estar liderando equipos que han pasado años colaborando en uno o más proyectos. El tiempo es un activo valioso, pero también lo es un buen trabajo en equipo; los gerentes deben sacar tiempo de sus apretadas agendas y aprender más sobre sus equipos, los miembros individuales del equipo y los problemas que pueden surgir.

La distancia emocional entre los gerentes remotos y sus subordinados también puede plantear un problema, ya que los miembros del equipo pueden ser reacios a confrontar a los nuevos líderes de equipo, o incluso acercarse a ellos en entornos formales o informales. Un buen gerente de empleados remotos debe reconocer esto e insistir en un compromiso más personal; como dije, "sea proactivo". – ¿De qué sirve tener un equipo de desarrolladores remotos talentosos si no comparten sus pensamientos contigo?

No use un sistema de información complicado

No pierda la oportunidad de implementar un sistema de información efectivo que incluya un sistema de gestión de código fuente (SCM), un rastreador de problemas (no demasiado complicado, por favor) y posiblemente algunas páginas Wiki donde todas las partes puedan documentar cosas o esbozar ideas y propuestas. Todas estas herramientas de colaboración harán que la gestión de desarrollo y lanzamiento sea mucho más fácil de lograr.

Es importante mantener las cosas lo más simples posible aquí, porque este sistema de información se utilizará diariamente/cada hora. Si resulta demasiado complicado, tomará tiempo que se debe utilizar en la implementación y/o diseño. Es posible que también sea necesario simplificar el proceso para los nuevos miembros del equipo y los autónomos que no tienen tiempo para conocer los entresijos de las políticas de una organización.

Mi aplicación de gestión de proyectos favorita desde hace mucho tiempo es Redmine, un sistema de código abierto, multiplataforma y multibase de datos. Esta plataforma es altamente configurable y puede integrar su propio SCM, diferentes complementos y ganchos de servicio.

Si no quiere pasar por la molestia de mantener su propio servidor con Ruby y configurar todo usted mismo (Redmine puede ser complicado para los administradores de sistemas sin experiencia), otra buena opción es GitHub, que presenta no solo el CMS de git sino también problemas de GitHub. , que se integra bien con sus mensajes de confirmación, solicitudes de extracción, etc.

Una vez que tenemos nuestro sistema de información configurado y listo, podemos comenzar a integrar nuestro desarrollador remoto en nuestro proyecto.

No microgestiones

Muchos gerentes tienen dificultades para dejar de lado sus responsabilidades, especialmente si ellos mismos provienen de un entorno de desarrollo. En lugar de centrarse en comunicar los problemas y los objetivos del proyecto, encuentran soluciones para esos problemas y brindan detalles de implementación, por lo que el único trabajo que le queda al desarrollador es codificar lo que se le ha dicho que codifique. Esta no es una buena práctica cuando se gestionan empleados remotos.

Por un lado, los gerentes pierden demasiado tiempo en cosas para las que contrataron al desarrollador remoto. Los desarrolladores pueden estar insatisfechos con esta situación, ya sea porque se sienten infravalorados y sin la oportunidad de ser creativos e innovadores, o simplemente para demostrar su valía. Después de todo, la resolución de problemas es exactamente lo que los desarrolladores estudian durante años, por lo que sacarlo de la ecuación y convertir a los desarrolladores en autómatas no tiene sentido.

Como todo en la vida, se trata de encontrar un buen equilibrio.

No se preocupe por las zonas horarias, utilícelas a su favor

Los buenos desarrolladores remotos tienden a ser autosuficientes e independientes por naturaleza; necesitan libertad y responsabilidad para organizar su tiempo. La superposición de horas de trabajo es útil, aunque no obligatoria, cuando tiene un buen sistema de información y una buena comunicación con sus desarrolladores.

Trabajar en diferentes zonas horarias puede ser beneficioso para la empresa, ya que puede lograr una eficiencia "las 24 horas del día" cuando los desarrolladores en diferentes zonas se hacen cargo de varios aspectos del proyecto. Si su desarrollador se adelanta a su zona horaria, le da la oportunidad de revisar su trabajo el mismo día y puede evaluar y coordinar de inmediato el próximo gran paso. Por otro lado, si estás por delante de tu zona de desarrolladores, esto te da la oportunidad de preparar todo lo que el desarrollador necesita para completar la tarea.

Recuerde, un buen gerente no es más que un servicio para sus empleados, permitiéndoles hacer el trabajo, ¡no al revés!

No fuerce las metas del día a día, concéntrese en las metas a mediano o largo plazo

Los objetivos del día a día son una forma de microgestión del proyecto. En su lugar, intente comunicar el panorama general a su desarrollador y, juntos, establezcan prioridades claramente definidas. Si logra que el desarrollador comprenda el proyecto tan bien como usted, es probable que el desarrollador sea más útil.

Por ejemplo, el desarrollador puede tener información sobre las tecnologías más nuevas o detalles de implementación que afectan la priorización de diferentes tareas o la determinación del Producto Mínimo Valioso (MVP). Ambos deben definir objetivos e hitos claros, y realizar el trabajo paso a paso. Es su responsabilidad asegurarse de que todos estos hitos encajen en el panorama general.

En mi opinión, el manifiesto Agile (metodologías) es lo mejor que ha sucedido en la gestión de proyectos en los últimos años.

Le permite hacer exactamente lo que se necesita, delegar la responsabilidad a quienes realmente implementan las cosas y forzar el sentido común en todas las partes involucradas en el proceso. Usted define sus objetivos y tareas a mediano y largo plazo con algunas estimaciones de dificultad de alto nivel, y en esas reuniones de planificación de sprint semanales (o quincenales), permite que el desarrollador determine la carga de trabajo exacta y la dificultad para completar esas tareas.

Como todo lo bueno, se necesita tiempo para construir buenos equipos ágiles. No espere tener un equipo de trabajo dentro de tres meses. Agile tiene que ver con aprender haciendo y crecer juntos como equipo.

No ocultes los detalles de la empresa

Bueno, este es complicado. Algunos proyectos son sensibles por naturaleza y la filtración de información puede ser dañina. Los acuerdos de confidencialidad (NDA) pueden abordar el problema, pero no son a prueba de balas.

Sin embargo, cuanto más sabe el desarrollador, más efectivo puede ser, no solo para resolver tareas predefinidas, sino también para resolver, sobre la marcha, todos estos pequeños problemas e inconvenientes molestos. Al final, esto hará que el desarrollador sea más productivo y te facilitará la vida.

El proceso de desarrollo Agile también es útil aquí. Permite el intercambio de conocimientos entre las partes (parte interesada, evaluador, desarrollador, etc.) eliminando cualquier jerarquía y considerando a esas partes como miembros iguales del equipo, con las mismas responsabilidades, y animándolos así a trabajar de la manera más transparente posible. Otro beneficio de la transparencia es que los problemas se “escalan” rápidamente y cualquier parte del equipo puede detectarlos.

No ignore a los miembros remotos del equipo

Recuerde, cuando administra trabajadores remotos, usted es un servicio para su equipo, y si el equipo necesita su aporte, no debe estar demasiado ocupado para brindarles asistencia. Si el desarrollador no puede resolver algo por sí mismo, se atascará y perderá un tiempo valioso.

Como desarrollador, por lo general, cuando me topé con un callejón sin salida, recurrí a mi SO en busca de consejo, además, traté de ofrecer consejos también. No ignore por completo el consejo del desarrollador, ya que podría ser revelador o podría resolver un problema del que ni siquiera estaba al tanto.

Si algo no está claro, o si cree que no es necesario abordar el problema, discuta su posición mientras mantiene la mente abierta y permita que el desarrollador tenga la oportunidad de convencerlo de que, después de todo, tiene razón.

Nuevamente, esto desarrollará habilidades de comunicación y mejorará la confianza.

Consejos rápidos para la gestión remota de equipos

Dado que ya he resumido los puntos principales en tweets e ilustraciones, aquí hay algunos consejos y pensamientos más rápidos.

• Estas reglas generales se pueden aplicar a desarrolladores remotos y en el sitio.
• Si microgestionas, perderás la oportunidad de aprender y dejar aprender.
• Sea de mente abierta y confiable, ya que esta es la única forma de construir un buen equipo remoto.
• Tenga en cuenta que una estimación es solo una estimación; encontrará subestimaciones y sobreestimaciones.
• Todos los que trabajan cometen errores, y si no perdonas los errores de los demás, los tuyos tampoco serán perdonados.
• Lo que es más importante, la mayor motivación para cualquier desarrollador (además de la satisfacción de realizar una tarea difícil) es el dinero. Por lo tanto, no demore los pagos y considere instituir políticas de bonificación también.